Register applicability-assessment in the references registry: which legal duty a record is evidence for #445

Spec section affected

§3.1.2 (registered rel values) and docs/references-registry.md. An informative registration: no new field, no change to the four rules.

Problem

The Sandbox proposal (aaif/project-proposals#42) names a compliance use case: showing an auditor which policy was in force when an agent touched regulated data. The auditor's next question is which legal duty the record is evidence for, and that turns on facts the record does not carry: the party's legal role, the jurisdiction, and the provision. Under the EU AI Act the same record can be evidence for a provider's duty to build in logging (Article 12(1), through Article 16(a)), for a deployer's duty to keep the logs (Article 26(6)), or for neither, if the system is not high-risk.

This replaces the compliance.framework_tags field I suggested there, which TRACE does not have. These facts are an assessor's claims, so they belong in an object the record points at, not in the signed facts, and §3.1.2 already has that shape.

Proposed change

Register one value:

• applicability-assessment. An assessor's statement of whether a stated legal provision applies to a stated party, held in another system.

The referenced object is a signed, content-addressed statement whose wire format is the issuer's, as for condition-appraisal. It carries:

• The party: an identifier and its role in the instrument's own term (provider, deployer, controller, processor). Often not the workload subject.
• The jurisdiction: an ISO 3166 code, or EU for Union law.
• The provision: the instrument's official identifier (ELI or CELEX where one exists), the article, and the date of the text read. Dates move under a record: Regulation (EU) 2026/1744 moved the high-risk obligations for Annex III systems to 2 December 2027.
• The outcome: a value from a closed vocabulary the object names (for example applies, does-not-apply, undetermined), and the date the provision applies from, when later than iat.
• The basis: the provisions the outcome rests on, such as the scope article and the classification rule.
• The issuer, its key reference, the signing time and the signature, as for condition-appraisal.

One assessment usually serves every record from a deployment; a revised one is a new object with a new digest.

A verifier may conclude what it may for condition-appraisal: whether the reference resolves, whether the bytes match digest, and whether the object verifies under its issuer's key, and nothing about the record. An applies is the assessor's statement, not evidence that the duty applies or was met, and §3.1.2's limit that a reference cannot carry compliance evidence stands.

Why not condition-appraisal: its outcome is in the checker's own vocabulary over a subject digest. An auditor reading objects from different assessors has to key on role, jurisdiction and provision as named facts, which is the registry's second-implementation test.

Worked example, one possible shape. A recruitment-screening agent (AI Act Annex III, point 4(a)) is built by provider A and run by deployer B, established in Germany. A Trust Record from one execution at B carries:

"references": [
  {
    "rel": "applicability-assessment",
    "id": "assessment/1",
    "resolver": "https://compliance.deployer-b.example",
    "digest": "sha256:4be1..."
  }
]

The object it points at, issued by B's compliance function:

{
  "type": "applicability-assessment",
  "issuer": "https://compliance.deployer-b.example",
  "issuer_key_id": "...",
  "party": { "id": "https://deployer-b.example", "role": "deployer" },
  "jurisdiction": "EU",
  "provision": {
    "instrument": "http://data.europa.eu/eli/reg/2024/1689/oj",
    "article": "26(6)",
    "text_as_of": "2026-09-30"
  },
  "basis": [
    "Regulation (EU) 2024/1689, Article 2(1)(b)",
    "Regulation (EU) 2024/1689, Article 6(2) and Annex III, point 4(a)",
    "Regulation (EU) 2026/1744, point (40)(b), amending Article 113"
  ],
  "outcome": {
    "status": "applies",
    "vocabulary": ["applies", "does-not-apply", "undetermined"],
    "applies_from": "2027-12-02"
  },
  "issued_at": "2026-10-01T09:00:00Z",
  "signature": "..."
}

A second entry, resolved by A, could carry A's assessment of Article 12(1) as provider. If the system were not high-risk, both would read does-not-apply and the record would verify exactly the same. The committed example set would add an unresolvable reference and an altered target, as the registry asks.

Backward compatibility

• Non-breaking (new optional field, informative addition)
• Breaking (removes or changes required field, changes wire format, changes algorithm set)

Motivation

The compliance consumer named on aaif/project-proposals#42. Primary sources (EUR-Lex):

• Regulation (EU) 2024/1689: Article 2, Article 6, Article 12, Article 16, Article 26, Article 113, Annex III
• Regulation (EU) 2026/1744, point (40)(b), the new Article 113 dates
• GDPR Article 4, points (7) and (8), for the controller and processor terms

Related issues or PRs

aaif/project-proposals#42; #226 (the registry); #314 and #328 (the Article 12 attribution).