The specification is frozen (delegus-). Changes after the freeze are published here as numbered errata, or as v0.3. An erratum states the sections it touches, what changed, and why. No erratum changes the bytes of the profile document (docs/) or of a trust-configuration descriptor; those are frozen separately because receipts pin their hashes.
Neither erratum below carries a date: both were applied before the v0.2 freeze was consolidated into the final document, and the repository's history begins after that (initial commit 2026-09-10). No earlier date is recorded.
Erratum 1 — revocation-read / replay-write ordering#
Sections: §5.3 (T5), §5.4 (canonical order), §7 (ordering within /verify), §15 step 5 (acceptance test).
Before. The freeze resolutions described the engine reading status_ "in the same pipeline as the replay SET", so the revocation-version read and the replay write were one internal operation, and the build-order acceptance test was "revoke, replay → AUTHORITY_".
After. The revocation-version read and the replay write are two distinct internal operations at fixed places in the canonical order:
P1 → T1 → T2 → T3 → P2 → P3 → P4 → P5
→ [read status_ver; refresh cached status credential if needed]
→ P6 → P7 → P8 → … → P14
→ [atomic replay SET NX]
→ T5 → P15 → … → P20T5 executes only after P1–P14 pass. Implementations MAY coalesce the status_ver read with the start of the request, but MUST NOT reorder P6 after T5 or execute T5 before P14 (§7). The acceptance test became "revoke the Grant; the same action with a fresh Proof → AUTHORITY_", because re-sending the same Proof exercises replay (PROOF_REPLAYED), not revocation.
Why. With the read and the write in one pipeline, a Proof's jti could be consumed for a request that was about to be denied for revocation, and the position of the read relative to P6 was not fixed by the text. Fixing both positions makes the read-after-write revocation guarantee (§7) and the "replay is recorded only for requests that passed P1–P14" property statements about the order rather than about an implementation.
Erratum 2 — historical verification clock#
Sections: §5.4 (definition of now), §6.4 (offline verification).
Before. §5.4 said now is Delegus server time and is recorded in the receipt. §6.4 said a third party can re-run delegus-base-v1 from the receipt and the artifacts it names, without saying which clock to use.
After. §5.4: now is recorded as evaluated_at, and historical re-verification uses that value as now. §6.4 adds the normative rule: when reproducing the protocol result represented by a Receipt, the verifier MUST use the Receipt's authenticated evaluated_at as now for every time-dependent check (P4, P5, P13) and MUST NOT use its own wall-clock time.
live /verify: now = Delegus server clock (recorded as evaluated_at)
offline receipt verification: now = signed receipt.evaluated_atWhy. With the verifier's wall clock, an ALLOW receipt would stop reproducing as soon as the Grant expired or the Proof window passed, so receipts would only be verifiable briefly. evaluated_at is inside the signed payload, so using it makes every receipt reproducible for its whole retention period and cannot be altered without invalidating the signature.
Note (2026-09-15) — licence statement added to the header#
Sections: none. A non-normative "Licence" line was added to the header of delegus-, after "Normative language". The specification text is licensed CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) with the attribution "Delegus Specification v0.2, © Delegus (delegus.ai)"; @delegus/core (with its conformance vectors) and @delegus/sdk are Apache-2.0. No normative text, profile document or trust-configuration descriptor changed, so this is recorded as a note rather than a numbered erratum.