ISO/IEC DIS 24970 Gap Analysis: Pre-Execution Enforcement Receipt Schema
ISO/IEC DIS 24970 specifies requirements for AI system transparency and traceability. This brief identifies four gaps in the current draft relevant to agentic AI systems: the absence of a receipt structure for pre-execution enforcement decisions, the absence of an enforcement failure taxonomy for ordered agent sequences, the absence of a chain integrity specification, and the absence of a specification for infrastructure-fetched evidence binding at enforcement time. A production reference implementation — the slp8_receipt_v2 schema — is offered for SC 42 consideration, with over one million signed enforcement decisions as evidence of operational feasibility.
1. Standard Under Review
ISO/IEC DIS 24970, Information technology — Artificial intelligence — AI system transparency and traceability, is under development by ISO/IEC JTC 1 / SC 42. It targets Q4 2026 finalisation, coinciding with the EU AI Act high-risk obligations window (December 2027 extended deadline under the Digital Omnibus on AI, May 2026).
The standard addresses transparency mechanisms for AI systems — documentation requirements, audit trails, and traceability of AI decisions and outputs. Its scope is directly relevant to the agentic AI deployment model, where a system composed of multiple AI agents executes ordered decision sequences with real-world consequences.
This brief addresses the gap between DIS 24970's traceability requirements and the enforcement record structure required to satisfy them in an agentic context. The four gaps identified are not editorial — they reflect structural absences in the draft that leave implementers without a specified record format for the most important transparency events in an agentic system: the enforcement decision made before an action executes, and the independent evidence that justified it.
2. Gap 1 — No Receipt Structure for Pre-Execution Decisions
DIS 24970 contains no specification for records generated before an AI agent action executes. The standard's traceability requirements address AI outputs and post-hoc decision records. Pre-execution enforcement — a gate decision made before the agent acts, recorded independently of the agent's own reporting — is not addressed. No fields are specified for ALLOW records. No fields are specified for DENY records. No distinction is drawn between self-reported agent logs and infrastructure-generated enforcement receipts.
This gap is consequential. A pre-execution enforcement receipt is structurally different from a post-execution log in two ways that matter for transparency and traceability:
Independence. A post-execution log is written by the AI system or application layer — the same system whose behaviour is being recorded. A pre-execution receipt is written by an enforcement layer that the agent cannot access or influence. The agent cannot write, alter, or selectively suppress its own gate receipts. This structural independence is what makes the receipt admissible as evidence rather than testimony.
Temporal priority. A receipt is written before the action executes. If the gate denies, a DENY receipt is written — proof the gate was active and refused, even though no action occurred. Post-execution logging has no mechanism to record events that were stopped before they ran. The DENY receipt closes this gap: it is forensic evidence of enforcement, not of action.
Canonical field set for an enforcement ALLOW decision (alphabetically ordered — same order used to compute pack_id):
action · action_type · attestation · decision: "ALLOW" · function · key_id · nonce · pack_id · payload_hash · prev_receipt_id · schema_version · sequence_id · signature · step · ts_ms
Canonical field set for an enforcement DENY decision — proof the gate ran and refused:
decision: "DENY" · denial_code · expected_step · function · nonce · pack_id · sequence_id · signature · step · ts_ms
The attestation field extends the ALLOW receipt to carry per-step evidence — a risk score, a KYC reference, a human approval token — signed into the receipt at the moment of enforcement. This directly satisfies the traceability requirement for AI systems making automated decisions about individuals: not just that the decision occurred, but what evidence justified it.
3. Gap 2 — No Enforcement Failure Taxonomy
DIS 24970 does not enumerate the categories of enforcement failure that a pre-execution gate must record. For ordered AI agent sequences, enforcement failures are not generic errors — they are specific, named events with distinct forensic implications. Without a taxonomy, implementers cannot produce interoperable denial records, and auditors cannot interpret them consistently.
The slp8_receipt_v2 schema enumerates seven denial codes covering the complete failure taxonomy for ordered AI agent sequences. Each maps to a specific enforcement rule and is machine-readable in the denial receipt.
| Denial code | Enforcement failure | Forensic implication |
|---|---|---|
SEQUENCE_VIOLATION |
Step arrived out of defined order | Agent attempted to skip or reorder a mandatory step. Receipt carries expected_step — the step the gate was waiting for. |
REPLAY_NONCE |
Nonce already used in this or any prior sequence | Replay attack detected. Receipt carries the reused nonce — proof of the attempt. |
SEALED_SEQUENCE |
Sequence already completed and permanently closed | Agent attempted re-entry after terminal step. Sequences cannot be unsealed. |
NO_POLICY_MATCH |
Function name not in the defined policy map | Agent attempted a step outside the approved sequence definition. |
FUNCTION_STEP_MISMATCH |
function and step fields do not match |
Payload integrity violation — the step identifier and function identifier must be identical by design. |
ACTION_NOT_ALLOWED |
action_type not in the permitted set for this function |
Agent presented a valid step with an unpermitted action type — policy boundary violation. |
STALE_TIMESTAMP |
|ts_ms − now| > 300 seconds | Closes the replay-with-fresh-nonce-after-delay vector. A valid nonce cannot be recycled after the timestamp window expires. |
This taxonomy is not theoretical — every code has fired in production, generating signed DENY receipts that remain in immutable storage. The evidence is publicly verifiable without login at report.agenticrail.nz/report.
4. Gap 3 — No Chain Integrity Specification
DIS 24970's traceability requirements do not specify how records should be linked to prove ordering and detect tampering. Without a chain integrity specification, a set of individual records — even if each is signed — cannot prove that no records were inserted, deleted, or reordered after the fact. Individual record integrity and sequence integrity are different properties. The standard addresses neither.
The prev_receipt_id field in slp8_receipt_v2 implements a hash chain across the enforcement sequence. Its value is the SHA-256 of the preceding receipt's canonical JSON — the same deterministic hash used to compute pack_id. This creates a self-verifying chain with four properties directly relevant to DIS 24970's traceability requirements:
- 1Tamper detection. Modifying any receipt changes its
pack_id, which breaks theprev_receipt_idreference in every subsequent receipt. The break propagates forward — a single altered record is detectable without examining each receipt individually. - 2Insertion detection. An inserted receipt cannot carry a valid
prev_receipt_id— it would need the hash of its predecessor, which was computed before the insertion. The chain cannot accommodate additions after the fact. - 3Ordering proof. The chain direction is forward-only. Step N's receipt references step N-1's hash. Reordering receipts breaks every reference across the reorder boundary.
- 4Third-party verifiability. Verification requires only the receipts themselves — no trusted third party, no oracle. Any verifier with the sequence ID can reproduce the chain check independently.
pack_id = SHA-256(JSON.stringify(pack, alphabetically sorted keys))
prev_receipt_id on receipt N = pack_id of receipt N-1
Receipt 0 (first step): prev_receipt_id = null
Chain verification: recompute each pack_id and confirm it matches the prev_receipt_id of the following receipt.
5. Gap 4 — No Infrastructure-Fetched Evidence Binding at Enforcement Time
DIS 24970 specifies no mechanism by which an enforcement layer should retrieve external evidence at decision time and bind it to the enforcement receipt. Where the standard addresses evidence or justification for AI decisions, it does not distinguish between evidence supplied by the AI agent itself and evidence retrieved independently by enforcement infrastructure. This distinction is consequential: agent-supplied evidence is self-reporting — the system being governed controls what evidence is attached to its own decisions. Infrastructure-fetched evidence is independent of the agent and cannot be altered, suppressed, or selectively reported by the system under governance.
This gap is structurally distinct from the absence of a receipt structure (Gap 1). A receipt can carry an attestation field populated by the agent — but if the agent populates it, the evidence is not independent. The gap is not in the receipt format; it is in the specification of who retrieves the evidence and when. DIS 24970 does not address this.
Independence. For attestation to function as independent evidence, the enforcement layer — not the agent — must retrieve it. An agent that self-reports its own risk score, KYC result, or approval token is producing testimony, not evidence. The enforcement layer calling an external oracle and writing the result into the receipt before returning a decision to the agent produces evidence the agent cannot influence.
Binding. Infrastructure-fetched evidence must be cryptographically bound to the specific enforcement decision — same nonce, same sequence position, same timestamp window. Evidence fetched at enforcement time and signed into the ALLOW receipt cannot be replayed, detached, or reattached to a different decision without breaking the receipt's HMAC signature.
On each ALLOW decision, the enforcement gate calls a registered customer endpoint — a risk scoring service, a KYC oracle, a compliance check — and writes the response directly into the attestation field of the ALLOW receipt before returning the decision to the agent. The agent does not supply, handle, or influence the attestation content. Subsequent steps receive the prior step's attestation as part of the receipt chain — the evidence sequence is as strong as the receipt chain that carries it. The mechanism is endpoint-agnostic: the gate calls whatever authoritative service the operator registers.
6. Reference Implementation — slp8_receipt_v2
The slp8_receipt_v2 schema is a production enforcement receipt schema with over one million signed decisions predating DIS 24970's Q4 2026 finalisation. It is offered as a reference structure for SC 42's consideration in addressing the three gaps identified above.
| Property | Value |
|---|---|
| Schema name | slp8_receipt_v2 |
| Schema format | JSON Schema Draft 2020-12 — published agenticrail.nz/spec/receipt-schema.json |
| Schema date | 2026-05-17 |
| Closed schema | additionalProperties: false on all objects |
| Objects defined | Receipt (slp8_receipt_v2), Pack (slp8_pack_1.0), Request Payload |
| Signing algorithm | HMAC-SHA256 (active) · Ed25519 (implemented, pending key provisioning) |
| Signing key ID | k1_2026-02-22_01 |
| Production decisions | 1,000,000+ ALLOW and DENY receipts in immutable storage |
| Public verification | report.agenticrail.nz/report — no login required for demo sequences |
| Formal specification | agenticrail.nz/spec/ — v1.0, published 2026-05-17 |
7. Mapping to DIS 24970 Transparency Requirements
The table below maps the three gaps identified in this brief to the slp8_receipt_v2 mechanisms that address them, cross-referenced to the relevant DIS 24970 transparency and traceability requirements.
| DIS 24970 requirement area | Gap in current draft | slp8_receipt_v2 mechanism |
|---|---|---|
| Transparency of AI decisions | No record structure specified for pre-execution enforcement decisions (ALLOW or DENY) | Canonical ALLOW and DENY receipt field sets. DENY receipts record enforcement events for steps that never executed — the only mechanism that proves the gate was active and refused. |
| Traceability of AI actions | No chain integrity specification — individual records cannot prove ordering or completeness | prev_receipt_id SHA-256 chain across the sequence. Self-verifying without trusted third party. Tamper, insertion, and reordering all break the chain. |
| AI decision categorisation | No enumeration of enforcement failure categories for ordered agent sequences | Seven denial codes: SEQUENCE_VIOLATION, REPLAY_NONCE, SEALED_SEQUENCE, NO_POLICY_MATCH, FUNCTION_STEP_MISMATCH, ACTION_NOT_ALLOWED, STALE_TIMESTAMP. Machine-readable. Carried on DENY receipts. All have fired in production. |
| Evidence independence — oversight proof | No specification for how enforcement infrastructure should retrieve external evidence independently of the agent and bind it to the enforcement receipt at decision time | Infrastructure-fetched attestation — the gate calls a registered customer endpoint on each ALLOW and writes the response into the receipt before returning the decision. The agent cannot alter or suppress the evidence. Cryptographically bound to the specific enforcement decision via HMAC signature. |
8. EU AI Act Alignment and SIP0001245
On 2026-05-17, TUARA KURI LIMITED submitted SIP0001245 to the EU AI Office under the EU AI Act standardisation input process, Priority 2 High. The submission identifies the same gap addressed in this brief: DIS 24970 contains no receipt structure for pre-execution AI enforcement decisions, and slp8_receipt_v2 is a production schema predating the standard's finalisation that addresses this gap directly.
The EU AI Act high-risk obligations deadline has been extended to December 2027 (Digital Omnibus on AI, May 2026). DIS 24970 targets Q4 2026 finalisation. If DIS 24970 is adopted as a harmonised standard under the EU AI Act, the absence of a pre-execution receipt structure in the current draft would leave implementers unable to satisfy Article 12 (logging requirements) at the enforcement level — the level at which evidence is produced before, not after, the AI acts.
AgenticRail has made this gap analysis available for direct standards contribution. The schema, the formal specification, and the production evidence are publicly accessible without login.
9. Live Evidence
| Metric | Value |
|---|---|
| Enforcement decisions in production | 1,000,000+ — ALLOW and DENY receipts in immutable R2 storage |
| Sequence violations enforced | 100% — zero bypasses in pressure testing at 1M decisions / 50 concurrent workers |
| DENY receipts generated | Across all seven denial code categories — publicly verifiable |
| Chain verification failures | 0 — no tampered receipt has passed chain verification |
| Deployment | Cloudflare Workers + Durable Objects + R2 + KV — globally distributed, no single point of failure |
| Public verification | report.agenticrail.nz/report — enter demo-loan-mpamzf82 |
| Formal specification | agenticrail.nz/spec/ — fingerprinted, published 2026-05-17 |