Write-once Append-only Receipt Digests (WARD): A Content-Free Hash-Chain Witnessing Protocol for Agentic AI Systems

4.1. Content-Free by Design

Ward entries MUST NOT store source event content, payloads, or attachments. Ward entries MUST reference source events only by identifier and payload hash. This constraint is non-negotiable and constitutes WARD's defining property. An implementation that stores event content is not a WARD implementation.¶

4.2. One-Way Observation

WARD MUST be a passive observer. Witnessing MUST NOT block, delay, or modify the source event pipeline. WARD failures MUST NOT disrupt AEE transport, AOCL decisions, or VOLT recording. This fire-and-forget integration model ensures that witnessing adds guarantees without introducing operational risk.¶

4.3. Minimal Schema, Extensible Evolution

Every ward entry MUST include a ward_version field. Unknown fields MUST be ignored by verifiers to ensure forward compatibility. Breaking changes MUST increment ward_version; while the major version is 0, a minor increment MAY be a breaking change (the standard pre-1.0 convention). The ward_version value stored in each entry selects the chain hash scheme a verifier MUST apply to that entry (see Section 7.4).¶

4.4. Deterministic and Reproducible

All hashes MUST be deterministically reproducible from the same inputs. No randomness is permitted in hash computation; only identifier generation may use random sources.¶

7.1. Hash Algorithm

All hashing in WARD v0.2 MUST use SHA-256 [RFC6234] [FIPS180-4].¶

7.2. Hash Encoding

Hash values MUST be encoded as lowercase hexadecimal strings of 64 characters (256 bits).¶

7.3. Genesis Hash

The genesis hash anchors a chain's origin deterministically:¶

genesis_hash = SHA-256("WARD-GENESIS|" + chain_id)

The input is the literal UTF-8 string WARD-GENESIS| concatenated with the chain_id. The genesis hash serves as prev_chain_hash for the first entry (seq = 1). Unlike the chain hash, this construction is not exposed to delimiter ambiguity: the input has exactly one variable field after a fixed literal prefix, so no two distinct inputs can collide by boundary confusion.¶

7.4. Chain Hash

Each entry's chain_hash links it to its predecessor. It is computed over the canonical JSON (see Section 6) of the entry's hash body: the ten required fields of the entry schema excluding chain_hash itself.¶

hash_body  = { chain_id, issuer_id, payload_hash,
               prev_chain_hash, seq, source_id, source_kind,
               ward_entry_id, ward_version, witnessed_at }

chain_hash = SHA-256(canonical_json(hash_body))

The hash body MUST contain exactly these ten members: no extras, none absent, none null. The seq value is hashed as a JSON integer, not a string. Optional fields (source_ts, tags, sig) MUST NOT be included in the hash body; they are annotations, not commitments, and are not tamper-protected by the chain.¶

Canonical JSON is used rather than delimiter concatenation because identifier fields carry no character-set restriction: with concatenation, a crafted identifier containing the delimiter character can make two distinct field tuples produce an identical hash input, so a single chain hash would commit to an ambiguous statement. JSON string escaping makes field boundaries unambiguous for every possible input. A legacy concatenation scheme used by ward_version 0.1 deployments is preserved for verification only in Appendix A.¶

Because ward_version is part of the hash body, the scheme an entry declares is itself tamper-protected: an attacker cannot downgrade an entry to the legacy scheme without breaking its hash.¶

7.5. Signatures

Signatures are OPTIONAL in WARD v0.2 but the schema reserves fields for them. If used:¶

• The signature algorithm SHOULD be Ed25519 [RFC8032].¶
• Public key identifiers SHOULD be stable (DID or key fingerprint).¶
• Tips SHOULD be signed; individual entries MAY be signed.¶
• Signing every entry is permitted but not expected, as it is computationally expensive for most deployments.¶

When signing a tip, the signature is computed over the raw UTF-8 bytes of the tip_chain_hash hexadecimal string.¶

Key resolution and trust are deployment-defined in this version. This specification does not define a key-resolution mechanism, trust anchor, or issuer-authorization rule for key_id: a verified signature therefore proves possession of whichever key the deployment resolved for that identifier, and nothing more. Deployments MUST document how key_id values resolve to keys and which keys are authorized to sign for a chain's issuer, and auditors SHOULD treat signature-verification counts as meaningful only relative to that documented policy.¶

8.1. Identifiers

The ward_entry_id MUST be unique within a chain. The chain_id MUST be unique within a deployment. Identifiers SHOULD be UUIDv4 [RFC9562] or ULID.¶

Chain identifiers follow a scoping convention:¶

• Per organisation/environment: ward:org/<org>/env/<env>¶
• Meta-chain: ward:meta/<deployment>¶

Examples: ward:org/quox/env/production, ward:org/quox/env/staging, ward:meta/quox-global.¶

A chain_id MUST NOT contain the sequence ::, which is reserved as the separator in meta-chain source_id values (Section 15.2). Identifiers SHOULD be limited to printable ASCII without whitespace; with canonical-JSON hashing this is hygiene rather than a hashing-safety requirement.¶

8.2. Timestamps

The witnessed_at field MUST be an ISO 8601 timestamp with UTC offset Z, for example 2026-03-05T14:30:00.000Z. This records when WARD observed the source event, not when the source event occurred. The optional source_ts field MAY carry the source event's own timestamp for correlation.¶

9.1. Required Fields

The two field groups differ in trust, not just in cardinality. Every required field except chain_hash is committed: it is inside the hash body of Section 7.4, so the chain proves it. Every optional field is an uncommitted annotation: it can be altered later without breaking any hash, and no claim of the form "WARD says this event was tagged X" is ever valid.¶

9.2. Optional Fields

9.3. Entry Example

The hash values below are real: the payload hash is the SHA-256 of a canonical example envelope (reproduced in the protocol repository's examples directory), the previous chain hash is the chain's genesis hash, and the chain hash recomputes from this entry's hash body under Section 7.4. Long values are folded per [RFC8792].¶

NOTE: '\' line wrapping per RFC 8792

{
  "ward_version": "0.2",
  "ward_entry_id": "01WARD-E001",
  "chain_id": "ward:org/quox/env/production",
  "seq": 1,
  "witnessed_at": "2026-03-05T14:30:00.000Z",
  "source_kind": "AEE",
  "source_id": "aee-env-550e8400",
  "payload_hash": "eead9b7ee8f898c3b17f5913989ab6d048f92a1368d27f\
9b1fad15d7bb3f45d2",
  "prev_chain_hash": "4228bb654b660969b96b84d502e1615de0ac7bffaeb\
37c52a7007b310127f481",
  "chain_hash": "6078eafecfd309ca8aa078f4d90017f17d65e53e1c9bdf8d\
3ac068d05ce4a1b4",
  "issuer_id": "ward-issuer-prod-01"
}

9.4. Uniqueness Constraint

Within a single chain, the combination of (chain_id, source_kind, source_id) MUST be unique. A chain MUST NOT contain two entries witnessing the same source event. Different chains MAY independently witness the same source event.¶

9.5. Sequence Ordering

The seq field MUST start at 1 and increase monotonically by exactly 1. Gaps in seq MUST NOT occur. Implementations MUST guarantee atomic, gap-free sequence assignment under concurrent access using a mechanism appropriate to their storage (database row or advisory locks, serializable transactions, or a single-writer process for file-based stores).¶

12.1. Tip Schema

Tips SHOULD be signed. Unsigned tips provide checkpoint convenience but weaker non-repudiation guarantees.¶

12.2. When to Create Tips

Tips SHOULD be created:¶

• Periodically (e.g., every N entries or every T minutes)¶
• At significant boundaries (end of a workflow run, end of day)¶
• Before chain sealing¶

12.3. Tip Signing

Tips SHOULD be signed with Ed25519 [RFC8032]. The signature is computed over the raw UTF-8 bytes of the tip_chain_hash hexadecimal string. A tip carrying sig MUST also carry key_id: a signature with no key identifier cannot be resolved and verified, so it would be an annotation posing as evidence. The key_id value SHOULD be a stable public key identifier (DID or key fingerprint) to enable key lookup during verification.¶

12.4. Tip Sinks

Tips MAY be published to external stores. Sinks differ in what they actually guarantee, and a deployment SHOULD document which property each configured sink provides:¶

• Git signed tags: replication plus a signature. A repository administrator can delete or replace tags, so this sink protects against attackers without that access; deletion is detectable only by a verifier who already knows the tip existed.¶
• Object storage with immutable retention (for example S3 Object Lock in compliance mode): genuine write-once retention for the configured period.¶
• Trusted timestamping: an RFC 3161 authority adds third-party time.¶
• Transparency services: append-only logs with third-party observability, such as services implementing the SCITT architecture [RFC9943]. WARD does not compete with transparency infrastructure; a tip is a natural signed statement to register in it, and defining such bindings is planned work.¶

The sink_ref field records where the tip was published, for example gitea:owner/repo#ward-tip/prod/42. Absence of an expected tip at its sink_ref is itself evidence and SHOULD surface as a verification warning, not be silently ignored.¶

12.5. Tip Example

This tip is real: tip_chain_hash is the head of the three-entry example chain in the protocol repository, and sig is a genuine Ed25519 signature over the raw UTF-8 bytes of that hash by a documentation key whose seed is published (SHA-256 of the string WARD-EXAMPLE-KEY-v0.2; public key pDN4/yZmzhkKfzDCHS5uc6seNgrcnei2+cJ3liDPwrc=), so both are independently verifiable. That key is for documentation only: its private half is public by construction. Long values are folded per [RFC8792].¶

NOTE: '\' line wrapping per RFC 8792

{
  "tip_id": "tip-stg-002",
  "chain_id": "ward:org/quox/env/staging",
  "tip_seq": 3,
  "tip_chain_hash": "88893edd241f630801a44bb4b839f85200a1e47ac38b\
5d6ec895c85e3a937791",
  "entry_count": 3,
  "created_at": "2026-03-05T15:01:00.000Z",
  "sig": "lHFDS97QRZSwAcmtxDyJxSNDutvZLJmcQIPyX4UeKYSPK+IsVie5xWQk\
TOrfs0ioVmQHcUPTJpZOmtM0XIOCDA==",
  "key_id": "ed25519:sha256:765fe10404e81eb5",
  "sink_ref": "https://gitea.example.com/ward-tips/tags/stg-tip-002",
  "notes": "End-of-batch tip for staging, March 5 2026"
}

13.1. What to Witness

WARD witnesses references, not content:¶

• For AEE: the envelope identifier and the SHA-256 of the canonical envelope JSON.¶
• For AOCL: the decision identifier and the SHA-256 of the canonical decision JSON.¶
• For VOLT: the event identifier or bundle commitment hash, and the SHA-256 of the relevant object.¶
• For WARD: a tip from a sub-chain (meta-chain pattern).¶
• For EXTERNAL: a caller-provided identifier and payload hash.¶

13.2. What NOT to Witness

WARD MUST NOT witness:¶

• Raw message content or payloads¶
• Secrets, tokens, or credentials¶
• Personally identifiable information (PII)¶
• Attachment contents (reference by hash only)¶

13.3. Witness Timing

WARD SHOULD witness events as soon as possible after they occur. WARD MUST NOT block or delay source event processing. If witnessing fails, the failure MUST be logged but MUST NOT affect the source pipeline.¶

13.4. Selective Witnessing

Implementations MAY witness a subset of source events based on configuration: by source kind, by event type (e.g., only AOCL denials), or by tag or scope. Selective witnessing SHOULD be documented in the chain's scope field.¶

13.5. Per-Protocol Witnessing Guidance

AEE Envelopes. Witness after the envelope is persisted or delivered, not while in-flight. The payload hash is computed over the whole canonical envelope JSON, including its payload fields, so any later modification of the stored envelope is detectable. WARD stores only the hash; the envelope content itself never enters the ward entry.¶

AOCL Decisions. Witness after the decision is finalised and persisted. Both allow and deny decisions SHOULD be witnessed. Implementations MAY filter to witness only terminal decisions (completions, rejections, bypasses) and skip layer-start events, which are high volume and low signal.¶

VOLT Transitions. Witness VOLT at boundaries, not every event: VOLT already chains events internally. Witness after a bundle is finalised or a run is completed or failed. Individual VOLT events MAY also be witnessed for higher-resolution audit trails.¶

EXTERNAL Events. The caller provides both source_id and payload_hash. WARD trusts the caller's hash; it does not verify against the source content because it never sees the content. This allows anchoring non-protocol events such as external audit logs, webhooks, and compliance records.¶

14.1. Chain Creation

1. Choose a chain_id following the conventions in Section 8.1.¶
2. Compute genesis_hash per Section 7.3.¶
3. Record the ward chain descriptor.¶

14.2. Appending Entries

1. Receive a source event reference (kind, identifier, payload hash).¶
2. Enforce the uniqueness constraint (Section 9.4).¶
3. Assign seq = previous seq + 1 (or 1 for the first entry).¶
4. Set prev_chain_hash to the previous entry's chain_hash (or genesis_hash for seq=1).¶
5. Compute chain_hash per Section 7.4.¶
6. Persist the ward entry.¶
7. Update the chain descriptor (entry_count, head_seq, head_chain_hash).¶

14.3. Chain Sealing

A chain MAY be sealed (made immutable). Sealing MUST create and sign a final tip covering the whole chain, and SHOULD publish that tip to an external sink; without external publication, the seal proves nothing to a party who does not already trust the store. Sealed chains MUST NOT accept new entries.¶

Chain lifecycle states are: active (accepting entries), sealed (final tip signed, no new entries), and archived (moved to cold storage).¶

15.1. How Meta-Chains Work

1. Create a meta-chain with identifier following ward:meta/<deployment>.¶
2. When a sub-chain creates a tip, witness it in the meta-chain with source_kind = WARD, source_id = <sub_chain_id>::<tip_seq>, and payload_hash = SHA-256 of the canonical tip JSON.¶

15.2. Meta-Chain Source Identifier Format

The double colon (::) separates the sub-chain identifier from the tip sequence number:¶

ward:org/quox/env/production::42

This means: "tip at sequence 42 from chain ward:org/quox/env/production". The double colon is chosen to avoid ambiguity with single colons in chain identifiers.¶

Normative grammar: for entries with source_kind WARD, the source_id MUST consist of the sub-chain identifier, then ::, then the tip sequence as a positive decimal integer with no leading zeros. Because a chain identifier MUST NOT contain :: (Section 8.1), splitting on the first occurrence of :: is unambiguous. A consumer MUST reject a WARD-kind source_id that does not match this grammar, including values where the separator region contains three or more consecutive colons.¶

15.3. Why Meta-Chains Exist

Meta-chains provide:¶

• A single chain-of-chains for a deployment¶
• Cross-chain integrity verification¶
• A single tip to publish externally instead of one per sub-chain¶
• Compact proof that multiple chains existed at a point in time¶

16.1. What Verification Guarantees

A successful verification proves:¶

• The genesis hash is correctly derived from the chain identifier.¶
• Every entry's chain hash recomputes correctly from its inputs.¶
• Each entry links correctly to its predecessor.¶
• Sequence numbers are monotonically increasing with no gaps.¶
• No duplicate source events exist within the chain.¶
• Tips reference valid chain state.¶
• Signatures (if present) are valid.¶

In short: the chain has integrity and no entries have been modified, inserted, or deleted.¶

16.2. What Verification Does NOT Guarantee

Verification does not prove:¶

• The source events were truthful.¶
• The issuer was uncompromised when it created entries.¶
• The payload hashes correspond to events that still exist.¶
• The witnessed events were complete (coverage is an integration concern).¶

WARD is a tamper-evidence protocol, not an oracle.¶

16.3. Verification Algorithm

A WARD verifier MUST execute the following six steps in order:¶

Step 0: Validate Entry Well-Formedness. Before any hash is recomputed, parse each entry with a JSON parser that rejects duplicate member names (Section 6), validate it against the entry schema (all eleven required fields present, correct types, hash fields 64-character lowercase hexadecimal, seq within [1, 2^53 - 1], no null hash-body members), and, for entries declaring version 0.2 or later, confirm every hash-body string is well-formed Unicode in NFC and that chain_id does not contain :: (version 0.1 entries predate those rules: a violation there MUST produce a warning, not a failure). Any failure produces failure code SCHEMA_INVALID. Skipping this step and verifying hashes alone can "verify" an entry whose displayed fields differ from its hashed fields.¶

Step 1: Validate Genesis. Compute expected_genesis = SHA-256("WARD-GENESIS|" + chain_id). Read the first entry (seq=1). Confirm that the entry's prev_chain_hash equals expected_genesis. Mismatch produces failure code GENESIS_MISMATCH.¶

Step 2: Validate Chain Hashes. For each entry in sequence order, select the hash scheme from the entry's ward_version: "0.2" uses the canonical-JSON hash body of Section 7.4; "0.1" uses the legacy concatenation of Appendix A; any other value produces failure code CHAIN_HASH_MISMATCH with a detail naming the unrecognized version. Recompute chain_hash under that scheme and confirm it equals the stored value; mismatch produces CHAIN_HASH_MISMATCH. Declared ward_version values MUST be non-decreasing in seq order, compared numerically as (major, minor); an entry declaring a lower version than any earlier entry produces failure code VERSION_DOWNGRADE. This makes "no new legacy entries" enforceable from stored data for upgraded chains. For a chain that has never upgraded, a verifier reading stored data cannot distinguish a legacy entry appended recently from one appended before the current version existed; the mitigation, as for any append to a compromised chain, is externally published signed tips, which bound the exposure to entries after the most recent tip. If a version 0.1 entry's ward_entry_id or source_id contains the | character, the verifier MUST append a warning to the result (delimiter-injection exposure, Appendix A).¶

Step 3: Validate Chain Linkage. For each entry where seq > 1, confirm that the entry's prev_chain_hash equals the chain_hash of the entry with seq - 1. Mismatch produces failure code CHAIN_LINK_BROKEN.¶

Step 4: Validate Ordering and Uniqueness. Confirm seq starts at 1, increases monotonically by 1 with no gaps, and that no duplicate (chain_id, source_kind, source_id) tuples exist. Sequence violation produces SEQ_INVALID; duplicate source produces DUPLICATE_SOURCE.¶

Step 5: Validate Tips. For each tip, locate the entry at tip_seq and confirm tip_chain_hash equals that entry's chain_hash. If sig is present, resolve key_id to a public key using the deployment's documented key-resolution policy (key resolution and trust are deployment-defined, see Section 7.5) and verify the Ed25519 signature over the tip_chain_hash hex bytes. A valid signature proves possession of the resolved key, not that the key was authorized. Hash mismatch produces TIP_MISMATCH; signature failure produces TIP_SIGNATURE_INVALID.¶

16.4. Failure Reason Codes

All codes except INCOMPLETE_CHAIN accompany the BROKEN status; INCOMPLETE_CHAIN accompanies PARTIAL. Implementations MAY define additional reason codes; a consumer that encounters an unknown code MUST treat it according to the status field, never as a success.¶

16.5. Verification Result Statuses

16.6. Verification Result Examples

The results below are illustrative: values in angle brackets are placeholders describing what belongs in each field, not computed hashes. Fully real, recomputable example chains and verification results are published in the protocol repository's examples directory.¶

INTACT result:¶

{
  "status": "INTACT",
  "chain_id": "ward:org/quox/env/production",
  "ward_version": "0.2",
  "entry_count": 1042,
  "head_seq": 1042,
  "head_chain_hash": "d4e5f6a7b8c9d0e1...a1b2c3d4",
  "genesis_verified": true,
  "tips_verified": 3,
  "signatures_verified": 2,
  "warnings": []
}

BROKEN result:¶

{
  "status": "BROKEN",
  "chain_id": "ward:org/quox/env/production",
  "reason": "CHAIN_HASH_MISMATCH",
  "details": {
    "seq": 417,
    "ward_entry_id": "01WARD-E417",
    "expected_chain_hash": "c3d4e5f6...recomputed",
    "found_chain_hash": "ff00ff00...stored"
  }
}

16.7. CLI Exit Codes

Implementations providing a command-line verifier SHOULD use the following exit codes:¶

• 0 = INTACT¶
• 1 = BROKEN (verification failed)¶
• 2 = ERROR (storage not readable, invalid arguments)¶
• 3 = PARTIAL (chain incomplete)¶

17.1. WARD-W (Witness)

An implementation is WARD-W conformant if it:¶

• Produces ward entries matching Section 9¶
• Computes genesis_hash and chain_hash correctly per Section 7¶
• Enforces the uniqueness constraint per Section 9.4¶
• Respects content-free constraints per Section 4.1¶

17.2. WARD-V (Verifier)

An implementation is WARD-V conformant if it:¶

• Implements the six-step verification algorithm per Section 16.3¶
• Produces verification results with the defined status codes and failure reasons¶

17.3. WARD-T (Tipper)

An implementation is WARD-T conformant if it:¶

• Creates valid tips per Section 12.1¶
• Optionally signs tips with Ed25519¶
• Optionally publishes tips to external sinks¶

18.1. SQLite (Single-Node)

SQLite with WAL mode is the recommended storage for single-node deployments. The following schema is suggested:¶

CREATE TABLE ward_entries (
    ward_entry_id TEXT PRIMARY KEY,
    chain_id      TEXT NOT NULL,
    seq           INTEGER NOT NULL,
    witnessed_at  TEXT NOT NULL,
    source_kind   TEXT NOT NULL
      CHECK (source_kind IN
        ('AEE','AOCL','VOLT','WARD','EXTERNAL')),
    source_id     TEXT NOT NULL,
    payload_hash  TEXT NOT NULL,
    prev_chain_hash TEXT NOT NULL,
    chain_hash    TEXT NOT NULL,
    issuer_id     TEXT NOT NULL,
    ward_version  TEXT NOT NULL DEFAULT '0.2',
    source_ts     TEXT,
    tags          TEXT,
    sig           TEXT,
    UNIQUE(chain_id, seq),
    UNIQUE(chain_id, source_kind, source_id)
);

Storage sizing is approximately 500 bytes per SQLite row including indexes; 10,000 entries require approximately 5 MB.¶

18.2. PostgreSQL (Multi-Node)

For multi-node or high-availability deployments, use the same schema with appropriate type mappings (UUID, BIGINT, TIMESTAMPTZ, JSONB). Implementations SHOULD configure append-only triggers to prevent UPDATE and DELETE on entry rows, ensuring the write-once property at the storage layer.¶

19.1. Threats WARD Mitigates

T1: Post-Hoc Tampering. An attacker modifies a ward entry after it has been recorded. The chain hash recomputation during verification detects the modification (CHAIN_HASH_MISMATCH).¶

T2: Entry Deletion. An attacker removes an entry from the middle of the chain. Chain linkage breaks at the entry after the gap (CHAIN_LINK_BROKEN) and the sequence gap is detected (SEQ_INVALID).¶

T3: Entry Insertion. An attacker inserts a fabricated entry. Unless they rehash all subsequent entries, chain linkage breaks. If they do rehash, signed tips published to external sinks detect the discrepancy.¶

T4: Backdating. An attacker assigns an earlier witnessed_at timestamp. If tips are published to external sinks with their own timestamps, the inconsistency is detectable. Without external sinks, backdating is harder to detect.¶

T5: Double-Witnessing. An attacker attempts to witness the same source event twice. The uniqueness constraint (chain_id, source_kind, source_id) prevents this at the storage layer.¶

19.2. Threats WARD Does Not Fully Mitigate

T6: Compromised Issuer. If the WARD issuer itself is compromised, the attacker can produce a valid but false chain with consistent hashes, or present an alternative branch (fork) built from the same predecessor entry while withholding the original; a verifier shown only one branch cannot detect the fork from chain data alone. Mitigation: signed tips published to external sinks prevent post-hoc modification and anchor the branch that existed at publication time; meta-chains from independent issuers provide cross-verification; periodic external audits detect inconsistencies.¶

T7: Pre-Witness Modification. WARD witnesses what it receives. If the source event is modified before WARD observes it, WARD cannot detect this. Mitigation: VOLT's internal hash chain detects VOLT modifications; AEE carries envelope-level integrity; AOCL persists decisions before triggering WARD. Defence in depth across all four protocols hardens the system.¶

T8: Key Theft. An attacker who steals the Ed25519 signing key can forge tips. Mitigation: store keys in HSM/TPM, implement key rotation schedules, maintain key revocation lists, and use separate keys per environment.¶