| Internet-Draft | Earned Authority: Interim Validation | October 2026 |
| Das | Expires 4 April 2027 | [Page] |
Authority to cause a real-world effect should not be granted for a whole session; it should be earned, one bounded step at a time, from the real path itself. This document specifies an experimental architecture for controlling consequential external effects produced by agentic, autonomous, and conventional computing systems, and is addressed in particular to operators of AI machines and to frontier AI model providers. It separates a proposed act from authority to make that act effective, permits a real bounded effect to occur, obtains protected evidence of what actually occurred, independently evaluates that evidence in an Interim Effectuation Validator (IEV), and makes a later effect technically dependent on a protected continuation condition. The validator does not relay the original command, and if trustworthy evidence is missing the system holds or quarantines the act instead of retrying it. The architecture supports single-phase, two-phase, and multi-phase operation; human, automatic, and hybrid escalation; crash and indeterminate-state reconciliation; validator-integrity hardening; conflicting-evidence handling; effectuation-time revocation; taint and provenance propagation; privilege-separated credential surrogation; and software, hardware, virtual-machine, operating-system, destination-native, quorum, and tokenless realizations.¶
The document defines an abstract protocol and conformance model rather than one mandatory transport or serialization. It also specifies implementation-invariance rules so that changing component placement, token representation, operating system, proxy topology, validator location, or credential representation does not by itself change the functional sequence when the required security properties are preserved.¶
Patent pending: the concept described in this document is the subject of Indian Patent Office application number 202631117633, "Systems and Methods for Cryptographically Staged Effectuation with Verified Partial Effect, Receipt-Bound Full Effectuation, and Software-Hardware Enforcement".¶
This note is to be removed before publishing as an RFC.¶
This is an individual Internet-Draft intended for technical review. It does not state or imply IETF consensus, adoption, implementation status, patent scope, infringement, ownership, or legal priority.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Agentic systems increasingly cross a boundary between computation and consequence. A model can propose a SEND operation, payment, API call, database mutation, network change, software deployment, physical command, or credential use, but the computation that produced the proposal is not necessarily the authority that should make the resulting effect real.¶
A conventional authorization design often evaluates a request once and then permits the entire requested consequence. This document describes an alternative in which authority can be staged. A first real effect may be deliberately bounded. Evidence of that effect is then validated independently before a later or broader effect becomes technically possible.¶
Candidate Act
|
v
Protected Validation / Phase-0 Authority
|
v
Finality Sink FS[0]
|
v
REAL EFFECT P[0]
|
v
Protected Evidence R[0]
|
v
Interim Effectuation Validator (IEV)
|
v
Protected Continuation Condition Gamma[1]
|
v
Finality Sink FS[1]
|
v
REAL EFFECT P[1]
The IEV is not merely a post-event auditor. In the IEV profile, a required continuation condition is established only after the earlier real effect has been independently evaluated, and the next Finality Sink depends on that condition.¶
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. See [RFC2119] and [RFC8174].¶
Most implementation examples in this document are explicitly non-normative. Normative requirements apply only when an implementation claims conformance to a profile defined in this document.¶
The architecture is applicable to AI agents, deterministic applications, operating systems, cloud controllers, communication systems, payment systems, databases, storage systems, accelerators, vehicles, robots, industrial controllers, telecom systems, radio systems, and other systems capable of causing consequential external or persistent effects.¶
Goal: distinguish proposal or computation from effectuation authority.¶
Goal: permit single-phase effectuation where protected policy allows it.¶
Goal: permit bounded real effectuation before broader effectuation.¶
Goal: bind later authority to protected evidence of an earlier real effect.¶
Goal: support exact, tolerance, range, set-membership, semantic, and predicate-based effect comparison.¶
Goal: preserve fail-closed or fail-limited behavior for unknown, stale, conflicting, replayed, or indeterminate evidence.¶
Goal: support software, hardware, local, remote, distributed, tokenless, state-machine, and destination-native realization.¶
Goal: prevent an implementation detail such as component naming, token format, or validator placement from being mistaken for the architecture itself.¶
Non-goal: define a single universal wire encoding, credential system, policy language, or human-approval interface.¶
Non-goal: treat every operation as requiring staged effectuation. Protected policy can select direct single-phase, staged, or denied paths by consequence class.¶
A proposed operation capable of causing an external, persistent, financial, communicative, informational, storage, network, rendering, model-state, device, or physical consequence.¶
A protected identifier for the Candidate Act, commonly D_A = H(Canon(A)), or an equivalent deterministic act-binding mechanism.¶
The transition by which a proposed operation becomes externally or persistently consequential.¶
A component or protected function positioned at an effect-capable boundary and able to withhold, permit, commit, transmit, actuate, persist, settle, render, decrypt, sign, route, or otherwise make a consequential operation effective.¶
A real but intentionally limited effectuation phase. It is not solely simulation, prediction, preview, or dry-run.¶
Machine-verifiable evidence representing what actually occurred during or after phase P[i].¶
A source of evidence meaningfully connected to the real effect, such as a destination, transaction system, storage engine, protected sensor, network component, device, or trusted observer.¶
A protected decision function that independently evaluates evidence of an earlier real effect before establishing eligibility for a later effect.¶
One possible explicit protected continuation object established after successful IEV validation. A CVI is not required in tokenless realizations.¶
Any technically required condition for phase i+1, including a CVI, key, key share, state bit, transaction state, latch, secure mailbox entry, policy transition, destination-side state, or equivalent mechanism.¶
One or more protected components that evaluate, bind, authorize, or enforce effectuation. The PED may be physically separate, logically separate, distributed, or co-located with the Finality Sink.¶
A state in which a requested remainder or later phase is not yet capable of producing its intended consequential effect.¶
Protected metadata representing relevant trust, provenance, exposure, information-flow, behavioral-risk, or lineage state.¶
A non-authoritative credential reference, placeholder, handle, alias, or session-scoped representation that requires protected boundary resolution before an actual credential can be used.¶
A state in which the system cannot establish whether a required effect, non-effect, receipt, or continuation condition is proven.¶
Index i current completed or observed phase P[i] real effectuation phase i R[i] protected evidence for P[i] X[i] expected effect for phase i O[i] observed effect for phase i FS[i] Finality Sink controlling phase i S_IEV[i] protected IEV state at phase i CVI[i+1] explicit continuation instruction for next phase Gamma[i+1] generic protected continuation condition Envelope_MAX maximum authorized consequence envelope PE, RE policy epoch and revocation epoch Ctr_IEV protected IEV monotonic counter
The architecture assumes that an act-generating component may be buggy, compromised, manipulated by untrusted input, subject to prompt injection, stale, confused about external state, or simply incorrect. It also considers failures or compromise in observers, validators, networks, credentials, destinations, and Finality Sinks.¶
Act substitution after approval or between phases.¶
Destination, recipient, route, resource, device, or sink substitution.¶
Forged, replayed, stale, duplicated, downgraded, or cross-act evidence.¶
Crash or timeout after a real effect but before receipt delivery.¶
Crash after continuation issuance but before Finality-Sink consumption.¶
Blind retry of an operation whose prior outcome is unknown.¶
Alternate effect-capable path that bypasses the protected continuation condition.¶
Validator unavailability, rollback, stale state, key compromise, false PASS, duplicate issuance, or internal inconsistency.¶
Two or more individually authentic evidence objects that are mutually inconsistent.¶
Policy, risk, taint, destination, human authority, or revocation change after IEV PASS but before the next effect becomes real.¶
Credential theft or leakage from an act-generating process.¶
Cross-tool taint propagation and provenance loss.¶
Produces or transports a proposed operation. It can be an AI agent, application, OS, workflow engine, human-operated application, controller, or other computational source. Generating a Candidate Act does not itself make the source authoritative.¶
Controls the actual effect-capable boundary. A Finality Sink can be a network proxy, API gateway, database engine, payment gateway, storage controller, kernel boundary, device driver, secure monitor, actuator controller, DPU, SmartNIC, GPU controller, telecom gateway, radio controller, remote destination, or equivalent component.¶
Reports protected evidence about what actually occurred. The observer and sink can be the same component or separate components.¶
Authenticates, binds, compares, evaluates, and decides whether earlier real-effect evidence satisfies required continuation predicates.¶
Profiles make explicit which properties are required for a deployment claiming a particular level of behavior. A deployment can implement more than one profile.¶
A single protected effectuation phase is permitted after protected validation. The Candidate Act remains distinct from final effectuation authority.¶
At least one real bounded effect occurs before a broader effect, and accepted evidence of the bounded effect is technically relevant to broader continuation.¶
EF-STAGED plus an IEV decision function that independently evaluates earlier real-effect evidence and establishes Gamma[i+1] before FS[i+1] permits the next phase.¶
EF-IEV plus validator-integrity checks, conflicting-evidence handling, replay protection, effectuation-time policy/revocation revalidation, and defined indeterminate-state behavior.¶
EF-IEV or EF-HARDENED plus protected taint/provenance evaluation and protected credential resolution or equivalent late-binding authority at an effectuation boundary.¶
Any applicable profile plus closure of act-equivalent alternate paths so that a required protected condition cannot be avoided through another API, credential, device path, debug path, network path, or equivalent route.¶
An implementation claiming EF-IEV conformance satisfies the following functional requirements. These requirements intentionally describe properties rather than product topology.¶
Candidate Act or authorized act class is distinguishable from the actual consequential effect.¶
At least one phase preceding a gated subsequent phase produces a real effect or protected predecessor state, not solely a simulation or model prediction.¶
Protected evidence for the preceding phase is obtained from a source or mechanism meaningfully connected to that phase.¶
The evidence is authenticated, integrity-protected, or otherwise made machine-verifiable to the degree required by policy.¶
The IEV decision function is not arbitrarily writable by the Candidate Act Source.¶
The IEV validates act/phase binding, freshness, replay state, relevant sink/destination/resource bindings, effect acceptability, and current protected policy predicates applicable to the deployment.¶
On successful validation, the IEV establishes or causes establishment of Gamma[i+1]. Receipt existence by itself is not sufficient.¶
FS[i+1] verifies or consumes Gamma[i+1] before making P[i+1] effective.¶
If a mandatory predicate is false, the ordinary next phase remains non-effective.¶
If a mandatory predicate is unknown or indeterminate, the deployment applies its defined reconciliation, safe-state, fail-limited, or escalation policy rather than silently treating the predicate as satisfied.¶
Consumed evidence and one-time continuation state are protected against replay or duplicate use.¶
No phase is permitted to expand authority beyond Envelope_MAX merely because earlier phases succeeded.¶
Where exact binding is required, a Candidate Act can be canonicalized and hashed. Canonicalization is one mechanism; a deterministic typed representation, transaction identifier, protected object identity, or equivalent binding can be used instead.¶
A_C = Canon(A) D_A = H(A_C) Authority(A) !=> Authority(B) where B is a materially different unauthorized act.
An authorized maximum envelope limits progression. Successful receipts do not implicitly enlarge that envelope.¶
Scope(P[i]) <= Envelope_MAX RequestedNextScope > Envelope_MAX => DENY
The architecture is not limited to staged operation. Protected policy may select a single-phase path for lower-consequence, pre-authorized, reversible, latency-sensitive, or structurally constrained acts.¶
Candidate Act -> Protected Validation -> Effectuation Authority
-> Finality Sink -> Authorized Full Effect -> Completion Evidence
A system can therefore deploy staged IEV controls only for selected consequence classes without requiring every operation to pass through a multi-phase workflow.¶
In the two-phase profile, the initial operation causes a real but bounded consequence. The evidence from this consequence participates in the authority chain for the next phase.¶
Candidate Act -> bounded authority C[0] -> FS[0] -> REAL bounded effect P[0] -> protected evidence R[0] -> IEV -> Gamma[1] -> FS[1] -> remaining or full effect P[1]
The first phase can be bounded by amount, bytes, recipient set, destination set, duration, device range, privilege, transaction state, deployment population, bandwidth, or another consequence dimension.¶
P[0] -> R[0] -> IEV[0] -> Gamma[1] -> P[1] P[1] -> R[1] -> IEV[1] -> Gamma[2] -> P[2] ... P[n-1] -> R[n-1] -> IEV[n-1] -> Gamma[n] -> P[n] -> R[n]
Mandatory phases cannot be skipped merely by invoking a later API or alternate route. A protected phase counter, receipt chain, transaction state, or equivalent sequence-binding mechanism can enforce ordering.¶
If phase index == i, direct execution of P[i+2] is rejected unless policy explicitly defines P[i+1] as unnecessary or equivalent.
Evidence can originate from the Finality Sink, destination, recipient, transaction system, database, storage engine, protected sensor, device controller, network component, cloud service, DPU, SmartNIC, secure element, HSM, TEE, quorum, or multiple observers.¶
An Effect Receipt can bind the Candidate Act digest, phase, prior authority digest, observed result, sink, destination, observer, resource, transaction identifier, nonce, counter, policy epoch, revocation epoch, timestamp, status, route, device measurement, taint snapshot, provenance digest, and next-stage eligibility evidence.¶
EffectReceipt R_i = {
act_digest,
phase_id,
phase_authority_digest,
observed_effect,
sink_id,
destination_id,
observer_id,
resource_id,
transaction_id,
nonce,
counter,
policy_epoch,
revocation_epoch,
timestamp,
result_code,
optional_taint_state,
optional_provenance_digest,
authentication_or_attestation
}
The IEV consumes protected evidence of an already attempted or completed phase and decides whether continuation is permitted, denied, held, reconciled, reduced, remediated, escalated, or terminated. The first phase need not traverse the IEV before effectuation; the IEV role can begin after P[0] has produced evidence.¶
P[i] -> R[i] -> IEV[i] -> Decision[i]
Decision[i] in {
PASS, FAIL, HOLD, RECONCILE, RETRY_OR_REMEDIATE,
HUMAN_REVIEW, REDUCE_SCOPE, TERMINATE
}
Protected IEV state can contain D_A, Envelope_MAX, current phase, expected sink and destination, expected effect, tolerance, receipt quality, policy and revocation epochs, next scope, consumed-receipt state, retry state, risk, taint, provenance, counters, escalation state, and continuation-issuance state.¶
IEVPass[i] = AuthValid(R[i]) AND ActMatch(R[i], D_A) AND PhaseMatch(R[i], i) AND SinkMatch(R[i]) AND DestinationMatch(R[i]) AND Fresh(R[i]) AND NOT Consumed(R[i]) AND EffectAcceptable(O[i], X[i]) AND PolicyCurrent AND RevocationClear AND WithinEnvelope(P[i+1])
Exact: O[i] == X[i] Tolerance: distance(O[i], X[i]) <= epsilon[i] Range: L[i] <= O[i] <= U[i] Authorized set: O[i] in A_set[i] Predicate set: ALL required Pred_k(O[i]) == TRUE
A continuation condition is a technical condition required by the next effectuation boundary. It need not be a bearer token and need not be externally visible.¶
CVI[i+1] = Protect_IEV({
act_digest: D_A,
prior_phase: i,
next_phase: i+1,
prior_receipt_digest: H(R[i]),
next_scope: Scope(P[i+1]),
next_sink: Sink[i+1],
next_destination: Destination[i+1],
policy_epoch,
revocation_epoch,
iev_counter,
expiry
})
A tokenless implementation can instead atomically update protected state. A hardware implementation can set a latch. A cryptographic implementation can derive or unseal next-phase material.¶
K[i+1] = KDF(K_root_IEV, D_A, H(R[i]), i+1, Sink[i+1], Ctr_IEV) K_final[i+1] = Combine(K_FS[i+1], K_IEV[i+1]) ENABLE[i+1] = FSValid AND (IEV_Latch == PASS[i])
The Finality Sink is the final protected decision point before the next real consequence becomes effective. A previously valid IEV decision does not remove the need to check current state at the effectuation boundary.¶
Enable(P[i+1], t_effect) = Valid(Gamma[i+1]) AND PolicyCurrent(t_effect) AND RevocationClear(t_effect) AND ContinuationNotWithdrawn(t_effect) AND DestinationStillValid(t_effect) AND ScopeStillAuthorized(t_effect)
When a misalignment or policy condition requires human judgment, the IEV can form a protected escalation record that binds the Candidate Act, prior receipt, expected effect, observed effect, deviation, proposed next phase, risk, and policy context. The human response returns to protected validation; it is not required to act as unrestricted direct execution authority.¶
PER_i = Protect({
act_digest: D_A,
receipt_digest: H(R[i]),
expected_effect: X[i],
observed_effect: O[i],
deviation,
proposed_next_phase,
risk_state,
policy_epoch
})
HumanDecision -> IEV revalidation -> bounded Gamma[i+1]
A communication-specific example is trailer -> real recipient -> receipt -> IEV misalignment -> protected human review -> IEV revalidation -> communication-specific continuation -> Finality Sink -> full SEND.¶
Human participation is optional. An automated remediation controller can propose re-query, re-attestation, retry, reduced scope, rollback, compensation, alternate sink, quarantine, safe state, or termination. The remediation controller does not automatically obtain unrestricted effectuation authority; its proposal returns through protected validation.¶
Mismatch -> Automated Remediation Proposal -> IEV revalidation -> bounded remediation or continuation condition -> Finality Sink
An uncertain outcome is not treated as proof of failure and is not treated as proof of success. The system can query protected state using act digest, phase, nonce, transaction identifier, idempotency identifier, counters, destination state, sink state, ledger state, sensors, replicas, or protected journals.¶
ReconciliationResult in {
PROVEN_EFFECTED,
PROVEN_NOT_EFFECTED,
PARTIALLY_EFFECTED,
STILL_INDETERMINATE
}
PROVEN_EFFECTED -> recovered evidence -> IEV validation
PROVEN_NOT_EFFECTED -> optional new bounded retry with new authority
PARTIALLY_EFFECTED -> residual-scope / compensation / escalation
STILL_INDETERMINATE -> next ordinary phase remains blocked
If a Finality Sink performed P[i] but R[i] was not delivered, the system does not blindly repeat P[i]. If a CVI was issued but consumption is unknown, the system reconciles the consumption state before reissuing equivalent authority.¶
A hardened deployment does not assume that a single IEV can never fail or lie. Validator integrity can be checked through state chaining, monotonic counters, attestation, watchdogs, diverse validators, threshold validators, hierarchical validators, proof-carrying decisions, or a subset of independent Finality-Sink checks.¶
SD[i] = H(S_IEV[i]) SD[i+1] = H(SD[i] || H(R[i]) || Decision[i] || Counter[i+1]) IEVTrusted[i] = AttestationValid[i] AND StateConsistent[i] AND CounterValid[i] AND WatchdogClear[i] Enable(P[i+1]) = CVIValid[i+1] AND IEVTrusted[i] AND FSBoundaryChecksValid
If the primary validator is unavailable, policy can HOLD, enter SAFE_STATE, use reduced scope, select an alternate validator, use FAIL_LIMITED behavior, or terminate. High-consequence profiles do not treat validator unavailability as implicit PASS.¶
Authentication and consistency are distinct properties. Two receipts can each authenticate correctly and still disagree about the effect.¶
Valid(R_a) == TRUE
Valid(R_b) == TRUE
Constraint(R_a, R_b) == FALSE
=> EvidenceState = CONFLICT
=> no ordinary continuation until conflict policy resolves
Conflict resolution can use predicate-specific source authority, quorum, weighted evidence, veto-class sensors, temporal consistency, causal identifiers, additional evidence, bounded diagnostic effects, automatic resolution, or protected human adjudication. A majority does not necessarily override a critical high-assurance contradiction.¶
A CVI valid when issued can become stale before the next effect. Policy, revocation, destination state, taint, risk, human approval, or device health can change in the interval between IEV PASS and Finality-Sink consumption.¶
IEVPass(t0) != IrrevocableAuthority(t1), where t1 > t0 ValidAtIssue(CVI) !=> ValidAtEffectuation(CVI)
Mechanisms include short-lived continuation leases, policy-epoch binding, revocation-epoch binding, explicit continuation-revocation records, generation counters, online consume handshakes, atomic revoke-or-consume state, hardware revocation latches, current-epoch key derivation, and prepare/commit continuation.¶
Taint is an input to protected policy and can represent semantic information flow, sensitive-data exposure, untrusted external content, provenance uncertainty, behavioral risk, tool-output lineage, or other trust-relevant state. Taint need not be a Linux-style byte label; equivalent protected lineage or risk state can be used.¶
tau_out = Join(tau_process, tau_input_1, ..., tau_input_n) tau(A[i+1]) = Propagate(tau(A[i]), tau(Context), tau(ToolOutputs), tau(Provenance)) UnableToValidateTaint !=> CLEAN
Origin attribution can bind a request to process, task, agent, UID, cgroup, container, VM, code measurement, session, or other protected identity. A receipt may preserve the relevant origin and taint snapshot so the IEV can evaluate the pathway that produced the effect.¶
An act-generating domain can hold a non-authoritative surrogate credential or reference while the actual credential remains in a protected credential authority. The protected boundary resolves, inserts, uses, or activates the actual credential only after required policy checks. The actual credential need not be returned to the agent.¶
sigma_j != K_real_j Possess(sigma_j) !=> EffectAuthority SwapAllowed[i+1] = SurrogateValid(sigma[i+1]) AND CVIValid(CVI[i+1]) AND PolicyCurrent AND RevocationClear AND DestinationCurrent AND TaintAcceptable
The surrogate can be an opaque token, handle, credential alias, object reference, session reference, key handle, signed request reference, or implicit protected credential reference. The architecture does not require a literal token swap.¶
Connector or tool logic can be divided into a narrow unprivileged stub and a protected worker. The worker can be restricted to a service-specific credential class and effect scope. Network, browser, filesystem, payment, database, and cloud operations can be mediated by corresponding brokers or Finality Sinks.¶
Agent / Lower-Trust Domain
|
v
Narrow Connector Stub
|
authenticated IPC
v
Privilege-Separated Worker / Broker / FS
|
protected credential and policy checks
v
External Service
The IEV role is functional rather than tied to a particular platform. Changing the validator placement does not change the sequence when the required protected properties are preserved.¶
The agent and IEV can execute in separate VMs or microVMs. A host broker, hypervisor service, or separate VM can act as Finality Sink. The agent VM can lack unrestricted network or storage authority.¶
The agent and IEV can use separate UIDs, namespaces, cgroups, containers, mandatory-access-control domains, or services. Kernel, LSM, eBPF-adjacent, seccomp, proxy, credential-broker, or transaction mechanisms can enforce effect boundaries.¶
The IEV can be a system service, isolated process, Binder service, native daemon, TEE component, remote validator, or application/backend service. Protected key operations can authenticate continuation decisions.¶
The IEV can be implemented through a protected backend, separate supported extension/helper, secure-key-assisted mechanism, or platform service. Where a third-party app cannot mediate all local OS resources, the server-side Finality Sink can preserve the same inter-phase dependency.¶
A helper, XPC service, daemon, sandboxed component, privileged broker, remote service, or hardware-backed key service can implement the protected validator and Finality Sink functions.¶
A Windows service, AppContainer-separated broker, restricted process, VM, VBS-assisted component, remote validator, or credential broker can implement the roles.¶
A lower-assurance realization can use separate processes, app-owned brokers, server-side gates, or even logically distinct modules in one process. Stronger isolation increases resistance to compromise but does not change the functional sequence.¶
This section states functional equivalence rules intended to prevent accidental coupling of the architecture to one topology, product name, token type, proxy, operating system, or cryptographic representation. It is a technical interoperability and architecture statement, not a legal conclusion.¶
Functional sequence F: E[i] -> R[i] -> IEV[i] -> Gamma[i+1] -> FS[i+1] -> E[i+1] If implementation X and implementation Y preserve the required role, trust-boundary, binding, state-transition, and anti-bypass properties, then replacing a component representation does not by itself change F.
One component can validate, perform a bounded effect, observe it, advance protected state, and perform the broader effect. Physical separation is not required if protected state prevents skipping the confirmation transition.¶
Gamma can be an internal state bit, transaction state, database state, latch, register, monotonic counter, consensus state, or other protected state rather than a transferable token.¶
A protected human signature can directly authorize an exact act or authorized envelope, with staged continuation optionally bound to prior evidence.¶
An AI can provide only a recommendation while a human independently originates the effect-capable operation in a trusted application.¶
Authority can be encoded in typed objects, capability graphs, language-level effect types, file descriptors, namespaces, memory-safe references, or hardware protection domains. Receipt validation can expose or unlock broader objects.¶
A database, payment service, message service, cloud control plane, or storage engine can enforce the staged state machine natively without an external token or broker.¶
Only protected consequence classes need staged effectuation. Lower-risk classes can use direct-within-envelope paths.¶
Compensation and rollback can exist as ancillary or fallback behavior when pre-effect staging is unavailable. They do not replace the staged invariant where policy requires it.¶
A strongly constrained or formally verified agent can reduce risk, while an effectuation boundary can still enforce execution-finality for selected consequence classes.¶
The destination itself can observe, validate, and gate broader effectuation.¶
Evidence and continuation authority can be represented by quorum certificates, threshold signatures, consensus state, or replicated commit state.¶
A protected action graph can define allowed states and transitions. Receipts can unlock edges, consume edges, advance a protected state pointer, or reduce the remaining graph.¶
A Linux daemon, VM, enclave, remote service, same-chip security domain, destination-local validator, or threshold set can replace another validator placement without changing the functional sequence if required properties remain.¶
A forward proxy, kernel gate, SmartNIC, DPU, API gateway, transaction engine, native destination, or hardware controller can implement the effectuation boundary.¶
A token, handle, alias, credential reference, object capability, protected slot, or implicit state can all represent late-bound authority.¶
Kernel labels, provenance graphs, cryptographic tags, protected metadata, process taint, semantic taint, or policy-derived lineage can represent the relevant protected state.¶
The architecture is intentionally transport-neutral. Interoperable deployments can define these objects using CBOR, JSON, protobuf-like schemas, typed RPC objects, database records, protected shared memory, hardware registers, or another deterministic representation. When cryptographic binding depends on serialization, implementations need a deterministic encoding or an unambiguous typed object representation.¶
act identifier or digest; act class; destination; resource; payload digest; scope; maximum envelope; policy epoch; revocation epoch; nonce; expiry; origin; optional taint and provenance.¶
act digest; phase; phase scope; sink; destination; nonce; expiry; policy/revocation epoch; authority authenticator or protected state reference.¶
act digest; phase; observed effect; sink/destination/observer; transaction and resource identifiers; nonce; counter; timestamp; status; optional prior receipt digest; authentication/attestation.¶
expected and observed effect, receipt digest, phase authority digest, sink/destination/observer/resource identifiers, policy state, transaction state, nonce, counter, timestamp.¶
act digest; prior phase; next phase; prior receipt digest; next scope; next sink/destination; policy/revocation epoch; counter; expiry; authenticator.¶
validator identity; validator measurement; protected state digest; decision; receipt digest; next scope; policy/revocation epoch; counter; timestamp; expiry; attestation or signature.¶
digests of conflicting evidence; conflicting fields; source identities and roles; policy epoch; conflict class; time window; optional confidence or assurance metadata.¶
act digest; receipt digest; expected effect; observed effect; deviation; proposed next phase; risk; policy context.¶
CVI digest or continuation generation; act digest; revocation reason; revocation epoch; authority identity; timestamp; authenticator.¶
act digest; commitment to phase receipts or receipt-chain root; final state; final counter; policy epoch; authenticator.¶
This version does not mandate one encoding. CBOR can be used as described by RFC 8949, with COSE structures from RFC 9052 for signing or message authentication. JSON deployments can use a deterministic canonicalization scheme such as RFC 8785 before hashing or signing. These are examples, not mandatory dependencies of the abstract architecture.¶
Cryptographic binding can use digital signatures, MACs, authenticated encryption, HSM/TEE attestations, hardware counters, threshold signatures, hash chains, Merkle commitments, secure logs, or equivalent mechanisms. Keys for a later phase can be derived from a prior receipt digest so that the later phase is cryptographically non-completable without accepted predecessor evidence.¶
Send a real trailer or bounded communication object, obtain recipient- or endpoint-bound evidence, validate it in the IEV, and release the remaining message, attachment, payload, or decryption capability only after continuation validation.¶
Perform a bounded hold, verification transfer, authorization, or escrow reservation. Validate beneficiary, account, amount, currency, rail, and transaction state before capture, settlement, or later tranche.¶
Release a manifest, ciphertext fragment, bounded chunk, or restricted object. Validate destination storage state and then release remaining data, visibility, or a decryption key.¶
Commit a provisional or restricted mutation, obtain durable commit evidence, validate it, then promote, expose, replicate, or perform dependent transactions.¶
Deploy to a bounded target set, validate health and state, then expand to additional nodes, zones, regions, tenants, or traffic percentages.¶
Permit a bounded real tool effect, validate actual tool result and destination, then authorize a dependent or broader tool effect.¶
Expose only a surrogate, reference, or low-scope authority for an earlier phase, then release or broker broader credential authority after validation.¶
Validate workload/device/firmware/output/DMA or egress evidence before broader memory exposure, external egress, or dependent action.¶
Write or expose a provisional state change, validate namespace, provenance, conflict, taint, and state receipt, then promote or replicate.¶
Activate a canary scope, obtain health evidence, validate it, then authorize broader rollout.¶
Move a bounded amount, measure actual motion or device state, validate against tolerance, then release the next motion envelope.¶
Authorize a bounded trajectory, maneuver, speed, or operating region and expand only after protected sensor/position/state evidence passes.¶
Apply a bounded process change, validate protected sensor response, then permit broader setpoint, batch, flow, or machine cycle.¶
Perform a bounded bearer, route, beam, RF burst, power level, or transmission, validate network/receiver state, then expand scope.¶
Collect a vector of destination receipts and require all, quorum, weighted, or role-constrained acceptance before broader progression.¶
A deployment should document which component acts as Finality Sink for each consequence class.¶
A deployment should document which evidence sources are authoritative for which predicates.¶
A deployment should document whether Gamma is explicit, implicit, tokenless, cryptographic, transactional, hardware-backed, or distributed.¶
A deployment should document canonicalization or typed object binding sufficient to prevent material interpretation drift.¶
A deployment should document receipt freshness, replay state, phase ordering, crash recovery, and idempotency behavior.¶
A deployment should document effectuation-time policy and revocation checks.¶
A deployment claiming EF-NON-BYPASSABLE should identify act-equivalent paths and how each path is mediated, disabled, credential-restricted, or equivalently gated.¶
A deployment using taint or provenance should document UNKNOWN or UNVERIFIABLE behavior rather than silently mapping missing lineage to clean state.¶
A deployment using surrogate credentials should document whether actual credentials ever enter the act-generating domain.¶
The security objective is not merely to decide whether a computation appears safe. It is to control the boundary at which computation becomes consequential and to keep later effects technically dependent on current protected conditions and verified predecessor evidence.¶
Receipts and continuation objects require authenticity and binding to the intended act, phase, sink, destination, resource, scope, and relevant policy state. A valid signature over the wrong operation is not sufficient.¶
Single-use receipts and continuation objects are consumed in protected state. Nonces, counters, phase identifiers, expiries, transaction identifiers, or sequence state can prevent reuse.¶
An attacker must not replace a required high-assurance trial, observer, validator, or effect boundary with a weaker one unless policy explicitly permits an equivalent profile.¶
Direct sockets, hidden APIs, alternate credentials, admin interfaces, raw device paths, debug paths, recovery paths, message queues, database connections, lower-level primitives, and equivalent effect-capable routes need equivalent mediation where non-bypassability is claimed.¶
Blind retry is dangerous for payments, SEND operations, deletes, commits, and physical actions. Reconciliation precedes retry when duplicate consequence would be unsafe.¶
Attestation, diverse validators, threshold decisions, watchdogs, state chaining, counters, proof-carrying decisions, and Finality-Sink minimum checks can limit reliance on one validator.¶
Authenticity does not imply consistency. Conflicting authentic evidence triggers conflict policy rather than ordinary continuation.¶
Policy, destination, risk, taint, human authority, and revocation can change after PASS. The Finality Sink revalidates current protected conditions at effectuation time.¶
Actual effect-capable credentials can remain outside the act-generating process and be resolved only at a protected boundary.¶
Attackers can trigger repeated trials, evidence collection, or reconciliation. Rate limits, bounded retries, backoff, quotas, safe fallback, and consequence-aware throttling are applicable.¶
Receipts can expose destinations, users, transaction state, physical state, or provenance. Deployments should minimize evidence and can use commitments, selective disclosure, protected storage, or privacy-preserving proofs.¶
Effect receipts, taint metadata, provenance graphs, human approvals, and reconciliation logs can contain sensitive personal or enterprise information. Implementations should minimize collection, bind evidence to the minimum necessary predicates, apply retention limits, separate operational telemetry from long-lived identity where possible, and protect evidence at rest and in transit. General Internet privacy guidance is available in RFC 6973.¶
An IEV can validate commitments or attestations rather than raw content when the predicate can be proven without exposing the underlying payload. For example, a receipt can prove that a destination, account, device, or state belongs to an authorized set without disclosing unrelated details.¶
Staged effectuation introduces latency, additional state, evidence collection, and failure modes. It is therefore especially appropriate where consequence magnitude justifies additional control, while lower-consequence operations can remain single-phase under protected policy.¶
Choose bounded phase size so the trial is meaningful but consequence-limited.¶
Define timeout behavior and distinguish timeout from proven non-effect.¶
Define receipt quality and authoritative observer classes.¶
Use idempotency and transaction identifiers when retried effects can duplicate consequence.¶
Define safe-state or fail-limited behavior for offline, partitioned, or validator-unavailable operation.¶
Keep policy epochs, revocation epochs, counters, and validator state rollback-resistant where required.¶
Test native-operation substitution, crash after provider entry, and alternate effect-capable paths.¶
Test canonicalization ambiguity and cross-language object equivalence.¶
Test high-concurrency receipt consumption and duplicate continuation races.¶
This document requests no IANA actions. Future specifications that define interoperable wire encodings, media types, registries, CBOR tags, or protocol parameters can define the corresponding IANA considerations separately.¶
This appendix preserves detailed source-derived technical material underlying the abstract protocol model in the main body. It is non-normative unless an explicit profile in the main body incorporates a requirement by reference.¶
title: "INTERIM EFFECTUATION VALIDATOR (IEV)" subtitle: "Core Embodiment, Cross-Embodiment Implementation, Operational Workflow, and Hardened Mathematical Model" author: "Technical drafting compilation" date: "1 October 2026" geometry: margin=22mm fontsize: 10pt linestretch: 1.08 papersize: a4 header-includes:¶
\usepackage{amsmath,amssymb,mathtools} \usepackage{microtype} \usepackage{booktabs,longtable,array} \usepackage{enumitem} \usepackage{fancyhdr} \usepackage{listings} \usepackage{xcolor} \lstset{basicstyle=\ttfamily\scriptsize,breaklines=true,breakatwhitespace=false,columns=fullflexible,keepspaces=true,showstringspaces=false,frame=single} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{Interim Effectuation Validator (IEV)} \fancyhead[R]{Revised Mathematical Edition} \fancyfoot[C]{\thepage} \setlength{\headheight}{14pt} \setlist{nosep,leftmargin=}¶
|¶
This document combines three coordinated technical parts concerning an Interim Effectuation Validator (IEV):¶
Part I - Core Interim Effectuation Validator Embodiment: defines the IEV, its protected inter-phase position, evidence intake, independent validation, continuation decision, escalation, and representative implementations.¶
Part II - Cross-Embodiment Technical Implementation: specifies how the IEV is concretely inserted into other compatible embodiments, including protected state, authenticated interfaces, continuation instructions, cryptographic missing material, hardware latches, software/kernel enforcement, network, transaction, SEND, payment, robotics, telecom, accelerator, model-state, update, multi-destination, and quorum implementations.¶
Part III - Step-by-Step Pseudocode / Operational Workflow: gives a procedural implementation from Candidate Act intake through Phase 0, receipt generation, IEV validation, continuation authority, Finality Sink verification, multi-phase repetition, human escalation, automated remediation, reconciliation, crash recovery, replay protection, anti-bypass, and final receipt generation.¶
The mathematical notation is normalized throughout this document. Unless expressly stated otherwise, a symbol retains the same meaning in all three Parts.¶
This section controls the mathematical notation used throughout the document. Textual workflow labels appearing later are illustrative shorthand; where there is any ambiguity, the definitions and indexed relationships in this section govern.¶
Let the effectuation process contain phases indexed by¶
i\in\{0,1,\ldots,n\}.¶
The following symbols are used consistently.¶
| Symbol | Formal meaning | |---|---| | A | Candidate Act. | | \operatorname{Canon}(A) | Canonical representation of Candidate Act A. | | D_A | Stable protected digest of A, with D_A=H(\operatorname{Canon}(A)). | | P_i | Real effectuation phase i, including its authorized phase scope. | | C_i | Explicit phase-specific authority for P_i, when an explicit authority object is used. | | FS_i | Finality Sink or equivalent effect-capable boundary controlling P_i. | | R_i | Protected evidence or receipt describing the actual result of P_i. | | X_i | Expected protected result for phase i. | | O_i | Observed protected result for phase i. | | IEV_i | Interim Effectuation Validator responsible for the transition after P_i. | | S^{IEV}_i | Protected IEV state relevant to validation after phase i. | | IVIR_i | Interim Validation Input Record associated with R_i. | | V_i | IEV validation decision for phase i. | | CVI_{i+1} | Continuation Validation Instruction for proposed phase P_{i+1}. | | \epsilon_i | Permitted tolerance for a phase-i observed result. | | \mathcal{A}_i | Authorized set of acceptable observed results for phase i. | | \mathcal{E}_{\max} | Maximum authorized effectuation envelope. | | p_i | Policy epoch bound to the relevant decision or continuation state. | | r_i | Revocation epoch bound to the relevant decision or continuation state. | | q_i | Protected monotonic IEV counter. | | \sigma_i | Protected digest of IEV state, \sigma_i=H(S^{IEV}_i). | | PER_i | Protected Escalation Record for phase i. | | CR_i | Continuation Revocation Record for CVI_{i+1}. |¶
Cryptographic concatenation is denoted by \parallel. Boolean conjunction, disjunction, and negation are denoted by \land, \lor, and \neg, respectively. A statement such as \operatorname{Pass}_i=\mathrm{true} denotes a protected Boolean decision and not a free-form textual assertion.¶
The Candidate Act digest is defined as¶
D_A = H\!\left(\operatorname{Canon}(A)\right).¶
Where a phase authority C_i is used, it should be bound to at least the Candidate Act, phase identity, permitted phase scope, authorized sink or destination, freshness information, and applicable policy/revocation state.¶
The central IEV relationship is¶
\boxed{ P_i \longrightarrow R_i \longrightarrow IEV_i \longrightarrow CVI_{i+1} \longrightarrow FS_{i+1} \longrightarrow P_{i+1} }.¶
A receipt is evidence of a preceding real effect, not by itself authority for a later real effect:¶
\boxed{ \operatorname{ReceiptExists}(R_i)=\mathrm{true} \;\not\Rightarrow\; \operatorname{Enable}(P_{i+1})=\mathrm{true} }.¶
Ordinary continuation instead requires protected interim validation:¶
\operatorname{Enable}(P_{i+1}) \Rightarrow \operatorname{Pass}_i=\mathrm{true},¶
subject to the expressly disclosed escalation, remediation, reconciliation, reduced-scope, revocation, or fail-limited paths.¶
Exact equality may be expressed as¶
O_i=X_i.¶
A scalar tolerance may be expressed as¶
\lvert O_i-X_i\rvert\leq\epsilon_i.¶
For vector, structured, or non-scalar observations, a distance or domain-specific metric d_i may be used:¶
d_i(O_i,X_i)\leq\epsilon_i.¶
Range acceptance may be expressed as¶
L_i\leq O_i\leq U_i.¶
Set membership may be expressed as¶
O_i\in\mathcal{A}_i.¶
A predicate-set embodiment may require¶
\bigwedge_{k=1}^{m_i} \operatorname{Pred}_{i,k}(O_i)=\mathrm{true}.¶
A non-limiting formalization is¶
\begin{aligned} \operatorname{Pass}_i={}& \operatorname{AuthValid}(R_i) \land \operatorname{ActMatch}(R_i,D_A) \land \operatorname{PhaseMatch}(R_i,i)\\ &\land \operatorname{SinkMatch}(R_i,FS_i) \land \operatorname{DestinationMatch}(R_i) \land \operatorname{Fresh}(R_i)\\ &\land \neg\operatorname{Consumed}(R_i) \land \operatorname{EffectAcceptable}(O_i,X_i)\\ &\land \operatorname{PolicyCurrent}(p_i) \land \operatorname{RevocationClear}(r_i) \land \operatorname{WithinEnvelope}(P_{i+1},\mathcal{E}_{\max}). \end{aligned}¶
The exact predicate set may vary by embodiment, but a protected PASS decision is distinct from a mere receipt assertion.¶
An illustrative protected continuation instruction is¶
\begin{aligned} CVI_{i+1} =\operatorname{Protect}_{K_{IEV}}\!\Big(& D_A \parallel (i+1) \parallel H(R_i) \parallel \operatorname{Scope}(P_{i+1})\\ &\parallel \operatorname{ID}(FS_{i+1}) \parallel \operatorname{DestinationID}_{i+1} \parallel p_i\\ &\parallel r_i \parallel q_{i+1} \parallel t^{\mathrm{exp}}_{i+1} \Big). \end{aligned}¶
Accordingly, the continuation object can be act-bound, phase-bound, receipt-bound, scope-bound, sink-bound, destination-bound, epoch-bound, counter-bound, and expiry-bound.¶
A stronger cryptographic embodiment may derive next-phase material as¶
K^{IEV}_{i+1} = \operatorname{KDF}\!\left( K^{IEV}_{root}, D_A, H(R_i), i+1, \operatorname{ID}(FS_{i+1}), q_{i+1} \right).¶
Without an accepted phase-i result, the required IEV-controlled material is absent, sealed, or unavailable:¶
\operatorname{Pass}_i\neq\mathrm{true} \Rightarrow K^{IEV}_{i+1}\ \text{unavailable}.¶
In a split-authority embodiment,¶
K^{Final}_{i+1} = \operatorname{Combine}\!\left( K^{FS}_{i+1}, K^{IEV}_{i+1} \right).¶
A hardware realization may use¶
\operatorname{ENABLE}_{i+1} = \operatorname{FSValid}_{i+1} \land \bigl(L^{IEV}_{i}=\mathrm{PASS}\bigr).¶
The latch or equivalent protected state may be implemented in hardware, firmware, protected memory, a security processor, a transaction engine, or another protected control plane.¶
A non-limiting decision domain is¶
\begin{aligned} V_i\in\{&\mathrm{PASS},\ \mathrm{FAIL},\ \mathrm{HOLD},\ \mathrm{RECONCILE},\ \mathrm{REMEDIATE},\\ &\mathrm{REDUCE\_SCOPE},\ \mathrm{HUMAN\_REVIEW},\ \mathrm{TERMINATE},\ \mathrm{INDETERMINATE}\}. \end{aligned}¶
The value \mathrm{INDETERMINATE} is not treated as equivalent to \mathrm{FAIL} or \mathrm{PASS} unless an expressly disclosed protected policy maps it to a bounded safe or fail-limited action.¶
\newpage¶
In one embodiment, a multi-phase effectuation architecture includes an Interim Effectuation Validator positioned logically between completion or attempted completion of an earlier real effectuation phase and authorization of a later effectuation phase.¶
The IEV provides an independent protected decision point that determines whether the preceding real effect occurred in a manner sufficiently aligned with the authorized Candidate Act, expected effect, applicable policy, protected state, and continuation conditions before the Finality Sink is permitted to produce a subsequent effect.¶
A first real effectuation phase may therefore occur through a Finality Sink directly to an external device, destination, service, actuator, transaction rail, network endpoint, storage system, or other effect-capable target:¶
A \rightarrow FS_0 \rightarrow P_0¶
After that real phase, protected evidence is returned to the IEV:¶
P_0 \rightarrow R_0 \rightarrow IEV_0¶
The IEV independently evaluates the evidence and, only if required continuation predicates are satisfied, issues or establishes the protected condition needed for the next phase:¶
R_0 \rightarrow IEV_0 \rightarrow CVI_1 \rightarrow FS_1 \rightarrow P_1¶
The IEV therefore need not relay the first effectuation command. It may become causally mandatory after the first real effect and before the next real effect.¶
An Interim Effectuation Validator (IEV) means one or more protected logical, software, firmware, hardware, cryptographic, transactional, network, or distributed components positioned in a causal control path between an earlier effectuation event and authorization of a later effectuation event.¶
The IEV is configured to independently evaluate evidence associated with an earlier real effectuation before permitting, recommending, authorizing, cryptographically enabling, or otherwise causing availability of a later effectuation phase.¶
The term is functional and non-limiting. An IEV need not be a physically separate device.¶
An IEV may be implemented:¶
inside the same chip as a Finality Sink;¶
inside a different security island of the same chip;¶
inside a secure enclave, TEE, HSM, TPM-associated service, secure element, or security processor;¶
inside a DPU, SmartNIC, NIC, modem, baseband processor, GPU security processor, storage controller, database transaction engine, or payment controller;¶
inside a vehicle ECU, robotic safety controller, PLC, actuator controller, industrial controller, or dedicated safety MCU;¶
inside firmware, a kernel, privileged operating-system service, hypervisor, microVM, or protected broker;¶
inside a remote protected service or destination-side protected service;¶
across multiple protected components under threshold, quorum, or distributed validation;¶
or through another architecture providing equivalent protected interim validation.¶
The IEV may be part of a Protected Enforcement Domain, may constitute a separate Protected Enforcement Domain, or may cooperate with one or more PEDs or Finality Sinks.¶
The IEV is preferably arranged so that its continuation decision cannot be arbitrarily determined, rewritten, forged, or bypassed by the component that proposed the Candidate Act or by an untrusted executor.¶
The IEV may receive externally generated evidence. Its neutrality therefore does not mean that it ignores external information. Rather, external information affects the IEV through defined authenticated evidence interfaces and protected policy inputs, after which the IEV applies its own protected validation logic.¶
Thus:¶
Assertion_{Agent} \neq Validation_{IEV}¶
and receipt existence alone does not imply continuation:¶
ReceiptExists_i = TRUE \not\Rightarrow Enable(P_{i+1})¶
A preferred causal relationship is:¶
Enable(P_{i+1}) \Rightarrow IEVPass_i=TRUE¶
unless an expressly authorized escalation, remediation, or recovery path substitutes for ordinary continuation.¶
Decision independence may be provided by privilege separation, process isolation, memory isolation, hardware-enforced isolation, key isolation, protected boot, secure firmware, immutable or authenticated policy, enclave protection, a separate security processor, physically separate hardware, a remote protected service, distributed threshold validation, administrative separation, or combinations thereof.¶
A Candidate Act A defines or is associated with a requested complete effect and an authorized maximum envelope Envelope_{MAX}.¶
The system first selects a bounded real phase P_0 and forms or activates a Phase-0 authority C_0 where explicit authority is used.¶
The Phase-0 Finality Sink verifies the applicable protected conditions and causes P_0 to become real:¶
FS_0(C_0,P_0) \rightarrow Effect_0¶
The first phase may travel directly from the Finality Sink to the external effect-capable target. The original effectuation command is not required to pass through the IEV before P_0.¶
The IEV's principal role may begin when protected evidence of that real first-phase effect is generated.¶
After phase P_i, evidence associated with the actual effect is delivered to the IEV.¶
Such evidence may comprise:¶
an Effect Confirmation Receipt;¶
sink-generated receipt;¶
destination acknowledgement;¶
protected sensor measurement;¶
transaction identifier or payment-rail confirmation;¶
database commit evidence;¶
storage commitment;¶
network acknowledgement;¶
actuator position or motion measurement;¶
current, voltage, pressure, temperature, torque, speed, or other physical measurement;¶
device-state transition;¶
hardware counter;¶
signed telemetry;¶
attestation;¶
secure log entry;¶
protected interrupt;¶
receiver-generated receipt;¶
route or endpoint evidence;¶
quorum evidence;¶
or another machine-verifiable representation of the preceding effect.¶
Let R_i represent the protected evidence associated with P_i.¶
The receipt may originate from the Finality Sink itself, the destination, an independent observer, a protected sensor, transaction system, network element, or multiple sources.¶
In a preferred embodiment, R_i contains or cryptographically binds information sufficient for the IEV to determine where, through what boundary, or under what protected context the earlier effect actually occurred.¶
R_i may bind one or more of:¶
sink identity;¶
device identity;¶
destination or recipient identity;¶
route or endpoint;¶
account, wallet, payment rail, or settlement path;¶
database instance, shard, resource generation, or commit position;¶
storage object, namespace, media/controller identity, or durability state;¶
actuator, motor channel, controller, or physical device;¶
process, VM, container, host, or hardware measurement;¶
execution environment;¶
resource identifier;¶
transaction identifier;¶
phase identifier;¶
policy epoch;¶
revocation epoch;¶
nonce;¶
timestamp;¶
observed result.¶
The IEV may therefore distinguish:¶
Effect\ at\ AuthorizedTarget¶
from:¶
Effect\ at\ SubstituteTarget¶
although both may superficially report success.¶
The IEV independently validates the earlier phase evidence.¶
A general protected operation may be written:¶
V_i = V_{IEV}(R_i,A,P_i,S^{IEV}_i)¶
The IEV may verify:¶
VerifyAuth(R_i),\quad MatchAct(R_i,D_A),\quad MatchPhase(R_i,P_i)¶
MatchSink(R_i),\quad MatchDestination(R_i),\quad MatchDevice(R_i)¶
Fresh(R_i),\quad NotReplayed(R_i),\quad PolicyCurrent,\quad RevocationClear¶
and may additionally verify observed effect, current protected state, risk, taint, provenance, receipt quality, authorized envelope, next-phase scope, required approvals, and other domain-specific predicates.¶
A generalized decision may be represented as:¶
IEVDecision_i = Validate( R_i, D_A, X_i, S^{IEV}_i )¶
The IEV may compare the expected effect X_i with the protected observed effect O_i.¶
For exact systems:¶
O_i=X_i¶
may be required.¶
For tolerance-based systems:¶
d(O_i,X_i)\le \epsilon_i¶
may be accepted.¶
For range-based systems:¶
L_i \le O_i \le U_i¶
may be required.¶
For set-based systems:¶
O_i\in\mathcal{A}_i¶
may be sufficient.¶
For predicate-based systems:¶
\bigwedge_{j=1}^{k} Pred_j(O_i)=TRUE¶
may define acceptance.¶
Accordingly, the IEV need not merely determine that "something happened." It may independently determine whether the correct bounded consequence occurred at the correct place, through the correct effect-capable boundary, within the correct scope, and under the correct protected conditions.¶
If the preceding effect satisfies the required conditions:¶
IEVDecision_i=PASS¶
then the IEV may produce or establish a Continuation Validation Instruction for the next phase:¶
CVI_{i+1}¶
The CVI may be implemented as:¶
signed instruction;¶
MAC-protected instruction;¶
protected state transition;¶
continuation capability or non-bearer authority;¶
key, key share, or key-unsealing condition;¶
transaction-state transition;¶
commit permission;¶
network permit;¶
actuator enablement;¶
register value;¶
hardware latch state;¶
policy-state transition;¶
cryptographic proof;¶
destination-local permission;¶
or equivalent technical continuation condition.¶
A strong embodiment binds the continuation instruction to the Candidate Act, prior receipt, next phase, next sink, and current protected state.¶
For example:¶
CVI_{i+1} = Protect_{K_{IEV}} \left( D_A \parallel (i+1) \parallel H(R_i) \parallel Scope(P_{i+1}) \parallel Sink_{i+1} \parallel PE \parallel Counter_{IEV} \parallel Expiry \right)¶
Thus:¶
Valid(R_i) \land IEVPass_i \rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1}¶
while:¶
IEVPass_i=FALSE \rightarrow \neg CVI_{i+1}¶
unless an expressly authorized alternate escalation or remediation path is completed.¶
The later Finality Sink may be configured so that the next phase is technically unavailable without the IEV's accepted result.¶
For example:¶
Enable(P_{i+1}) = Valid(CVI_{i+1}) \land CurrentStateValid \land WithinEnvelope(P_{i+1})¶
The Finality Sink therefore does not need to trust a statement from the proposing agent that the preceding phase succeeded. It verifies protected IEV output or protected state established by the IEV.¶
The architecture creates the causal sequence:¶
RealEffect_i \rightarrow IndependentInterimValidation_i \rightarrow RealEffect_{i+1}¶
The same process may be repeated for any number of phases:¶
P_0 \rightarrow R_0 \rightarrow IEV_0 \rightarrow CVI_1 \rightarrow P_1 \rightarrow R_1 \rightarrow IEV_1 \rightarrow CVI_2 \rightarrow \cdots \rightarrow P_n¶
The same physical IEV may validate every phase, or distinct validators may be used:¶
IEV_0,IEV_1,\ldots,IEV_{n-1}¶
The IEV may determine that the earlier phase does not sufficiently match the authorized or expected result.¶
Examples include:¶
wrong recipient or endpoint;¶
wrong sink or device;¶
wrong actuator or route;¶
wrong amount, file, object, or resource;¶
excessive or insufficient physical movement;¶
unexpected latency or altered payload;¶
incorrect transaction state;¶
stale policy epoch or stale receipt;¶
invalid signature or missing attestation;¶
sensor disagreement;¶
route substitution;¶
unexpected taint or provenance;¶
unauthorized intermediary;¶
excessive risk;¶
partial failure;¶
or another protected deviation.¶
Let:¶
Misalignment_i=TRUE¶
When misalignment is detected, the next phase is not automatically released.¶
One response path is:¶
Misalignment_i \rightarrow ProtectedHumanReview¶
The IEV may prepare a protected escalation record describing the intended effect, actual observed effect, deviation, receipt, sink, destination, device, risk, proposed next phase, remediation options, and relevant protected context.¶
The human may:¶
authorize continuation;¶
authorize reduced scope;¶
require another trial;¶
change an authorized destination where policy permits;¶
deny continuation;¶
require rollback or compensation;¶
terminate the act;¶
or escalate to another protected authority.¶
A human override should preferably be separately authenticated and bound to the observed evidence and requested continuation scope.¶
Misalignment need not always require human intervention. The IEV may send the condition to an Automated Error-Correction or Escalation Controller.¶
The controller may propose:¶
evidence re-query;¶
stronger attestation;¶
bounded retry;¶
reduced next-phase scope;¶
alternate authorized sink;¶
rollback;¶
compensation;¶
reconciliation;¶
quarantine;¶
a new bounded trial;¶
fail-limited mode;¶
or protected human review.¶
The automated controller need not itself receive unrestricted authority. Its proposed remediation may return to the IEV for validation before a bounded remediation authority is issued.¶
A generalized IEV decision set may be:¶
\begin{aligned} \operatorname{IEVDecision}_i\in\{&\mathrm{PASS},\ \mathrm{FAIL},\ \mathrm{HOLD},\ \mathrm{RETRY},\ \mathrm{RECONCILE},\\ &\mathrm{ESCALATE},\ \mathrm{HUMAN\_REVIEW},\ \mathrm{REDUCE\_SCOPE},\ \mathrm{TERMINATE}\}. \end{aligned}¶
If the IEV cannot independently establish whether the preceding phase occurred correctly:¶
IEVDecision_i=INDETERMINATE¶
then the next phase remains unavailable.¶
The system may obtain additional sink evidence, destination state, protected logs, idempotency state, sensor evidence, transaction status, replica evidence, quorum evidence, trusted time, hardware counters, or other reconciliation inputs.¶
No broader effect need be released until the indeterminate state is resolved under protected policy.¶
The IEV may form a protected middle decision plane:¶
\begin{aligned} \mathrm{Application/Agent} &\rightarrow FS_i \rightarrow \operatorname{RealEffect}_i \rightarrow R_i \rightarrow IEV_i\\ &\rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow \operatorname{RealEffect}_{i+1}. \end{aligned}¶
The IEV may be positioned locally, remotely, on-chip, off-chip, within the same physical component, or across multiple protected components. The controlling concept is the protected causal position between evidence of one real effectuation phase and authority for the next phase.¶
In one embodiment, the IEV resides inside the same SoC as the executor or Finality Sink but within a separate protected security domain.¶
A representative chain is:¶
\begin{aligned} \mathrm{ApplicationCPU} &\rightarrow \mathrm{HardwareFS} \rightarrow P_i \rightarrow \mathrm{ProtectedCompletionState}\\ &\rightarrow \mathrm{OnChipIEV} \rightarrow CVI_{i+1} \rightarrow \mathrm{HardwareFS} \rightarrow P_{i+1}. \end{aligned}¶
The IEV may have independent key storage, protected SRAM, policy state, monotonic counters, validation logic, secure boot measurement, and receipt-verification logic.¶
The IEV may instead reside in another device or protected service:¶
Device_A \rightarrow P_i \rightarrow Device_B \rightarrow R_i \rightarrow IndependentValidator_C \rightarrow CVI_{i+1} \rightarrow FS_A¶
Such separation may provide administrative, hardware, manufacturer, jurisdictional, or operational independence.¶
An AI agent proposes sending a sensitive file.¶
Phase 0 causes a real bounded trailer or protected pre-release object to reach the intended recipient. The recipient generates R_0 confirming the actual endpoint, recipient, trailer digest, and relevant path state.¶
The receipt is not used directly by the agent to release the full file. Instead:¶
R_0 \rightarrow IEV_0¶
The IEV verifies recipient, endpoint, trailer digest, message binding, route, freshness, receipt authenticity, policy, and expected destination state.¶
If all required conditions match:¶
IEV_0\rightarrow CVI_1¶
The Finality Sink verifies CVI_1 and only then releases the remaining payload or decryption key.¶
If the recipient or endpoint differs from the authorized destination, the IEV may block, reduce scope, reconcile, or route the matter to protected human review.¶
A Candidate Payment Act requests transfer of a larger authorized amount.¶
The Finality Sink first performs a bounded real verification transfer, reservation, hold, or other rail-supported bounded financial effect.¶
The payment infrastructure returns R_0. The IEV independently verifies payer, beneficiary, account, rail, bounded amount, asset/currency, transaction identifier, settlement/hold state, policy, and receipt authenticity.¶
Only after successful validation does the IEV provide CVI_1 or equivalent continuation material to the payment Finality Sink.¶
A mismatch may cause:¶
HOLD,\quad HUMAN\_REVIEW,\quad RECONCILE,\quad REDUCE\_SCOPE,\quad or\quad TERMINATE¶
rather than automatic broader payment.¶
Suppose the requested total movement is:¶
90^{\circ}¶
The first real phase permits:¶
5^{\circ}¶
A protected sensor reports an observed movement such as:¶
O_0=4.98^{\circ}¶
The IEV checks:¶
|4.98^{\circ}-5^{\circ}|\le\epsilon_0¶
and additionally verifies actuator identity, sensor identity, fault state, nonce, time window, policy, and applicable safety state.¶
If valid, the IEV issues CVI_1, allowing the hardware Finality Sink to release the next movement envelope. The sensor does not directly authorize the remaining movement; the IEV independently interprets the protected sensor evidence.¶
The IEV may require multiple evidence sources, for example:¶
R_i^{Sink},\quad R_i^{Destination},\quad R_i^{Sensor},\quad R_i^{Network}¶
Continuation may require conjunction:¶
\bigwedge_{j=1}^{m} Valid(R_i^j)=TRUE¶
or a threshold/quorum rule:¶
\sum_{j=1}^{n} Valid(R_i^j)\ge m¶
This may prevent a single compromised observer from automatically causing progression.¶
Physical separation is not required.¶
A single chip, processor, controller, or service may implement both IEV and Finality Sink functions provided protected state preserves the causal separation between:¶
Thus:¶
PhysicalComponent_{IEV}=PhysicalComponent_{FS}¶
may be permitted while the protected decision functions remain logically distinct.¶
Where interim validation is mandatory, the next phase must not remain available through an alternate path that ignores the IEV.¶
Equivalent continuation paths may therefore require an IEV-issued instruction, IEV-controlled state, IEV-derived key/share, IEV signature, IEV counter transition, protected latch, threshold participation, or an equivalent protected condition.¶
If an act-equivalent alternate path can cause P_{i+1} without equivalent interim validation, that path must be disabled, mediated, capability-restricted, cryptographically locked, hardware-gated, transaction-gated, or subjected to corresponding protected validation.¶
Invariant 1. At least one earlier real effectuation phase occurs or is attempted through an effect-capable boundary.¶
Invariant 2. Evidence describing the actual earlier effect is made available to an IEV.¶
Invariant 3. The IEV evaluates that evidence independently of a mere success assertion by the Candidate Act source.¶
Invariant 4. A required later phase remains unavailable until the IEV accepts the earlier effect or an explicitly authorized escalation/remediation path completes.¶
Invariant 5. The IEV may be software, firmware, hardware, on-chip, off-chip, local, remote, centralized, distributed, or combined with another protected component.¶
Invariant 6. Mismatch, failure, uncertainty, or policy deviation may block progression, reduce scope, invoke remediation, enter reconciliation, or invoke protected human escalation.¶
Invariant 7. Physical placement does not define the architecture; the controlling property is the protected causal position of the IEV between evidence of one real effectuation phase and authority for a subsequent phase.¶
The embodiment may be summarized as:¶
\boxed{ \begin{aligned} \operatorname{RealEffect}_i &\rightarrow \operatorname{ProtectedEvidence}_i \rightarrow \operatorname{IndependentIEVValidation}_i\\ &\rightarrow \operatorname{ContinuationAuthority}_{i+1} \rightarrow FS_{i+1} \rightarrow \operatorname{RealEffect}_{i+1} \end{aligned} }¶
The IEV operates as a protected inter-phase judgment boundary. It does not itself need to perform the external effect. It independently determines whether evidence generated by an earlier real effect is sufficiently aligned with the authorized act and continuation requirements, and only thereafter permits the Finality Sink to produce the next consequential effect.¶
\newpage¶
The IEV architecture may be incorporated into any compatible single-phase, two-phase, multi-phase, software, hardware, network, transaction, communication, payment, storage, database, cloud, AI-tool, credential, data-release, robotic, vehicular, industrial, telecom, radio, satellite, accelerator, model-state, software-update, distributed, multi-destination, quorum, reconciliation, or recovery embodiment in which a later consequential phase can be made dependent on protected evaluation of evidence from an earlier phase.¶
Where an embodiment includes effectuation events or protected transitions P_0,P_1,\ldots,P_n, an IEV may be inserted between selected phases:¶
P_i \rightarrow R_i \rightarrow IEV_i \rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1}¶
The IEV need not replace an existing Finality Sink, PED, receipt verifier, hardware gate, policy engine, transaction controller, or effect observer. It may be inserted as an additional protected validation layer in the continuation path.¶
For an existing embodiment having:¶
P_i \rightarrow R_i \rightarrow ContinuationAuthority_{i+1} \rightarrow P_{i+1}¶
an IEV-enabled version may replace the direct transition with:¶
P_i \rightarrow R_i \rightarrow IEV_i \rightarrow ValidatedContinuationState_i \rightarrow ContinuationAuthority_{i+1} \rightarrow P_{i+1}¶
The IEV therefore becomes a required consumer of phase-i evidence.¶
A receipt merely existing is insufficient:¶
ReceiptExists_i=TRUE¶
The protected continuation condition may instead require:¶
ReceiptValid_i \land IEVPass_i =TRUE¶
before broader effectuation is technically enabled.¶
Each effectuation phase may produce a structured Interim Validation Input Record:¶
IVIR_i¶
A non-limiting structure is:¶
\begin{aligned} IVIR_i=\{&D_A,\ PhaseID_i,\ H(C_i),\ X_i,\ O_i,\\ &SinkID_i,\ DestinationID_i,\ ObserverID_i,\\ &ResourceID_i,\ TransactionID_i,\ Nonce_i,\\ &Counter_i,\ PE_i,\ RE_i,\ ResultCode_i,\\ &H(R_i),\ Timestamp_i\}. \end{aligned}¶
The IVIR may be formed from an ECR, completion receipt, sensor receipt, payment receipt, database commit receipt, network receipt, storage receipt, hardware event, or equivalent protected evidence.¶
It may be authenticated using digital signature, MAC, attestation, authenticated hardware mailbox, protected shared memory, secure interrupt, secure RPC, measured IPC channel, hardware register, transaction record, or equivalent integrity-protected transport.¶
The IEV rejects an unauthenticated or structurally invalid IVIR.¶
The IEV may maintain protected state S^{IEV}_i containing one or more of:¶
D_A;¶
Envelope_{MAX};¶
current phase identifier;¶
expected prior phase;¶
expected sink, destination, and observer;¶
acceptable result or tolerance;¶
minimum receipt quality;¶
policy and revocation epochs;¶
allowed continuation scope;¶
permitted phase sequence;¶
receipt-consumption state;¶
retry state;¶
human-escalation state;¶
reconciliation state;¶
taint and provenance requirements;¶
current risk state;¶
monotonic counter;¶
continuation-authority status.¶
The state may reside in protected process memory, kernel-protected memory, enclave memory, secure-element memory, HSM state, TPM NV storage, protected SRAM, secure flash, FPGA registers, ASIC state, hardware counters, protected database state, replicated consensus state, or other tamper-resistant/access-controlled storage.¶
The Candidate Act source preferably lacks arbitrary write authority to S^{IEV}_i.¶
A concrete validation operation may comprise:¶
authenticate the receipt source;¶
confirm Candidate Act binding;¶
confirm the phase identifier;¶
confirm prior phase authority where applicable;¶
verify sink identity;¶
verify destination or recipient identity;¶
verify resource identity;¶
verify observer identity where applicable;¶
verify receipt freshness;¶
verify nonce/counter state;¶
verify absence of replay;¶
compare expected and observed effects;¶
verify policy epoch;¶
verify revocation state;¶
verify risk, taint, and provenance predicates;¶
determine whether the requested next phase remains inside Envelope_{MAX};¶
determine whether additional human or threshold approval is required;¶
atomically record the validation result.¶
For example:¶
\begin{aligned} IEVPass_i ={}& AuthValid(R_i) \land ActMatch(R_i,D_A) \land PhaseMatch(R_i,i)\\ &\land SinkMatch(R_i) \land DestinationMatch(R_i) \land Fresh(R_i)\\ &\land NotConsumed(R_i) \land EffectAcceptable(O_i,X_i)\\ &\land PolicyCurrent \land RevocationClear \land WithinEnvelope(P_{i+1}). \end{aligned}¶
Only if all required predicates evaluate to an acceptable protected state does ordinary continuation proceed.¶
O_i=X_i¶
|O_i-X_i|\le\epsilon_i¶
or, for structured effects:¶
d(O_i,X_i)\le\epsilon_i¶
L_i\le O_i\le U_i¶
O_i\in\mathcal{A}_i¶
\bigwedge_{j=1}^{k}Pred_j(O_i)=TRUE¶
These alternatives permit the IEV to operate across digital, transactional, network, and physical systems.¶
After successful evaluation, the IEV may create:¶
CVI_{i+1}¶
A representative structure is:¶
\begin{aligned} CVI_{i+1}=Protect_{K_{IEV}}(&D_A \parallel (i+1) \parallel H(R_i) \parallel Scope(P_{i+1})\\ &\parallel Sink_{i+1} \parallel Destination_{i+1} \parallel PE\\ &\parallel Counter_{IEV} \parallel Expiry). \end{aligned}¶
The CVI may therefore bind the original act, prior verified effect, next phase, next scope, next sink, next destination, protected epoch, validator counter, and validity period.¶
The next Finality Sink may independently verify:¶
Verify_{IEV}(CVI_{i+1})¶
MatchAct(CVI_{i+1},D_A)¶
MatchReceipt(CVI_{i+1},H(R_i))¶
MatchPhase(CVI_{i+1},i+1)¶
MatchScope(CVI_{i+1},P_{i+1})¶
MatchSink(CVI_{i+1},FS_{i+1})¶
and may additionally verify destination, policy epoch, freshness, expiry, counter, consumption state, and protected local state.¶
A CVI for one Candidate Act, phase, destination, sink, scope, or epoch therefore need not be valid for another.¶
A stronger implementation makes the IEV technically indispensable by placing part of the next-phase execution material under IEV control.¶
For example:¶
K^{IEV}_{i+1} = KDF\left( K^{IEV}_{root}, D_A, H(R_i), i+1, Sink_{i+1}, Counter_{IEV} \right)¶
The Finality Sink may require that material to authenticate, decrypt, unwrap, sign, schedule, commit, transmit, or actuate the next phase.¶
Without successful IEV validation:¶
IEVPass_i\neq TRUE \Rightarrow K^{IEV}_{i+1}\ unavailable¶
The next phase may therefore be cryptographically non-completable rather than merely policy-disallowed.¶
The Finality Sink may hold its own protected share K^{FS}_{i+1} while the IEV controls K^{IEV}_{i+1}.¶
The usable next-phase authority may require:¶
K^{Final}_{i+1} = Combine\left(K^{FS}_{i+1},K^{IEV}_{i+1}\right)¶
Thus:¶
K^{FS}_{i+1}\ alone \not\Rightarrow Enable(P_{i+1})¶
and:¶
K^{IEV}_{i+1}\ alone \not\Rightarrow Effectuate(P_{i+1})¶
Both protected conditions are required.¶
Instead of or in addition to cryptographic key material, the IEV may control protected hardware state L_{IEV}.¶
A next-phase enable condition may be:¶
ENABLE_{i+1} = FSValid_{i+1} \land (L_{IEV}=PASS_i)¶
The latch may reside in FPGA logic, ASIC logic, secure MCU, safety controller, motor controller, NIC, SmartNIC, DPU, storage controller, memory controller, GPU security processor, modem, baseband, ECU, PLC, actuator controller, or another hardware component.¶
Ordinary application software preferably cannot directly write the protected latch.¶
Where the IEV and Finality Sink reside in separate hardware or trust domains, the IEV may place CVI_{i+1} into an authenticated secure mailbox:¶
Mailbox_{IEV\rightarrow FS}¶
The mailbox may enforce authenticated sender identity, sequence numbers, monotonic counters, one-time consumption, fixed destination, integrity protection, confidentiality where required, interrupt binding, and acknowledgement.¶
The Finality Sink accepts continuation only from the protected IEV mailbox or an equivalent authenticated source.¶
A software PED implementation may operate as follows:¶
an agent issues a bounded Candidate Act;¶
a kernel/service Finality Sink permits P_0;¶
an authenticated result event is delivered to a privileged IEV process;¶
the IEV validates the receipt;¶
the IEV updates protected continuation state;¶
a kernel hook permits P_1 only if that state is valid.¶
A representative chain is:¶
\begin{aligned} \mathrm{Agent} &\rightarrow \mathrm{FinalityGate} \rightarrow P_i \rightarrow \mathrm{Receipt/Event} \rightarrow \mathrm{PrivilegedIEV}\\ &\rightarrow \mathrm{ProtectedContinuationState} \rightarrow \mathrm{Kernel/NetworkGate} \rightarrow P_{i+1}. \end{aligned}¶
The application cannot directly alter the IEV state.¶
A network embodiment may use:¶
\begin{aligned} \mathrm{Application} &\rightarrow \mathrm{EgressFS} \rightarrow \operatorname{BoundedNetworkEffect}_i \rightarrow R_i \rightarrow IEV_i\\ &\rightarrow CVI_{i+1} \rightarrow \mathrm{EgressFS} \rightarrow \operatorname{BroaderTransmission}_{i+1}. \end{aligned}¶
The network Finality Sink may be a host proxy, API gateway, service mesh, firewall, NIC, SmartNIC, DPU, router, switch, telecom gateway, or remote service.¶
The second-phase traffic may carry an IEV-issued authenticator, reference to CVI_{i+1}, or a phase-specific key derived from IEV approval.¶
For database or transaction embodiments:¶
TX_i \rightarrow COMMIT_i \rightarrow CommitReceipt_i \rightarrow IEV_i \rightarrow PromotionPermit_{i+1} \rightarrow TX_{i+1}¶
The database may store protected transaction metadata such as:¶
IEV\_APPROVED_{i+1}=TRUE¶
A trigger, transaction manager, commit hook, WAL controller, database policy module, or native state machine may refuse the next commit unless the protected validation state is present.¶
A storage controller may first persist Object_i in a restricted namespace and generate a durable-state receipt.¶
The IEV may verify object digest, storage target, media/controller identity, namespace, replication state, durability state, destination, and policy.¶
The IEV then authorizes promotion into a broader visible state or key release:¶
RestrictedStorage_i \rightarrow R_i \rightarrow IEV_i \rightarrow PromotionAuthority_{i+1} \rightarrow VisibleStorage_{i+1}¶
For SEND:¶
Trailer_i \rightarrow Recipient \rightarrow R_i \rightarrow IEV_i \rightarrow CVI^{SEND}_{i+1} \rightarrow MessageFS \rightarrow FullOrBroaderMessage_{i+1}¶
The IEV may verify exact recipient, service identity, device identity, endpoint, trailer digest, message digest binding, route, receipt freshness, policy, and replay state.¶
A receipt from another recipient or endpoint does not satisfy the continuation condition for the authorized target.¶
For payment:¶
BoundedPayment_i \rightarrow PaymentReceipt_i \rightarrow IEV_i \rightarrow SettlementPermit_{i+1} \rightarrow PaymentFS \rightarrow Payment_{i+1}¶
The IEV may verify payer, beneficiary, account, wallet, asset, currency, amount, rail, transaction identifier, hold/reservation state, settlement state, risk state, policy, and receipt authenticity.¶
The next payment stage may require an IEV-generated signature share, state transition, permit, or key share.¶
For physical systems:¶
Motion_i \rightarrow SensorEvidence_i \rightarrow IEV_i \rightarrow MotionPermit_{i+1} \rightarrow ActuatorFS \rightarrow Motion_{i+1}¶
The IEV may evaluate position, velocity, acceleration, current, torque, pressure, temperature, fault state, location, geofence, obstacle state, sensor agreement, controller identity, and safety envelope.¶
The IEV may be implemented by a dedicated safety MCU or security island separate from the autonomous planning controller.¶
For telecommunications or radio:¶
\begin{aligned} \operatorname{BoundedTransmission}_i &\rightarrow \operatorname{NetworkRFReceipt}_i \rightarrow IEV_i \rightarrow \operatorname{TransmissionPermit}_{i+1}\\ &\rightarrow \mathrm{RF/NetworkFS} \rightarrow \operatorname{BroaderTransmission}_{i+1}. \end{aligned}¶
The IEV may validate carrier/band, frequency, channel, beam, power, duration, cell, destination, route, bearer, network slice, satellite/gateway identity, receiver acknowledgement, interference state, and applicable safety conditions.¶
The next transmission key, scheduler permit, bearer expansion, or RF authority may remain unavailable before IEV approval.¶
For accelerator systems:¶
ComputePhase_i \rightarrow DeviceReceipt_i \rightarrow IEV_i \rightarrow ReleasePermit_{i+1} \rightarrow GPU/DPU/MemoryFS \rightarrow Effect_{i+1}¶
The IEV may validate accelerator identity, measured firmware, model/workload digest, memory region, command queue, device counter, output digest, protected execution state, DMA destination, and allowed egress.¶
Successful computation alone need not permit broader external data release, tool invocation, SEND, payment, or another consequential effect.¶
For tool use:¶
ToolEffect_i \rightarrow ToolReceipt_i \rightarrow IEV_i \rightarrow ToolContinuationPermit_{i+1} \rightarrow ToolFS \rightarrow NextToolEffect_{i+1}¶
The IEV may independently verify tool identity, method, arguments, resource, account, destination, actual result, side-effect scope, authorization envelope, and next requested tool operation.¶
The AI cannot self-certify that the prior tool call was successful.¶
For model memory, vector stores, or persistent AI state:¶
ProvisionalState_i \rightarrow StateReceipt_i \rightarrow IEV_i \rightarrow PromotionPermit_{i+1} \rightarrow StateFS \rightarrow CommittedState_{i+1}¶
The IEV may validate namespace, model/user identity, provenance, taint, vector/object identifiers, write-set digest, retention policy, conflict state, and resulting storage state.¶
For updates:¶
CanaryActivation_i \rightarrow HealthReceipt_i \rightarrow IEV_i \rightarrow RolloutPermit_{i+1} \rightarrow UpdateFS \rightarrow BroaderActivation_{i+1}¶
The IEV may verify artifact digest, signer, device/host cohort, boot state, error rate, crash state, health checks, compatibility state, rollback availability, security measurements, and policy.¶
Where phase i affects destinations D_1,D_2,\ldots,D_n, the IEV may receive:¶
R_i^1,R_i^2,\ldots,R_i^n¶
Continuation may require all:¶
\bigwedge_{j=1}^{n}Valid(R_i^j)=TRUE¶
or a quorum:¶
\sum_{j=1}^{n}Valid(R_i^j)\ge m¶
or a role-weighted/critical-node rule.¶
The IEV may then determine which destinations may proceed. A failed destination need not cause authority to be granted to another destination unless protected policy permits it.¶
The IEV itself may be distributed.¶
Let:¶
IEV^1,IEV^2,\ldots,IEV^n¶
be independent validator instances.¶
Continuation may require:¶
\sum_{j=1}^{n}Pass(IEV^j)\ge m¶
The resulting continuation instruction may be threshold-signed, multi-signed, consensus committed, Merkle committed, replicated, or otherwise collectively authenticated.¶
No single validator need control continuation.¶
When:¶
IEVDecision_i=ESCALATE¶
or:¶
IEVDecision_i=HUMAN\_REVIEW¶
the IEV may generate a Protected Escalation Record:¶
PER_i¶
For example:¶
\begin{aligned} PER_i=Protect(&D_A, H(R_i), X_i, O_i, Deviation_i,\\ &RequestedNextPhase_i, Risk_i, PE_i). \end{aligned}¶
The protected human interface displays relevant evidence. A human response H_i may be bound to both H(R_i) and H(PER_i) before becoming effective.¶
The human thereby approves the actual observed deviation and proposed continuation rather than an unrelated generic request.¶
An automated remediation component may receive PER_i or an equivalent protected error record and propose:¶
\begin{aligned} \operatorname{Action}_i\in\{&\mathrm{REQUERY},\ \mathrm{REATTEST},\ \mathrm{RETRY},\ \mathrm{REDUCE},\ \mathrm{ROLLBACK},\\ &\mathrm{COMPENSATE},\ \mathrm{ALTERNATE\_SINK},\ \mathrm{QUARANTINE},\ \mathrm{HUMAN},\ \mathrm{TERMINATE}\}. \end{aligned}¶
The error controller does not automatically receive unrestricted continuation authority.¶
A protected sequence may be:¶
ErrorControllerProposal \rightarrow IEV_i \rightarrow RemediationAuthority_i¶
To prevent replay, successful IEV validation may atomically:¶
Consumed(R_i)=TRUE¶
PhaseState=i+1¶
CVI_{i+1}=ISSUED¶
A representative protected transaction is:¶
Atomic\{Consume(R_i);\ AdvancePhase();\ Issue(CVI_{i+1});\}¶
This prevents a crash between validation and consumption from allowing the same receipt to independently authorize multiple next-phase effects.¶
If the IEV approves continuation but the Finality Sink crashes before confirming consumption, protected state may record:¶
CVIState_{i+1}=ISSUED\_NOT\_CONFIRMED¶
After recovery, the system queries Finality Sink consumption/effect state rather than blindly issuing a second equivalent authority.¶
If consumption is proven, the corresponding effect is reconciled. If non-consumption is proven, protected policy may permit reuse or replacement. If unknown, the system enters an indeterminate state.¶
If CVI_{i+1} was consumed but the result of P_{i+1} is uncertain, the IEV does not simply reissue equivalent continuation authority.¶
Instead:¶
P_{i+1} \rightarrow Reconciliation \rightarrow R_{i+1}¶
must establish whether the phase was effected, not effected, partially effected, rolled back, compensated, or remains indeterminate.¶
A receipt from a valid but different operation must not enable continuation for the current operation.¶
For example, R_X is unacceptable for phase i if any required binding differs:¶
D_{A_X}\neq D_A¶
or:¶
Sink_X\neq Sink_i¶
or:¶
Destination_X\neq Destination_i¶
or:¶
Phase_X\neq i.¶
The receipt must therefore be contextually valid, not merely cryptographically authentic.¶
Where IEV validation is mandatory, all act-equivalent paths capable of causing P_{i+1} may be configured so that they lack at least one required execution condition unless the IEV has approved continuation.¶
Examples of missing conditions include:¶
signing key/share;¶
transaction role;¶
decryption material;¶
network permit;¶
hardware enable;¶
database role;¶
message-send credential;¶
actuator key;¶
DMA permission;¶
storage promotion bit;¶
RF scheduler permit;¶
protected phase state.¶
Thus:¶
BypassPath_{i+1} \not\supseteq RequiredMaterial_{i+1}¶
unless the bypass path is subjected to the same or equivalent IEV-controlled continuation process.¶
For avoidance of doubt, an embodiment that does not expressly repeat the words Interim Effectuation Validator may incorporate the IEV by the following technical transformation:¶
Identify a real effectuation phase or bounded consequence already present in the embodiment.¶
Cause the responsible Finality Sink, effect observer, destination, transaction system, sensor, or protected component to generate authenticated evidence describing that phase.¶
Route the authenticated evidence to an IEV having protected state and policy not arbitrarily writable by the Candidate Act source.¶
Cause the IEV to authenticate the evidence and compare the observed effect with the authorized and expected effect.¶
Where required conditions match, cause the IEV to generate or enable a phase-specific continuation condition.¶
Configure the next Finality Sink or effect-capable boundary to require that continuation condition before the next phase can become effective.¶
Where conditions do not match, withhold the continuation condition and invoke a protected failure, reconciliation, automated-remediation, reduced-scope, or human-escalation path.¶
This provides a concrete technical method for incorporating the IEV into compatible embodiments without reproducing the complete validator description in every domain-specific section.¶
Where an IEV is incorporated, the architecture may satisfy:¶
\boxed{ \begin{aligned} \operatorname{Effect}_i &\rightarrow \operatorname{AuthenticatedEvidence}_i \rightarrow \operatorname{IndependentIEVValidation}_i\\ &\rightarrow \operatorname{ProtectedContinuationCondition}_{i+1} \rightarrow FS_{i+1} \rightarrow \operatorname{Effect}_{i+1} \end{aligned} }¶
Accordingly, the statement that an IEV may be used is not merely an abstract policy option. It may specifically mean that:¶
authenticated evidence is generated from a real preceding effect;¶
protected IEV state receives and evaluates that evidence;¶
the IEV produces a cryptographically, electronically, transactionally, or logically enforced continuation condition; and¶
the next effect-capable boundary is technically unable, or is configured not, to effectuate the protected next phase without satisfaction of that condition.¶
\newpage¶
ALGORITHM: INTERIM_EFFECTUATION_VALIDATOR_WORKFLOW
PURPOSE:
Permit a first real effectuation phase.
Obtain protected evidence describing what actually occurred.
Independently validate that evidence in an Interim Effectuation Validator (IEV).
Permit a subsequent effectuation phase only if:
(a) the IEV accepts the earlier effect, or
(b) an explicitly authorized escalation/remediation path permits continuation.
----------------------------------------------------------------------
INPUTS
----------------------------------------------------------------------
CandidateAct A
ActDigest D_A
AuthorizedMaximum Envelope_MAX
PhasePlan:
P_0, P_1, ... P_n
ProtectedPolicy Policy
PolicyEpoch PE
RevocationEpoch RE
ExpectedSink[i]
ExpectedDestination[i]
ExpectedEffect[i]
AllowedTolerance[i]
ApprovalMode[i]:
AUTOMATIC
HUMAN
HYBRID
PREAUTHORIZED
THRESHOLD
Protected IEV State S_IEV
FinalitySink FS[i]
EffectObserver EO[i]
Optional:
HumanApprovalSystem HAS
AutomatedErrorController AEC
ReconciliationController RC
ProtectedReceiptStore PRS
----------------------------------------------------------------------
PROTECTED STATE INITIALIZATION
----------------------------------------------------------------------
S_IEV.act_digest := D_A
S_IEV.maximum_envelope := Envelope_MAX
S_IEV.current_phase := 0
S_IEV.policy_epoch := PE
S_IEV.revocation_epoch := RE
S_IEV.status := READY_FOR_PHASE_0
S_IEV.consumed_receipts := EMPTY_SET
S_IEV.issued_CVI := EMPTY_SET
S_IEV.retry_count := 0
S_IEV.escalation_state := NONE
S_IEV.reconciliation_state := NONE
----------------------------------------------------------------------
STEP 1 - RECEIVE CANDIDATE ACT
----------------------------------------------------------------------
function RECEIVE_CANDIDATE_ACT(A):
D_A := HASH(CANONICALIZE(A))
if D_A != S_IEV.act_digest:
return BLOCK("Candidate Act mismatch")
if A exceeds Envelope_MAX:
return BLOCK("Candidate Act exceeds authorized maximum")
if REVOCATION_ACTIVE(A, RE):
return BLOCK("Candidate Act revoked")
proceed to PHASE_0_AUTHORIZATION
----------------------------------------------------------------------
STEP 2 - AUTHORIZE FIRST REAL EFFECTUATION PHASE
----------------------------------------------------------------------
function PHASE_0_AUTHORIZATION():
P_0 := PhasePlan[0]
verify:
P_0 is within Envelope_MAX
ExpectedSink[0] is authorized
ExpectedDestination[0] is authorized
Policy is current
Required initial approval is satisfied
if validation fails:
return BLOCK
create or activate Phase0Authority C_0
bind C_0 to:
D_A
PhaseID = 0
Scope(P_0)
ExpectedSink[0]
ExpectedDestination[0]
PE
RE
nonce_0
expiry_0
send:
A
P_0
C_0
to:
FS[0]
----------------------------------------------------------------------
STEP 3 - FINALITY SINK VERIFIES PHASE 0
----------------------------------------------------------------------
function FINALITY_SINK_PHASE_0(A, P_0, C_0):
verify:
AuthorityValid(C_0)
MatchAct(C_0, D_A)
MatchPhase(C_0, 0)
MatchScope(C_0, P_0)
MatchSink(C_0, FS[0])
MatchDestination(C_0, ExpectedDestination[0])
Fresh(C_0)
NotRevoked(A)
if any required check fails:
return BLOCK
perform REAL EFFECT P_0
IMPORTANT:
This is an actual effectuation.
It is not merely:
simulation
dry-run
prediction
local preview
or model-generated expectation.
Result_0 := EFFECTUATE(P_0)
obtain actual-effect evidence
R_0 := GENERATE_EFFECT_RECEIPT(
D_A,
PhaseID=0,
Result_0,
ActualSink,
ActualDestination,
Observer,
TransactionID,
DeviceState,
nonce_0,
counter,
PE,
timestamp
)
send R_0 to Interim Effectuation Validator
----------------------------------------------------------------------
STEP 4 - CONSTRUCT INTERIM VALIDATION INPUT RECORD
----------------------------------------------------------------------
function BUILD_IVIR(R_i):
IVIR_i := {
ActDigest = D_A,
PhaseID = i,
PhaseAuthorityDigest = HASH(C_i),
ExpectedEffect = ExpectedEffect[i],
ObservedEffect = EXTRACT_OBSERVED_EFFECT(R_i),
SinkID = EXTRACT_SINK(R_i),
DestinationID = EXTRACT_DESTINATION(R_i),
ObserverID = EXTRACT_OBSERVER(R_i),
ResourceID = EXTRACT_RESOURCE(R_i),
TransactionID = EXTRACT_TRANSACTION(R_i),
Nonce = EXTRACT_NONCE(R_i),
Counter = EXTRACT_COUNTER(R_i),
PolicyEpoch = EXTRACT_POLICY_EPOCH(R_i),
ResultCode = EXTRACT_RESULT(R_i),
ReceiptDigest = HASH(R_i),
Timestamp = EXTRACT_TIME(R_i)
}
return IVIR_i
----------------------------------------------------------------------
STEP 5 - IEV AUTHENTICATES THE EVIDENCE
----------------------------------------------------------------------
function IEV_AUTHENTICATE(IVIR_i, R_i):
if NOT VERIFY_RECEIPT_AUTHENTICITY(R_i):
return FAIL_INVALID_RECEIPT
if IVIR_i.ActDigest != D_A:
return FAIL_ACT_SUBSTITUTION
if IVIR_i.PhaseID != S_IEV.current_phase:
return FAIL_WRONG_PHASE
if HASH(R_i) in S_IEV.consumed_receipts:
return FAIL_REPLAY
if NOT FRESH(R_i):
return FAIL_STALE
if IVIR_i.PolicyEpoch != CURRENT_POLICY_EPOCH():
return HOLD_POLICY_CHANGED
if REVOCATION_ACTIVE(A):
return FAIL_REVOKED
proceed to IEV_EFFECT_VALIDATION
----------------------------------------------------------------------
STEP 6 - IEV INDEPENDENTLY DETERMINES WHERE EFFECT OCCURRED
----------------------------------------------------------------------
function IEV_VALIDATE_EFFECT_LOCATION(IVIR_i):
if IVIR_i.SinkID != ExpectedSink[i]:
return MISALIGNMENT_WRONG_SINK
if IVIR_i.DestinationID != ExpectedDestination[i]:
return MISALIGNMENT_WRONG_DESTINATION
if ResourceBindingRequired:
if IVIR_i.ResourceID != ExpectedResource[i]:
return MISALIGNMENT_WRONG_RESOURCE
if ObserverBindingRequired:
if IVIR_i.ObserverID not in AuthorizedObservers[i]:
return MISALIGNMENT_INVALID_OBSERVER
return LOCATION_VALID
----------------------------------------------------------------------
STEP 7 - IEV INDEPENDENTLY COMPARES EXPECTED EFFECT WITH ACTUAL EFFECT
----------------------------------------------------------------------
function IEV_COMPARE_EFFECT(IVIR_i):
X_i := IVIR_i.ExpectedEffect
O_i := IVIR_i.ObservedEffect
choose comparison mode
CASE EXACT:
if O_i == X_i:
return EFFECT_VALID
else:
return EFFECT_MISALIGNED
CASE TOLERANCE:
if DISTANCE(O_i, X_i) <= AllowedTolerance[i]:
return EFFECT_VALID
else:
return EFFECT_MISALIGNED
CASE RANGE:
if LowerBound[i] <= O_i <= UpperBound[i]:
return EFFECT_VALID
else:
return EFFECT_MISALIGNED
CASE AUTHORIZED_SET:
if O_i in AuthorizedResultSet[i]:
return EFFECT_VALID
else:
return EFFECT_MISALIGNED
CASE PREDICATE_SET:
for each mandatory predicate p in EffectPredicates[i]:
result := p(O_i)
if result == FALSE:
return EFFECT_MISALIGNED
if result == UNKNOWN or INDETERMINATE:
return EFFECT_INDETERMINATE
return EFFECT_VALID
----------------------------------------------------------------------
STEP 8 - IEV CHECKS CURRENT PROTECTED CONDITIONS
----------------------------------------------------------------------
function IEV_CHECK_CURRENT_STATE(i):
verify:
CURRENT_POLICY_EPOCH == S_IEV.policy_epoch
OR permitted revalidation completed
RevocationClear == TRUE
RiskState acceptable
TaintState acceptable
ProvenanceState acceptable
ProposedNextPhase inside Envelope_MAX
Current phase == i
Required receipt quality satisfied
Required destination state satisfied
Required approval state satisfied
if any mandatory predicate is FALSE:
return FAIL
if any mandatory predicate is UNKNOWN or INDETERMINATE:
return INDETERMINATE
return PASS
----------------------------------------------------------------------
STEP 9 - FORM IEV DECISION
----------------------------------------------------------------------
function IEV_DECIDE(i, R_i):
AuthResult := IEV_AUTHENTICATE(IVIR_i, R_i)
LocationResult := IEV_VALIDATE_EFFECT_LOCATION(IVIR_i)
EffectResult := IEV_COMPARE_EFFECT(IVIR_i)
StateResult := IEV_CHECK_CURRENT_STATE(i)
if all required results == PASS or VALID:
IEVDecision_i := PASS
else if result indicates resolvable evidence uncertainty:
IEVDecision_i := RECONCILE
else if result indicates potentially recoverable technical error:
IEVDecision_i := RETRY_OR_REMEDIATE
else if protected policy requires human judgment:
IEVDecision_i := HUMAN_REVIEW
else if next phase may safely continue at reduced scope:
IEVDecision_i := REDUCE_SCOPE
else:
IEVDecision_i := TERMINATE
record IEVDecision_i in protected state
proceed according to decision
----------------------------------------------------------------------
STEP 10A - PASS PATH
----------------------------------------------------------------------
if IEVDecision_i == PASS:
NextPhase := i + 1
verify:
P_(i+1) exists
P_(i+1) <= Envelope_MAX
atomically:
mark R_i consumed
advance S_IEV.current_phase from i to i+1
create continuation state
create CVI_(i+1)
----------------------------------------------------------------------
STEP 10B - FORM CONTINUATION VALIDATION INSTRUCTION
----------------------------------------------------------------------
CVI_(i+1) := PROTECT_WITH_IEV_KEY({
ActDigest = D_A,
PriorPhase = i,
NextPhase = i+1,
PriorReceipt = HASH(R_i),
NextScope = Scope(P_(i+1)),
NextSink = ExpectedSink[i+1],
NextDestination = ExpectedDestination[i+1],
PolicyEpoch = CURRENT_POLICY_EPOCH,
IEVCounter = NEXT_COUNTER(),
Expiry = expiry_(i+1)
})
----------------------------------------------------------------------
OPTIONAL STRONGER CRYPTOGRAPHIC IMPLEMENTATION
----------------------------------------------------------------------
K_(i+1) := KDF(
K_IEV_ROOT,
D_A,
HASH(R_i),
i+1,
ExpectedSink[i+1],
IEVCounter
)
Without IEV PASS:
K_(i+1) does not exist
OR
K_(i+1) remains sealed
OR
IEV key share remains unavailable
----------------------------------------------------------------------
OPTIONAL SPLIT-KEY IMPLEMENTATION
----------------------------------------------------------------------
K_FINAL_(i+1) := COMBINE(
K_FS_(i+1),
K_IEV_(i+1)
)
Therefore:
Finality Sink alone cannot authorize next phase.
IEV alone cannot perform next effect.
Both protected conditions are required.
----------------------------------------------------------------------
STEP 11 - SEND CONTINUATION AUTHORITY TO FINALITY SINK
----------------------------------------------------------------------
SEND_TO_FINALITY_SINK(
CVI_(i+1),
P_(i+1),
A
)
----------------------------------------------------------------------
STEP 12 - FINALITY SINK VERIFIES IEV OUTPUT
----------------------------------------------------------------------
function FS_VERIFY_CVI(CVI_(i+1)):
verify:
IEV signature/MAC/attestation
ActDigest == D_A
PriorReceipt == HASH(R_i)
NextPhase == i+1
NextScope == requested scope
NextSink == this Finality Sink
NextDestination == authorized destination
PolicyEpoch current
Expiry valid
CVI not previously consumed
if any check fails:
BLOCK P_(i+1)
else:
mark CVI_(i+1) consumed
EFFECTUATE P_(i+1)
----------------------------------------------------------------------
STEP 13 - GENERATE NEXT RECEIPT
----------------------------------------------------------------------
after P_(i+1) occurs:
R_(i+1) := GENERATE_EFFECT_RECEIPT(...)
send R_(i+1) to IEV
repeat validation cycle
----------------------------------------------------------------------
GENERAL MULTI-PHASE LOOP
----------------------------------------------------------------------
for i = 0 to n-1:
EFFECTUATE P_i
R_i := RECEIVE_PROTECTED_EFFECT_EVIDENCE(P_i)
IVIR_i := BUILD_IVIR(R_i)
Decision := IEV_DECIDE(i, R_i)
if Decision == PASS:
CVI_(i+1) := ISSUE_PHASE_BOUND_CONTINUATION(R_i)
FS_(i+1).VERIFY(CVI_(i+1))
FS_(i+1).EFFECTUATE(P_(i+1))
else if Decision == REDUCE_SCOPE:
P_(i+1) := CALCULATE_REDUCED_PHASE()
issue restricted CVI_(i+1)
continue
else if Decision == HUMAN_REVIEW:
execute HUMAN_ESCALATION_WORKFLOW()
else if Decision == RETRY_OR_REMEDIATE:
execute AUTOMATED_ERROR_WORKFLOW()
else if Decision == RECONCILE:
execute RECONCILIATION_WORKFLOW()
else:
terminate progression
----------------------------------------------------------------------
HUMAN ESCALATION WORKFLOW
----------------------------------------------------------------------
function HUMAN_ESCALATION_WORKFLOW():
PER_i := PROTECT({
ActDigest = D_A,
ReceiptDigest = HASH(R_i),
ExpectedEffect = X_i,
ObservedEffect = O_i,
Deviation = DIFFERENCE(X_i, O_i),
CurrentPhase = i,
ProposedNext = P_(i+1),
RiskState = CurrentRisk,
PolicyEpoch = CurrentPolicyEpoch
})
send PER_i to protected human approval interface
HumanDecision := WAIT_FOR_PROTECTED_HUMAN_DECISION()
CASE HumanDecision:
APPROVE_AS_REQUESTED:
H_i := SIGN_PROTECTED_HUMAN_APPROVAL(
HASH(PER_i),
HASH(R_i),
Scope(P_(i+1))
)
send H_i back to IEV
IEV revalidates:
Human signature
Human role
Freshness
Act binding
Receipt binding
Scope
if valid:
issue CVI_(i+1)
APPROVE_REDUCED_SCOPE:
P_(i+1) := HumanSpecifiedReducedScope
verify P_(i+1) <= Envelope_MAX
issue restricted CVI_(i+1)
RETRY_TRIAL:
issue new bounded phase authority
with NEW nonce and NEW idempotency identifier
ROLLBACK:
issue rollback/remediation authority
DENY:
TERMINATE
ESCALATE_HIGHER:
route PER_i to higher protected authority
----------------------------------------------------------------------
AUTOMATED ERROR / REMEDIATION WORKFLOW
----------------------------------------------------------------------
function AUTOMATED_ERROR_WORKFLOW():
ErrorRecord := {
D_A,
HASH(R_i),
X_i,
O_i,
ErrorClass,
RiskState,
PhaseID=i
}
ProposedAction := AUTOMATED_ERROR_CONTROLLER(ErrorRecord)
ProposedAction may be:
REQUERY
REATTEST
RETRY
REDUCE_SCOPE
ROLLBACK
COMPENSATE
ALTERNATE_SINK
QUARANTINE
HUMAN_ESCALATION
TERMINATE
IMPORTANT:
Automated Error Controller does NOT itself receive
unrestricted authority to perform the next effect.
ProposedAction
->
return to IEV
->
IEV verifies remediation
->
IEV issues bounded RemediationAuthority
----------------------------------------------------------------------
RECONCILIATION WORKFLOW
----------------------------------------------------------------------
function RECONCILE_PHASE(i):
S_IEV.status := RECONCILING
obtain evidence from one or more of:
Finality Sink
Destination
Transaction ledger
Database
Storage controller
Hardware counter
Sensor
Message identifier
Network state
Replica
Protected journal
Idempotency record
determine:
PROVEN_EFFECTED
PROVEN_NOT_EFFECTED
PARTIALLY_EFFECTED
STILL_INDETERMINATE
CASE PROVEN_EFFECTED:
reconstruct/recover valid receipt
pass recovered receipt through IEV validation
DO NOT simply assume continuation
CASE PROVEN_NOT_EFFECTED:
a new bounded retry may be authorized
use:
new nonce
new authority
new idempotency identifier
CASE PARTIALLY_EFFECTED:
calculate residual state
determine:
compensation
reduced continuation
human escalation
termination
CASE STILL_INDETERMINATE:
keep next phase BLOCKED
----------------------------------------------------------------------
CRASH AFTER IEV APPROVAL
----------------------------------------------------------------------
if IEV issued CVI_(i+1)
and Finality Sink has not confirmed consumption:
store:
CVI_State = ISSUED_NOT_CONFIRMED
after restart:
query Finality Sink consumption state
if PROVEN_NOT_CONSUMED:
allow same protected CVI or authorized replacement
if PROVEN_CONSUMED:
do NOT issue another equivalent CVI
reconcile P_(i+1)
if UNKNOWN:
enter INDETERMINATE
----------------------------------------------------------------------
CRASH AFTER EFFECT BUT BEFORE RECEIPT
----------------------------------------------------------------------
if FS performed P_i
but R_i was not delivered:
DO NOT blindly execute P_i again
query using:
ActDigest
PhaseID
nonce
transaction ID
idempotency identifier
protected counter
reconcile before retry
----------------------------------------------------------------------
REPLAY PROTECTION
----------------------------------------------------------------------
before accepting any R_i:
if HASH(R_i) in S_IEV.consumed_receipts:
REJECT
before accepting any CVI_i:
if CVI_i previously consumed:
REJECT
----------------------------------------------------------------------
ANTI-BYPASS RULE
----------------------------------------------------------------------
for each ActEquivalentPath capable of P_(i+1):
require at least one protected condition controlled by:
IEV
OR
equivalent protected interim validation logic
examples:
IEV signature
IEV key share
IEV state bit
IEV hardware latch
IEV transaction state
IEV network permit
IEV protected register
IEV threshold share
if alternate path can effectuate P_(i+1)
without any equivalent condition:
architecture is NOT non-bypassable
protect, disable, or mediate alternate path
----------------------------------------------------------------------
FINAL PHASE
----------------------------------------------------------------------
when P_n completes:
R_n := obtain final protected evidence
IEV verifies R_n
if valid:
S_IEV.status := FULLY_EFFECTED
FinalReceipt := PROTECT({
D_A,
HASH(R_0),
HASH(R_1),
...
HASH(R_n),
FinalState,
IEVCounter,
PolicyEpoch
})
store FinalReceipt
else:
enter failure/reconciliation path¶
The operational sequence is therefore:¶
\boxed{ Candidate\ Act \rightarrow FS_0 \rightarrow Real\ Effect_0 \rightarrow R_0 \rightarrow IEV }¶
The IEV then performs:¶
Authenticate \rightarrow Bind \rightarrow Compare \rightarrow Evaluate \rightarrow Decide¶
If everything matches:¶
IEV \rightarrow CVI_1 \rightarrow FS_1 \rightarrow Real\ Effect_1¶
and then:¶
R_1 \rightarrow IEV \rightarrow CVI_2 \rightarrow FS_2 \rightarrow Real\ Effect_2¶
until completion.¶
If misalignment occurs:¶
R_i \rightarrow IEV \rightarrow \begin{cases} HumanReview\\ AutomatedRemediation\\ ReducedScope\\ Reconciliation\\ Rollback\\ Compensation\\ Termination \end{cases}¶
The particularly important technical relationship is:¶
\boxed{ Receipt\ existence \neq Continuation\ authority }¶
Instead:¶
\boxed{ Authenticated\ Receipt + Independent\ IEV\ Validation = Eligibility\ for\ Next\ Phase }¶
and in the stronger implementation:¶
\boxed{ IEV\ PASS \rightarrow Missing\ Execution\ Material \rightarrow Finality\ Sink \rightarrow Next\ Effect }¶
This means the IEV is not merely an auditor. It is inside the causal execution path between real effects. \newpage¶
Phase indexing. P_i is the real effectuation phase whose outcome is described by R_i. The IEV validates R_i before ordinary progression to P_{i+1}.¶
Continuation indexing. CVI_{i+1} is always the continuation instruction associated with the next phase P_{i+1} and is bound to H(R_i).¶
Expected versus observed effect. X_i is the protected expected result; O_i is the protected observed result. Acceptance may use exact equality, a distance/tolerance function, a range, set membership, or protected predicates.¶
Envelope rule. No successful receipt or IEV decision enlarges the operation beyond Envelope_{MAX} unless a new protected authorization explicitly changes that envelope.¶
Key derivation. K^{IEV}_{i+1} is shown as one non-limiting receipt-dependent construction. The essential property is protected dependence on accepted evidence from phase i, not use of a specific KDF.¶
Split-key rule. K^{Final}_{i+1}=Combine(K^{FS}_{i+1},K^{IEV}_{i+1}) is illustrative. Threshold signatures, hardware unsealing, state bits, command authenticators, transaction roles, or equivalent mechanisms may provide the same causal dependence.¶
Human escalation. Human approval does not automatically erase the earlier mismatch. A protected human decision should be bound to the relevant receipt/evidence, deviation, next-phase scope, and act identity.¶
Indeterminate state. Absence of proof of effect is not treated as proof of non-effect. Where effect status is unresolved, the architecture may remain blocked pending reconciliation.¶
Atomicity. Receipt consumption, phase advancement, and issuance of a next-phase continuation condition should preferably be atomic or protected by equivalent replay-safe state machinery.¶
Non-bypassability. Any act-equivalent path capable of producing the protected next effect should require the IEV-controlled condition or an equivalent protected interim-validation condition where the architecture is intended to be non-bypassable.¶
The three Parts reduce to the following protected causal relationships:¶
\boxed{ Receipt\ existence \neq Continuation\ authority }¶
\boxed{ AuthenticatedReceipt_i + IndependentIEVValidation_i \Rightarrow EligibilityFor(P_{i+1}) }¶
For a cryptographically stronger implementation:¶
\boxed{ IEVPass_i \rightarrow MissingExecutionMaterial_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} }¶
For repeated multi-phase operation:¶
\boxed{ P_i \rightarrow R_i \rightarrow IEV_i \rightarrow CVI_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} }¶
The IEV is therefore positioned inside the causal chain between real effects rather than functioning merely as a post-event auditor.¶
\newpage¶
This Part extends the IEV architecture to three failure surfaces: (i) failure, compromise, or inconsistency of the validator itself; (ii) multiple authentic but mutually incompatible evidence objects; and (iii) revocation or state change after IEV PASS but before Finality-Sink consumption.¶
Let the IEV receive¶
\mathbf{R}_i = \left( R_i^{(1)}, R_i^{(2)}, \ldots, R_i^{(n_i)} \right).¶
Each evidence object may authenticate independently:¶
a_{i,j} = \operatorname{AuthValid}\!\left(R_i^{(j)}\right).¶
Authentication and consistency are different properties.¶
For evidence sources j and k, define¶
c_{i,jk} = \operatorname{Consistent}\!\left(R_i^{(j)},R_i^{(k)}\right).¶
A protected conflict exists when¶
\operatorname{Conflict}_i = \bigvee_{1\leq j<k\leq n_i} \left( a_{i,j} \land a_{i,k} \land \neg c_{i,jk} \right).¶
Thus¶
\operatorname{AuthValid}\!\left(R_i^{(j)}\right) \land \operatorname{AuthValid}\!\left(R_i^{(k)}\right)¶
does not imply¶
\operatorname{Consistent}\!\left(R_i^{(j)},R_i^{(k)}\right).¶
The IEV may distinguish the evidence state¶
E_i\in \left\{ \mathrm{VALID\_CONSISTENT}, \mathrm{INVALID}, \mathrm{CONFLICT}, \mathrm{PARTIAL}, \mathrm{INDETERMINATE} \right\}.¶
A signature failure can yield \mathrm{INVALID}; two individually authentic but mutually incompatible observations can yield \mathrm{CONFLICT}.¶
For a high-assurance embodiment,¶
E_i=\mathrm{CONFLICT} \Rightarrow \neg\operatorname{OrdinaryContinuation}.¶
The IEV may instead create a protected ConflictRecord_i and initiate further evidence collection, reconciliation, bounded diagnostic effectuation, automated adjudication, or human adjudication.¶
An illustrative record is¶
\begin{aligned} ConflictRecord_i =\operatorname{Protect}\!\Big(& D_A, i, H(R_i^{(1)}),\ldots,H(R_i^{(n_i)}),\\ &\operatorname{ConflictFields}, \operatorname{SourceIDs}, \operatorname{SourceRoles},\\ &\operatorname{TimeWindow}, p_i, \operatorname{ConflictClass} \Big). \end{aligned}¶
Where weighting is appropriate, let w_j\geq0 denote source weight. For candidate outcome v:¶
\operatorname{Score}_i(v) = \sum_{j=1}^{n_i} w_j\, \mathbf{1}\!\left[ R_i^{(j)}\ \text{supports}\ v \right].¶
Continuation may require¶
\operatorname{Score}_i(v_{expected})\geq\tau_i.¶
For safety-critical predicates, a veto-class contradiction may override a numerical quorum:¶
\operatorname{QuorumSatisfied}_i \land \neg\operatorname{CriticalContradiction}_i.¶
A quorum rule may be expressed as¶
\sum_{j=1}^{n_i} \mathbf{1}\!\left[ \operatorname{ValidAndConsistent}\!\left(R_i^{(j)}\right) \right] \geq m_i.¶
Apparently conflicting evidence may be consistent if it represents a permitted state evolution. Given observations at t_a<t_b:¶
\operatorname{TemporalConsistent} = \operatorname{StateTransitionValid}\!\left( S_a,S_b,t_b-t_a \right).¶
The IEV may compare transaction identifiers, phase identifiers, nonces, sequence numbers, predecessor digests, log positions, block heights, generation numbers, or protected counters to determine whether two receipts actually describe the same attempt, different retries, different phases, or different resources.¶
When conflict remains, the IEV may request additional evidence or authorize a bounded diagnostic phase P_i^{diag}. The resulting evidence R_i^{diag} returns to the IEV:¶
P_i^{diag} \rightarrow R_i^{diag} \rightarrow IEV_i.¶
A diagnostic phase does not by itself authorize the originally requested next phase.¶
A non-limiting conflict-resolution result is¶
\begin{aligned} G_i\in\{&\mathrm{RESOLVED\_EXPECTED},\ \mathrm{RESOLVED\_ALTERNATE},\ \mathrm{PARTIAL},\\ &\mathrm{INVALIDATED\_SOURCE},\ \mathrm{UNRESOLVED}\}. \end{aligned}¶
Ordinary continuation may be allowed only for a resolved state that satisfies the protected continuation policy.¶
The IEV may form \Pi_i^{cons}, a consistency proof or protected resolution record. The continuation object may bind it:¶
\begin{aligned} CVI_{i+1} =\operatorname{Protect}\!\Big(& D_A, H(\mathbf{R}_i), H(\Pi_i^{cons}),\\ &\operatorname{Scope}(P_{i+1}), \operatorname{ID}(FS_{i+1}), q_{i+1} \Big). \end{aligned}¶
\boxed{ \mathrm{Authentic} \neq \mathrm{Consistent} }¶
and therefore¶
\boxed{ \mathbf{R}_i \longrightarrow \operatorname{ConsistencyEvaluation}_i \longrightarrow V_i \longrightarrow CVI_{i+1} }.¶
Let t^{iss}_{i+1} denote the time at which CVI_{i+1} is issued and t^{eff}_{i+1} the time at which the Finality Sink is about to cause P_{i+1}, with¶
t^{iss}_{i+1}<t^{eff}_{i+1}.¶
A continuation object valid at issue time need not remain valid at effectuation time:¶
\operatorname{ValidAtIssue}(CVI_{i+1}) \not\Rightarrow \operatorname{ValidAtEffectuation}(CVI_{i+1}).¶
A preferred boundary rule is¶
\begin{aligned} \operatorname{Allow}_{i+1}(t^{eff}_{i+1})={}& \operatorname{Valid}(CVI_{i+1}) \land \operatorname{PolicyCurrent}(t^{eff}_{i+1})\\ &\land \operatorname{RevocationClear}(t^{eff}_{i+1}) \land \operatorname{NotWithdrawn}(CVI_{i+1})\\ &\land \operatorname{DestinationValid}(t^{eff}_{i+1}) \land \operatorname{ScopeAuthorized}(t^{eff}_{i+1}). \end{aligned}¶
Additional embodiments may require current risk, taint, human-approval, device-health, route, or account predicates.¶
Let \Delta_{max} be the maximum permitted age of a continuation object. Then¶
t_{now}-t^{iss}_{i+1}\leq\Delta_{max}¶
must hold at effectuation. Otherwise,¶
CVI_{i+1}\mapsto\mathrm{EXPIRED}.¶
If the CVI carries policy epoch p_i, the Finality Sink may require¶
p(CVI_{i+1})=p_{current}.¶
If not,¶
p(CVI_{i+1})\neq p_{current} \Rightarrow \neg\operatorname{Consume}(CVI_{i+1})¶
until a permitted revalidation occurs.¶
Similarly,¶
r(CVI_{i+1})=r_{current}¶
may be required. Advancing the revocation epoch invalidates an unconsumed older continuation object.¶
A protected authority may issue¶
CR_i = \operatorname{Protect}\!\left( D_A, H(CVI_{i+1}), \operatorname{Reason}, r_{current}, \operatorname{AuthorityID}, t_{rev} \right).¶
Then¶
\operatorname{Valid}(CR_i) \Rightarrow \operatorname{Reject}(CVI_{i+1}).¶
Let g_i be the continuation generation. The Finality Sink may require¶
g(CVI_{i+1})=g_{current}.¶
Advancing the generation gives¶
g(CVI_{i+1})<g_{current} \Rightarrow \operatorname{Reject}(CVI_{i+1}).¶
This can invalidate an entire outstanding class of older continuation instructions without enumerating each object.¶
If destination d was valid at issue time but is revoked, reassigned, compromised, or otherwise invalid at the effectuation boundary,¶
\operatorname{DestinationValid}(d,t^{eff}_{i+1})=\mathrm{false} \Rightarrow \operatorname{Allow}_{i+1}=\mathrm{false}.¶
For human approval identifier h_i:¶
\operatorname{HumanApprovalCurrent}(h_i,t) = \operatorname{Valid}(h_i,t) \land \neg\operatorname{Withdrawn}(h_i,t).¶
Thus a prior protected human approval may be withdrawn before Finality-Sink consumption where policy permits withdrawal.¶
If risk changes from \rho_0 to \rho_1 and¶
\rho_1>\tau_{risk},¶
then¶
\operatorname{Allow}_{i+1}=\mathrm{false}.¶
Likewise, if current taint state T(t) is outside the authorized set \mathcal{T}_{allow},¶
T(t^{eff}_{i+1})\notin\mathcal{T}_{allow} \Rightarrow \operatorname{Allow}_{i+1}=\mathrm{false}.¶
Where current conditions have changed but continuation may remain permissible, the IEV may issue a revalidation object RV_{i+1}. The Finality Sink may require¶
\operatorname{Valid}(CVI_{i+1}) \land \operatorname{Valid}(RV_{i+1}).¶
For a high-consequence effect, the Finality Sink may request a fresh one-time consume grant:¶
FS_{i+1} \rightarrow \operatorname{ConsumeRequest}(CVI_{i+1}) \rightarrow IEV_i.¶
After fresh checks,¶
IEV_i \rightarrow \operatorname{ConsumeGrant}_{i+1} \rightarrow FS_{i+1}.¶
The consume grant may be single-use and short-lived.¶
Let¶
\operatorname{CVIState} \in \{\mathrm{ISSUED},\mathrm{REVOKED},\mathrm{CONSUMED}\}.¶
Permitted terminal transitions include¶
\mathrm{ISSUED}\rightarrow\mathrm{REVOKED}¶
and¶
\mathrm{ISSUED}\rightarrow\mathrm{CONSUMED}.¶
A transition¶
\mathrm{REVOKED}\rightarrow\mathrm{CONSUMED}¶
is prohibited.¶
An atomic compare-and-swap realization is¶
\operatorname{CAS}\!\left( \operatorname{CVIState}, \mathrm{ISSUED}, \mathrm{CONSUMED} \right)=\mathrm{success}.¶
The Finality Sink effectuates only if the state transition succeeds.¶
A hardware boundary may require¶
\operatorname{ENABLE}_{i+1} = L^{IEV}_{pass} \land \neg L_{revoked} \land \operatorname{EpochMatch}.¶
If revocation asserts L_{revoked}=1, then¶
\operatorname{ENABLE}_{i+1}=0.¶
Next-phase material may include current epochs:¶
K_{i+1} = \operatorname{KDF}\!\left( K_{root}, D_A, H(R_i), p_{current}, r_{current}, i+1 \right).¶
A Finality Sink accepts only material corresponding to the current protected epoch state.¶
An IEV may first issue a prepared continuation object CVI^{prep}_{i+1}. Immediately before effectuation, a protected authority issues a commit object CVI^{commit}_{i+1}. Then¶
\operatorname{Enable}(P_{i+1}) = \operatorname{Valid}(CVI^{prep}_{i+1}) \land \operatorname{Valid}(CVI^{commit}_{i+1}).¶
A changed condition need not always require total cancellation. If a previously authorized scope s_{old} exceeds a newly safe scope s_{new},¶
s_{new}\subset s_{old},¶
the old continuation object may be invalidated and replaced by a reduced-scope continuation object.¶
A continuation object may bind destination d_{i+1}. At effectuation,¶
\operatorname{RequestedDestination} = d_{i+1}¶
must hold. Otherwise,¶
\operatorname{RequestedDestination}\neq d_{i+1} \Rightarrow \operatorname{BLOCK}.¶
The same principle may bind account, recipient, resource, device, route, API, tool, file, payment rail, actuator, interface, or storage object.¶
Where CVI_{i+1} has propagated to sinks FS^{(1)},\ldots,FS^{(N)}, revocation may be distributed to all such sinks. A sink unable to establish freshness of revocation state may fail closed or enter a bounded fail-limited mode.¶
For an offline sink, protection may be provided by short expiry, bounded scope, one-time keys, monotonic counters, hardware epochs, preloaded revocation windows, or bounded energy/action budgets, with¶
\operatorname{Scope}_{offline} \subset \operatorname{Scope}_{online}.¶
The central time-sensitive rule is¶
\boxed{ \operatorname{IEVPass}(t_0) \neq \operatorname{IrrevocableAuthority}(t_1) \quad\text{for }t_1>t_0 }.¶
Instead,¶
\boxed{ \operatorname{Enable}(P_{i+1},t_1) = \operatorname{Valid}(CVI_{i+1},t_1) \land \operatorname{CurrentProtectedConditions}(t_1) }.¶
The three hardening embodiments may operate simultaneously:¶
\boxed{ \begin{aligned} P_i &\rightarrow \mathbf{R}_i \rightarrow \operatorname{ConsistencyEvaluation}_i \rightarrow \operatorname{HardenedIEVValidation}_i\\ &\rightarrow CVI_{i+1}^{\mathrm{revocable}} \rightarrow \operatorname{BoundaryRevalidation}_{i+1} \rightarrow FS_{i+1} \rightarrow P_{i+1} \end{aligned} }.¶
A formal IEV acceptance condition may be written as¶
\begin{aligned} \operatorname{HardenedPass}_i={}& \operatorname{ReceiptAuthentic}_i \land \operatorname{EvidenceConsistent}_i \land \operatorname{EffectAcceptable}_i\\ &\land \operatorname{IEVIntegrityValid}_i \land \operatorname{PolicyCurrent}_i \land \operatorname{RevocationClear}_i. \end{aligned}¶
The Finality Sink independently evaluates current effectuation conditions:¶
\begin{aligned} \operatorname{FSAllow}_{i+1}={}& \operatorname{CVIValid}_{i+1} \land \operatorname{IEVIntegrityValid}_i \land \operatorname{PolicyCurrent}_{i+1}\\ &\land \operatorname{RevocationClear}_{i+1} \land \operatorname{ContinuationNotWithdrawn}_{i+1}\\ &\land \operatorname{DestinationValid}_{i+1} \land \operatorname{ScopeAuthorized}_{i+1}. \end{aligned}¶
For a high-consequence embodiment,¶
\operatorname{Effectuate}(P_{i+1}) \Rightarrow \operatorname{HardenedPass}_i \land \operatorname{FSAllow}_{i+1}.¶
Ordinary continuation may be blocked while any required condition remains unresolved, including¶
\begin{gathered} \operatorname{IEVUnavailable},\quad \operatorname{IEVIntegrityUnknown},\quad \operatorname{IEVStateConflict},\\ \operatorname{EvidenceConflict},\quad \operatorname{RevocationStateUnknown},\quad \operatorname{PolicyEpochMismatch},\\ \operatorname{ContinuationWithdrawn},\quad \operatorname{DestinationStateUnknown},\quad \operatorname{CVIConsumptionUnknown}. \end{gathered}¶
Accordingly,¶
\boxed{ \mathrm{UNKNOWN}\neq\mathrm{AUTHORIZED} }.¶
A system may instead enter reconciliation, safe state, reduced scope, alternate-validator mode, bounded diagnostic mode, quarantine, protected human review, or termination.¶
The hardened architecture expressly distinguishes:¶
\boxed{\mathrm{AuthenticEvidence}\neq\mathrm{ConsistentEvidence}}¶
\boxed{\mathrm{IEVPass}\neq\mathrm{InfallibleIEV}}¶
\boxed{\mathrm{ValidAtIssue}\neq\mathrm{ValidAtEffectuation}}¶
\boxed{\mathrm{ValidatorUnavailable}\neq\mathrm{PermissionToBypass}}¶
and¶
\boxed{\mathrm{HumanOrMachineResolution}\neq\mathrm{DirectEffectuationAuthority}}.¶
For a hardened high-assurance embodiment, define¶
\begin{aligned} \operatorname{Enable}(P_{i+1})={}& \operatorname{ReceiptAuthentic}_i \land \operatorname{EvidenceConsistent}_i \land \operatorname{EffectAcceptable}_i\\ &\land \operatorname{IEVIntegrityValid}_i \land \operatorname{CVIValid}_{i+1} \land \operatorname{PolicyCurrent}_{i+1}\\ &\land \operatorname{RevocationClear}_{i+1} \land \operatorname{ContinuationNotWithdrawn}_{i+1}\\ &\land \operatorname{DestinationValid}_{i+1} \land \operatorname{ScopeAuthorized}_{i+1}. \end{aligned}¶
If a required predicate is \mathrm{false}, the ordinary next phase is blocked. If a required predicate is \mathrm{unknown}, the system enters the applicable reconciliation, safe-state, fail-limited, revalidation, or escalation path rather than assuming authorization.¶
The hardened causal chain is therefore¶
\boxed{ \begin{aligned} \operatorname{RealEffect}_i &\rightarrow \operatorname{ProtectedEvidence}_i \rightarrow \operatorname{EvidenceConsistency}_i \rightarrow \operatorname{IEVIntegrity}_i\\ &\rightarrow V_i \rightarrow CVI_{i+1}^{\mathrm{revocable}} \rightarrow \operatorname{EffectuationTimeRevalidation}_{i+1}\\ &\rightarrow FS_{i+1} \rightarrow \operatorname{RealEffect}_{i+1} \end{aligned} }.¶
\newpage¶
| Symbol | Meaning | |---|---| | \sigma_i | Digest of protected IEV state S^{IEV}_i. | | q_i | Protected monotonic validator counter. | | IDEO_i | IEV Decision Evidence Object. | | \pi_i | Machine-verifiable proof carried with or referenced by an IEV decision. | | \mathbf{R}_i | Vector of evidence objects for phase i. | | R_i^{(j)} | Evidence object from source j for phase i. | | a_{i,j} | Authenticity predicate for R_i^{(j)}. | | c_{i,jk} | Pairwise consistency predicate between sources j and k. | | E_i | Evidence-state classification. | | G_i | Conflict-resolution result. | | \Pi_i^{cons} | Consistency proof or protected conflict-resolution record. | | t^{iss}_{i+1} | Time at which CVI_{i+1} is issued. | | t^{eff}_{i+1} | Time at which FS_{i+1} is about to cause the next effect. | | CR_i | Continuation Revocation Record. | | g_i | Continuation generation. | | RV_{i+1} | Revalidation object for an already issued continuation. | | \kappa_i | Validator-key epoch. | | \rho_i | Protected risk value. | | \tau_{risk} | Protected risk threshold. | | \mathcal{T}_{allow} | Authorized set of taint states. |¶
The symbols in this appendix supplement, rather than replace, the unified notation at the beginning of this document.¶
This appendix gives non-limiting implementation patterns for isolated VMs, microVMs, Linux, Android, iOS/iPadOS, macOS, Windows, ordinary applications, local-plus-remote validation, and validator substitution.¶
title: "INTERIM EFFECTUATION VALIDATOR (IEV) - SOFTWARE, ISOLATED-VM, OPERATING-SYSTEM, MOBILE-PLATFORM, AND APPLICATION EMBODIMENTS" subtitle: "Platform-Neutral Protected Inter-Phase Validation with Validator-Substitution Invariance" author: "Technical Specification - Non-Limiting Embodiments" date: "October 2026" geometry: margin=18mm fontsize: 10pt mainfont: "DejaVu Serif" sansfont: "DejaVu Sans" monofont: "DejaVu Sans Mono" header-includes:¶
\usepackage{amsmath,amssymb,mathtools}¶
\usepackage{booktabs,longtable,array}¶
\usepackage{microtype}¶
\usepackage{enumitem}¶
\setlist[itemize]{itemsep=2pt,topsep=3pt}¶
\setlist[enumerate]{itemsep=2pt,topsep=3pt}¶
\usepackage{fancyhdr}¶
\pagestyle{fancy}¶
\fancyhf{}¶
\lhead{Interim Effectuation Validator - Software/OS Embodiments}¶
\rhead{Platform-Neutral IEV}¶
\cfoot{\thepage}¶
\setlength{\headheight}{14pt}¶
This section describes non-limiting implementations of an Interim Effectuation Validator (IEV) in software, virtualized computing, operating-system, mobile-platform, desktop, application, backend, and mixed local/remote environments.¶
The IEV is not limited to a dedicated hardware block. It may be realized as an isolated virtual machine, microVM, privileged process, daemon, system service, protected application service, trusted execution component, remote service, distributed validator set, or other protected software component.¶
The functional invariant is preserved regardless of the validator's physical or software placement:¶
boxed{
E_i
->
R_i
->
V_i
->
Gamma_{i+1}
->
FS_{i+1}
->
E_{i+1}
}
where an earlier real effect produces protected evidence, the evidence is independently validated, and a subsequent real effect is made dependent on a protected continuation condition.¶
The IEV may be used with communications, payments, file transfer, storage, database transactions, API calls, AI-agent tool use, model-state mutation, GPU or accelerator egress, cloud deployment, software update, telecommunications, physical actuation, robotics, vehicles, industrial control, or other consequential operations.¶
The following notation is used consistently throughout this embodiment.¶
| Symbol | Meaning | |---|---| | A | Candidate Act or proposed consequential operation | | D_A | canonical digest or protected binding of A | | i | current phase index | | P_i | authorized phase specification for phase i | | E_i | actual real effect produced for phase i | | R_i | protected effect evidence or receipt for E_i | | X_i | expected effect or expected effect properties for phase i | | O_i | observed effect or observed effect properties derived from R_i | | V_i | IEV validation function applied to phase i | | S_i^{IEV} | protected IEV state associated with phase i | | FS_i | Finality Sink controlling phase i | | C_i | initial or phase-specific authority enabling phase i | | CVI_{i+1} | Continuation Validation Instruction associated with phase i+1 | | \Gamma_{i+1} | generic protected continuation condition for phase i+1 | | K_{i+1} | optional receipt-dependent execution material or phase key | | p_i | policy epoch or protected policy state | | r_i | revocation epoch or protected revocation state | | c_i | monotonic counter or protected sequence value | | \epsilon_i | permitted numerical or semantic tolerance | | \mathcal{A}_i | authorized result set | | \mathcal{V} | set of permissible IEV implementations | | v\in\mathcal{V} | one concrete IEV implementation |¶
The generic continuation condition \Gamma_{i+1} may be realized as a signed instruction, MAC, protected state transition, key, key share, hardware latch, database state, secure mailbox record, kernel state, transaction state, credential state, or equivalent non-bypassable condition.¶
For any supported software implementation, the preferred sequence is:¶
A
->
FS_i
->
E_i
->
R_i
->
V_i(R_i,S_i^{IEV})
->
Gamma_{i+1}
->
FS_{i+1}
->
E_{i+1}.
A more explicit form is:¶
D_A = H(Canon(A)),
E_i = Effectuate(FS_i,P_i,C_i),
R_i = Observe(E_i),
delta_i = V_i(R_i,S_i^{IEV}),
Gamma_{i+1} = EstablishContinuation(delta_i,R_i,D_A,P_{i+1}),
E_{i+1} = Effectuate(FS_{i+1},P_{i+1},Gamma_{i+1}).
Ordinary continuation is permitted only when the required validation outcome is satisfied.¶
A non-limiting validation predicate is:¶
Pass_i ={}
AuthValid(R_i)
AND ActMatch(R_i,D_A)
AND PhaseMatch(R_i,i)
AND SinkMatch(R_i,FS_i)
AND DestinationMatch(R_i)
AND Fresh(R_i)
AND negConsumed(R_i)
AND EffectAcceptable(O_i,X_i)
AND PolicyCurrent(p_i)
AND RevocationClear(r_i)
AND WithinEnvelope(P_{i+1}).
The validator may return more than a binary result:¶
delta_i in
{PASS,FAIL,HOLD,RECONCILE,REDUCE,REMEDIATE,ESCALATE,TERMINATE}.
The IEV may evaluate expected and observed effects using one or more of the following.¶
O_i=X_i.
d(O_i,X_i) <= epsilon_i.
For a scalar quantity:¶
|O_i-X_i| <= epsilon_i.
bigwedge_{k=1}^{m} Q_{i,k}(O_i)=true.
Different predicates may be used for recipient identity, payment state, route, device state, sensor response, storage persistence, transaction state, model-state mutation, or other properties.¶
A software IEV is preferably separated from the proposing application such that the proposing component cannot arbitrarily:¶
write S_i^{IEV};¶
create an accepted receipt;¶
set \delta_i=\mathrm{PASS};¶
increment the protected phase counter;¶
mark R_i as consumed;¶
synthesize a valid CVI_{i+1};¶
derive or obtain K_{i+1};¶
clear revocation state;¶
rewrite an expected destination or scope; or¶
bypass the Finality Sink.¶
Isolation may be implemented by process privilege, VM separation, memory protection, access control, mandatory access control, sandboxing, hypervisor isolation, hardware-backed keys, TEE execution, cryptographic authentication, remote validation, or combinations thereof.¶
A protected validator state may be represented as:¶
S_i^{IEV}=
<= ft(
D_A,
i,
mathcal{E}_{max},
X_i,
FS_i,
Dest_i,
p_i,
r_i,
c_i,
mathcal{C}_i,
Risk_i,
Taint_i,
Prov_i
),
where \mathcal{C}_i includes receipt and continuation-consumption state.¶
The app may receive a read-only projection:¶
Pi_{app}(S_i^{IEV}),
without gaining write authority over protected continuation state.¶
A software CVI may be constructed as:¶
CVI_{i+1} = Protect_{K_{IEV}}(D_A || H(R_i) || (i+1)
|| Scope_{i+1} || FS_{i+1}
|| Dest_{i+1} || p_i || r_i
|| c_{i+1} || Expiry_{i+1}).
The protected operation may be a signature, MAC, authenticated encryption, protected database transition, kernel state transition, secure mailbox write, threshold signature, hardware-backed signature, or equivalent authenticated mechanism.¶
An explicit transferable token is not required.¶
The IEV may atomically establish:¶
State^{cont}_{i+1}=VALID.
The Finality Sink then requires:¶
State^{cont}_{i+1}=VALID
before the next effect can occur.¶
This state may reside in protected shared memory, kernel state, a database record, transaction engine, daemon memory, secure registry, hypervisor state, remote service state, or other protected state.¶
A stronger construction makes the next phase cryptographically incomplete without successful validation:¶
K_{i+1}
=
KDF
<= ft(
K_{root}^{IEV},
D_A,
H(R_i),
i+1,
FS_{i+1},
c_{i+1}
).
If \operatorname{Pass}_i=\mathrm{false}, then K_{i+1} may remain unavailable, sealed, incomplete, or ungenerated.¶
An application or AI agent may execute in:¶
VM_A,
while the IEV executes in:¶
VM_{IEV}.
The Finality Sink may execute in a host process, hypervisor service, separate VM, or privileged broker.¶
A non-limiting topology is:¶
VM_A
->
FS_i^{host}
->
E_i
->
R_i
->
VM_{IEV}
->
Gamma_{i+1}
->
FS_{i+1}^{host}.
The application VM is not provided with sufficient host privilege, credential material, or protected state access to synthesize \Gamma_{i+1}.¶
The application VM may have only mediated egress:¶
VM_A -> vNIC -> NetworkFS -> Network.
A first real bounded effect may be a challenge, trailer, limited payload, connection setup, bounded API call, or endpoint probe.¶
The resulting remote evidence returns to VM_{IEV}. Broader transmission is enabled only after validated continuation.¶
A VM may write to a provisional storage layer:¶
Write_{staged}
->
R_i^{storage}
->
IEV
->
Gamma_{promote}
->
StorageFS
->
Write_{authoritative}.
Thus a VM-visible write need not immediately become authoritative or externally visible.¶
An AI agent may run in a microVM with a narrow host interface. The microVM may expose only a SUBMIT_CANDIDATE function, while host-side protected logic exclusively exposes SET_VALIDATED_CONTINUATION to the IEV.¶
The microVM may therefore request an act without being able to advance protected phase state.¶
A Linux deployment may include:¶
agentd: proposal/agent process;¶
effect-broker: Finality Sink;¶
effect-observer: receipt source;¶
ievd: Interim Effectuation Validator;¶
policyd: protected policy service;¶
credentiald: protected credential/key broker.¶
The sequence is:¶
agentd -> effect-broker -> E_i,
E_i -> effect-observer -> R_i -> ievd,
ievd
->
Gamma_{i+1}
->
effect-broker.
The agent process and IEV daemon may run under different identities and different mandatory-access-control domains.¶
The agent and IEV may occupy different user, PID, mount, network, or cgroup domains. The IEV may also be outside the agent container entirely.¶
A container boundary is not relied upon solely as the invention; it is one means of implementing protected separation between the proposer and the validator.¶
One or more Linux enforcement points may prevent the agent from using effect-capable paths outside the Finality Sink.¶
For example:¶
Agent -> LSM/eBPF/KernelGate -> EffectBroker.
An IEV may establish a protected state consumed by the broker or kernel-adjacent enforcement component.¶
The IEV itself may remain a user-space daemon, privileged service, VM, or remote service.¶
The full credential need not enter agent memory:¶
K_{full} not-in Memory(Agent).
After a validated first effect:¶
R_i
->
IEV
->
Gamma_{i+1}
->
credentiald,
and the credential broker either performs or authorizes only the scoped subsequent act.¶
An Android implementation may place the proposing application in its ordinary application sandbox while the IEV resides in a separate process, isolated service, privileged service, OEM system service, native daemon, secure-world component, or remote service.¶
A representative sequence is:¶
App
->
Binder/SystemFS
->
E_i
->
R_i
->
IEVService
->
Gamma_{i+1}
->
SystemFS.
The proposing app cannot directly write the IEV decision state.¶
The IEV service may expose narrowly defined operations such as:¶
It need not expose an app-callable setPass function.¶
A Binder request may be accepted only if:¶
CallerUID in AuthorizedUIDs
and required act/phase/nonces are valid.¶
The IEV may authenticate a continuation instruction using a hardware-backed validator key:¶
CVI_{i+1}
=
Sign_{K_{IEV}}
<= ft(
D_A,
H(R_i),
i+1,
Scope_{i+1},
Expiry_{i+1}
).
The security hardware need not implement the entire IEV policy. It may protect the key used to prove that an authorized IEV instance produced the continuation decision.¶
Some or all validation may run in a trusted execution environment.¶
The normal-world process supplies an authenticated validation input, and trusted-world logic evaluates:¶
delta_i
=
V_i(R_i,S_i^{IEV}).
On PASS, the protected component may sign a CVI, unseal a key, advance a counter, or set protected continuation state.¶
No OEM modification is required in another embodiment.¶
An ordinary Android application may use a server-side Finality Sink and remote IEV:¶
AndroidApp
->
BackendFS_i
->
E_i
->
R_i
->
RemoteIEV
->
Gamma_{i+1}
->
BackendFS_{i+1}.
This preserves the IEV functional sequence even though the validator is remote rather than device-resident.¶
An iOS or iPadOS application may use a local helper or extension where permitted, a Secure-Enclave-assisted key, app-integrity evidence, a remote IEV, or combinations thereof.¶
The strongest commercial implementation may place the effect-controlling Finality Sink and IEV on a backend service while the sandboxed app remains the proposal interface.¶
A representative sequence is:¶
iOSApp
->
BackendFS_i
->
E_i
->
R_i
->
RemoteIEV
->
Gamma_{i+1}
->
BackendFS_{i+1}.
A protected device key may authenticate locally generated validation evidence or continuation state:¶
CVI_{i+1}
=
Sign_{K_{secure}}
(D_A,H(R_i),i+1,Scope_{i+1}).
The key protection mechanism may be local while the policy engine remains remote.¶
An application may separate the agent, validator, and effect broker into distinct application components or services:¶
AgentApp
->
EffectHelper
->
E_i
->
R_i
->
IEVService
->
Gamma_{i+1}
->
EffectHelper.
The helper may hold privileges not granted to the agent process.¶
A Windows deployment may use a restricted application or AppContainer for the proposer and a separate broker service for actual effects.¶
RestrictedApp
->
BrokerFS_i
->
E_i
->
R_i
->
IEVService
->
Gamma_{i+1}
->
BrokerFS_{i+1}.
The restricted application need not possess the broker's full credential or device privilege.¶
Sensitive IEV keys, counters, receipt-chain roots, or critical predicates may be placed in a VBS-protected enclave or comparable protected environment.¶
The host IEV may call protected enclave logic to establish:¶
Gamma_{i+1}
only after required predicates are satisfied.¶
An implementation need not use kernel modification, TEE, or virtualization. A conventional application suite may separate:¶
OS identities and access-control lists may be sufficient for a lower-assurance commercial deployment, while the same functional sequence is retained.¶
The IEV may be a module in the same process as the agent in a lower-assurance implementation:¶
Application=
{AgentModule,IEVModule,EffectModule}.
Logical protection may be provided using cryptographic state, memory-safe encapsulation, internal capabilities, type-level state machines, or signed internal transitions.¶
This embodiment has weaker isolation but does not alter the functional ordering.¶
A system may combine:¶
IEV_{local}
and:¶
IEV_{remote}.
High-consequence continuation may require:¶
Pass_{local} AND Pass_{remote}.
Lower-consequence continuation may require only one validator according to policy.¶
A client application may never possess final authority. The authoritative state may exist only on a backend.¶
For example:¶
Client -> CandidateRequest -> BackendFS_i -> E_i -> R_i -> BackendIEV.
This is especially useful for mobile apps, browser apps, SaaS products, and managed enterprise clients.¶
Assume an application intends to send full payload M to recipient A.¶
The first phase sends a real bounded trailer:¶
P_0=Send(Trailer_A).
A recipient-side or service-side observer produces:¶
R_0=(RecipientID,EndpointID,Binding,DeliveryState,Nonce,Timestamp).
The IEV checks, for example:¶
RecipientID(R_0)=A
and:¶
Binding(R_0)=H(M).
If valid:¶
IEV -> CVI_{SEND} -> FS_{SEND} -> Send(M).
If the observed recipient is B\neq A:¶
RecipientID(R_0)=B != A,
then ordinary full-message continuation is withheld.¶
For a proposed payment:¶
A=Pay(Payer,Beneficiary,Amount,Currency),
a first real bounded phase may be a hold, beneficiary verification transfer, limited authorization, or reserved transaction.¶
The receipt may be validated using:¶
Beneficiary(R_0)=Beneficiary_A,
Currency(R_0)=Currency_A,
State(R_0) in mathcal{A}_{payment}.
Only then may broader capture or settlement become eligible.¶
A file-release system may first transmit a manifest, ciphertext fragment, trailer, or bounded file portion.¶
E_0=Release(BoundedObject).
The remote system returns evidence of tenant, storage account, destination, object identifier, digest, or persistence state.¶
After IEV validation:¶
Gamma_{1}=CVI_{FILE}
may enable the remaining chunks, promotion, share capability, or decryption key.¶
An AI agent proposes a tool invocation:¶
A=ToolCall(Tool,Args,Destination).
A first bounded tool effect occurs under a Finality Sink.¶
The effect evidence is evaluated independently of the model's textual assertion of success.¶
Thus:¶
ModelSaysSuccess !=> IEVPass.
Only protected evidence can satisfy required continuation predicates.¶
An accelerator may complete computation without automatically authorizing data egress.¶
Compute_i
->
R_i^{device}
->
IEV
->
Gamma_{egress}
->
EgressFS.
Evidence may bind workload digest, device identity, firmware state, memory region, DMA destination, or output digest.¶
A provisional database state may be created first:¶
ProvisionalCommit_i
->
R_i^{db}
->
IEV
->
PromotionPermit_{i+1}
->
DBFS
->
AuthoritativeCommit.
The same sequence applies if the validator is implemented in a database service, host daemon, VM, remote policy service, or enclave.¶
A bounded canary activation may produce:¶
E_i=CanaryActivation.
Health, integrity, compatibility, and error evidence form R_i.¶
Then:¶
R_i
->
IEV
->
RolloutPermit_{i+1}
->
UpdateFS.
If the IEV identifies a mismatch, a protected UI may display the expected and observed states.¶
The resulting human decision is returned to the IEV:¶
HumanDecision_i
->
IEV
->
Gamma_{i+1}.
Human approval does not need to operate as direct unrestricted execution authority.¶
A mismatch may instead cause:¶
IEV -> AutomatedRemediation -> RemediationProposal -> IEV.
The IEV may then establish only a bounded remediation condition.¶
If a CVI is issued but consumption is unknown:¶
CVIState=ISSUED_NOT_CONFIRMED.
After restart the system determines whether it is:¶
PROVEN_NOT_CONSUMED, quad PROVEN_CONSUMED, quad UNKNOWN.
An unknown state does not automatically authorize reissuance.¶
If E_i occurred but R_i was not delivered, the software system does not blindly repeat E_i.¶
Instead it reconciles using one or more of:¶
(D_A,i,Nonce,TransactionID,IdempotencyID,c_i).
For each act-equivalent path q:¶
EffectCapable(q) => RequireProtectedContinuation(q)
or the path is disabled or rendered unable to complete the relevant effect.¶
Potential bypasses include alternate sockets, API clients, credentials, filesystem paths, database roles, debug interfaces, subprocesses, privileged helpers, device handles, or alternate IPC routes.¶
The identity, process type, operating system, virtualization technology, or physical location of the IEV does not define the functional sequence.¶
Let:¶
mathcal{V}=
{
VM,
MicroVM,
LinuxDaemon,
AndroidService,
iOSLocalHelper,
RemoteIEV,
WindowsService,
Enclave,
AppProcess,
DistributedValidator
}.
For each concrete implementation:¶
v in mathcal{V},
define its validator function as:¶
V^{(v)}_i(R_i,S_i^{(v)}).
The implementation is functionally conforming when it preserves the required interface contract:¶
mathcal{C}=
{
InputEvidence,
ProtectedValidation,
Decision,
ProtectedContinuationOutput
}.
The canonical sequence is therefore invariant under validator substitution:¶
boxed{
E_i
->
R_i
->
V^{(v)}_i
->
Gamma^{(v)}_{i+1}
->
FS_{i+1}
->
E_{i+1},
quad forall v in mathcal{V}.
}
Two validator implementations v_a and v_b are functionally equivalent for the disclosed inter-phase role when:¶
v_asim_F v_b
if both satisfy:¶
ValidInputContract(v),
ProtectedDecisionState(v),
BoundContinuation(v),
and:¶
NoOrdinaryNextEffectWithoutContinuation(v).
Accordingly:¶
ChangeValidatorImplementation !=> ChangeFunctionalSequence.
Implementation A:¶
E_i
->
R_i
->
LinuxDaemonIEV
->
CVI_{i+1}
->
FS_{i+1}.
Implementation B:¶
E_i
->
R_i
->
VM_{IEV}
->
CVI_{i+1}
->
FS_{i+1}.
The isolation boundary changes, but the causal relationship does not:¶
R_i
prec
IEVPass_i
prec
Gamma_{i+1}
prec
E_{i+1},
where \prec denotes required causal precedence.¶
Local Android realization:¶
E_i
->
R_i
->
AndroidIEVService
->
Gamma_{i+1}
->
SystemFS.
Remote realization:¶
E_i
->
R_i
->
RemoteIEV
->
SignedCVI_{i+1}
->
BackendFS.
The communication transport and trust boundary differ, but the required sequence remains:¶
Effect -> Evidence -> IndependentValidation -> ProtectedContinuation -> NextEffect.
Software service:¶
R_i
->
WindowsIEVService
->
CVI_{i+1}.
VBS-assisted implementation:¶
R_i
->
HostIEV
->
VBSProtectedLogic
->
CVI_{i+1}.
Moving key material or critical predicates into a protected enclave increases assurance but does not alter phase semantics.¶
One implementation may use a local device component to authenticate device-side state and a remote validator to make the continuation decision:¶
R_i
->
LocalAttestation
->
RemoteIEV
->
Gamma_{i+1}.
Another implementation may place all validation remotely:¶
R_i
->
RemoteIEV
->
Gamma_{i+1}.
Both preserve the inter-phase dependency when the Finality Sink still requires \Gamma_{i+1}.¶
Lower-assurance realization:¶
AppProcess:
quad
R_i
->
IEVModule
->
State^{cont}_{i+1}.
Higher-assurance realization:¶
AppProcess
->
R_i
->
IEVProcess
->
AuthenticatedCVI_{i+1}.
The implementation changes from intra-process isolation to inter-process isolation, but the required logical order remains unchanged.¶
Single validator:¶
Pass_i=V_i(R_i,S_i^{IEV}).
Threshold realization:¶
SUM _{j=1}^{n}mathbf{1}[Pass_i^{(j)}=true] >= m.
Only after the threshold rule is met is \Gamma_{i+1} established.¶
Again:¶
E_i
->
R_i
->
Validation
->
Gamma_{i+1}
->
E_{i+1}
is unchanged.¶
Implementation A uses an explicit CVI:¶
R_i
->
IEV
->
CVI_{i+1}
->
FS_{i+1}.
Implementation B uses no transferable object:¶
R_i
->
IEV
->
State^{cont}_{i+1}=VALID
->
FS_{i+1}.
Therefore the continuation representation may change without changing the functional sequence.¶
Software realization:¶
Gamma_{i+1}=CVI_{i+1}.
Hardware-assisted realization:¶
Gamma_{i+1}=L_{IEV}=PASS_i.
The Finality Sink may require:¶
Enable_{i+1}=FSValid_{i+1} AND (L_{IEV}=PASS_i).
The continuation mechanism changes, while the protected dependency remains.¶
The disclosed architecture therefore distinguishes functional role from implementation location.¶
The following are implementation choices:¶
process or VM boundary;¶
operating system;¶
local or remote execution;¶
hardware-backed or software-only cryptography;¶
token or tokenless continuation;¶
single or distributed validator;¶
application-owned or platform-owned service.¶
The functional role is instead characterized by:¶
ObservedPriorEffect -> ProtectedIndependentValidation -> TechnicallyRequiredNextPhaseCondition.
A preferred implementation includes:¶
an act-generating application or AI agent in a first protection domain;¶
a Finality Sink outside unrestricted control of the act-generating component;¶
a first real bounded effect;¶
a protected evidence path from an observer to an IEV;¶
protected validator state not arbitrarily writable by the proposer;¶
validation of actual effect evidence against expected effect conditions;¶
generation or establishment of a continuation condition bound to the prior effect evidence;¶
effectuation-time verification by the next Finality Sink;¶
prevention of the next effect in the absence of the continuation condition;¶
replay protection;¶
indeterminate-state reconciliation;¶
policy and revocation revalidation;¶
optional human, automatic, or hybrid remediation; and¶
anti-bypass enforcement across act-equivalent paths.¶
For any conforming implementation v\in\mathcal{V}, define:¶
delta_i^{(v)}=V_i^{(v)}(R_i,S_i^{(v)}).
Define continuation establishment as:¶
Gamma_{i+1}^{(v)}=
G^{(v)}
<= ft(
delta_i^{(v)},
D_A,
H(R_i),
P_{i+1},
p_i,
r_i
).
The next effect is permitted only when:¶
Enable^{(v)}(E_{i+1})={}
ContinuationValid(Gamma_{i+1}^{(v)})
AND PolicyCurrent(p_i)
AND RevocationClear(r_i)
AND DestinationValid(Dest_{i+1})
AND ScopeAuthorized(P_{i+1}).
Thus the architecture is invariant to validator realization when these logical conditions remain enforced.¶
The IEV is not defined by whether it is a Linux daemon, Android service, iOS-associated service, Windows service, isolated VM, enclave, microVM, cloud service, application module, or distributed validator set.¶
It is defined functionally by the protected causal relationship between an earlier real effect and authority for a later real effect.¶
ValidatorLocation != ValidatorFunction.
ChangeOfValidator != ChangeOfFunctionalSequence.
The operative invariant is:¶
boxed{
E_i
->
R_i
->
IEV_i
->
Gamma_{i+1}
->
FS_{i+1}
->
E_{i+1}.
}
Accordingly, replacing one conforming validator implementation with another changes the deployment topology, assurance boundary, transport, or platform integration, but does not change the disclosed inter-phase effectuation sequence so long as the next consequential effect remains technically dependent on protected validation of the earlier real effect.¶
This appendix gives non-limiting implementation patterns for taint and provenance propagation, origin attribution, surrogate credentials, protected credential resolution, privilege-separated connectors, boundary invariance, and taint-aware IEV progression.¶
title: "TAINT-AWARE BOUNDARY CREDENTIAL SURROGATION, PRIVILEGE-SEPARATED EFFECTUATION, AND IEV-GATED PROGRESSIVE EFFECTUATION" subtitle: "Non-Limiting Software, OS, VM, Connector, Browser, Credential-Broker and Interim Effectuation Validator Embodiment" author: "Technical Specification Draft" date: "October 1, 2026" geometry: margin=20mm fontsize: 10pt papersize: a4 header-includes:¶
\usepackage{amsmath,amssymb,mathtools,array,longtable,booktabs,microtype,xcolor,fancyhdr,enumitem} \usepackage[T1]{fontenc} \usepackage{fvextra} \DefineVerbatimEnvironment{Highlighting}{Verbatim}{breaklines=true,breakanywhere=true,commandchars=\\\{\}} \setlist[itemize]{leftmargin=1.4em,itemsep=2pt,topsep=3pt} \setlist[enumerate]{leftmargin=1.6em,itemsep=2pt,topsep=3pt} \pagestyle{fancy} \fancyhf{} \fancyhead[L]{IEV - Taint-Aware Boundary Surrogation Embodiment} \fancyhead[R]{Technical Specification Draft} \fancyfoot[C]{\thepage} \setlength{\headheight}{14pt} \renewcommand{\arraystretch}{1.15}¶
|¶
This embodiment describes a layered execution-control architecture in which an act-generating component - including an AI agent, application, workflow engine, browser-driving process, tool-use system, or autonomous software component - may possess extensive computational capability while lacking unrestricted authority to cause consequential external effects.¶
The architecture may combine, in any compatible arrangement:¶
isolation of the act-generating domain;¶
semantic, process, context, provenance, or information-flow taint;¶
protected process and request attribution;¶
restriction of direct effect-capable interfaces;¶
surrogate, reference, handle, or non-exportable credential representations inside the lower-trust domain;¶
protected substitution, exchange, activation, or use of the actual credential only at an effectuation boundary;¶
privilege-separated connector workers;¶
destination and route verification;¶
independent safety or risk classifiers;¶
a first real bounded effect;¶
protected evidence of what actually occurred;¶
independent Interim Effectuation Validator (IEV) evaluation of the resulting evidence;¶
protected continuation authority for a subsequent phase; and¶
effectuation-time revalidation at a Finality Sink.¶
The central functional sequence is:¶
\boxed{ \begin{aligned} A_i &\rightarrow \operatorname{OriginAttribution}_i \\ &\rightarrow \operatorname{TaintEvaluation}_i \\ &\rightarrow \operatorname{ProtectedPolicy}_i \\ &\rightarrow \operatorname{BoundaryCredentialResolution}_i \\ &\rightarrow FS_i \\ &\rightarrow E_i \\ &\rightarrow R_i \\ &\rightarrow IEV_i \\ &\rightarrow \Gamma_{i+1} \\ &\rightarrow \operatorname{EffectuationTimeRevalidation}_{i+1} \\ &\rightarrow FS_{i+1} \\ &\rightarrow E_{i+1}. \end{aligned}}¶
The sequence is non-limiting. Compatible implementations may combine steps, distribute steps across components, or realize a protected continuation condition without an explicit transferable token.¶
| Symbol | Meaning | |---|---| | A_i | Candidate Act or requested consequential operation for phase i | | D_A | canonical or otherwise protected digest/binding of the Candidate Act | | \mathcal D_A | act-originating or lower-trust execution domain | | \mathcal D_P | protected execution/control domain | | FS_i | Finality Sink controlling whether phase i becomes effective | | E_i | actual real effect of phase i | | R_i | protected effect evidence or receipt corresponding to E_i | | IEV_i | Interim Effectuation Validator acting between phases i and i+1 | | S_i^{IEV} | protected IEV state at phase i | | \tau(x) | taint state associated with object, process, context, request, or act x | | \mathcal T | set of supported taint states | | \sigma_i | surrogate credential, credential handle, alias, or non-authoritative credential reference | | K_i^{real} | actual effect-capable credential or protected secret material | | \Gamma_{i+1} | generic protected continuation condition for phase i+1 | | CVI_{i+1} | one implementation of \Gamma_{i+1} as a Continuation Validation Instruction | | X_i | expected effect for phase i | | O_i | observed effect for phase i | | \epsilon_i | permitted tolerance for a comparison | | \mathcal A_i | authorized set of acceptable observed results | | p_i | policy state or policy epoch | | r_i | revocation state or revocation epoch | | Ctr_i | protected counter | | Prov_i | provenance state or digest | | B_i | protected effectuation boundary used for phase i | | q | an alternative act-equivalent effect-capable path |¶
A taint-state set may, for example, be:¶
\mathcal T = \{\mathrm{CLEAN},\mathrm{TAINTED},\mathrm{UNVERIFIABLE}\}.¶
The particular names, cardinality, and ordering of taint states are non-limiting.¶
The Candidate Act may originate from an AI agent, application, model process, browser automation component, code-generation system, tool-use agent, subagent, containerized workload, virtual machine, mobile app, desktop app, or remote service.¶
The act-originating component may execute in:¶
\mathcal D_A,¶
while protected effectuation, credential, policy, and validation services may execute in:¶
\mathcal D_P.¶
A preferred relationship is:¶
\mathcal D_A \neq \mathcal D_P.¶
The separation may be implemented using a separate process, operating-system identity, container, namespace, microVM, virtual machine, hypervisor partition, trusted execution environment, system service, security processor, DPU, SmartNIC, secure gateway, remote service, or another protected domain.¶
The architecture distinguishes:¶
\boxed{\operatorname{ProposalAuthority} \neq \operatorname{EffectuationAuthority}.}¶
The act-generating component may construct a request without possessing the material or protected state required to complete the effect.¶
A process, data object, context unit, tool result, request, Candidate Act, or resource may carry a taint state:¶
\tau(x) \in \mathcal T.¶
Taint may represent, without limitation:¶
exposure to untrusted external content;¶
private or regulated information;¶
prompt-injection-capable material;¶
sensitive credentials or secrets;¶
downloaded content;¶
unknown or conflicting provenance;¶
tool output;¶
user-private context;¶
compromised or unverified execution state;¶
risk-relevant behavioral history.¶
Taint may be semantic rather than purely byte-level. A summary, embedding, transformed object, retrieved memory item, or derived instruction may remain tainted even where the original bytes are not retained.¶
A taint state may propagate across process, data, tool, memory, connector, network, or Candidate-Act boundaries.¶
An illustrative propagation rule is:¶
\tau_{out} = \operatorname{Join} \left( \tau_{process}, \tau_{input_1}, \ldots, \tau_{input_n} \right).¶
For a downstream Candidate Act:¶
\tau(A_{i+1}) = \operatorname{Propagate} \left( \tau(A_i), \tau(Context), \tau(ToolOutputs), \tau(Prov_i) \right).¶
A fail-safe rule may provide:¶
\operatorname{UnableToValidateTaint} \not\Rightarrow \mathrm{CLEAN}.¶
Instead:¶
\operatorname{UnableToValidateTaint} \Rightarrow \mathrm{UNVERIFIABLE}.¶
An unverifiable state may result in denial, reduced scope, re-attestation, human review, additional validation, quarantine, or a bounded diagnostic phase.¶
Taint may be represented using any compatible machine-verifiable mechanism, including:¶
process metadata;¶
context metadata;¶
kernel labels;¶
LSM labels;¶
cgroup state;¶
security contexts;¶
protected tags;¶
cryptographic tags;¶
provenance graphs;¶
signed labels;¶
database metadata;¶
policy-engine state;¶
secure runtime state;¶
hypervisor metadata;¶
remote attestation state.¶
The embodiment is not limited to Linux, eBPF, LSM, or any particular implementation.¶
A protected enforcement component may determine which process, workload, task, agent, subagent, VM, container, user, session, or execution context caused a request.¶
Let:¶
\operatorname{Origin}(Q)¶
represent the protected origin attribution of request Q.¶
Attribution may derive from:¶
process credentials;¶
UID/GID;¶
peer credentials;¶
cgroup membership;¶
namespace identity;¶
executable measurement;¶
code signature;¶
VM identity;¶
container identity;¶
attestation;¶
authenticated IPC;¶
cryptographic session identity.¶
The protected policy may then evaluate:¶
F\big(\operatorname{Origin}(Q),\tau(\operatorname{Origin}(Q)),Destination,Scope,Policy\big).¶
A protected policy may differentiate clean, tainted, and unverifiable states.¶
For example:¶
\operatorname{AutoAllow}_i = \operatorname{Clean}_i \land \operatorname{NarrowPolicyMatch}_i \land \operatorname{DestinationValid}_i \land \operatorname{ScopeValid}_i.¶
A tainted request may satisfy:¶
\mathrm{TAINTED} \Rightarrow \neg\operatorname{AutoAllow}.¶
An unverifiable request may similarly satisfy:¶
\mathrm{UNVERIFIABLE} \Rightarrow \neg\operatorname{AutoAllow}.¶
The protected decision may be selected from, for example:¶
\{\mathrm{ALLOW},\mathrm{DENY},\mathrm{ASK},\mathrm{BOUNDED\_TRIAL},\mathrm{REDUCE\_SCOPE},\mathrm{RECONCILE}\}.¶
The lower-trust domain may possess a surrogate credential or credential reference:¶
\sigma_i.¶
The surrogate may have the syntax or appearance of a token, key, session object, handle, cookie, credential alias, certificate reference, account reference, key slot, or credential object without granting unrestricted authority by possession alone.¶
The actual effect-capable credential is denoted:¶
K_i^{real}.¶
A preferred relationship is:¶
\boxed{\sigma_i \neq K_i^{real}.}¶
The actual credential may be absent from the memory of the act-generating component:¶
K_i^{real}\notin \operatorname{Memory}(\mathcal D_A).¶
A surrogate may be bound to one or more of:¶
\sigma_i = \operatorname{Bind} (Principal,Service,CredentialClass,Session,Scope,Expiry,Nonce,Phase).¶
The surrogate may be single-use, session-scoped, task-scoped, destination-scoped, service-scoped, phase-scoped, act-scoped, time-limited, non-bearer, or otherwise restricted.¶
The surrogate need not contain a recoverable representation of the real credential.¶
At a protected boundary B_i, the system may detect a surrogate or credential reference and, only after required checks, resolve:¶
\sigma_i \longmapsto K_i^{real}.¶
Equivalent terminology may include boundary credential substitution, boundary swap, late credential binding, just-in-time credential resolution, surrogate redemption, protected credential insertion, credential materialization, or protected credential activation.¶
The act-generating component need not observe K_i^{real}.¶
For an initial phase, an illustrative boundary condition is:¶
\begin{aligned} \operatorname{SwapAllowed}_i={}& \operatorname{SurrogateValid}(\sigma_i)\\ &\land\operatorname{OriginAuthorized}_i\\ &\land\operatorname{PolicyCurrent}_i\\ &\land\operatorname{TaintPermitted}_i\\ &\land\operatorname{DestinationValid}_i\\ &\land\operatorname{ScopeValid}_i. \end{aligned}¶
For a subsequent IEV-gated phase:¶
\begin{aligned} \operatorname{SwapAllowed}_{i+1}={}& \operatorname{SurrogateValid}(\sigma_{i+1})\\ &\land\operatorname{ContinuationValid}(\Gamma_{i+1})\\ &\land\operatorname{PolicyCurrent}_{i+1}\\ &\land\operatorname{RevocationClear}_{i+1}\\ &\land\operatorname{DestinationCurrent}_{i+1}\\ &\land\operatorname{TaintAcceptable}_{i+1}. \end{aligned}¶
A protected boundary may:¶
receive an outbound request containing or referencing \sigma_i;¶
authenticate the originating process;¶
evaluate taint and protected policy;¶
obtain or use K_i^{real} internally;¶
construct or modify the concrete outbound request;¶
transmit the request;¶
erase transient credential material where applicable; and¶
generate protected evidence of the resulting effect.¶
At no stage need the real credential be returned to the act-generating component.¶
A boundary performing protected credential resolution may constitute all or part of a Finality Sink:¶
FS_i = \{Policy,Boundary,CredentialResolution,RequestVerification,EffectGate\}.¶
The ability to resolve \sigma_i into effect-capable use of K_i^{real} may itself be protected execution material without which the effect cannot be completed.¶
Connector logic may be divided into a lower-trust stub and a protected worker:¶
Agent \rightarrow ConnectorStub \rightarrow ProtectedIPC \rightarrow Worker_j.¶
The stub may parse typed arguments and provide them to the worker. The worker may alone possess authority to interact with external APIs, payment systems, databases, privileged files, cloud services, network destinations, or devices.¶
Worker-specific authority may satisfy:¶
Credentials(W_j)\subseteq AllowedCredentialSet_j.¶
For different workers:¶
Credentials(W_a)\cap Credentials(W_b)=\varnothing¶
where separation is desired.¶
In one embodiment, three functions are logically distinguished:¶
Privilege placement - where effect-capable code executes.¶
Credential authority - which protected credential or credential class may be used.¶
Effectuation authority - whether the concrete consequential operation may become effective.¶
These functions may be physically separate or combined while maintaining logically distinct protected state.¶
The lower-trust execution domain may lack unrestricted network egress.¶
Traffic may be forced through:¶
\mathcal D_A \rightarrow NetworkFS \rightarrow ExternalNetwork.¶
The network Finality Sink may evaluate:¶
hostname;¶
resolved destination;¶
port and protocol;¶
HTTP method and path;¶
request-body digest;¶
headers;¶
recipient identity;¶
credential class;¶
process origin;¶
taint state;¶
purpose;¶
policy;¶
continuation state.¶
A protected rule may require both logical and resolved destination checks:¶
\operatorname{HostnameAllowed} \land \operatorname{ResolvedDestinationAllowed}.¶
A browser used by an agent may be controlled through a broker outside unrestricted control of the agent.¶
The broker may restrict raw browser-process access, debugging interfaces, unrestricted JavaScript execution, direct credential extraction, raw DOM operations, or other privileged browser capabilities.¶
The relevant relationship is:¶
AgentBrowserAuthority \subset BrokerBrowserAuthority.¶
Credentials stored by a user or protected credential service may be inserted into a browser form through a protected path without exposing them to the agent.¶
One or more classifiers outside the act-generating domain may evaluate prompt injection, anomalous tool output, exfiltration patterns, suspicious requests, malicious instructions, or other risk categories.¶
For classifiers C_1,\dots,C_n:¶
ClassifierDecision = F(C_1,\ldots,C_n).¶
The result may be one predicate among several:¶
PreEffectPermit_i = PolicyPermit_i \land ClassifierClear_i \land TaintCondition_i.¶
Classifier output need not itself constitute execution authority.¶
A Candidate-Act descriptor may be:¶
D_i= \{D_A,Origin_i,Scope_i,Destination_i,\tau_i,H(Prov_i),PolicyEpoch_i\}.¶
A continuation condition may bind the next phase to a specific taint or provenance state:¶
\Gamma_{i+1} = Protect(D_A,H(R_i),\tau_i,H(Prov_i),Scope_{i+1},\ldots).¶
After pre-effect checks, the Finality Sink may permit a first real bounded effect E_i such as:¶
trailer transmission;¶
bounded API request;¶
bounded payment or reservation;¶
provisional database change;¶
canary deployment;¶
bounded file release;¶
low-energy actuator motion;¶
network handshake;¶
bounded browser submission;¶
limited credential use.¶
The effect is real and externally or persistently consequential, not merely simulated.¶
A receipt may bind both the observed effect and the protected pathway that produced it:¶
R_i = Protect \left( D_A, i, Origin_i, \tau_i, CredentialClass_i, BoundaryID_i, DestinationID_i, RequestDigest_i, O_i, Timestamp_i, Ctr_i \right).¶
The receipt may therefore allow the IEV to verify what was requested, which process caused it, which taint state applied, which protected boundary authorized it, which credential class was used, where the effect occurred, and what result was observed.¶
The IEV may evaluate both effect correctness and protected-path correctness.¶
An illustrative PASS expression is:¶
\begin{aligned} IEVPass_i={}& \operatorname{AuthValid}(R_i)\\ &\land\operatorname{ActMatch}(R_i,D_A)\\ &\land\operatorname{OriginMatch}(R_i)\\ &\land\operatorname{TaintConsistent}(R_i)\\ &\land\operatorname{BoundaryExpected}(R_i)\\ &\land\operatorname{CredentialClassAllowed}(R_i)\\ &\land\operatorname{DestinationMatch}(R_i)\\ &\land\operatorname{EffectAcceptable}(O_i,X_i)\\ &\land\operatorname{PolicyCurrent}_i\\ &\land\operatorname{RevocationClear}_i. \end{aligned}¶
The IEV may use one or more comparison functions.¶
Exact equality:¶
O_i=X_i.¶
Tolerance:¶
d(O_i,X_i)\leq\epsilon_i.¶
Scalar tolerance:¶
|O_i-X_i|\leq\epsilon_i.¶
Range:¶
L_i\leq O_i\leq U_i.¶
Authorized set:¶
O_i\in\mathcal A_i.¶
Predicate set:¶
\bigwedge_{k=1}^{m} P_k(O_i)=\mathrm{true}.¶
Suppose a phase is expected to use protected boundary B_1, while evidence indicates use of B_2.¶
If:¶
B_1\neq B_2¶
and B_2 is not an accepted equivalent protected boundary, the IEV may set:¶
IEVDecision_i=\mathrm{FAIL}.¶
This addresses substitution of the protected egress or effectuation path.¶
A named proxy, daemon, kernel hook, gateway, or hardware block is not required.¶
Two boundaries may be treated as functionally equivalent when both preserve required properties:¶
\operatorname{EquivalentBoundary}(B_x,B_y)=\mathrm{true}¶
where both enforce the required set of protected predicates, such as origin attribution, taint evaluation, credential isolation, destination verification, continuation gating, evidence generation, and anti-bypass.¶
Replacing:¶
Proxy\rightarrow KernelGate¶
or:¶
LinuxDaemon\rightarrow SmartNIC¶
or:¶
LocalBroker\rightarrow RemoteGateway¶
need not alter the functional architecture.¶
Let B_i be any boundary satisfying the required Finality-Sink properties. Then:¶
\boxed{ A_i \rightarrow B_i \rightarrow E_i \rightarrow R_i \rightarrow IEV_i \rightarrow \Gamma_{i+1} \rightarrow B_{i+1} \rightarrow E_{i+1}.}¶
Replacing B_i with B_i' preserves the architecture when:¶
FunctionalProperties(B_i)=FunctionalProperties(B_i').¶
A surrogate need not be a token. It may be a credential handle, alias, slot, object reference, signed request reference, non-exportable capability, session reference, or other protected reference.¶
Changing:¶
\sigma_i^{token}\rightarrow\sigma_i^{handle}¶
need not alter the architecture when neither representation independently exposes the real credential and both require protected boundary resolution.¶
An implementation may use an implicit protected credential reference rather than an explicit surrogate value.¶
Thus:¶
ExplicitSurrogate¶
and:¶
ImplicitProtectedCredentialReference¶
are alternative realizations of late credential binding.¶
Possession of a next-phase surrogate does not itself authorize effectuation:¶
Possess(\sigma_{i+1}) \not\Rightarrow EffectAuthority_{i+1}.¶
Instead, an illustrative expression is:¶
\boxed{ EffectAuthority_{i+1} = \operatorname{SurrogateValid}_{i+1} \land \operatorname{ContinuationValid}(\Gamma_{i+1}) \land \operatorname{BoundaryChecksValid}_{i+1}.}¶
A boundary may jointly evaluate the surrogate and current taint state:¶
\begin{aligned} Authorize_i={}& \operatorname{SurrogateValid}(\sigma_i)\\ &\land\operatorname{CredentialClassAllowed}_i\\ &\land\operatorname{TaintPolicySatisfied}(\tau_i)\\ &\land\operatorname{DestinationAllowed}_i\\ &\land\operatorname{ScopeAllowed}_i. \end{aligned}¶
A surrogate therefore does not bypass taint policy.¶
Taint may change after the first real effect:¶
\tau_{before}\neq\tau_{after}.¶
If the later state becomes tainted or unverifiable, the IEV may withhold or reduce continuation authority.¶
A continuation condition may specify a maximum permitted taint state:¶
\Gamma_{i+1}\supset\tau_{max}.¶
The Finality Sink then verifies:¶
\tau_{current}\preceq\tau_{max}.¶
Even after IEV PASS at time t_0, the Finality Sink may evaluate current state at effectuation time t_1.¶
\begin{aligned} Enable(E_{i+1},t_1)={}& \operatorname{ContinuationValid}(\Gamma_{i+1})\\ &\land\operatorname{TaintCurrentAcceptable}(t_1)\\ &\land\operatorname{PolicyCurrent}(t_1)\\ &\land\operatorname{RevocationClear}(t_1)\\ &\land\operatorname{DestinationCurrent}(t_1). \end{aligned}¶
Thus:¶
IEVPass(t_0) \not\Rightarrow IrrevocableAuthority(t_1).¶
An AI reads untrusted content and proposes:¶
SEND(File_X,Recipient_A).¶
The agent is marked:¶
\tau(Agent)=\mathrm{TAINTED}.¶
The outbound request contains or references:¶
\sigma_{mail}.¶
Policy may prohibit full automatic release but permit a bounded trailer:¶
P_0=SendTrailer.¶
At the protected boundary:¶
\sigma_{mail}\longmapsto K_{mail}^{real}.¶
The real credential is used transiently without being disclosed to the agent.¶
The recipient or service returns R_0. The IEV may check:¶
Recipient(R_0)=Recipient_A¶
and:¶
TaintState(R_0)=\mathrm{TAINTED}.¶
If required predicates pass, the IEV may establish:¶
\Gamma_1=CVI_{FULL\_SEND}.¶
If recipient, route, destination, or boundary evidence is misaligned, the full file remains non-effective.¶
For selected high-risk effects:¶
\mathrm{TAINTED} \land \mathrm{ExternalDisclosure} \Rightarrow \mathrm{HumanReview}.¶
A protected UI may display intended recipient, observed recipient, taint reason, bounded-trailer result, and proposed full send.¶
A human decision returns to the protected authority or IEV rather than directly granting unrestricted execution authority to the agent.¶
A fully automatic policy is also supported. For example:¶
\mathrm{TAINTED} \land \operatorname{RecipientVerified} \land \operatorname{PolicyAllows} \Rightarrow \Gamma_{FULL\_SEND}.¶
Thus a human is optional rather than architecturally required.¶
An agent proposes:¶
PAY(Beneficiary_B,Amount).¶
The agent holds or references:¶
\sigma_{pay}¶
rather than the actual payment credential.¶
The Finality Sink resolves or uses the actual payment credential only for a bounded first phase. The payment rail returns R_0.¶
The IEV may verify:¶
Beneficiary(R_0)=B,¶
Account(R_0)=Account_{authorized},¶
Currency(R_0)=Currency_{authorized},¶
and:¶
State(R_0)\in AuthorizedStates.¶
Only then may a subsequent settlement or broader transfer become eligible.¶
An agent visits a page containing potentially malicious content, causing:¶
\tau(Agent)=\mathrm{TAINTED}.¶
The agent attempts an authenticated submission without access to the real password or session secret. A protected browser broker inserts the credential and performs a bounded effect. The resulting evidence R_0 is evaluated by the IEV before broader continuation.¶
An agent invokes a connector through a narrow stub:¶
Agent\rightarrow ConnectorStub\rightarrow Worker_{calendar}.¶
The calendar worker may be limited to calendar credentials and denied payment credentials:¶
CredentialClass(Worker_{calendar})=Calendar.¶
The resulting external service effect generates R_i, and the IEV may validate the created event before permitting a dependent operation such as sending invitations or booking travel.¶
If Tool 1 processes tainted information and its output influences Tool 2, then:¶
\tau(Tool2Request) = \operatorname{Join} \big(\tau(Tool1Output),\tau(Agent)\big).¶
A later communication, payment, file upload, database mutation, or device act can therefore inherit taint lineage.¶
Each receipt may preserve a taint snapshot:¶
R_i\supset\tau_i.¶
A receipt chain may capture:¶
\tau_0,\tau_1,\ldots,\tau_n.¶
An unexpected transition such as:¶
\mathrm{CLEAN}\rightarrow\mathrm{TAINTED}¶
may invalidate or narrow a previously contemplated continuation.¶
Durable application state, credential state, and IEV state may be physically or logically separated:¶
Storage_{Agent} \neq Storage_{Credentials} \neq Storage_{IEV}.¶
This prevents an agent with write access to its workspace from automatically modifying credential secrets, policy, consumed-receipt state, or continuation state.¶
Protected services may communicate over authenticated IPC or RPC. An operation may be permitted only when:¶
Identity(Sender)\in ACL(Operation).¶
The mechanism may use peer credentials, signed RPC, mutual TLS, local capabilities, secure mailboxes, hypervisor-authenticated channels, or equivalent protections.¶
Where human approval is used, a protected approval object H_i may bind:¶
H_i = Bind(Act,Destination,Scope,Session,Expiry,UseCount).¶
A conversational response to an AI need not itself constitute the protected approval artifact.¶
A connector may distinguish read and write authority:¶
Permission(ReadResource)=\mathrm{true}¶
while:¶
Permission(ModifyResource)=\mathrm{false}.¶
Provider credential scope need not equal the effect scope granted to the agent:¶
ProviderCredentialScope \neq AgentEffectScope.¶
A protected connector may withhold selected high-risk content from the agent, including one-time codes, password-reset links, security secrets, payment authentication codes, recovery codes, or private keys.¶
This filtering is optional and may be combined with taint and IEV controls.¶
Inference requests themselves may be routed through a protected proxy or policy boundary that constrains model endpoints, telemetry, destination, request size, data classification, or authentication.¶
This expresses the general principle:¶
AgentRequest \neq UnrestrictedNetworkAuthority.¶
The architecture does not depend on any one layer providing complete protection.¶
Conceptually:¶
Security = f(Isolation,Taint,PrivilegeSeparation,CredentialSurrogation,BoundaryPolicy,IEV,FinalitySink,HumanApproval,Evidence,AntiBypass).¶
A classifier may fail while credential isolation, boundary mediation, and IEV-gated continuation still restrict consequential effects.¶
For every act-equivalent effect-capable path q:¶
EffectCapable(q) \Rightarrow RequireEquivalentProtectedGate(q).¶
Otherwise:¶
Disable(q).¶
Potential alternate paths include raw sockets, alternate HTTP clients, shell commands, browser debugging interfaces, alternate credentials, direct connector code, unrestricted subprocesses, alternate network namespaces, direct device handles, database administrator credentials, debug interfaces, or recovery interfaces.¶
The architecture does not require any particular named operating system, daemon, proxy, credential broker, container manager, kernel hook, classifier, or browser.¶
A functional relationship is preserved when:¶
\boxed{ UntrustedOrLowerTrustActSource \rightarrow ProtectedEffectuationBoundary \rightarrow RealEffect \rightarrow ProtectedEvidence \rightarrow IndependentIEV \rightarrow ProtectedNextPhaseAuthority.}¶
Taint implementation may change:¶
eBPF/LSM \rightarrow KernelLabel \rightarrow RuntimeProvenanceGraph \rightarrow CryptographicTaintTag.¶
Isolation may change:¶
Container\rightarrow VM\rightarrow MicroVM\rightarrow RemoteService.¶
Credential representation may change:¶
SurrogateToken\rightarrow CredentialHandle\rightarrow ImplicitProtectedReference.¶
Boundary implementation may change:¶
ForwardProxy\rightarrow KernelNetworkGate\rightarrow SmartNIC\rightarrow RemoteGateway.¶
Validator implementation may change:¶
LocalIEV\rightarrow RemoteIEV\rightarrow TEEIEV\rightarrow ThresholdIEV.¶
These changes need not alter the core functional sequence.¶
Let I denote an isolation mechanism, T a taint mechanism, S a credential-surrogation mechanism, B an effectuation boundary, and V an IEV implementation.¶
Define:¶
\Phi(I,T,S,B,V)¶
as a particular implementation of the architecture.¶
For two implementations:¶
\Phi_1=\Phi(I_1,T_1,S_1,B_1,V_1)¶
and:¶
\Phi_2=\Phi(I_2,T_2,S_2,B_2,V_2),¶
the implementations may differ while remaining functionally equivalent if both preserve:¶
\boxed{ A_i \rightarrow ProtectedPreEffectValidation_i \rightarrow E_i \rightarrow R_i \rightarrow IndependentValidation_i \rightarrow ProtectedContinuation_{i+1} \rightarrow E_{i+1}.}¶
The following pseudocode is illustrative only. Functions may be combined, reordered where causally compatible, distributed across different components, or realized in hardware, software, firmware, a remote service, or protected state transitions.¶
ALGORITHM TAINT_AWARE_IEV_EFFECTUATION(A_i):
# Phase 1 - Candidate construction
D_A := HASH(CANONICALIZE(A_i))
origin := PROTECTED_ORIGIN_ATTRIBUTION(current_request)
tau_i := READ_PROTECTED_TAINT_STATE(origin, A_i)
provenance:= GET_PROVENANCE(A_i)
if tau_i == UNKNOWN:
tau_i := UNVERIFIABLE
# Phase 2 - Initial protected policy
pre_decision := POLICY_EVALUATE(
act_digest = D_A,
origin = origin,
taint = tau_i,
provenance = provenance,
destination = A_i.destination,
requested_scope = A_i.scope,
policy_epoch = CURRENT_POLICY_EPOCH(),
revocation = CURRENT_REVOCATION_STATE()
)
if pre_decision == DENY:
return BLOCK
if pre_decision == ASK:
approval := PROTECTED_APPROVAL_FLOW(A_i)
if NOT VALIDATE_APPROVAL(approval, D_A):
return BLOCK
phase_scope := SELECT_BOUNDED_PHASE(pre_decision, A_i)
# Phase 3 - Protected boundary / credential resolution
sigma_i := GET_CREDENTIAL_REFERENCE(A_i)
if NOT SURROGATE_OR_REFERENCE_VALID(sigma_i, origin, phase_scope):
return BLOCK
if NOT TAINT_POLICY_SATISFIED(tau_i, phase_scope):
return BLOCK_OR_REDUCE_SCOPE
boundary_request := BUILD_PHASE_REQUEST(A_i, phase_scope)
# Real credential remains outside act-generating domain
real_credential := PROTECTED_CREDENTIAL_AUTHORITY.RESOLVE_FOR_USE(
credential_reference = sigma_i,
origin = origin,
destination = A_i.destination,
phase_scope = phase_scope
)
if real_credential unavailable:
return BLOCK
# Phase 4 - Real bounded effect
E_i := FINALITY_SINK.EFFECTUATE(
request = boundary_request,
credential_use = real_credential
)
# Phase 5 - Protected evidence generation
R_i := EFFECT_OBSERVER.CREATE_RECEIPT(
act_digest = D_A,
phase_id = i,
origin = origin,
taint = tau_i,
credential_class = CLASS(real_credential),
boundary_id = FINALITY_SINK.ID,
destination_id = OBSERVED_DESTINATION(E_i),
observed_effect = OBSERVE(E_i),
request_digest = HASH(boundary_request),
policy_epoch = CURRENT_POLICY_EPOCH(),
counter = NEXT_PROTECTED_COUNTER()
)
# Phase 6 - Independent interim validation
iev_result := IEV.VALIDATE(
receipt = R_i,
expected_act = D_A,
expected_origin = origin,
expected_taint = tau_i,
expected_boundary = FINALITY_SINK.ID,
expected_destination = A_i.destination,
expected_effect = EXPECTED_EFFECT(A_i, phase_scope),
current_policy = CURRENT_POLICY_EPOCH(),
current_revocation = CURRENT_REVOCATION_STATE()
)
if iev_result == FAIL:
return FAILURE_OR_REMEDIATION_PATH(R_i)
if iev_result == INDETERMINATE:
return RECONCILIATION_PATH(R_i)
# Phase 7 - Next-phase continuation
Gamma_next := IEV.CREATE_CONTINUATION(
act_digest = D_A,
prior_receipt = HASH(R_i),
next_phase = i + 1,
next_scope = DETERMINE_NEXT_SCOPE(R_i),
next_destination = NEXT_DESTINATION(A_i),
taint_bound = CURRENT_PROTECTED_TAINT_STATE(),
policy_epoch = CURRENT_POLICY_EPOCH(),
expiry = SHORT_EXPIRY()
)
# Phase 8 - Effectuation-time revalidation
if NOT FINALITY_SINK.VERIFY_CONTINUATION(Gamma_next):
return BLOCK
if POLICY_CHANGED() OR REVOCATION_ACTIVE():
return REVALIDATE_OR_BLOCK
if TAINT_NO_LONGER_ACCEPTABLE():
return REVALIDATE_REDUCE_OR_BLOCK
if DESTINATION_CHANGED():
return BLOCK
# Phase 9 - Next-phase credential resolution
sigma_next := GET_NEXT_PHASE_CREDENTIAL_REFERENCE(A_i)
if NOT SURROGATE_OR_REFERENCE_VALID(sigma_next):
return BLOCK
credential_next := PROTECTED_CREDENTIAL_AUTHORITY.RESOLVE_FOR_USE(
credential_reference = sigma_next,
continuation = Gamma_next,
next_scope = Gamma_next.scope
)
if credential_next unavailable:
return BLOCK
# Phase 10 - Next real effect
E_next := FINALITY_SINK.EFFECTUATE_NEXT_PHASE(
continuation = Gamma_next,
credential_use = credential_next
)
return E_next¶
FUNCTION PROPAGATE_TAINT(process_state, inputs, tool_outputs, provenance):
states := [process_state.taint]
FOR each input IN inputs:
states.append(input.taint)
FOR each output IN tool_outputs:
states.append(output.taint)
IF provenance missing OR provenance unverifiable:
states.append(UNVERIFIABLE)
return PROTECTED_TAINT_JOIN(states)¶
One non-limiting ordering may be:¶
\mathrm{CLEAN}\prec\mathrm{TAINTED}\prec\mathrm{UNVERIFIABLE},¶
although an implementation may use a lattice, labels, category sets, confidence scores, or incomparable classes instead of a total order.¶
FUNCTION RESOLVE_CREDENTIAL_AT_BOUNDARY(request, sigma, Gamma_optional):
origin := PROTECTED_ORIGIN_ATTRIBUTION(request)
tau := CURRENT_PROTECTED_TAINT(origin)
if NOT SURROGATE_OR_REFERENCE_VALID(sigma, origin):
return DENY
if NOT DESTINATION_ALLOWED(request.destination):
return DENY
if NOT TAINT_POLICY_SATISFIED(tau, request.scope):
return DENY_OR_REDUCE_SCOPE
if Gamma_optional exists:
if NOT VERIFY_CONTINUATION(Gamma_optional):
return DENY
if Gamma_optional.destination != request.destination:
return DENY
if request.scope exceeds Gamma_optional.scope:
return DENY
credential := CREDENTIAL_AUTHORITY.GET_NONEXPORTABLE_USE(sigma)
if credential unavailable:
return DENY
concrete_request := SUBSTITUTE_OR_APPLY_CREDENTIAL(request, credential)
result := SEND_THROUGH_PROTECTED_BOUNDARY(concrete_request)
ZEROIZE_TRANSIENT_SECRET_MATERIAL_WHERE_APPLICABLE()
return result¶
FUNCTION IEV_VALIDATE(R_i, expected):
if NOT AUTHENTICATE_RECEIPT(R_i):
return FAIL
if R_i.act_digest != expected.act_digest:
return FAIL
if R_i.phase_id != expected.phase_id:
return FAIL
if R_i.origin != expected.origin:
return FAIL
if NOT TAINT_CONSISTENT(R_i.taint, expected.taint):
return FAIL_OR_RECONCILE
if NOT AUTHORIZED_EQUIVALENT_BOUNDARY(
actual = R_i.boundary_id,
expected = expected.boundary_id):
return FAIL
if NOT CREDENTIAL_CLASS_ALLOWED(R_i.credential_class):
return FAIL
if R_i.destination_id != expected.destination_id:
return FAIL
if NOT EFFECT_ACCEPTABLE(
observed = R_i.observed_effect,
expected = expected.effect):
return FAIL
if NOT POLICY_CURRENT(R_i.policy_epoch):
return HOLD_OR_REVALIDATE
if REVOCATION_ACTIVE():
return FAIL
if RECEIPT_ALREADY_CONSUMED(HASH(R_i)):
return FAIL
ATOMICALLY:
MARK_RECEIPT_CONSUMED(HASH(R_i))
ADVANCE_PHASE()
return PASS¶
FUNCTION SAFE_SEND(full_message, intended_recipient):
candidate := BUILD_SEND_ACT(full_message, intended_recipient)
trailer := BUILD_BOUNDED_TRAILER(candidate)
trailer_result := TAINT_AWARE_IEV_EFFECTUATION(trailer)
if trailer_result not proven acceptable:
return BLOCK_OR_REMEDIATE
R0 := GET_TRAILER_RECEIPT(trailer_result)
if R0.recipient != intended_recipient:
return BLOCK_OR_HUMAN_OR_AUTOMATED_REMEDIATION
Gamma_full := IEV.CREATE_CONTINUATION(
prior_receipt = HASH(R0),
next_scope = FULL_SEND_SCOPE,
destination = intended_recipient
)
return FINALITY_SINK.SEND_FULL_PAYLOAD(
message = full_message,
continuation = Gamma_full
)¶
FUNCTION HANDLE_MISALIGNMENT(R_i, expected):
mismatch := CLASSIFY_MISMATCH(R_i, expected)
proposal := AUTOMATED_REMEDIATION_CONTROLLER.PROPOSE(mismatch)
# The remediation controller does not directly receive full effect authority.
validation := IEV.VALIDATE_REMEDIATION_PROPOSAL(
proposal = proposal,
receipt = R_i,
maximum_authorized_envelope = CURRENT_MAX_ENVELOPE()
)
if validation == APPROVE_REDUCED_SCOPE:
return IEV.CREATE_RESTRICTED_CONTINUATION(proposal.scope)
if validation == REQUERY:
return AUTHORIZE_BOUNDED_DIAGNOSTIC_REQUERY()
if validation == RECONCILE:
return ENTER_RECONCILIATION()
if validation == HUMAN_REVIEW:
return PROTECTED_HUMAN_REVIEW()
return TERMINATE_OR_SAFE_STATE¶
A non-limiting Linux or VM deployment may contain:¶
agentd in a lower-trust namespace, container, or VM;¶
effect-broker as the Finality Sink;¶
credentiald holding real credentials or non-exportable credential-use authority;¶
effect-observer generating protected receipts;¶
ievd maintaining protected continuation state;¶
optional kernel, cgroup, LSM, eBPF, seccomp, or namespace mechanisms supporting attribution, isolation, or taint.¶
Illustrative flow:¶
agentd \rightarrow effect\text{-}broker \rightarrow E_i \rightarrow R_i \rightarrow ievd \rightarrow \Gamma_{i+1} \rightarrow effect\text{-}broker.¶
The precise names, process topology, and Linux primitives are non-limiting.¶
An Android or other mobile implementation may use:¶
an ordinary application or isolated process as the act source;¶
a Binder/system-service/backend broker as the Finality Sink;¶
hardware-backed or server-side credential authority;¶
TEE or remote IEV state;¶
protected receipt return from the server or destination.¶
The same functional sequence applies even where the strongest effectuation gate is server-side rather than local.¶
A Windows or desktop implementation may use:¶
a restricted application or AppContainer-like act source;¶
a broker service as the Finality Sink;¶
a separate Windows service, enclave-assisted service, or remote validator as the IEV;¶
a credential broker that never returns the real credential to the application.¶
The application may therefore prepare high-level requests without possessing unrestricted effect authority.¶
A sandboxed mobile application may use a remote Finality Sink and remote IEV where the application lacks system-level privilege to mediate all local resources.¶
For example:¶
iOSApp \rightarrow BackendFS_0 \rightarrow E_0 \rightarrow R_0 \rightarrow RemoteIEV \rightarrow \Gamma_1 \rightarrow BackendFS_1 \rightarrow E_1.¶
A device-bound key, secure hardware identity, application attestation, or protected credential reference may supplement the remote architecture.¶
The embodiment may be provided as:¶
an AI-agent runtime;¶
enterprise endpoint service;¶
operating-system security service;¶
mobile SDK plus backend;¶
local daemon;¶
microVM;¶
virtual appliance;¶
application middleware;¶
API gateway;¶
network proxy;¶
credential broker;¶
secure browser broker;¶
connector execution service;¶
DPU or SmartNIC service;¶
cloud control-plane component;¶
transaction gateway;¶
messaging safety layer;¶
payment control layer;¶
application helper;¶
remote validation service.¶
The embodiment preserves the following distinctions:¶
\boxed{Computation\neq AuthorityToAct.}¶
\boxed{CredentialReference\neq ActualCredentialAuthority.}¶
\boxed{ReceiptExistence\neq ContinuationAuthority.}¶
\boxed{IEVPassAt(t_0)\neq IrrevocableAuthorityAt(t_1).}¶
A preferred combined invariant is:¶
\boxed{ \begin{aligned} Enable(E_{i+1})={}& \operatorname{OriginAuthorized}_{i+1}\\ &\land\operatorname{TaintAcceptable}_{i+1}\\ &\land\operatorname{CredentialReferenceValid}_{i+1}\\ &\land\operatorname{ContinuationValid}(\Gamma_{i+1})\\ &\land\operatorname{PolicyCurrent}_{i+1}\\ &\land\operatorname{RevocationClear}_{i+1}\\ &\land\operatorname{DestinationValid}_{i+1}\\ &\land\operatorname{ScopeAuthorized}_{i+1}\\ &\land\operatorname{CredentialClassAllowed}_{i+1}. \end{aligned}}¶
The final causal relationship is:¶
\boxed{ \begin{aligned} &ProtectedBoundaryValidation\\ &\quad + RealObservedEffect\\ &\quad + IndependentIEVValidation\\ &\quad + CurrentContinuationCondition\\ &\qquad \Rightarrow EligibilityForSubsequentEffectuation. \end{aligned}}¶
This implication describes eligibility under the protected architecture; it does not require that every implementation use identical components, names, cryptographic forms, operating systems, or process boundaries.¶
This appendix consolidates topology-independent patterns from the staged-effectuation design notes. The term "equivalent realization" is used here to describe technical architecture variation; this appendix does not make legal conclusions.¶
The staged-effectuation architecture is defined principally by technical control over when and under what protected conditions a consequential operation becomes effective. Accordingly, physical separation between a Protected Enforcement Domain, authority generator, effectuation gate, observer, and destination is not required unless expressly stated for a particular embodiment. A protected function may be collapsed into one component, distributed across multiple components, represented by explicit cryptographic material, represented only by protected state, or enforced natively by a destination, transaction engine, operating system, hardware controller, consensus group, or finite-state machine. The following embodiments expressly describe such realizations so that topology, token format, or product-layer placement is not treated as a mandatory limitation.¶
For embodiments that retain the central staged-effectuation invariant, a bounded real effect, protected confirmation state, or equivalent protected predecessor condition remains technically relevant to broader continuation. Certain mixed-mode embodiments below also permit lower-risk, pre-authorized, reversible, or formally constrained actions to proceed under a different path while reserving receipt-gated staged effectuation for defined consequence classes. Such mixed modes do not require every operation in a system to use the same finality path.¶
A single protected executor may receive a proposed operation, canonicalize or otherwise identify the operation, evaluate policy, determine a bounded first-stage action, perform that action, observe or verify the result, advance protected state, and perform the broader or full effect. No inter-process, inter-device, or network-visible PED-to-capability-to-sink sequence is required. Logical separation may exist only as protected states or internal state-machine transitions.¶
PROPOSED -> VALIDATED -> PARTIAL_EFFECT -> CONFIRMED -> FULL_EFFECT
The monolithic executor may be a database engine, transaction engine, secure service, trusted application, TEE, HSM, secure MCU, PLC, ECU, storage controller, NIC, DPU, GPU security processor, modem/baseband, or other protected component. A transition to the broader effect is rejected unless the executor itself records the required predecessor state or confirmation predicate. Thus, physical component separation is optional; non-skippable protected state is the relevant property.¶
An embodiment need not create, transmit, expose, or store a discrete capability, Execution Handle, bearer token, signed permit, or other transferable authority object. The authority to continue may exist solely as protected state inside the enforcing component.¶
EnableFull := (ProtectedState == CONFIRMED) AND PolicyCurrent AND RevocationClear
Equivalent realizations include an atomic state bit, transaction role, database row state, latch value, hardware register state, monotonic counter state, secure monitor state, consensus state, memory-protection state, or an internal predicate evaluated at commit time. The proposing agent or application may never receive any authority object at all. A successful protected state transition itself may be the full-effectuation authority.¶
A protected human authority may directly sign, authenticate, or otherwise cryptographically approve the exact operation that a destination or effect-capable boundary will execute. In this embodiment, the human approval artifact itself may constitute all or part of the execution authority; a separately minted PED capability is not required.¶
The signed object may bind a canonical act digest, operation class, recipient or beneficiary, destination, resource, payload or payload digest, amount, maximum scope, nonce, expiry, policy epoch, revocation epoch, device or authenticator identity, and where staged execution is used, the digest or identity of a prior Effect Confirmation Receipt.¶
Human Authenticator -> Exact-Act Signature -> Destination / Sink Verification -> Effect
The AI agent may act only as a transporter of the signed operation and need not possess authority to alter it. Any material mutation after human signing causes signature or binding verification to fail. A staged variation permits the human to sign the maximum authorized envelope initially and later sign continuation after viewing verified evidence of the bounded real effect.¶
An AI system may be technically incapable of submitting an effect-capable operation. The AI produces only a recommendation, proposed parameters, explanation, or non-authoritative Candidate Act Descriptor. A human then opens or uses a separate trusted application and independently originates the actual SEND, payment, API operation, infrastructure mutation, data release, or physical command.¶
The trusted application may import none, some, or all of the AI-proposed parameters. It may display the recommendation while requiring the human to re-enter, confirm, or reconstruct critical fields. The resulting human-originated act receives a new act identifier and may optionally commit to the AI recommendation digest for provenance without treating the AI recommendation as authority.¶
The human-originated act may then use single-phase protected effectuation or any staged receipt-gated workflow disclosed herein. This embodiment distinguishes computational assistance from legal, operational, or technical origination of the consequential act.¶
Authority may be encoded structurally into the execution environment rather than represented as a per-act finality token. Examples include object capabilities, typed tool references, typed resource handles, language-level effect types, memory-safe capability references, namespace-limited descriptors, kernel-enforced file descriptors, hardware protection domains, or other references that make unauthorized resources or operations technically unrepresentable or unreachable.¶
A Candidate Act can be constrained to the operations expressible by the currently available authority graph. Receipt verification or protected policy may expand, replace, narrow, or revoke that graph after a bounded real effect. For example, the initial graph may expose only a bounded SEND trailer method, a one-row database object, a low-amplitude actuator object, or a limited payment-hold object; successful confirmation may cause the protected runtime to expose a broader typed object or state transition.¶
AuthorityGraph_i + ValidReceipt_i -> ProtectedTransition -> AuthorityGraph_(i+1)
No reusable credential or independent execution handle is necessary. The inability to obtain or name an effect-capable object outside the protected graph may itself enforce non-bypassability.¶
A database, payment service, message service, cloud control plane, storage engine, tool service, or other transactional destination may embed the staged-effectuation constraint directly into its native commit state machine. No external Finality Sink process, separate receipt broker, or transferable continuation capability is required where the native transaction engine itself prevents an invalid transition.¶
PROVISIONAL -> OBSERVED / VERIFIED -> COMMITTABLE -> COMMITTED
The confirmation evidence may be represented by an internal durable commit record, protected log sequence number, settlement reference, version counter, replicated state, sensor-backed register, or another native state transition. The full commit operation succeeds only when the native invariant is satisfied. In one realization, calling commit() while the transaction lacks the required confirmed predecessor state returns an error or leaves the transaction non-effective.¶
A system need not subject every operation to staged effectuation. Protected policy may partition operations into classes. A low-consequence, reversible, pre-authorized, or structurally constrained class may execute under ambient or session authority, while a higher-consequence, novel-destination, tainted, high-value, irreversible, safety-critical, or otherwise selected class is routed through receipt-gated staged effectuation.¶
Classify(Act) -> { DIRECT_WITHIN_ENVELOPE | STAGED_EFFECTUATION | DENY }
The classification rule itself should preferably reside in protected policy and should not be alterable by the proposing AI agent. A direct path for one class does not imply a direct path for a class whose protected policy requires staged finality. Anti-bypass controls may therefore be scoped by consequence class rather than universally applied to all operations.¶
Some systems may include operations for which pre-effect staged confirmation is unavailable, impractical, or deliberately waived within a protected policy envelope. For such operations, the system may execute an authorized effect, obtain protected post-effect evidence, and then revoke, compensate, retract, roll back, quarantine, or otherwise remediate if the observed result violates a protected condition.¶
This post-effect mode is not required to be treated as equivalent to the preferred receipt-gated pre-effectuation invariant. It may coexist with staged effectuation in the same product, with protected policy determining which consequence classes require pre-effect gating and which permit compensating control. Where both modes exist, the presence of a compensation path must not silently downgrade a class that policy marks as requiring receipt-gated continuation.¶
A formally verified, measured, attested, deterministic, policy-restricted, or otherwise trusted execution runtime may be granted a pre-authorized authority envelope broader than that granted to an ordinary probabilistic agent. The protected system may treat successful code measurement, formal proof identifier, secure-boot state, attested binary identity, deterministic policy hash, or equivalent runtime evidence as one authority predicate.¶
Within a finite pre-authorized envelope, such a runtime may execute selected operations without generating a new human approval object for every act. Operations outside the envelope, operations having higher consequence, or operations affected by changed destination, policy, taint, revocation, or environmental state may still require staged effectuation or human approval. Attestation or formal verification therefore may change the authority source without requiring the architecture to assume that all model output is inherently authoritative.¶
The remote destination itself may combine policy evaluation, exact-act verification, effectuation gating, receipt generation, and final commitment. An upstream PED-created authority object is not mandatory where the destination has sufficient protected information to decide whether the exact request may become effective.¶
The destination may verify a direct human signature, identity-bound request, device attestation, transaction state, policy epoch, revocation state, resource version, scope, nonce, and freshness. In a staged variation, the destination first accepts or performs a bounded real effect, records the resulting protected state, and then permits broader effect only when its own local confirmation state is satisfied. In another variation, the destination returns a signed ECR that an upstream system uses to release additional data, value, privilege, or actuator authority.¶
No single component need constitute the unique Finality Sink. Multiple replicas, validators, controllers, observers, or administrative domains may collectively determine whether an operation becomes effective. The protected continuation condition may be a quorum certificate, threshold signature, replicated log entry, consensus commit index, fault-tolerant state transition, or another aggregate state.¶
ValidVotes / Receipts >= RequiredQuorum -> CommitCertificate / ConfirmedState -> Broader Effect
The quorum or consensus state may itself function as the confirmation evidence and authority; a separate capability-verification stage is optional. Membership epoch, replica identity, role constraints, conflicting certificates, split-brain state, stale views, and critical-replica requirements may be bound to the protected commit condition. A later phase may depend on the accepted consensus state rather than on a receipt from one sink.¶
The preceding embodiments may be combined. For example, a monolithic destination may use no token, enforce authority as native transaction state, receive a direct human exact-act signature, operate inside a pre-authorized action graph, and use quorum replication for durable commitment. Conversely, a structural capability operating system may expose only bounded objects until a destination-local receipt or consensus state unlocks broader objects. Accordingly, the disclosure does not require any particular number of components, any transferable capability object, any particular direction of authority flow, or any specific placement of the finality decision, so long as the selected embodiment preserves the protected conditions applicable to that mode.¶
The following catalogue records non-limiting workflow families used throughout the source material. It is intentionally broad so that the abstract protocol is not read as limited to messaging or payments.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
This workflow family applies the same execution-finality principle with domain-specific observers, effect boundaries, receipts, continuation conditions, and recovery behavior. Implementations can combine this family with the IEV, hardening, taint, surrogation, human, automatic, threshold, or tokenless patterns described elsewhere in this document.¶
The pseudocode in this appendix is explanatory. It does not mandate APIs, programming language, process topology, or object representation.¶
function effectuate_phase(i, candidate, state):
assert within_envelope(candidate, state.Envelope_MAX)
authority = authorize_phase(i, candidate, state)
if not authority.valid:
return BLOCK
result = FS[i].effectuate(candidate, authority)
receipt = observe_and_protect(i, candidate, result)
return receipt
function evaluate_receipt(i, receipt, state):
if not auth_valid(receipt): return FAIL_INVALID_RECEIPT
if not act_match(receipt, state.D_A): return FAIL_ACT_SUBSTITUTION
if not phase_match(receipt, i): return FAIL_WRONG_PHASE
if consumed(receipt): return FAIL_REPLAY
if not fresh(receipt): return HOLD_STALE
if not sink_destination_resource_match(receipt, state): return FAIL_MISALIGNED
effect = compare_effect(receipt.observed, state.expected[i])
if effect == INDETERMINATE: return RECONCILE
if effect == FAIL: return remediate_or_escalate(receipt, state)
if not current_policy_state_valid(state): return HOLD
atomic {
consume(receipt)
advance_phase(i, i+1)
Gamma = issue_continuation(i+1, H(receipt), state)
}
return Gamma
function finality_sink_consume(i_plus_1, Gamma, state):
if not continuation_valid(Gamma): return BLOCK
if not policy_current(): return BLOCK
if not revocation_clear(): return BLOCK
if continuation_withdrawn(Gamma): return BLOCK
if not destination_still_valid(Gamma): return BLOCK
if not scope_still_authorized(Gamma): return BLOCK
atomic_consume(Gamma)
return FS[i_plus_1].effectuate()
function reconcile(i, identity):
evidence = query_sink_destination_ledger_sensor_journal(identity)
status = classify(evidence)
switch status:
PROVEN_EFFECTED:
recovered = construct_or_recover_receipt(evidence)
return evaluate_receipt(i, recovered, state)
PROVEN_NOT_EFFECTED:
return MAY_AUTHORIZE_NEW_BOUNDED_RETRY
PARTIALLY_EFFECTED:
return RESIDUAL_SCOPE_OR_COMPENSATION_OR_ESCALATION
STILL_INDETERMINATE:
return BLOCK_NEXT_PHASE
function taint_aware_boundary(request, process_state):
tau = join_taint(process_state.taint,
request.input_taint,
request.provenance_taint)
if tau == UNVERIFIABLE:
return policy_for_unknown_taint()
origin = protected_origin_attribution(request)
if not policy_allows(origin, tau, request.destination, request.scope):
return DENY_OR_BOUNDED_TRIAL
surrogate = request.credential_reference
real_credential = credential_authority.resolve(surrogate,
origin,
request.destination,
request.scope)
return protected_boundary_send(request, real_credential)
Computation != Authority
Receipt existence != Continuation authority
Authenticated evidence != Consistent evidence
IEV PASS != Infallible IEV
Valid at issue != Valid at effectuation
Validator unavailable != Permission to bypass validator
Human decision != Direct unrestricted execution authority
Automated remediation proposal != Direct unrestricted execution authority
Change of validator placement != Change of functional sequence
Change of token representation != Change of protected continuation semantics
Change of proxy / boundary technology != Change of Finality-Sink role
RealEffect[i] -> ProtectedEvidence[i] -> IndependentValidation[i] -> ProtectedContinuation[i+1] -> EffectuationTimeRevalidation[i+1] -> FinalitySink[i+1] -> RealEffect[i+1]
This draft consolidates architecture, workflow, hardening, implementation-invariance, operating-system, taint, provenance, credential-surrogation, and effectuation-boundary material developed through iterative technical drafting and public-review preparation. Any future acknowledgements of external reviewers should distinguish review input from authorship or co-development unless expressly agreed otherwise.¶