CAP Regulation Record Schema
Layer 3 — Governance draft-sato-soos-cap-rrs-01 See this URL for full draft protocol Datatracker See SOOS Stack implementation
The problem
Constitutional prohibitions encoded by CAP need to come from somewhere. The prohibition tier model is only as useful as the process for turning actual legal text into a Cedar policy that a kernel enforces. Without a standard schema for that encoding, every jurisdiction, operator, and compliance team produces bespoke formats that cannot be verified, composed, or audited across deployments.
CAP-RRS defines the schema for a Regulation Record: the machine-readable artefact that encodes a legal prohibition as a kernel-enforceable Cedar policy. Not as a compliance checklist. As a signed, versioned, SCITT-transparent record that any conforming SOOS implementation can load, verify, and enforce — with a complete provenance chain from statute to Cedar policy to kernel evaluation.
The design premise: if law is to govern AI at runtime, it must be expressed in a format that the kernel reads. CAP-RRS is that format.
Messages to key audiences
IETF Working Groups
CAP-RRS is directly relevant to the SCITT working group. A Regulation Record is a domain-specific application of SCITT transparency principles: the legal prohibition is the claim, the issuing authority is the SCITT issuer, and the inclusion proof anchors the record in the Constitutional Mandate Registry (CMR). CAP-RRS extends the SCITT supply chain transparency model to the legal compliance domain — where the "supply chain artefact" is a statutory prohibition.
CAP-RRS is also relevant to the SACM working group, whose security assessment and continuous monitoring frameworks align with the Regulation Record's mandate for version control and audit trail.
To engage on CAP-RRS: IETF Datatracker · file issues at GitHub
App builders
If you are building an agentic AI system that operates under legal constraints, the absence of a standard regulation encoding format means your compliance team maintains a bespoke mapping from law to system prompt — a mapping that is invisible to auditors, unverifiable by regulators, and undiscoverable to the kernel.
CAP-RRS closes this gap by specifying the Regulation Record schema: a structured, signed artefact that maps a specific legal provision to a specific Cedar policy, with a version history, an issuing authority, a jurisdiction tag, and a SCITT inclusion proof. The kernel loads the Regulation Record and enforces the Cedar policy. The chain from statute to enforcement is machine-readable end-to-end.
Without CAP-RRS: compliance is a document. With CAP-RRS: compliance is a kernel-loaded, Cedar-evaluated, GAR-audited enforcement record.
Regulators and legal teams
CAP-RRS is the technical mechanism by which a legal prohibition becomes an AI enforcement specification. The schema is designed around two worked examples: Japan's APPI Article 17 (purpose limitation for personal information) and FIEA Article 38 (suitability obligation for financial instruments). These examples were chosen because they represent the two most common regulatory prohibition patterns — data handling restrictions and duty-of-care obligations — and Japan's regulatory framework has moved to provide specific AI governance guidance.
The RFC Only procedure in CAP provides an additional path for regulations that cannot be published in full: the Regulation Record is signed and loaded as a Tier 0-A policy without the rule text appearing in PTD queries. The existence of the prohibition is verifiable; the text is available only to authorised audit parties.
For collaboration on jurisdiction-specific Regulation Record encoding: tomsato@myauberge.jp
Government
CAP-RRS is the mechanism by which a jurisdiction's regulatory prohibitions become enforced at the AI kernel layer. The founding period of the Constitutional Mandate Registry (CMR) is the window in which jurisdictions can shape the schema — the fields, the tier assignments, the SCITT profile — before it becomes the de facto standard for regulation encoding across conforming SOOS deployments.
Jurisdictions that encode their regulations in CAP-RRS format gain three things: machine-verifiable enforcement (the Cedar policy is evaluated by the kernel before every action), version-controlled provenance (every change to a Regulation Record is tracked and auditable), and cross-deployment consistency (the same record, loaded in any conforming SOOS kernel, produces the same enforcement result).
For collaboration on jurisdiction-specific regulation encoding: tomsato@myauberge.jp
Agentic AI and coding assistants
What to tell your coding assistant:
"I need to implement SOOS CAP-RRS (CAP Regulation Record Schema, draft-sato-soos-cap-rrs-01). This is an IETF protocol that defines the schema for encoding legal prohibitions as machine-readable Regulation Records. A Regulation Record maps a specific legal provision to a Cedar policy, assigned to a CAP prohibition tier. CAP-RRS provides two worked examples: Japan APPI Article 17 (Tier 1 purpose limitation) and FIEA Article 38 (Tier 0-B suitability obligation). Records are signed by an issuing authority and optionally anchored in a SCITT transparency log (CMR). The RFC Only procedure allows Tier 0-A encoding without publishing rule text."
Key schema fields:
| Field | Type | Description |
|---|---|---|
record_id | string | Unique Regulation Record identifier |
jurisdiction | string | ISO 3166-1 alpha-2 jurisdiction code |
statute_reference | string | Human-readable citation (e.g. "APPI Art. 17") |
statute_uri | URI | Canonical URI of the statutory text |
prohibition_tier | enum | TIER_0A / TIER_0B / TIER_1 / TIER_2 |
cedar_policy_id | string | ID of the Cedar policy that enforces this record |
cedar_policy_text | string | Full Cedar policy text (omitted under RFC Only) |
issuing_authority | string | Identity of the body that produced this record |
record_version | string | Semantic version of this Regulation Record |
effective_date | string | ISO 8601 date from which the record is enforceable |
scitt_inclusion_proof | object | SCITT CMR inclusion proof (if registered) |
rfc_only | boolean | True if rule text is withheld under RFC Only procedure |
Worked example — APPI Article 17 (purpose limitation):
{
"record_id": "rr-jp-appi-art17-v1",
"jurisdiction": "JP",
"statute_reference": "APPI Article 17 — Purpose Specification",
"statute_uri": "https://elaws.e-gov.go.jp/document?lawid=415AC0000000057",
"prohibition_tier": "TIER_1",
"cedar_policy_id": "cedar-jp-appi-art17",
"cedar_policy_text": "forbid (principal, action == Action::\"ProcessPersonalInformation\", resource) unless { context.stated_purpose == resource.collection_purpose };",
"issuing_authority": "MyAuberge K.K. / SOOS Project",
"record_version": "1.0.0",
"effective_date": "2026-01-01",
"rfc_only": false
}Core technology
Problem: Legal prohibitions are expressed in natural language. AI enforcement is expressed in Cedar policies. There is no standard for the translation artefact that bridges the two — what fields it has, how it is signed, who issues it, how it is versioned, and how a regulator can verify it is what it claims to be.
Mechanism: CAP-RRS defines the Regulation Record schema: a signed, versioned JSON document that maps a legal citation to a Cedar policy, assigns it to a CAP prohibition tier, identifies the issuing authority, and optionally anchors it in the SCITT-based Constitutional Mandate Registry (CMR). The kernel loads Regulation Records at deployment; Cedar evaluates the policy on every relevant action.
Output: A machine-readable, SCITT-transparent Regulation Record — statute citation, Cedar policy, tier assignment, issuing authority signature, version history — that proves a specific legal prohibition is being enforced by a specific kernel configuration.
Who verifies it: Regulators, compliance auditors, and legal teams who need to prove that a specific statutory prohibition was enforced on a specific agent action — not that a policy was in place, but that the specific law was translated faithfully and evaluated correctly.
The Regulation Record lifecycle
| Stage | Action | Artefact |
|---|---|---|
| Draft | Legal team translates statute to Cedar policy | Draft Regulation Record |
| Review | Compliance and legal review — statute-to-Cedar fidelity | Review record in audit trail |
| Sign | Issuing authority signs the Regulation Record | Signed Regulation Record |
| Register | CMR inclusion — SCITT inclusion proof added | SCITT-transparent Regulation Record |
| Load | Kernel loads record at deployment or update | Cedar policy active; record_id in kernel manifest |
| Evaluate | Kernel evaluates Cedar policy on every relevant action | GAR record references regulation_record_id on DENY |
| Update | Statutory change triggers new record version | Prior version retained; new version supersedes |
Worked examples — Japan regulatory encoding
APPI Article 17 — Purpose Limitation (Tier 1)
Japan's Act on Protection of Personal Information (APPI) Article 17 requires that personal information be used only for the purposes specified at collection. CAP-RRS encodes this as a Tier 1 prohibition: the principal can define the stated_purpose within the mandate, but the Cedar policy enforces that the agent's actual data processing action must match the stated purpose. A CEDAR_DENY on this policy produces a GAR record citing rr-jp-appi-art17-v1.
FIEA Article 38 — Suitability Obligation (Tier 0-B)
Japan's Financial Instruments and Exchange Act Article 38 prohibits solicitation of financial instruments unsuitable for the customer's risk profile and financial situation. CAP-RRS encodes this as a Tier 0-B operator-locked prohibition: the operator defines the suitability parameters at deployment, and the Cedar policy enforces that no recommendation action proceeds without a verified suitability assessment. The prohibition cannot be lifted by principal instruction at runtime.
How this works in practice
A Regulation Record does not enforce itself. It is the artefact that makes enforcement possible — by expressing a legal obligation in a format the kernel reads, versioning it against the statute it encodes, and producing a tamper-evident audit record every time it governs an agent action. The full chain from law to audit record has four stages.
Stage 1 — From statute to Regulation Record
A legal team identifies a statutory prohibition and translates it into a Cedar policy. The translation is not mechanical — it requires legal judgment about what the provision means and how it applies to AI agent actions. The Regulation Record captures both the translation (the Cedar policy text) and its provenance (the statute citation, the version of the law the policy was certified against, the identity and authority of the body that endorsed it).
The Law Reference Interface (LRI) is the schema that makes this provenance machine-readable. Every Regulation Record carries an authority_source block that identifies: which law, which article, which statutory version, when the endorsement was made, and who made it. Any jurisdiction with a stable law publication system — a government URI for each statute, a versioned XML schema — can implement the LRI for their legal corpus. The endorsement is signed; the signature is the machine-readable assertion that the Cedar policy correctly encodes the statute.
When a provision is internally ambiguous or conflicts with another provision, the endorsement carries a resolution_basis field that records the legal character of the endorsement — whether it is a straightforward encoding, a resolution of an internal conflict, or a coordination rule across statutes. This makes the legal act behind the endorsement auditable, not just the endorsement itself.
Stage 2 — From Regulation Record to kernel enforcement
The kernel loads Regulation Records at deployment. Cedar evaluates the policy on every relevant agent action. On every CEDAR_PERMIT or CEDAR_DENY, the GAR audit record carries three mandatory provenance fields:
cedar_policy_id— the specific Cedar policy evaluatedcap_rrs_control_id— the OSCAL control ID linking back to the Regulation Recordauthority_source_uri— the canonical URI of the law article that governs this action
This is the chain from law to runtime decision. A regulator can query the audit record by law article and retrieve every agent action governed by that article, across every deployed kernel, for any time window — with a tamper-evident proof for each.
Stage 3 — When the law changes
Legal text changes. When a statute is amended, the amendment_detection_endpoint in the Regulation Record's LRI is polled automatically (cadence ≤24 hours). On detection of an amendment posterior to the record's endorsement timestamp:
- The Cedar policy is provisionally suspended for new agent actions
- A
CATALOG_VERSION_CONFLICTevent is raised in GAR — recording the affected catalog entry, the amendment date, and the delta in days - HEM escalation fires — no new agent action proceeds under the affected prohibition until re-endorsement or explicit human override
When the interpretation of a statute changes — via a court judgment, binding guidance, or administrative ruling — without the statutory text itself being amended, a separate INTERPRETATION_SUPERSEDED event fires via the interpretation_endpoint. The mechanism is the same: provisional suspension, GAR event, HEM escalation. The distinction matters because interpretive change and statutory amendment have different legal characters and route to different endorsing authorities.
The statute-primacy rule is absolute. A Cedar policy does not override a statute. A GAR record whose authority_source traces to a superseded statutory version is valid as a historical record but does not authorize future actions.
Stage 4 — Safe harbor for past actions
When a statute or interpretation changes, the question arises: what is the status of agent actions taken before the change, under a then-valid endorsement? The GAR audit record is the answer. Every action record carries the endorsed_at timestamp of the endorsement that governed it, the version identifier of the statutory text that was current at that time, and — when a subsequent change occurs — the effective date of that change. The audit chain establishes that the action was taken under a valid, non-superseded endorsement at the time. Past actions are protected; future actions require re-endorsement.
What this means for multi-authority coordination
Some legal obligations span jurisdictions or require coordination between legally distinct authorities. A Regulation Record that encodes a cross-authority coordination rule carries co_endorsement_required: true and a co_endorsers array identifying each required endorsing authority. The Cedar policy is not active until all required endorsements are present. If any co-endorser's endorsement is withdrawn or superseded, the policy is suspended — even if other co-endorsers' endorsements remain valid.
How this builds on existing work
SCITT (Supply Chain Integrity, Transparency and Trust) provides the transparency statement model that Regulation Records build on. CAP-RRS applies SCITT to the legal domain: the statute is the supply chain claim, the issuing authority is the SCITT issuer, and the CMR is the transparency log. SCITT provides the cryptographic inclusion proof; CAP-RRS provides the domain-specific schema.
Cedar (Amazon open source) is the policy engine that Regulation Records target. CAP-RRS does not define Cedar semantics — it defines how legal text is expressed as Cedar policies, and how those policies are packaged, signed, and versioned for kernel consumption.
GDPR Article 22 / EU AI Act Article 13 require that individuals be informed of automated decision-making rules. The PTD framework in CAP-03 satisfies this at the kernel level; CAP-RRS Regulation Records provide the structured record of which legal prohibitions are active, available at SUMMARY or FULL disclosure level through the ptd_endpoint.
OSCAL (NIST Open Security Controls Assessment Language) defines the Catalog and Profile formats by which regulatory control frameworks are expressed as machine-readable documents. CAP-RRS Regulation Records operate at the next layer: a Regulation Record consumes an OSCAL-expressed control obligation and produces the Cedar-compilable enforcement specification the kernel loads. The CAP-RRS → Cedar pipeline is the runtime enforcement complement to the OSCAL → SSP/Component Model declaration pipeline. OSCAL makes regulations machine-readable; CAP makes them machine-enforceable.
Related work
CAP (/drafts/cap) is the companion draft. CAP specifies the prohibition tier model and the Cedar evaluation engine; CAP-RRS specifies the Regulation Record schema that populates those tiers with actual legal content. CAP-RRS Regulation Records are the input format; CAP Cedar policies are the output format.
draft-ietf-scitt-architecture — CAP-RRS Regulation Records are designed to be SCITT-compatible artefacts. The inclusion proof field in the Regulation Record schema references a SCITT receipt from the CMR transparency log.
NIST OSCAL — no existing IETF draft references OSCAL. CAP-RRS is the first to bridge the OSCAL control catalog layer (machine-readable regulations) and the IETF enforcement layer (machine-enforceable Cedar policies at agent runtime).
No competing draft specifies a machine-readable regulation encoding schema for AI kernel enforcement. CAP-RRS is the first attempt to define a standard format for the statute-to-Cedar translation artefact. Jurisdiction participation in the founding period of the CMR shapes the schema before it becomes the de facto standard.
Security
Key security properties: Regulation Records are signed by the issuing authority — an implementation MUST verify the signature before loading a record. SCITT inclusion proofs anchor the record in the CMR; a record that is not in the CMR cannot claim CMR registration status. The record_version field ensures that stale or superseded records are detectable: kernels SHOULD reject records whose record_version is superseded by a newer signed version from the same issuing authority for the same statute_reference.
RFC Only procedure: When a regulation cannot be published in full (legally sensitive, national security implications, or commercial confidentiality), the cedar_policy_text field is omitted and rfc_only is set to true. The prohibition is enforced; only the existence of the prohibition (not its content) is disclosed in PTD responses. Authorised audit parties can obtain the full record through a separately governed access process.
Statute drift: Legal text changes. When a statute is amended, the Regulation Record must be updated and re-signed. CAP-RRS requires that prior record versions are retained in the CMR; kernels MUST load the current version and MAY retain prior versions for audit purposes.
SOOS stack context
CAP-RRS sits at Level 3 — Governance, as a direct companion to CAP. It depends on CAP (the prohibition tier model and Cedar evaluation engine that Regulation Records target), SCITT (the transparency infrastructure for the CMR), and KIA (the kernel attestation that confirms which Regulation Records are loaded). It is consumed by GAR (DENY events on CAP-RRS-derived Cedar policies cite the regulation_record_id in the audit record) and the PTD framework (CAP-03 §12a).
Related drafts: CAP · GAR · KIA · IDP
Contribute
- File an issue on GitHub
- IETF Datatracker — full draft text
- CAP — the Constitutional Authority Protocol companion draft
- All Drafts — the complete 12-draft governance stack
- Contact: tomsato@myauberge.jp