AgenticRail Enforcement Specification

This document specifies the AgenticRail deterministic enforcement gate: its decision architecture, enforcement rules, receipt structures, sequence enforcement mechanism, and cryptographic verification model. It is a technical specification, not a marketing document. Every claim here is verifiable without login or operator involvement: run a test sequence at agenticrail.nz/demo/, verify the receipt chain at report.agenticrail.nz/report, or watch live enforcement at dashboard.agenticrail.nz.

1. Decision Architecture

AgenticRail sits between an AI agent's intent and the action's execution. Before any step runs, it must pass the gate. The gate returns one of three responses. No other outputs exist.

ALLOW and DENY are the enforcement decisions; HALT is a rejection at the boundary, returned when a request is refused before enforcement runs. Every enforcement decision — including DENY — produces a cryptographic receipt written before the action executes. A DENY receipt is forensic evidence of enforcement. It proves the gate ran and refused. A HALT produces no receipt, because nothing reached enforcement to be recorded. This is the architectural distinction from post-execution logging systems, which have no mechanism to receipt a step that was stopped before it ran.

2. Enforcement Rules

Rules are evaluated in order. The first failure terminates evaluation and returns DENY with the corresponding denial code. All nine rules must pass for ALLOW. (Corrected in v1.2, 2026-07-05 — see the amendment below: rules 1–3's actual codes, and rule 8, were not accurately documented in v1.0/v1.1.)

• 1Function missing or empty → DENY:missing_function
• 2action_type not permitted for function → DENY:ACTION_NOT_ALLOWED
• 3step !== function → DENY:FUNCTION_STEP_MISMATCH
• 4Sequence already sealed → DENY:SEALED_SEQUENCE
• 5Nonce already used → DENY:REPLAY_NONCE
• 6Step out of order → DENY:SEQUENCE_VIOLATION
• 7|ts_ms − now| > 300s → DENY:STALE_TIMESTAMP
• 8RECORD_RESULT at boundary citing a witnessed_pack_id that doesn't match the real, durably-written, immediately-preceding receipt → DENY:ARTIFACT_UNBOUND (added 2026-07-05)
• 9All pass → ALLOW

Rule 7 closes the replay-with-fresh-nonce-after-delay attack vector. A valid nonce does not help an attacker whose timestamp window has expired. Rules 5 and 7 together mean a step cannot be replayed at any time: not immediately (nonce), not later (timestamp).

3. Enforcement Architecture

Client / Agent
  → Wrapper Worker     (auth, rate limit, D1 key store)
  → Gate Worker        (hardening, poison check, internal secret injection)
  → Core Worker        (policy map, timestamp, sequence position)
  → Durable Object     (nonce uniqueness, step counter — per sequence_id)
  → R2                 (Ed25519-signed receipts, tamper-evident storage)
  → KV                 (stats index, fast read for report generator)

The Gate is the only public entry point. The Core Worker is not publicly callable — it receives requests exclusively via service binding from the Gate, which injects an internal secret before forwarding. This means the enforcement logic cannot be bypassed by calling Core directly.

4. Payload Contract

{
  "schema_version": "1.0",
  "model_id":       "MSMD",
  "sequence_id":    "<unique sequence identifier>",
  "step":           "<step name>",
  "function":       "<function name — must equal step>",
  "action_type":    "<permitted action type for this function>",
  "action":         "<human readable label>",
  "inputs":         { "signal": "..." },
  "nonce":          "<uuid — unique per step, never reused>",
  "ts_ms":          1775262544154
}

The invariant step === function is an ontological constraint, not a validation rule. A step cannot be what it is not. The gate does not attempt to reconcile a mismatch — it denies immediately.

5. Sequence Spines

The gate enforces ordered sequences called spines. Steps must execute in the defined order. No skipping. No replay. The sequence is sealed permanently at the final step — no unsealing mechanism exists.

The architecture is spine-agnostic. Any ordered sequence of named steps can be enforced with the same gate mechanism. The spine defines the permitted order; the Durable Object enforces it per sequence_id.

6. Receipt Structure — ALLOW

On ALLOW, an Ed25519-signed receipt is written to R2 storage before the action executes. Receipt fields are listed in canonical order (alphabetically sorted — the same order used to compute pack_id). (Corrected in v1.2, 2026-07-05 — v1.0/v1.1 named fields that don't exist at this level, nonce/action/schema_version, and omitted several that do. Corrected further in v1.3, 2026-07-08 — prev_receipt_id's description previously overstated what it alone protects; and prev_receipt_hash was added as a new field. This table now matches the live implementation and the published JSON Schema exactly.)

meta (nested, alphabetical): action_type, function, model_id, policy_map_ids, sequence_id, step.

7. Receipt Structure — DENY

Every denied step produces a DENY receipt — the same field shape as ALLOW above, not a separate structure. This is the critical distinction from post-execution logging: the gate receipts what it stopped, not just what it allowed. A DENY receipt is forensic evidence of an enforcement event — proof the gate was active and refused a non-compliant step. (Corrected in v1.2, 2026-07-05 — v1.0/v1.1 described a separate DENY shape with denial_code/expected_step fields that were never implemented; the real reason is carried in the same reasons array ALLOW uses, empty on ALLOW and populated on DENY.)

Common values in reasons at the enforcement-rule level: ACTION_NOT_ALLOWED, ARTIFACT_UNBOUND, FUNCTION_STEP_MISMATCH, REPLAY_NONCE, SEALED_SEQUENCE, SEQUENCE_VIOLATION, STALE_TIMESTAMP. Field-validation codes (e.g. missing_nonce) are enumerated in the JSON Schema, not repeated here.

8. Cryptographic Model

pack_id is computed as SHA-256 of the receipt's canonical JSON — keys alphabetically sorted, values as-stored. This makes the fingerprint deterministic regardless of key insertion order. Any verifier can reproduce it independently.

prev_receipt_id links every receipt to the previous receipt in the sequence by pack_id — an identifier reference establishing chain order. On its own it proves something with that identifier preceded this receipt; it does not prove the predecessor's content is unchanged. prev_receipt_hash (added 2026-07-08, v1.3) closes that gap: a SHA-256 of the previous receipt's full canonical JSON, signature included. Tampering with any receipt in the chain changes its hash, breaking every subsequent prev_receipt_hash link even if prev_receipt_id references still match — this is the property that makes the chain self-verifying without a trusted third party. It is null for the chain's first receipt and for any link whose anchor predates this field; the compliance report treats that as "not verifiable", not "broken", and surfaces it as a distinct Chain hash column alongside the existing pack_id and linkage checks.

signature is Ed25519 over the receipt's canonical JSON (with the signature field removed), signed in the air-gapped core with key k2_2026-06-07_ed25519 and verifiable offline against the published public key. Multi-generation verification logic covers both canonical JSON and JSON.stringify forms to handle Gen-1 and Gen-2 receipts.

The signature_alg field on every receipt records the algorithm used (Ed25519 or hmac-sha256). Ed25519 signing has been active since 2026-06-07: receipts carry an Ed25519 signature verifiable against the published public key at /spec/receipt-public-keys.json with no call back to any AgenticRail endpoint. Receipts issued before the cutover carry HMAC-SHA256 under k1_2026-02-22_01 — a shared secret, therefore confirmable only server-side, not by a third party. The verifier selects key and algorithm per receipt by key_id; the compliance report flags each receipt's third_party_verifiable status so a legacy receipt cannot be mistaken for an offline-verifiable one.

What is signed. The signature covers the canonical JSON of the full receipt envelope, not only the fields tabled above. The envelope also carries meta (function, step, model_id), executed, sealed, signature_alg, and version — all inside the signed preimage. The compliance report exposes that exact preimage as signed_canonical alongside the raw signature and key_id, so a third party can reconstruct and verify the signed bytes independently. Note the semantics of executed: executed: true attests only that the gate permitted the step (decision = ALLOW). It does not assert that the downstream action ran or succeeded — AgenticRail is an enforcement layer, not an execution runtime.

payload_hash is SHA-256 of the raw request body — independent verification that the payload the gate evaluated matches what was submitted.

9. Article 12 Mapping — EU AI Act

10. Deployment

11. NIST AI RMF Mapping

A formal mapping of AgenticRail's pre-execution enforcement gate to NIST AI Risk Management Framework 1.0 subcategories: Manage 2.4 (mechanisms to supersede, disengage, or deactivate a non-compliant system), Measure 2.4 (per-action monitoring contemporaneous with execution), and Manage 4.1 (post-deployment monitoring with appeal and override). Includes the evidence package available for US enterprise and federal AI risk programme documentation.

agenticrail.nz/spec/nist-ai-rmf/ — gap analysis, subcategory mapping table, mechanism descriptions, evidence available, cross-framework alignment. Prints to two pages.

12. Formal Receipt Schema

A machine-readable JSON Schema (Draft 2020-12) for the slp8_receipt_v2 enforcement receipt is published at agenticrail.nz/spec/receipt-schema.json.

The schema formally specifies three objects:

• 1Receipt (slp8_receipt_v2) — the signed enforcement decision written to R2 before the action executes. Fields: ts_ms, pack_id, version, decision, reasons, executed, sealed, meta, attestation, payload_hash, prev_receipt_id, key_id, signature_alg, signature. additionalProperties: false on all objects — the schema is closed.
• 2Pack (slp8_pack_1.0) — the enforcement decision object whose SHA-256 canonical hash becomes pack_id. The minimal authoritative record of the decision, independent of receipt metadata. Defined at $defs.pack.
• 3Request Payload — the client payload submitted to POST /v1/evaluate. Eight required fields; the raw body is hashed to produce receipt.payload_hash. Defined at $defs.request_payload.

Relation to DIS 24970. ISO/IEC DIS 24970 (AI system transparency and traceability, targeting Q4 2026 finalisation) contains no receipt structure for pre-execution enforcement decisions — no specification of what an ALLOW or DENY record must carry, how denial codes map to enforcement rules, or how receipts chain across a sequence. The slp8_receipt_v2 schema addresses this gap directly: a production schema with over one million signed enforcement decisions predating the standard's finalisation. The reason codes (SEQUENCE_VIOLATION, REPLAY_NONCE, SEALED_SEQUENCE, UNKNOWN_STEP, FUNCTION_STEP_MISMATCH, ACTION_NOT_ALLOWED, STALE_TIMESTAMP, ARTIFACT_UNBOUND) enumerate the enforcement failure taxonomy in machine-readable form. (Corrected 2026-07-05 — the previously-listed NO_POLICY_MATCH was never implemented; UNKNOWN_STEP is the real mechanism, and ARTIFACT_UNBOUND, added 2026-07-05, is included.)

The schema is dated 2026-05-17. Future revisions carry new $id URIs and retain prior versions at their original URLs.

13. Evidence Completeness Specification

A neutral completeness specification for pre-execution agent enforcement records: the eight requirements (R1–R8) that distinguish an evidence-grade record from a logging-grade one, and the single property that divides them — irreversible sequence sealing. The framing is append versus seal: every system that keeps a record appends; a complete record also closes. The seal is the earth pin of an enforcement record — the safety ground that carries no payload and holds only when something faults. The specification names no product but its own reference implementation; it is offered as a measure any enforcement record, from any vendor, can be assessed against.

agenticrail.nz/spec/completeness/ — eight requirements, two conformance levels, the completeness test, reference implementation, framework mapping. Fingerprinted. Published 2026-06-24.

14. AI in New Zealand Health Care — Sector Gap Analysis

A cited gap analysis of New Zealand's national AI deployment in health care: ambient AI scribes in use by ~1,250 emergency-department clinicians across all public EDs (with 1,000 further licences for mental-health teams), AI-guided treatment in ICU trial, and documented use of consumer chatbots (ChatGPT, Claude, Gemini) to draft clinical notes. The brief shows that the deployment's stated safeguards — "the doctor reviews and confirms," and privacy compliance — are not, at present, captured in any sealed, pre-execution, tamper-evident record. The Medical Council's own guidance (Mar 2026) requires the accuracy check, informed consent, and documentation of AI use; the sealed receipt is the instrument that makes those requirements provable. Asserts no harm and no breach — an argument for an instrument, not against a person. Every claim cited to a primary New Zealand source.

agenticrail.nz/spec/nz-health/ — deployment scale, the evidence gap, mapping to NZ's regulatory framework, the instrument, full references. Fingerprinted. Published 2026-06-24.

15. AI in New Zealand Education Assessment — Sector Gap Analysis

A cited gap analysis of NZQA and Ministry of Education assessment integrity. NZQA's own Assessment Rules (a statutory rule under s.452(1)(m) of the Education and Training Act 2020) define Plagiarism to explicitly include "machine or device generated content (such as through the use of artificial intelligence)" — and NZQA's assessment framework has required internal work to be verifiable ("recorded in a way that allows someone else to verify the evidence") since 2020, years before generative AI existed as a public product. Reported breaches rose from 876 (2024) to 1,241 (2025); AI-attributed breaches rose from 59 to 168 over the same period. The brief shows that NZQA's own required verification steps — teacher authenticity checks, internal moderation — are still discharged through unsealed declaration forms and self-attested school paperwork, with no independent seal. Asserts no failure of duty by NZQA, the Ministry, any school, or any teacher — an argument for an instrument, not against a person. Every claim cited to a primary New Zealand source.

agenticrail.nz/spec/nzqa-nz-education/ — statutory basis, the evidence gap, mapping to NZ's regulatory framework, the instrument, full references. Fingerprinted. Published 2026-07-06.

16. Automated Decisions and the Provable Safeguard — Public-Sector Note

A technical note occasioned by New Zealand's move to automated public-sector decision-making (the Social Security (Modernisation) Amendment, in effect from 1 July 2026, permitting automated benefit decisions "with appropriate safeguards"). The note distinguishes three tiers of safeguard — asserted (a policy says the check happens), enforced (the system structurally cannot proceed past a skipped step), and provable (every decision leaves a signed, sealed, offline-verifiable receipt) — and documents from the public record that the two most consequential automated-decision failures of the past decade (Australia's Robodebt; the Dutch childcare benefits scandal) were failures of sequence and evidence at the first tier, not failures of artificial intelligence. Includes a five-minute verification anyone can run. Asserts no failure by any New Zealand agency and names no individuals.

agenticrail.nz/spec/enforceable-safeguards/ — the commitments, the failure shape, three tiers, the instrument, the test, full references. Fingerprinted. Published 2026-07-17.

17. When the Marker Is a Machine — Evidence for AI-Assisted Assessment Decisions

New Zealand marks national writing assessments with automated scoring, quality assured by human check-marking concentrated at the achievement boundaries. This note asks what evidence supports a single result when it is challenged. Its central distinction: an agreement rate is a property of a system measured across a population, while a challenge concerns one instance — and an aggregate figure carries no information about any particular script. It also notes that where an automated tool assists moderation rather than marking, the assurance layer acquires the same property as the layer beneath it, and the chain terminates only at a record that does not depend on the account of the party being checked. Asserts no failure by any agency and names no individuals.

agenticrail.nz/spec/ai-marked-assessment/ — what is already running, the four questions a challenge actually asks, the boundary-concentration point, the instrument, full references. Fingerprinted. Published 2026-07-26.

18. If AI Detectors Don't Work, What Does? — Authenticity by Process Record

Three responses to generative AI in assessment are available: prohibit it, detect it, or record the process that produced the work. New Zealand has tried the first two at national scale and stated its reasoning publicly — detection has been withdrawn by three universities and ruled unsuitable as a sole means by national guidance, and reverting to supervised handwriting works while relocating the cost onto specific students. The note sets out why prohibition and detection share one structural weakness (both interrogate the finished artifact, which cannot reveal how it was made) and what changes when the object of examination is the sequence instead. Includes the measured bias of detectors against non-native English writers, cited to the peer-reviewed study.

agenticrail.nz/spec/assessment-authenticity/ — the three options, the documented withdrawal of detection, the artifact-versus-process comparison, the instrument, full references. Fingerprinted. Published 2026-07-26.

19. NCEA Is Being Replaced — What Will Assure the Internal Assessment?

The qualifications replacing NCEA were confirmed on 16 May 2026: the New Zealand Certificate of Education at Year 12 and the New Zealand Advanced Certificate of Education at Year 13, with "every subject will include internal assessments and an examination" and a six-point A+ to E grade for every subject. Two things follow directly: no subject is assessed entirely externally, and none entirely internally — internal assessment becomes universal rather than shrinking. The note documents that the release confirming the structure contains no information about moderation, comparability or consistency of internal assessment, and that the earlier next-steps release lists those as matters for future consideration. It treats that as a design window while the design is open, not as a criticism, and covers the parallel shift to audited self-accreditation in the tertiary system.

agenticrail.nz/spec/nzce-internal-assessment/ — what has been confirmed, what follows structurally, the tertiary parallel, the window, the instrument, full references. Fingerprinted. Published 2026-07-26, amended to v1.1 the same day (adds the Ministry’s Tāhūrangi detail page as a checked source and the published commitment that assessment will be “consistent nationwide”).

20. Segregation of Duties When the Agent Is Both Maker and Checker — Controls Note

Most writing about controlling AI agents invents new vocabulary for the problem. This note does the opposite, treating agent oversight as an IT general controls question rather than an AI safety question. Segregation of duties — maker-checker, the four-eyes principle — requires that the party authorising an action is not the party performing it. An autonomous agent with tool access is both, in one process. The note sets out the four things an auditor actually asks (existence, coverage, non-bypassability, and independence of the record), why a system prompt asking for confirmation is an instruction to the maker rather than a separate checker, and the difference between evidence that a control was configured and evidence that it operated. Grades a control in three states — documented, enforced, evidenced — and names the existing record-keeping duties that already apply to automated systems without mentioning AI at all. States its own limits in full, including the absence of SOC 2 and ISO certification and the key-custody question.

agenticrail.nz/spec/segregation-of-duties/ — the control that predates the technology, the failure shape, what the auditor asks, three states of a control, who already owes the duty, the instrument, the five-minute test, a deliberate boundary, full references. Fingerprinted. Published 2026-08-04.

The v1.0 fingerprint above is permanent and unchanged. The amendment below records a later development — the activation of Ed25519 signing — as a separate, independently-fingerprinted record. v1.0 is not edited; it is superseded.

The v1.0 and v1.1 fingerprints above are permanent and unchanged. v1.2 corrects documentation errors in the ALLOW/DENY receipt field lists and denial codes published in v1.0/v1.1 (they named fields that were never implemented and omitted several that were) and adds one new enforcement rule. Neither v1.0 nor v1.1 is edited; v1.2 is a separate, independently-fingerprinted record.

The v1.0, v1.1, and v1.2 fingerprints above are permanent and unchanged. v1.3 adds one new receipt field, prev_receipt_hash — a genuine hash chain, not merely an identifier chain. Neither v1.0, v1.1, nor v1.2 is edited; v1.3 is a separate, independently-fingerprinted record.

The v1.0, v1.1, v1.2, and v1.3 fingerprints above are permanent and unchanged. v1.4 removes the Hokianga Spine definition present in v1.0-v1.3. Neither v1.0, v1.1, v1.2, nor v1.3 is edited; v1.4 is a separate, independently-fingerprinted record.