# Receipt Taxonomy — Research Note

Status: **RESEARCH**. No wire-format change is proposed at this time. This
note exists so that when a wider terminology is needed, the design has
been thought through and is not driven by marketing pressure.

## Motivation

The term *Decision Receipt* is precise, but it is not always appropriate:

- Some organisations do not want to describe an AI system as "making a
  decision". They may prefer *action*, *processing step*, *recommendation*,
  or *observation*.
- The wire artefact is agnostic to that distinction — it commits a set of
  metadata + hashes to an immutable chain and signs the whole. The
  semantics of what that metadata represents is contextual.

Nothing about the current `decision_receipt` type is changed by this
research note. The name in the on-wire body remains `decision_receipt` for
existing deployments. Any new class arrives as a versioned addition.

## Proposed umbrella and specialisations

**Evidence Receipt** — the umbrella name for the family. All members are
identical in cryptographic structure (canonical body + `receipt_hash` +
Ed25519 signature + chain link). They differ only in what the metadata
describes:

| Class | Intended meaning | Example |
|-------|------------------|---------|
| Decision Receipt | The recorded outcome of an evaluative process, whether human, AI, or hybrid. | "Approved / rejected / needs review" for a triage flow. |
| Action Receipt | The record that a specific action was invoked, with its inputs and outcome. | "Sent SEPA transfer with hash X to account hash Y at T". |
| Recommendation Receipt | The record of a suggestion presented to a human operator, whether or not it was acted upon. | "Recommended dosage adjustment; final choice logged elsewhere". |
| Processing Receipt | The record that a specific processing step ran on committed inputs and produced committed outputs, with no outcome interpretation. | "Ran normalisation pipeline v3 on document hash X → hash Y". |
| Attestation Receipt | The record of an assertion made by a human or system about another artefact. | "Reviewer R attests that receipt STR-… was inspected on date T". |

None of these classes changes the verification pipeline. They are labels
that inform how a reader should interpret the metadata.

## Introduction path (if adopted later)

If a future revision adopts multi-class receipts, the recommended path is:

1. Introduce an optional discriminator on the body:

   ```jsonc
   "receipt_class": "decision" | "action" | "recommendation"
                  | "processing" | "attestation"
   ```

   Absent value ⇒ implicit `"decision"` (matches existing behaviour).

2. Keep the on-wire `type` field at `"decision_receipt"` for existing
   deployments; add `receipt_class` alongside. This preserves byte-level
   compatibility of existing receipt bodies while enabling classification
   for new ones.

3. Bump the spec version to `1.1`. Do not bump to `2.0` unless a
   genuinely breaking change accompanies it.

4. Update the verify page to render the class label, but keep every
   check block identical.

## Non-goals

- No renaming of `decision_receipt` in stored receipts.
- No change to `receipt_hash` computation semantics.
- No mandatory adoption. A deployment that only ever emits Decision
  Receipts continues to work.
- No implication that any class carries stronger legal effect than any
  other. All classes are cryptographically identical; their meaning is
  contextual.

## Concerns not solved by taxonomy alone

- A "Recommendation Receipt" does not become an audit-safe record of
  human judgement without an accompanying attestation receipt or an
  attestation hash committed in the recommendation's metadata.
- A "Processing Receipt" is not evidence that the processing was correct,
  only that it ran on committed inputs.
- Naming does not substitute for the boundary statement:

  > Cryptographic verification confirms the integrity and authenticity of
  > recorded evidence. It does not prove that the underlying process was
  > correct, fair, lawful, safe, complete, or based on all relevant
  > real-world factors.

  Every class inherits this boundary.

## Recommendation

Defer implementation. Ship the taxonomy note in engineering docs only.
Revisit after two independent deployments have expressed concrete needs
for classes other than Decision Receipt.