Skip to content

fix(spec): correct ARR wire id + disambiguate rac vs ar evaluation #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sergideki wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix(spec): correct ARR wire id + disambiguate rac vs ar evaluation #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions spec/evidence.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -147,7 +147,7 @@ carry and a requirement may reference.
|----------|---------------------|--------------------------------------|
| `APR` | `ar.provenance.v1` | Agent Provenance Receipt — a recorded agent action / data-processing provenance event. |
| `ACR` | `ar.consent.v1` | Anchored Consent Receipt — a recorded, informed grant of consent. |
| `ARR` | `ar.retention.v1` | Anchored Retention Receipt — a recorded data-retention schedule / retention-enforcement run. |
| `ARR` | `ar.erasure.v1` | Anchored Retention Receipt — a recorded data-retention schedule / retention-enforcement run. (The retention family's canonical discriminator is `ar.erasure.v1`; it spans the erasure/expiry/hold/anonymization/archive/batch claim types.) |
| `ALR` | `ar.lineage.v1` | Anchored Lineage Receipt — a recorded data-flow / lineage step. |
| `ATR` | `ar.transfer.v1` | Anchored Transfer Receipt — a recorded cross-border data transfer (GDPR Ch. V / Schrems II). |
| `APuR` | `ar.purpose.v1` | Anchored Purpose Receipt — a recorded processing purpose. |
Expand All @@ -160,8 +160,10 @@ carry and a requirement may reference.
| `AIR` | `ar.impact.v1` | Anchored Impact Receipt — a recorded impact assessment such as a DPIA (GDPR Arts. 35–36). |
| `ATokR` | `ar.tokenization.v1`| Anchored Tokenization Receipt — a recorded PII-tokenization lifecycle event. |

These map one-to-one to the locked `AnchorsFamily` union in the reference
implementation. The acronyms (`APR`, `ACR`, …) are documentation shorthand; the
These 14 are the GDPR-core subset of the anchors family registry that RaC's
reference binding pins; the registry itself has grown beyond them, so this is a
**subset** mapping, not a one-to-one of the full `AnchorsFamily` union. The
acronyms (`APR`, `ACR`, …) are documentation shorthand; the
canonical wire identifier is the `ar.<noun>.v<N>` form. The exact wire formats
are an anchors concern and are **out of scope** for this spec; RaC sees only the
projected `CorpusReceipt`.
Expand Down
7 changes: 7 additions & 0 deletions spec/receipt.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,13 @@ both identically to `compilation.md`.
> signed object, and the algorithm match the implementation exactly. A verifier
> targeting this spec MUST treat `rac.evaluation.v1` as the discriminator and
> SHOULD accept `compass.evaluation.v1` as its reference-implementation alias.
>
> **Do not confuse this with the anchors family `ar.evaluation.v1` (AER).** They
> are distinct receipt types: an RaC evaluation receipt records **obligation
> satisfaction over an evidence corpus** (many predicates, one compliance
> verdict), whereas AER records a **single conformity / automated-decision
> event**. Same English word, different structure and purpose; they do not
> interoperate.

---

Expand Down
Loading