raucle

Status: Draft  ·  Version: 1.0.0-draft  ·  Updated: 2026-05-29

Raucle Provenance Receipt — v1

A signed, content-addressed, append-only record of one AI agent action — the call to a model, the use of a tool, a retrieval, a guardrail decision, a handoff, a sanitisation, or a merge. Receipts are JWS envelopes that chain into a directed acyclic graph (the provenance graph) describing how an output came to be.

This document defines the wire format, the semantics, and the verifier obligations. It is the protocol layer Raucle uses to represent agent provenance and is offered as a candidate standard for the wider AI infrastructure ecosystem. The conformance language (MUST, SHOULD, MAY) is used per RFC 2119.

Contents

  1. 1. Scope and design goals
  2. 2. Terminology
  3. 3. Envelope (JWS)
  4. 4. Payload
  5. 5. Operations
  6. 6. Identity, keys, and capability statements
  7. 7. Taint propagation rules
  8. 8. The provenance graph
  9. 9. Verifier obligations
  10. 10. Privacy
  11. 11. Interoperability profiles
  12. 12. Security considerations
  13. 13. IANA / Media-type registrations
  14. 14. Extension points
  15. 15. Worked example
  16. 16. References

1. Scope and design goals

The Raucle Provenance Receipt format describes how an output produced by an AI system was produced. It is designed to be emitted by guardrail engines, tool gateways, retrieval layers, and agent frameworks; consumed by verifiers, auditors, SIEMs, and regulators; and stored as offline-verifiable evidence of an agent's behaviour.

The format is designed to satisfy four invariants:

  1. Offline verification. A receipt MUST be verifiable against a known issuer key without contacting any external service.
  2. Content addressing. A receipt's identity is a deterministic hash of its signed bytes. Two parties MUST compute the same identifier for the same receipt.
  3. Taint monotonicity. Information about upstream untrusted inputs MUST flow forward through the graph; it can only be reduced by an explicit, signed sanitisation operation.
  4. Privacy by default. Receipts MUST NOT carry prompt or output plaintext. Hashes only, with an opt-in slot for content-bearing receipts in deployments that require full payload disclosure (e.g. internal audit).

Non-goals: the spec does not define how chains are stored, how keys are distributed, how policies are evaluated, or how receipts are exchanged between organisations. Those layers are deliberately left to the deployer.

2. Terminology

Action
A single observable event in an agent's execution — one model call, one tool invocation, one retrieval, one guardrail scan, one handoff, one sanitisation, one merge.
Receipt
A JWS-encoded signed statement that an action occurred and produced an output with the stated hash, in the stated taint state.
Agent
The signing principal. Identified by an agent_id string and an Ed25519 public key. Distinct agent identities SHOULD use distinct keys.
Capability statement
A signed list of operations an agent is permitted to perform. See §6.
Provenance graph
The DAG of receipts whose vertices are actions and whose edges are the parents arrays in payloads.
Taint tag
A short ASCII string labelling an upstream untrusted input — e.g. untrusted_user, retrieval:knowledge_base.

3. Envelope (JWS)

A receipt MUST be encoded as a Compact JWS per RFC 7515 with the following header parameters: 

{
  "alg": "EdDSA",
  "typ": "provenance-receipt/v1",
  "kid": "<agent_key_id>",
  "crit": ["raucle/v1"]
}

4. Payload

The payload MUST be a UTF-8 encoded, canonical-JSON object (RFC 8785) containing exactly the fields below. Implementations MUST NOT include extra top-level fields outside the x_ namespace defined in §14.

FieldTypeDescription
issstringIssuer URI (e.g. https://acme.example/raucle). MUST match the URI bound to the signing key.
iatintegerIssued-at, seconds since Unix epoch.
agent_idstringStable agent identifier matching ^agent:[a-z0-9][a-z0-9_\-./]{0,127}$.
agent_key_idstringOpaque identifier for the Ed25519 key. MUST equal JWS kid.
operationstringOne of the values in §5.
parentsarray of stringsReceipt IDs (see §8) of direct ancestors. MAY be empty only for user_input.
input_hashstringHex SHA-256 of the input bytes. For user_input this is the raw prompt; for downstream operations, the assembled input.
output_hashstringHex SHA-256 of the output bytes.
taintarray of stringsSorted set of taint tags carried by the output. See §7.
ruleset_hashstringHex SHA-256 of the policy/ruleset effective at the moment of the action. MUST be present for guardrail_scan and sanitisation; SHOULD be present for all others.
guardrail_verdictstringOne of ALLOW, BLOCK, SANITISE, NA. Required for guardrail_scan; NA elsewhere.
modelobject (optional)Operation-specific descriptor; required for model_call. See §5.
toolobject (optional)Operation-specific descriptor; required for tool_call.
corpusobject (optional)Operation-specific descriptor; required for retrieval.
tenantstring (optional)Multi-tenant scope identifier. MUST be opaque to the verifier.

5. Operations

Receipts describe exactly one of the following operations:

OperationMeaningRequired descriptor
user_inputRaw input entered an agent's boundary.—
model_callAn LLM was queried.model.{provider, name, version}
tool_callAn external tool was invoked.tool.{name, version, side_effects}
retrievalDocuments were fetched from a corpus.corpus.{id, snapshot}
guardrail_scanA policy decision was rendered.—; guardrail_verdict required.
agent_handoffControl passed to a different agent.—
sanitisationTaint tags were intentionally removed.—; see §7.
mergeMultiple parents combined into one output.—

Verifiers MUST reject receipts with an unknown operation value. Future operations will be introduced under a new typ (e.g. provenance-receipt/v2); they will not be added to v1.

6. Identity, keys, and capability statements

Each agent_id binds to one or more Ed25519 public keys, each identified by an opaque agent_key_id. The binding is published in a capability statement: a JWS of type capability-statement/v1 listing the operations the agent is permitted to perform and the keys it MAY use.

In open-source mode an agent MAY self-sign its capability statement with its own key. In commercial deployments the capability statement SHOULD be issued by a separate authority key. The binding mechanism is out of scope; the verifier obligation is: before accepting a receipt from agent A, the verifier MUST have a verified capability statement for A that permits the operation in the receipt.

7. Taint propagation rules

The taint field carries a sorted set of tags describing which untrusted upstream inputs the output may contain. Taint MUST propagate monotonically:

  1. For every receipt R with parents P1…Pn: taint(R) ⊇ ⋃ taint(Pi) unless R has operation = sanitisation.
  2. A sanitisation receipt MUST list the removed tags in an x_removed_taint field. Tags not listed there MUST remain present.
  3. Tag strings are case-sensitive ASCII matching ^[a-z][a-z0-9_:\-]{0,63}$.
  4. New tags MAY be introduced by any receipt; sanitisation MAY only remove tags.

A verifier that observes a violation of (1) or (2) MUST treat the chain as invalid from that receipt onward.

8. The provenance graph

A receipt's identifier is the hex SHA-256 of the Compact JWS string of the receipt, computed as ASCII bytes including the dot separators. This is deterministic: any party handed the JWS computes the same identifier.

A receipt's parents array lists the identifiers of its direct ancestors. The transitive closure of parents forms a directed acyclic graph (the provenance graph). Cycles MUST be rejected by verifiers.

A chain is any topologically-ordered subset of the provenance graph that is closed under parents — i.e. every parent reference in the chain is itself present in the chain. Verifiers operate on chains.

9. Verifier obligations

To accept a chain C, a verifier MUST:

  1. Verify the JWS signature of every receipt with the key denoted by its kid / agent_key_id.
  2. Confirm each typ = provenance-receipt/v1 and crit ⊇ ["raucle/v1"].
  3. Confirm that each receipt's identifier (as defined in §8) equals the value referenced by any descendant's parents entry.
  4. Confirm the graph is acyclic and closed under parents.
  5. Confirm taint monotonicity per §7.
  6. For each receipt, confirm there exists a verified capability statement permitting the receipt's operation for the receipt's agent_id as of iat.
  7. Where the operation is guardrail_scan, confirm ruleset_hash and guardrail_verdict are present.

A verifier MAY perform additional policy checks (e.g. “output_hash matches what was actually delivered to the user”) but those are out of scope for v1 acceptance.

10. Privacy

Receipts MUST NOT contain prompt plaintext or output plaintext. Only hashes. This enables a deployment to publish receipts to external SIEMs and regulators without exposing the underlying content.

Deployments that require content disclosure (e.g. internal audit) MAY emit a paired content envelope alongside the receipt — an out-of-band, separately-encrypted blob of the pre-image bytes, addressable by input_hash / output_hash. The format of the content envelope is out of scope for v1.

11. Interoperability profiles

Two minimum profiles are defined:

12. Security considerations

13. IANA / media-type registrations

The following media types are claimed:

14. Extension points

Implementations MAY add fields whose names begin with x_. Verifiers MUST preserve unknown x_ fields when re-serialising. Verifiers MUST NOT let unknown x_ fields affect signature verification or taint propagation.

Non-x_ fields not defined in this document are RESERVED. Receipts containing reserved fields MUST be rejected.

14.1 Registered extension: x_tee_attestation

A receipt emitted from inside a hardware Trusted Execution Environment (AMD SEV-SNP or Intel TDX) MAY carry a hardware attestation quote that binds the receipt's signing key to a measured enclave: 

"x_tee_attestation": {
  "tee_type": "sev-snp",          // "sev-snp" | "tdx"
  "quote": "base64…",             // raw attestation report bytes
  "report_data_alg": "sha512",    // binds report_data to the signing key
  "vcek_cert": "base64…"          // optional leaf cert (else fetched from the vendor KDS)
}

The enclave requests its quote with report_data = SHA-512(agent signing public key), so the hardware signs the key's hash into the quote. A TEE-aware verifier, if this field is present, MUST verify the quote signature to the vendor root, MUST confirm report_data binds to agent_key_id, and MAY enforce an allowlist of approved enclave measurements. A verifier that does not understand TEE attestation MUST ignore the field (it is x_-namespaced) — the receipt remains valid as an ordinary signed receipt. Full design: tee-attested-provenance.md.

15. Worked example

A guardrail scan receipt covering the user's initial prompt. The signed payload (canonical JSON, line-wrapped here for reading): 

{
  "agent_id": "agent:raucle.scanner",
  "agent_key_id": "k_8c2f4e1a",
  "iat": 1748505600,
  "iss": "https://acme.example/raucle",
  "operation": "guardrail_scan",
  "parents": ["c1d2…f4a9"],
  "input_hash": "9f86d081884c7d65…",
  "output_hash": "9f86d081884c7d65…",
  "ruleset_hash": "1a79a4d60de6718e…",
  "guardrail_verdict": "ALLOW",
  "taint": ["untrusted_user"]
}

Wrapped as Compact JWS the on-wire form is roughly: 

eyJhbGciOiJFZERTQSIsImtpZCI6Imtf8GMyZjRlMWEiLCJ0eXAiOiJwcm92ZW5hbmNlLXJlY2VpcHQvdjEiLCJjcml0IjpbInJhdWNsZS92MSJdfQ.eyJhZ2VudF9pZCI6…

Its identifier — what descendants cite in their parents — is the SHA-256 hex of those ASCII bytes including the two dots.

16. References

Comments and issues: raucle-detect on GitHub. This document is offered for public comment. v1 is expected to freeze 2026-07.