Stopping AI Hallucinations and Unsafe Acts from Becoming Real-World Consequences (DAS Protocols)

1.1. The Missing Protocol Layer of the Internet

The internet was built with protocols governing how data moves — TCP/IP for transmission, TLS for confidentiality, DNS for naming, OAuth for delegated identity. Each protocol solved a specific boundary problem. What no existing protocol addresses is the boundary at which a computational output becomes an externally effective act.¶

As artificial-intelligence systems assume increasing operational authority — executing payments, mutating databases, controlling infrastructure, issuing communications, managing supply chains, and directing physical systems — the absence of a finality protocol at the computation-to-consequence boundary becomes a structural gap in internet architecture. Existing protocols govern the transmission of instructions; none governs whether a computationally generated instruction has satisfied the machine-verifiable predicates required to become a consequence.¶

The disclosed architecture addresses this gap by introducing a protected finality layer positioned at the output-to-consequence boundary — a protocol- level enforcement mechanism that does for artificial-intelligence-generated acts what TLS did for data in transit and what OAuth did for delegated access: it converts an uncontrolled technical boundary into a machine-verifiable, cryptographically enforced, and sink-verified governance checkpoint through which no artificial-intelligence-generated output may pass into external consequence without satisfying the required finality predicates.¶

1.2. Scope and Relationship to the Broader DAS Protocols Family

This document describes a focused embodiment of the broader DAS Protocols execution-finality architecture. It is technically related to the body of work disclosed across multiple Indian provisional applications and PCT international applications, including the Mothership application PCT/IB2026/055615. Full identification of related filings appears in Appendix A.¶

2.1. Technical Field

This disclosure relates to artificial-intelligence governance, hallucination- resistant artificial-intelligence control, autonomous-agent execution control, protected execution finality, machine-verifiable compliance, cryptographic capability release, hardware-rooted execution control, secure distributed computing, trusted enforcement domains, and technical systems for controlling the boundary at which computational outputs become externally effective acts.¶

More particularly, this disclosure relates to systems and methods in which an artificial-intelligence-generated output is treated as a non-effective Candidate Act and is prevented from becoming an external consequence unless a protected finality pipeline validates output-level, provenance-level, factual-support-level, consequence-level, jurisdiction-level, epoch-level, and sink-level predicates. Advanced embodiments further provide non-completability in which a Finality Sink is technically unable to complete a Candidate Act unless a protected Execution Handle or other sink-bound capability enables completion.¶

2.2. Background and Core Technical Problems

Artificial-intelligence systems increasingly generate outputs that are not merely informational. Modern systems — autonomous agents, enterprise copilots, orchestration systems, cloud-management systems, software-development agents, database agents, financial agents, telecom controllers, robotic systems, and decision-support systems — may produce outputs that trigger tool calls, payments, data exports, database commits, memory writes, model updates, communications, software deployments, network-configuration changes, settlement events, legal commitments, physical commands, or other externally effective acts.¶

Existing artificial-intelligence governance approaches commonly focus on model training, alignment, prompt filtering, output moderation, identity checks, access control, policy review, ordinary human approval, logging, monitoring, or post-hoc audit. These approaches may reduce risk, but they do not reliably control the precise technical boundary at which an artificial-intelligence-generated output becomes an external consequence.¶

A specific technical problem arises because an artificial-intelligence model may be approved, a workflow may be approved, a prompt policy may be approved, a tool policy may be approved, and observed runtime behavior may remain within an expected envelope, yet the specific generated output may still be incorrect, unsupported, stale, unsafe, confidential, technically undesired, jurisdictionally improper, or otherwise unsuitable for effectuation.¶

Thus: approval of the model is not approval of the output. Approval of the workflow is not approval of the consequence. Approval of runtime behavior is not approval of the specific act becoming externally effective.¶

Additional problems include:¶

• bypass or separation of moderation/policy layers from the actual effectuation interface;¶

• state drift and time-of-check-to-time-of-use risk between validation and execution;¶

• binary allow-or-deny outcomes that are impractical for elevated-risk but necessary acts;¶

• software-only enforcement that can be bypassed by alternate paths to effectuation.¶

The technical problem is therefore not merely whether an artificial-intelligence system was allowed to generate an output. The technical problem is whether the generated output should be permitted to cross the machine boundary from computation into consequence, under current protected state conditions, and under what scope, safeguards, and sink-verifiable authority.¶

3.1. Difference from AI Moderation and Output Filtering

Existing safety systems often focus on prompt filtering, response moderation, toxicity classification, refusal policies, output scoring, content filtering, or guardrail models. Such systems may classify or suppress certain generated content, but they do not necessarily control the final machine boundary where an AI- generated output becomes an external consequence.¶

The disclosed architecture converts the AI-generated output into a Candidate Act and holds it in a non-effective state. The Candidate Act cannot become externally effective merely because a moderation layer permitted the text or a model generated the output. It must satisfy protected finality predicates before a scoped non-bearer capability or Execution Handle is released and verified by the Finality Sink. The invention does not merely moderate output; it governs whether the output may become consequence.¶

3.2. Difference from Identity, Access-Control, and API Authorization

Identity and access-control systems answer the question: “Who or what is allowed to request an operation?” The disclosed architecture answers a different technical question: “Whether this specific AI-generated Candidate Act may become this specific external consequence at this specific Finality Sink under current protected state conditions.”¶

A user, model, service, or agent may be authenticated and authorized, yet the specific Candidate Act may still be blocked if it lacks factual support, exceeds the Result-Consequence Acceptance Envelope, relies on stale provenance, conflicts with jurisdiction, fails consequence simulation, uses a stale policy or revocation epoch, or is not accepted by the Finality Sink. Identity or access authority is not treated as execution authority.¶

3.3. Difference from Ordinary Bearer Tokens and Permission Tokens

Ordinary permission or bearer tokens may permit access when presented by a holder and may be misused if copied, stolen, forwarded, or replayed. The disclosed scoped non-bearer finality capability is different: possession of the capability data alone is insufficient to cause effectuation. The capability may be bound to the Candidate Act hash, Finality Sink identity, permitted recipient, purpose, jurisdiction, data class, consequence type, nonce, expiration, policy epoch, revocation epoch, Result-Consequence Acceptance Envelope, validation receipt, and sink verification context. In advanced embodiments the Execution Handle may also supply or activate missing execution material required by the Finality Sink.¶

3.4. Difference from Policy Engines and Gatekeeper Systems

Policy engines may return allow-or-deny decisions that remain separated from the actual effectuation interface. If downstream software can still execute the act, the policy decision may be bypassed, ignored, or stale. The disclosed architecture requires the finality requirement to follow the Candidate Act to the Finality Sink. In advanced non-completability embodiments the sink is technically unable to complete the Candidate Act unless protected finality validation releases the missing execution material. The invention is therefore a sink-bound finality- control system, not merely a policy decision system.¶

3.5. Difference from Confidential Computing or Trusted Execution Alone

Trusted execution environments may protect computation, secrets, or data in use. The disclosed architecture may use such components, but the invention is not merely the use of a trusted environment. The protected domain is used to enforce a specific output-to-consequence finality sequence: validate the Candidate Act, bind evidence, evaluate consequence, record validation evidence, release a scoped capability or Execution Handle, and prevent effectuation unless the Finality Sink verifies the required authority.¶

3.6. Difference from Logging, Monitoring, and Post-Hoc Audit

Logging and audit systems record what happened after an action occurred. They do not necessarily prevent an improper act from becoming externally effective. In the disclosed architecture the Candidate Act remains non-effective before effectuation. Validation occurs before or atomically with capability release. The validation receipt participates in the protected finality transaction that binds validation evidence to release authority.¶

3.7. Difference from Ordinary Human Approval

Ordinary human approval (click, email, chat, workflow prompt) may be stale, replayed, spoofed, unbound to the actual consequence, or separated from the Finality Sink. The disclosed architecture may require a Protected Human Approval Finality Token bound to the Candidate Act, output content, predicted consequence, approving role, authenticated user presence, approval time, policy epoch, revocation epoch, and Finality Sink identity. Human approval is converted into a protected, act-specific finality predicate.¶

3.8. Difference from Simulation or Digital-Twin Systems Alone

Simulation systems may estimate the effect of a proposed action but remain advisory. The disclosed architecture uses consequence simulation as a pre- effectuation predicate. The simulation result may be bound to the Candidate Act, Result-Consequence Acceptance Envelope, validation receipt, scoped capability, Execution Handle, and Finality Sink verification context. Simulation becomes part of a machine-verifiable finality condition for effectuation.¶

3.9. Difference from Binary Allow-or-Deny Systems

Binary allow-or-deny structures are often impractical for elevated-risk but necessary acts. The disclosed architecture supports graduated finality: a Candidate Act may be allowed, denied, quarantined, routed for review, redacted, delayed, sandboxed, reduced in scope, made reversible, executed as a canary, or classified as escalated but still allowable. In Escalated Conditional Finality Mode additional controls (protected human approval, multi-party approval, shortened expiration, reduced value, stricter scope, enhanced monitoring) may be applied while the Candidate Act remains non-effective until those controls succeed.¶

3.10. Difference from Validate-Once-Execute-Later Systems

Systems that validate at one time and execute later are exposed to state drift. The disclosed architecture requires current-state finality. In some embodiments validation, consequence simulation, policy-epoch and revocation-epoch verification, sink attestation, nonce generation, monotonic counter advancement, validation- receipt generation, and capability or Execution Handle release occur within a protected atomic transaction. The Finality Sink accepts the capability only if current state remains cryptographically congruent with the state bound during validation. Historical approval is insufficient for current effectuation.¶

3.11. Summary of Differences

Existing systems may authorize, moderate, simulate, or audit. The disclosed architecture prevents an artificial-intelligence-generated Candidate Act from becoming consequence unless protected finality succeeds at the sink boundary.¶

Core sequence (base path):¶

AI Output → Candidate Act → Non-Effective State
   → Hash-Linked Candidate Act Descriptor (HCAD)
   → Algorithmic Logic Fingerprint (ALF) Validation
   → Runtime Behavioral Descriptor (RBD) Matching
   → Output Provenance Capsule (OPC) Validation
   → Factual Claim Unit (FCU) Verification
   → Result-Consequence Acceptance Envelope (RCAE)
   → Consequence Simulation
   → Graduated / Escalated Finality Decision
   → Scoped Non-Bearer Capability or Execution Handle Release
   → Finality Sink Verification
   → Effectuation or Denial

4.1. Base Output-to-Consequence Finality Path

Every effect-capable AI-generated output is treated as a Candidate Act (message, recommendation, command, tool call, data disclosure, payment instruction, network-configuration change, database mutation, memory write, model update, physical actuation, settlement, or other effect-capable operation). The Candidate Act is held in a non-effective state.¶

Key steps include:¶

1. Candidate Act Formation — convert the AI output into a structured Candidate Act and place it in a non-effective state.¶

2. HCAD Generation — generate a Hash-Linked Candidate Act Descriptor binding the act to output hash, originating system, ALF/RBD/OPC identifiers, policy/revocation epochs, Finality Sink identity, recipient, purpose, jurisdiction, risk class, timestamp, and nonce.¶

3. ALF Validation — confirm that the Candidate Act was generated under an approved computational logic configuration (process-integrity predicate, not final authority to act).¶

4. RBD Matching — compare observed runtime behavior with the ALF-bound approved behavioral envelope.¶

5. OPC Validation — validate the Output Provenance Capsule for sources, retrieval records, tool outputs, timestamps, confidence indicators, limitation flags, and permitted-use constraints.¶

6. FCU Verification — for hallucination-sensitive outputs, extract and verify Factual Claim Units against permitted evidence, freshness, confidence, and scope.¶

7. RCAE Generation — generate or retrieve a Result-Consequence Acceptance Envelope defining the permitted consequence boundary.¶

8. Consequence Simulation — determine what the Candidate Act would cause if effectuated by the applicable Finality Sink; bind the simulation result to the protected finality state.¶

9. Graduated / Escalated Finality Decision — allow, deny, quarantine, redact, delay, sandbox, reduce scope, or escalate with additional safeguards.¶

10. Scoped Non-Bearer Capability or Execution Handle Release — only after successful validation and (where required) receipt commitment.¶

11. Finality Sink Verification — the sink verifies the capability/handle before effectuation; in advanced embodiments the sink lacks completion material until the handle supplies it.¶

4.2. Advanced Non-Completability Path

In advanced embodiments the Finality Sink is technically unable to complete the Candidate Act unless protected finality validation releases, reconstructs, unseals, combines, or activates missing execution material via an Execution Handle. The sequence is strengthened to:¶

Candidate Act
   → Result-Consequence Acceptance Envelope
   → Execution Authorization Scope Object
   → Atomic Receipt-With-Release
   → Execution Handle
   → Hardware-Bound Sink Verification
   → Reconstruction / Unsealing / Combining / Activation of Missing Material
   → Effectuation Only if Completion Succeeds

A copied or stolen artifact therefore cannot operate as generic permission to act.¶

5.1. Candidate Act

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://das-protocols.example/schemas/candidate-act-v1.json",
  "title": "CandidateAct",
  "type": "object",
  "required": ["actId", "outputHash", "originatingSystemId", "intendedSinkId", "status"],
  "properties": {
    "actId": { "type": "string", "format": "uuid" },
    "outputHash": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
    "originatingSystemId": { "type": "string" },
    "modelId": { "type": "string" },
    "workflowId": { "type": "string" },
    "intendedRecipient": { "type": "string" },
    "intendedTool": { "type": "string" },
    "intendedSinkId": { "type": "string" },
    "purpose": { "type": "string" },
    "jurisdiction": { "type": "string" },
    "dataClass": { "type": "string" },
    "riskClass": { "type": "string" },
    "requestedConsequence": { "type": "string" },
    "timestamp": { "type": "string", "format": "date-time" },
    "alfId": { "type": "string" },
    "status": {
      "type": "string",
      "enum": ["non-effective", "under-validation", "escalated", "capability-issued", "effectuated", "denied", "quarantined"]
    }
  },
  "additionalProperties": false
}

5.2. Hash-Linked Candidate Act Descriptor (HCAD)

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://das-protocols.example/schemas/hcad-v1.json",
  "title": "HashLinkedCandidateActDescriptor",
  "type": "object",
  "required": ["hcadId", "actId", "outputHash", "policyEpoch", "revocationEpoch", "nonce"],
  "properties": {
    "hcadId": { "type": "string", "format": "uuid" },
    "actId": { "type": "string", "format": "uuid" },
    "outputHash": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
    "originatingSystemId": { "type": "string" },
    "alfId": { "type": "string" },
    "rbdId": { "type": "string" },
    "opcId": { "type": "string" },
    "rcaeId": { "type": "string" },
    "policyEpoch": { "type": "integer", "minimum": 0 },
    "revocationEpoch": { "type": "integer", "minimum": 0 },
    "finalitySinkId": { "type": "string" },
    "recipient": { "type": "string" },
    "purpose": { "type": "string" },
    "jurisdiction": { "type": "string" },
    "riskClass": { "type": "string" },
    "timestamp": { "type": "string", "format": "date-time" },
    "nonce": { "type": "string", "minLength": 16 },
    "evidenceRefs": { "type": "array", "items": { "type": "string" } }
  },
  "additionalProperties": false
}

5.3. Scoped Non-Bearer Finality Capability / Execution Handle

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://das-protocols.example/schemas/execution-handle-v1.json",
  "title": "ExecutionHandle",
  "type": "object",
  "required": [
    "handleId", "actId", "hcadDigest", "sinkId", "policyEpoch",
    "revocationEpoch", "expiresAt", "oneTimeUse"
  ],
  "properties": {
    "handleId": { "type": "string", "format": "uuid" },
    "actId": { "type": "string", "format": "uuid" },
    "hcadDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
    "validationReceiptDigest": { "type": "string", "pattern": "^[0-9a-fA-F]{64,}$" },
    "sinkId": { "type": "string" },
    "hardwareBoundSinkId": { "type": "string" },
    "permittedRecipient": { "type": "string" },
    "permittedPurpose": { "type": "string" },
    "permittedJurisdiction": { "type": "string" },
    "permittedDataClass": { "type": "string" },
    "permittedConsequenceType": { "type": "string" },
    "rcaeDigest": { "type": "string" },
    "policyEpoch": { "type": "integer", "minimum": 0 },
    "revocationEpoch": { "type": "integer", "minimum": 0 },
    "nonce": { "type": "string" },
    "expiresAt": { "type": "string", "format": "date-time" },
    "oneTimeUse": { "type": "boolean", "const": true },
    "consumed": { "type": "boolean", "default": false },
    "executionMaterialHint": {
      "type": "string",
      "description": "Optional reference or sealed material required for non-completability embodiments"
    }
  },
  "additionalProperties": false
}

6.1. Adversary Classes

The architecture considers four adversary classes:¶

• External attacker — no privileged access to the AI system, the Protected Enforcement Domain (PED), or the Finality Sink; interacts only through exposed interfaces (prompts, tool responses, retrieved documents, network traffic).¶

• Compromised or adversarially manipulated model — the model itself (through jailbreak, adversarial fine-tuning, data poisoning, or prompt injection) attempts to cause an unauthorized effect, while the surrounding software stack is uncompromised.¶

• Malicious or coerced insider — an operator, engineer, or administrator with legitimate access to some subset of the PED, sink, or key material attempts to misuse that access.¶

• Infrastructure-level attacker — an attacker who has gained code execution, root, or hypervisor-level access to a component (model host, PED node, sink node) through an unrelated vulnerability.¶

Consistent with Section 7, simultaneous compromise of every Protected Enforcement Domain instance, every alternate effectuation path, and the Finality Sink is outside the claimed assurance boundary of any single-domain deployment; Section 6.2, Paragraph 11 and multi-party/multi-domain deployment patterns address this residual risk.¶

6.2. Enumerated Threats and Mitigations

T1 — Direct effectuation bypass. The originating AI system, or software downstream of it, attempts to invoke the Finality Sink (or an equivalent effectuation interface) directly, skipping Candidate Act formation entirely.
Mitigation: the Finality Sink is architecturally required to accept only a verified scoped capability or Execution Handle bound to a valid HCAD; in the advanced non-completability path the sink lacks the material needed to complete the act without that handle, so a bypassed request has no effect at the sink regardless of how it was submitted.¶

T2 — Capability or Execution Handle forgery/replay. An attacker who observes a valid Execution Handle attempts to forge a similar one, or replays a previously consumed handle.
Mitigation: handles are non-bearer, single-use (oneTimeUse), bound by cryptographic digest to the specific Candidate Act, HCAD, sink identity, policy epoch, revocation epoch, and nonce, and expire (expiresAt). Consumption is tracked (consumed); the sink MUST reject a second presentation of the same handle.¶

T3 — Compromise of the Protected Enforcement Domain. An attacker gains control of the PED and attempts to issue capabilities for Candidate Acts that should not be authorized.
Mitigation: this is the threat the architecture cannot fully defend against from within a single PED instance, and the document says so directly rather than claiming otherwise (see Section 7). Deployments requiring resistance to single-domain compromise SHOULD use multi-party or hardware-attested PED instances (e.g., threshold approval across independent PED replicas, or a hardware-rooted PED per Section 3.5) so that no single compromised instance can unilaterally release a capability.¶

T4 — Compromise or collusion at the Finality Sink. An attacker controlling the Finality Sink attempts to effectuate an act without a valid handle, or colludes with a compromised PED.
Mitigation: hardware-bound sink verification and, in advanced embodiments, cryptographic non-completability mean the sink itself does not hold sufficient material to complete the act unilaterally — completion material must be supplied, reconstructed, or unsealed via the Execution Handle. This reduces (but, per T3/T4 combined compromise, does not eliminate) the value of compromising the sink alone.¶

T5 — Time-of-check-to-time-of-use / state drift. A Candidate Act is validated under one set of conditions (policy, revocation state, risk posture) but effectuated later under different conditions.
Mitigation: see Section 3.10 — policy-epoch and revocation-epoch binding, nonce-based replay prevention, and (in advanced embodiments) an atomic validation-to-release transaction requiring the sink to confirm current-state congruence before accepting the handle.¶

T6 — Prompt injection producing a facially valid but adversary-directed Candidate Act. The model itself is not compromised at the weights level, but adversarial input (a retrieved document, a tool response, a user message) induces the model to construct a Candidate Act that is well-formed and internally consistent but serves an attacker's goal (e.g., an injected instruction to exfiltrate data to an attacker-controlled recipient).
Mitigation: this is explicitly why finality predicates are evaluated against externally-anchored state rather than the model's own assertions — OPC (provenance) validation, FCU (factual claim) verification against permitted evidence, and the Result-Consequence Acceptance Envelope constrain permitted recipients, purpose, and data class independently of what the model claims about them. A Candidate Act requesting an out-of-envelope recipient or data class is denied at the PED even though the model itself is not misbehaving in a way any output filter would catch. This threat is discussed further in Section 8.5.¶

T7 — Insider fabrication of validation evidence. An operator with legitimate access to PED tooling manually crafts an HCAD or validation receipt for an act that was never actually validated.
Mitigation: validation evidence is itself bound (hash-linked) into the chain that the Finality Sink verifies; a fabricated HCAD lacking a genuine ALF/RBD/OPC/FCU validation trail from an attested PED instance fails sink verification if the sink checks provenance of the validation itself (e.g., a signature from an attested PED key) rather than merely the shape of the HCAD. Deployments concerned with this threat SHOULD bind HCAD issuance to attested PED signing keys, not merely to HCAD schema conformance.¶

T8 — Denial-of-service to force fail-open. An attacker floods the PED or Finality Sink to induce resource exhaustion, hoping operators disable enforcement to restore availability.
Mitigation: Section 7 requires fail-closed behavior for missing, stale, or unverifiable protected state; the architecture treats unavailability of the PED or sink as a denial condition for new effectuations, not as a reason to bypass finality. This is an explicit availability/safety trade-off discussed in Section 8.10.¶

T9 — Side-channel or timing attack against sealed execution material. In the advanced non-completability path, an attacker attempts to infer or extract the missing execution material through timing, power, or other side channels on the sink or PED.
Mitigation: this is a standard hardware-security-module and confidential- computing concern rather than one specific to this architecture; implementations SHOULD apply established side-channel countermeasures for whatever key-management or TEE substrate they use to hold sealed material.¶

T10 — Supply-chain compromise of the ALF/RBD baseline. An attacker compromises the build or update pipeline that establishes the Algorithmic Logic Fingerprint or Runtime Behavioral Descriptor baseline, so that a subsequently malicious model or agent still matches the "approved" fingerprint.
Mitigation: ALF/RBD matching is a process-integrity predicate, not the sole finality gate (see Section 2.2) — it narrows the space of acts that proceed to OPC/FCU/RCAE/consequence-simulation checks, but a poisoned baseline does not by itself grant effectuation authority, since downstream predicates still evaluate the specific act's provenance, factual support, and consequence envelope independently of ALF/RBD status.¶

T12 — Downgrade to the base path when non-completability was required. An attacker (or a misconfigured deployment) induces the system to process a high-risk Candidate Act through the base finality path rather than the advanced non-completability path, so that a compromised sink alone becomes sufficient to effectuate it.
Mitigation: risk class and required finality path SHOULD be bound into the RCAE and HCAD at Candidate Act formation time (not selected later by the effectuating component), and the Finality Sink SHOULD refuse to accept a base-path capability for an act whose RCAE marks it as requiring non-completability.¶

8.1. "Doesn't this duplicate the tool-permission scoping already in function calling / MCP?"

Existing tool-call allowlisting, MCP scoped tool grants, and function-calling schemas constrain which tools a model may invoke and with what argument shape. They generally do not evaluate whether this specific generated argument is factually supported, within a defined consequence envelope, or consistent with current policy/revocation state at the moment of effectuation. [draft-das-agentic-tool-binding] (companion draft) binds this architecture directly onto tool_use/function-calling/MCP tools/call dispatch to make the relationship concrete: the tool-permission layer decides eligibility to call a tool at all; the Candidate-Act layer decides whether this particular call, with this particular content, may complete. The two are complementary, not redundant — see Section 3.2.¶

8.2. "What is the latency overhead, and how does this work for interactive, low-latency chat completions?"

The document does not currently specify a target latency budget or measured overhead, and this is a legitimate open engineering question rather than a solved one. The base path adds, at minimum, HCAD generation and RCAE/consequence- simulation evaluation before capability release; the advanced non-completability path adds sink-side reconstruction/unsealing. For latency-sensitive interactive use (e.g., low-risk conversational turns with no external effect), the architecture is intended to apply primarily to effect-capable outputs — a Candidate Act is only formed for outputs that would trigger an externally effective act (Section 2.2) — so purely informational completions are not expected to enter the finality pipeline at all. For effect-capable but latency-sensitive acts (e.g., a high-frequency low-value tool call), graduated finality (Section 3.9) permits pre-authorized, narrowly-scoped, reduced-value fast paths rather than forcing every act through full escalated review; quantifying the achievable latency for such fast paths is left to implementation and benchmarking, not specified normatively here.¶

8.3. "Isn't the Finality Sink / PED a centralization risk or single point of failure?"

Yes, in a naive single-instance deployment, and the document does not claim otherwise (Section 7, Section 6, T3/T4). The architecture specifies the finality protocol — the sequence of predicates and the non-bearer binding properties — not a mandated deployment topology. Nothing in the base or advanced path requires a single PED or sink instance; multi-party approval, threshold signing across independent PED replicas, or per-jurisdiction/per-tenant sink instances are all conformant deployment patterns. Availability engineering for the PED/sink (replication, threshold quorum) is an implementation concern the document flags but does not itself specify.¶

8.4. "How does this interact with token-by-token streaming, where the 'output' doesn't exist as a discrete object until generation completes?"

Candidate Act formation is defined over the effect-capable output once it is complete enough to be evaluated as a discrete act (e.g., a completed tool call, a completed message intended for external send, a completed payment instruction) — not over intermediate generation tokens. Streaming text intended purely for display to the requesting user, with no external effect, does not itself constitute a Candidate Act. Where a system streams partial tool-call arguments and begins side effects before generation completes, that pattern is itself the kind of premature-effectuation risk this architecture is meant to close off: implementations SHOULD NOT begin effectuation from partial/streaming output.¶

8.5. "What actually stops a jailbroken or adversarially-fine-tuned model from forging a valid Candidate Act on its own?"

The model is treated as untrusted with respect to finality — see T6 in Section 6.2. Candidate Act formation, HCAD generation, and predicate validation are specified as occurring in the Protected Enforcement Domain, which is architecturally distinct from the model's own inference process; a model cannot itself mint a valid HCAD, capability, or Execution Handle, because those artifacts require PED-side attestation, epoch state, and (in the advanced path) sink-side sealed material the model has no access to. A compromised model can request an act it should not be permitted to take, but requesting is not the same as effectuating; the request is still evaluated against externally anchored provenance, factual-support, and consequence-envelope predicates it does not control.¶

8.6. "FCU (factual claim) verification assumes a ground-truth oracle. What about domains with no verifiable ground truth — creative writing, opinion, open-ended reasoning?"

FCU verification is scoped to "hallucination-sensitive outputs" (Section 4.1), not to every generated token. The architecture is directed at outputs that become external, effect-bearing consequences (payments, database mutations, communications sent on the user's behalf, physical actuation, and similar); purely creative or opinion content that carries no such consequence is not the target of FCU verification and is not expected to require it. Where a consequence-bearing act does rest on an unverifiable factual premise (no available ground truth), the correct outcome under this architecture is denial, quarantine, or escalation pending human approval — not silent effectuation on an unverified claim.¶

8.7. "Who operates the PED in a real deployment — the model provider, the enterprise customer, or a third party? What's the trust and liability model?"

The document specifies the architecture, not a fixed deployment or business model; a PED could plausibly be operated by the model provider (inline in the serving stack), by the deploying enterprise (as middleware in front of the effectuation interfaces it controls), or by an independent attestation service. Each placement has different trust and liability implications that the document does not adjudicate. This is flagged as an open deployment-architecture question rather than resolved here.¶

8.8. "How is this different from existing capability-based security (e.g., Zanzibar-style relationship tuples, Cap'n Proto capabilities), sealed secrets, or policy engines like OPA — isn't this a recombination of known primitives?"

The individual primitives referenced — capability tokens, policy evaluation, sealed/HSM-held material, provenance tracking — are independently known. The disclosed contribution, as claimed across the related PCT filings (Appendix A), is their specific composition into a mandatory, non-bypassable sequence gating the transition from AI-generated computation to external consequence, with the non-bearer capability bound to act-specific content hash, provenance, and consequence-envelope state rather than merely to identity or role, and with the optional cryptographic non-completability property removing the Finality Sink's unilateral ability to complete the act. Whether this composition is novel and non-obvious over any specific piece of prior art is a patent-examination question addressed during prosecution of the related applications, not settled by this document.¶

8.9. "How does this handle multi-step agentic plans, where step N depends on the (still non-effective) result of step N-1 — won't every intermediate step needing its own Candidate Act make agent loops impractically slow?"

The document does not require that every internal reasoning or planning step form a Candidate Act — only effect-capable outputs that would themselves become external consequences (Section 2.2). Purely internal plan-construction steps that produce no external effect are not Candidate Acts. Where an agentic plan's later steps genuinely depend on the external effect of an earlier step (e.g., step 2 needs the result of a payment made in step 1), step 1 must still complete finality before step 2 can proceed, since step 2's Candidate Act cannot be truthfully formed without that result. Composition across many agents or many chained effectful steps (T11, Section 6.2) is flagged as an open problem, not a solved one: single-PED validation of each step in isolation does not by itself catch a multi-step plan whose steps are each individually within-envelope but whose combination is not.¶

8.10. "Mandatory fail-closed sounds good for safety but creates an availability/DoS risk — how do you avoid legitimate high-volume agentic workloads (thousands of tool calls per second) being halted by PED/sink unavailability or an attacker deliberately overloading the PED?"

This is a real trade-off the document makes explicitly rather than hiding: T8 in Section 6.2 treats forced unavailability as a path to denial-of-service, and Section 7 still requires fail-closed behavior in that case, because the alternative — failing open under load — defeats the purpose of the architecture precisely when an attacker has the strongest incentive to induce that failure. The document's answer to the resulting availability concern is architectural, not a relaxation of fail-closed: PED and sink capacity, replication, and graduated finality's fast paths for narrowly pre-scoped, low-risk, reduced-value acts (Section 3.9) are the intended mitigation for throughput, not weakening the fail-closed guarantee itself.¶

8.11. "What's the key-management, rotation, and revocation story for PED signing keys and sink-bound sealed material?"

The document specifies the finality-protocol data model (HCAD, capability, Execution Handle) and the required binding properties (policy epoch, revocation epoch, nonce, expiry, one-time use), but does not itself specify a key-management protocol; implementations are expected to use established key-management practice (HSM-backed signing keys, standard rotation/revocation procedures) for whatever keys back PED attestation and sink-bound sealed material. This is an implementation concern outside this document's scope, consistent with how TLS specifies a handshake protocol without mandating a specific PKI operational practice.¶

8.12. "Why would a frontier lab voluntarily absorb the engineering cost and latency tax of this architecture rather than continuing with existing guardrails, tool allowlists, and human-in-the-loop review?"

This document makes a technical case, not a business case, and does not attempt to resolve the adoption-incentive question. The technical argument is narrower: for effect-capable AI outputs, existing model/workflow/runtime approval does not by itself constrain whether a specific generated output should become a specific external consequence (Section 2.2), and that gap persists regardless of adoption incentives. Whether the cost of closing that gap through this specific architecture is justified for a given deployment's risk profile is a decision left to implementers.¶

8.13. Other gaps not yet addressed in this document

For completeness, the following questions are anticipated but not yet given a worked answer anywhere in this draft or its companions, and are noted here as open items rather than silently omitted:¶

• A quantified latency/throughput budget or reference benchmark for the base and advanced paths (see Section 8.2).¶

• A concrete key-management and PED-attestation protocol, rather than a reference to "established practice" (see Section 8.11).¶

• A formal cross-domain consequence-composition mechanism for multi-agent or multi-step plans (T11, Section 8.9).¶

• Guidance on partial/rollback semantics when a multi-effect Candidate Act (e.g., a batch of database mutations) is authorized as a unit but effectuation fails partway through at the sink.¶

• Interoperability testing or a reference conformance suite demonstrating the base path against a real tool-calling/MCP stack, beyond the architectural binding described in [draft-das-agentic-tool-binding].¶

9.1. Test Coverage

The repository's test suite (Python unittest) comprises 74 tests covering: non-effective-state invariants and output-hash correctness; ordering of evidence recording before handle issuance; expiry, policy-epoch, and revocation-epoch invalidation; persistence across database reopening; replay and concurrent-consumption handling with atomic UNUSED -> CONSUMED_PENDING -> EFFECTUATED transitions; tampering detection across the Execution Handle, HCAD, validation receipt, and Candidate Act; substitution attacks against every bound field (output, originating system, model, workflow, recipient, tool, sink, purpose, jurisdiction, data class, risk class, requested consequence, and ALF identifier); policy-violation and threat scenarios corresponding to Section 6.2 (unapproved systems/models/tools, ALF mismatch, runtime-behavior drift, stale or invalid provenance, unsupported factual claims, unsafe consequence simulation, out-of-envelope recipient/purpose/ jurisdiction/data-class/consequence, excessive risk or scope, missing human approval, duplicate approvals, intentional delay); and the graduated decision set (allow, deny, quarantine, redact, delay, sandbox, reduce scope, escalate). All 74 tests passed, with zero failures and zero skips, both in the development directory and from a freshly extracted release archive.¶

9.2. Non-Normative Latency Benchmark

Consistent with Section 8.2, this document does not impose a mandatory numeric latency target. The repository defines its own non-normative engineering regression targets and recorded the following local, single-process microbenchmark (SQLite in-memory, no network I/O, 1,000 iterations after 100 warm-up iterations):¶

These figures exclude network round-trip time, remote evidence retrieval, real consequence-simulation cost, hardware-security operations, replicated storage, distributed consensus, external API or payment-settlement latency, queueing, and multi-region communication, and MUST NOT be read as a production SLA. They are offered only as an existence proof that the base-path predicate sequence itself need not dominate end-to-end latency in a single-process deployment; the open engineering questions in Section 8.2 and Section 8.13 remain open at the distributed-deployment level.¶

9.3. Scope and Limitations of the Reference Implementation

The reference implementation is a software emulation, not a hardware or production system, and its trusted computing base assumes the PED, Finality Sink, configured cryptographic secret, clock, epoch source, and SQLite engine are not compromised. It does not implement a real AI model or agent runtime, a real evidence-generation system, or a complete world-model consequence simulator; it uses software-held HMAC-SHA-256 rather than an HSM, TPM, secure enclave, or remote attestation, and does not demonstrate hardware-bound non-exportability or physical non-completability. SQLite provides local atomicity, not distributed consensus, and no real external API, payment rail, robot, or production system was contacted. Formal verification, fuzzing, penetration testing, and hardware fault injection were not performed, and the other language targets it documents (TypeScript, Go, Rust, Java, Kotlin, C#, C/C++, WebAssembly, secure elements, FPGA) are design guidance only and were not implemented or tested. These limitations do not narrow the claims of this document; they scope what the reference implementation itself does and does not demonstrate.¶

9.4. Licensing of the Reference Implementation

The reference implementation repository is published under the Creative Commons Attribution-NonCommercial 4.0 International License (CC BY-NC 4.0); attribution is required and commercial use requires separate written permission from the rights holder. That copyright license does not itself grant patent rights; commercial implementation of the architecture described in this document may require a separate patent license under the applications identified in Appendix "Appendix A. Intellectual Property Disclosure — Related Applications", consistent with BCP 79.¶

9.5. Related Public-Policy Resource

For non-normative context on the public-policy and digital-sovereignty framing of this architecture, see the Applicant's community submission to the European Commission's Apply AI Alliance Futurium platform:¶

[Futurium-Sovereignty] — "Protecting Europe: A Technical Foundation for Digital Sovereignty, Data Protection, and AI Governance" — https://futurium.ec.europa.eu/en/apply-ai-alliance/community-content/protecting-europe-technical-foundation-digital-sovereignty-data-protection-and-ai-governance¶

That submission is a policy-oriented companion piece; it does not alter or extend the technical claims made in this Internet-Draft.¶

9.6. Related DAS Protocols Internet-Drafts

This document is one member of a broader family of DAS Protocols Internet-Drafts applying the execution-finality architecture to specific domains. The current related drafts, each linked to its IETF Datatracker page, are:¶

• draft-das-ntn-rf-execution-finality¶

• draft-das-payment-execution-finality¶

• draft-das-precision-bounded-egress¶

• draft-das-ai-native-6g-execution-finality¶

• draft-das-6g-query-scoped-communication-handles¶

• draft-das-map-discovery-communication-finality¶

• draft-das-rats-attestation-bnd-execution-finality¶

• draft-das-child-safe-rendering-finality¶

• draft-das-rats-openai-anthropic-extraction¶

• draft-das-protocols-enterprise-ai¶

• draft-das-rats-frontier-model-extraction¶

• draft-das-enterprise-ai-output-finality¶

• draft-das-execution-finality-ai-interoperability¶

• draft-das-agentic-tool-binding¶

• draft-das-execution-finality-protocol-layer¶

• draft-das-eu-ai-act-execution-enforcement¶

• draft-das-global-privacy-execution-enforcement¶

• draft-das-digital-sovereignty-finality¶

• draft-das-agentic-execution-finality¶

• draft-das-ot-actuation-finality¶

• draft-das-protocols-candidate-act-finality (this document)¶

• draft-agentic-ai-tool-execution-finality¶

• draft-das-hardware-enforced-execution-finality¶

Datatracker links point to the latest posted revision of each draft, which may be a later revision than the one current at the time this document was prepared.¶

A.1. Related Indian Provisional Applications

The present work is technically aligned with the Applicant’s broader body of work developed across the following Indian provisional patent applications:¶

1. Indian Patent Application No. 202531123959, filed 9 December 2025;¶

2. Indian Patent Application No. 202531123977, filed 9 December 2025;¶

3. Indian Patent Application No. 202531125643, filed 12 December 2025;¶

4. Indian Patent Application No. 202531129538, filed 20 December 2025;¶

5. Indian Patent Application No. 202531130168, filed 22 December 2025;¶

6. Indian Patent Application No. 202531130665, filed 23 December 2025;¶

7. Indian Patent Application No. 202631000572, filed 3 January 2026;¶

8. Indian Patent Application No. 202631001586, filed 7 January 2026;¶

9. Indian Patent Application No. 202631002990, filed 12 January 2026;¶

10. Indian Patent Application No. 202631004331, filed 16 January 2026;¶

11. Indian Patent Application No. 202631005583, filed 20 January 2026;¶

12. Indian Patent Application No. 202631005645, filed 20 January 2026;¶

13. Indian Patent Application No. 202631006616, filed 22 January 2026;¶

14. Indian Patent Application No. 202631007467, filed 26 January 2026;¶

15. Indian Patent Application No. 202631009579, filed 30 January 2026;¶

16. Indian Patent Application No. 202631011216, filed 3 February 2026;¶

17. Indian Patent Application No. 202631011630, filed 3 February 2026;¶

18. Indian Patent Application No. 202631016797, filed 16 February 2026;¶

19. Indian Patent Application No. 202631018571, filed 18 February 2026;¶

20. Indian Patent Application No. 202631024957, filed 3 March 2026;¶

21. Indian Patent Application No. 202631030760, filed 14 March 2026;¶

22. Indian Patent Application No. 202631034260, filed 21 March 2026;¶

23. Indian Patent Application No. 202631035846, filed 24 March 2026;¶

24. Indian Patent Application No. 202631038227, filed 27 March 2026;¶

25. Indian Patent Application No. 202631041923, filed 1 April 2026;¶

26. Indian Patent Application No. 202631043195, filed 4 April 2026;¶

27. Indian Patent Application No. 202631043507, filed 6 April 2026;¶

28. Indian Patent Application No. 202631046689, filed 11 April 2026;¶

29. Indian Patent Application No. 202631046739, filed 12 April 2026;¶

30. Indian Patent Application No. 202631047382, filed 14 April 2026;¶

31. Indian Patent Application No. 202631049021, filed 17 April 2026; and¶

32. Indian Patent Application No. 202631051652, filed 23 April 2026.¶

A.2. Related International (PCT) Applications

The present document is also technically related to subject matter disclosed in one or more of the following international applications:¶

1. PCT/IB2026/053385, filed 7 April 2026;¶

2. PCT/IB2026/054453, filed 5 May 2026;¶

3. PCT/IB2026/055615, filed 4 June 2026 (the “Mothership Application” / “DAS Protocols Mothership”);¶

4. PCT/IB2026/055760, filed 7 June 2026;¶

5. PCT/IB2026/055870, filed 10 June 2026;¶

6. PCT/IB2026/056058, filed 13 June 2026;¶

7. PCT/IB2026/056353, filed 22 June 2026;¶

8. PCT/IB2026/056771, filed 1 July 2026;¶

9. PCT/IB2026/056809, filed 1 July 2026;¶

10. PCT/IB2026/056941, filed 6 July 2026; and¶

11. PCT/IB2026/057198, filed 12 July 2026.¶

The foregoing applications may disclose related, complementary, overlapping, upstream, downstream, domain-specific, or implementation-specific aspects of protected execution governance, non-bearer authority, protected validation evidence, technical non-completability, mandatory mediation, artificial- intelligence governance, and execution-finality enforcement.¶

A.3. Relationship to the Mothership Application (PCT/IB2026/055615)

International Application No. PCT/IB2026/055615, filed 4 June 2026, discloses a broader execution-finality architecture. The present disclosure develops a focused embodiment directed at preventing AI-generated hallucinations, unsupported outputs, stale outputs, and unsafe agentic acts from becoming external consequences through Candidate-Act Finality, Consequence Simulation, Escalated Conditional Finality, and Cryptographic Execution-Dependency Non-Completability.¶