# How Does a Deterministic Enforcement Gate Decide ALLOW, DENY, or HALT?

> Markdown mirror for AI agents, generated 2026-08-12 from the live page.
> Canonical: https://agenticrail.nz/spec/
> Site context: https://agenticrail.nz/llms.txt

Specification v1.4 Published 2026-05-17 · Amended 2026-07-08 TUARA KURI LIMITED

# 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/](https://agenticrail.nz/demo/), verify the receipt chain at [report.agenticrail.nz/report](https://report.agenticrail.nz/report), or watch live enforcement at [dashboard.agenticrail.nz](https://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.

Permitted

ALLOW

Refused

DENY

Request rejected

HALT

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
- 2`action_type` not permitted for function → DENY:ACTION_NOT_ALLOWED
- 3`step !== 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
- 8`RECORD_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.

MSMD Spine — 8 steps intake → disruption → instability → state_read → internal_driver → execution → boundary → settle

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.)*

| Field | Description |
| `attestation` | Optional per-step evidence — AML results, approval hashes, boundary witness references. Excluded from poison check. |
| `decision` | **ALLOW** or **DENY** — the two enforcement decisions, same receipt shape for both. **HALT never appears in this field.** A HALT is a rejection at the boundary before enforcement runs, so no receipt is written at all. Reconciling receipts against calls will show no receipt for a HALTed call: that is correct, not a gap. |
| `executed` | Whether the decision was ALLOW (permitted) — *not* whether the downstream action ran or succeeded |
| `key_id` | Signing key identifier: `k2_2026-06-07_ed25519` (active Ed25519; receipts before the 2026-06-07 cutover carry `k1_2026-02-22_01`) |
| `meta` | Nested object — see below |
| `pack_id` | SHA-256 of canonical JSON (alphabetically sorted keys) — deterministic fingerprint |
| `payload_hash` | SHA-256 of raw request body |
| `prev_receipt_id` | `pack_id` of the previous receipt — an identifier reference (chain order), not a content hash of the predecessor. Anchor only advances on ALLOW + a confirmed-durable write (2026-07-05). |
| `prev_receipt_hash` | SHA-256 of the previous receipt's full canonical JSON, signature included (added 2026-07-08) — the actual hash chain. An in-place edit to any earlier receipt breaks every subsequent link, even if `prev_receipt_id` references still match. Null for the chain's first receipt and for any link whose anchor predates this field. |
| `reasons` | Array of denial codes — empty on ALLOW |
| `sealed` | Whether this receipt closes the sequence permanently (true only at the final step) |
| `signature` | Ed25519 over the receipt's canonical JSON minus this field, signed in the air-gapped core (pre-cutover receipts: HMAC-SHA256) |
| `signature_alg` | `Ed25519` or `hmac-sha256` |
| `ts_ms` | Gate decision timestamp in milliseconds |
| `version` | `slp8_receipt_v2` |

**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](https://agenticrail.nz/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

| Article 12 Requirement | AgenticRail Mechanism |
| Automatic logging of events | Gate decision written to R2 before action executes |
| Traceability of operation | `prev_receipt_id` chain — every step linked to previous |
| Integrity of records | Ed25519 signature (HMAC-SHA256 pre-cutover) — tamper breaks chain verification |
| Independence from AI system | Gate is architecturally separate — model cannot write its own receipt |
| Human oversight evidence | DENY receipts prove enforcement was active and refused non-compliant steps |
| Third-party verifiability | Run [agenticrail.nz/demo/](https://agenticrail.nz/demo/), take the sequence ID it returns, verify it at report.agenticrail.nz/report. No login required. |

## 10. Deployment

| Detail | Value |
| Public verification | Run [agenticrail.nz/demo/](https://agenticrail.nz/demo/), then verify the sequence ID it returns at [report.agenticrail.nz/report](https://report.agenticrail.nz/report) |
| Deployment | Cloudflare Workers + Durable Objects + R2 + KV + D1 |
| Entity | TUARA KURI LIMITED, Hokianga, New Zealand |

## 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/](https://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`](https://agenticrail.nz/spec/receipt-schema.json).

The schema formally specifies three objects:

- 1**Receipt** (`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.
- 2**Pack** (`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`.
- 3**Request 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/](https://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/](https://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/](https://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/](https://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/](https://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/](https://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/](https://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/](https://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.

Document Fingerprint — SHA-256 — v1.0 (superseded by v1.1 below)

ceebe558492a3ba33ceb78e49fd3aa7fed334ce3a8f127938e4fed0fb8a4d6ba

 This hash is SHA-256 of the canonical specification content defined below. It is reproducible independently of this page.

 **Canonical content covers:** version, date, entity, decision values, enforcement rules (numbered, in order), MSMD spine, Hokianga spine, ALLOW receipt fields (alphabetical), DENY receipt fields (alphabetical), denial codes, pack_id method, prev_receipt_id method, payload_hash method, signature algorithm, key_id, verification URL.

 **To verify:** Reconstruct the canonical string from the fields above in the order specified at [agenticrail.nz/spec/canonical.txt](https://agenticrail.nz/spec/canonical.txt) and compute SHA-256. The result must equal the hash above.

 Published: 2026-05-17 | Version: 1.0 | Key ID: k1_2026-02-22_01

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.

Amendment v1.1 — Ed25519 Activation — SHA-256

4e7ab63ed319ea2a4f45a891b16a532d709c3d716bedc2e2535139af1e2352e9

 On 2026-06-07 receipt signing was activated to **Ed25519** (key_id `k2_2026-06-07_ed25519`) and the verification public key was published at [agenticrail.nz/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) — receipts are now offline-verifiable by anyone, no endpoint required.

 **Unchanged from v1.0:** the receipt schema, canonicalization, `pack_id` derivation, and chain linkage. Only the active signature algorithm and key_id change. Receipts issued before the cutover remain HMAC-SHA256 under `k1_2026-02-22_01` and are unaffected; the verifier selects key and algorithm per receipt by `key_id`, so chains spanning the cutover verify intact.

 **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_1.txt](https://agenticrail.nz/spec/canonical-v1_1.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0 record remains independently reproducible from [canonical.txt](https://agenticrail.nz/spec/canonical.txt) and is not affected.

 Published: 2026-06-07 | Version: 1.1 | Key ID: k2_2026-06-07_ed25519

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.

Amendment v1.2 — Receipt Field & Denial Code Correction — SHA-256

6ab32d42d3055890616327ef661e0868b7d7dae4b139e4fa268f35cbc2dbd958

 On 2026-07-05, the ALLOW/DENY receipt field lists and denial codes published in v1.0/v1.1 were found to be inaccurate — they named fields that were never implemented at the receipt's top level (`nonce`, `action`, `schema_version`, `denial_code`, `expected_step`) and omitted several that were (`meta`, `executed`, `sealed`, `reasons`, `signature_alg`, `version`). Verified directly against the live enforcement engine's receipt-building code and cross-checked against the machine-readable JSON Schema at [receipt-schema.json](https://agenticrail.nz/spec/receipt-schema.json), which already carried the correct structure. v1.2 also documents the artifact-binding enforcement rule (9, added 2026-07-05: a boundary witness claim must match the real, durably-written, immediately-preceding receipt — `DENY:ARTIFACT_UNBOUND` otherwise) and its new denial code.

 **Unchanged from v1.0/v1.1:** the receipt schema, canonicalization, `pack_id` derivation, chain linkage, and signature algorithm. This amendment corrects documentation of the receipt's shape and denial-code set — it does not alter the shape or the set.

 **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_2.txt](https://agenticrail.nz/spec/canonical-v1_2.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0 and v1.1 records remain independently reproducible from their own files and are not affected.

 Published: 2026-07-05 | Version: 1.2 | Key ID: k2_2026-06-07_ed25519

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.

Amendment v1.3 — Hash-Chain Field — SHA-256

f0983383ee013ebc398aa8cda8e30293cfeecc719dd16291f47e65b70fef83a6

 On 2026-07-08, a new receipt field `prev_receipt_hash` was added: a SHA-256 of the immediately preceding receipt's full canonical JSON (signature included), not merely its `pack_id`. `prev_receipt_id` is an identifier reference — it proves something with that identifier preceded this receipt, not that the predecessor's content is unchanged. `prev_receipt_hash` closes that specific gap: an in-place edit to any earlier receipt in the chain changes its hash, breaking every subsequent link even if `prev_receipt_id` references still match. Null for the chain's first receipt, and for any link whose anchor predates this field — the report generator's chain-integrity check treats that as "not verifiable", not "broken", the same way legacy pre-Ed25519 receipts are treated as unverifiable rather than invalid. Verified directly against the live enforcement engine and report generator, then confirmed end-to-end against a real production sequence the same day (the report's `hash_chain` field showed `verified:7, broken:0, not_verifiable:1` — the 1 being the chain's own first receipt).

 **Unchanged from v1.2:** the enforcement rules, decision set, denial codes, `pack_id` derivation, and signature algorithm. This amendment adds one new receipt field only.

 **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_3.txt](https://agenticrail.nz/spec/canonical-v1_3.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0, v1.1, and v1.2 records remain independently reproducible from their own files and are not affected.

 Published: 2026-07-08 | Version: 1.3 | Key ID: k2_2026-06-07_ed25519

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.

Amendment v1.4 — Hokianga Spine Removed — SHA-256

beba65d05587ca2a368eda128187ca59ac3aa19ad92d557f7233ca24874175a6

 On 2026-07-08, the Hokianga Spine (an 8-step dialect-provenance sequence) was removed from this specification. AgenticRail is a deterministic sequence-enforcement and accountability layer — it does not provide, and has never claimed to provide, language or data sovereignty. The Hokianga Spine was never wired into the live enforcement engine (`slp8-core.js` imports only `msmd_policy_maps.js`; a separate policy-map file prepared for it was never integrated) and is withdrawn as it did not reflect an actual product capability.

 **Unchanged from v1.3:** the enforcement rules, decision set, denial codes, receipt fields, `pack_id` derivation, and signature algorithm. This amendment removes one spine definition only.

 **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_4.txt](https://agenticrail.nz/spec/canonical-v1_4.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0, v1.1, v1.2, and v1.3 records remain independently reproducible from their own files and are not affected.

 Published: 2026-07-08 | Version: 1.4 | Key ID: k2_2026-06-07_ed25519