Internet Engineering Task Force T. Sato Internet-Draft MyAuberge K.K. Intended status: Standards Track 5 September 2026 Expires: 5 March 2027 Constitutional AI Protocol -- Regulation Record Specification (CAP-RRS) draft-sato-soos-cap-rrs-03 Abstract Compliance with applicable law should be a package import, not a Cedar authoring problem. The Constitutional AI Protocol (CAP) defines the enforcement architecture for governed AI agent systems: a three-tier Cedar policy evaluation model that distinguishes absolute prohibitions, jurisdictional legal constraints, operator policies, and resource limits. CAP specifies what the Governance Execution Controller (GEC) does when a Cedar policy fires. It does not specify how Cedar policies are authored, certified, distributed, or maintained as law changes. This document defines the Regulation Record: the structured representation of a compliance obligation at any CAP tier. A Regulation Record is the human-readable, machine-compilable intermediate form between legal text and Cedar policy. This document specifies the Regulation Record schema, the Cedar Compilation Profile that governs how Regulation Records are translated into Cedar policies, the conflict declaration model, the certification model governing which publishers may certify records at each tier, and the versioning and update protocol for the Constitutional Mandate Registry. Version -02 adds the Law Reference Interface (LRI) generic model, the Statute-Primacy Rule, and the Operational Requirements for catalog amendment and interpretation detection. These three additions complete the regulation lifecycle: from law encoding through law reference and provenance, through the consequences of law amendment, through the operational cadence governing detection and response. Version -03 corrects the Statute-Primacy Rule's event schemas to record resolution as a new, causally-linked GAR event rather than an in-place mutation of the original conflict event. The core developer experience this document enables: a developer imports certified Regulation Record packages from the Constitutional Mandate Registry, declares their own Tier 2 operator policies and Tier 3 resource policies, calls compile(), and receives a Cedar policy set ready for GEC loading. No Cedar is authored by hand for compliance purposes. Compliance is a package management operation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. The Compliance Authoring Problem 1.2. The Compilation Model 1.3. Relationship to CAP 1.4. Cedar as Compilation Target 2. Conventions and Definitions 3. Architecture Overview 3.1. The Three-Layer Stack 3.2. Developer Experience 3.3. Registry as Package Ecosystem 4. Regulation Record Schema 4.1. Top-Level Fields 4.2. agent_check Object 4.3. resource_policy Object (Tier 3) 4.4. conflict_declarations Array 4.5. certification Object 4.6. Complete Schema Reference 4.7. Tier-Specific Requirements 4.8. Worked Examples 4.8.1. Tier 0-A: Genocide Prohibition (Rome Statute) 4.8.2. Tier 1: GDPR Article 6 Lawful Basis 4.8.3. Tier 1: AML Suspicious Transaction (BSA) 4.8.4. Tier 1: Japan -- APPI Article 17 4.8.5. Tier 1: Japan -- FIEA Article 38 4.8.6. Tier 2: Operator Data Access Policy 4.8.7. Tier 3: Token Budget Resource Policy 5. Cedar Compilation Profile 5.1. Compilation Overview 5.2. Field Mapping: agent_check to Cedar 5.3. Conflict Surfacing at Compile Time 5.4. Compiler Conformance Requirements 6. Conflict Declaration Model 6.1. Conflict Types 6.2. Static vs. Runtime Conflicts 6.3. Conflict Resolution Protocol 7. Certification Model 7.1. Publisher Tiers 7.2. Certification Process 7.3. Certification Verification 8. Constitutional Mandate Registry Protocol 8.1. Package Structure 8.2. Versioning 8.3. Update Notification 8.4. GEC Update Response Options 9. Law Reference Interface (LRI) (NEW in -02) 9.1. Purpose and Design Rationale 9.2. LRI Generic Schema 9.3. Five Normative LRI Requirements 9.4. resolution_basis Controlled Vocabulary 9.5. Co-Endorsement Model 9.6. interpretation_endpoint 9.7. LRI Profile URI Registry 10. Statute-Primacy Rule (NEW in -02) 10.1. Normative Rule Text 10.2. CATALOG_VERSION_CONFLICT Event 10.3. INTERPRETATION_SUPERSEDED Event 10.4. Safe Harbor Clause 10.5. catalog_version Object Schema 11. Operational Requirements (NEW in -02) 11.1. Amendment Detection Cadence 11.2. Interpretation Detection Cadence 11.3. Maximum Suspension Window 11.4. authority_source_uri Mandatory Field 12. HEM Integration 12.1. HEM_TIER3_ANTICIPATORY (Class 8) 12.2. HEM_TIER3_OBSERVED (Class 9) 12.3. Execution Options Package 12.4. Natural Breakpoint Declaration 13. Open Issues 14. Security Considerations 15. Privacy Considerations 16. IANA Considerations 17. References 17.1. Normative References 17.2. Informative References Acknowledgments Appendix A. Japan e-LAWS LRI Profile Notes Appendix B. Related Work B.1. Compliance Automation Approaches B.2. Relationship to CAP B.3. Relationship to SCITT B.4. Relationship to AIPREF B.5. Relationship to OSCAL Author's Address 1. Introduction 1.1. The Compliance Authoring Problem The Constitutional AI Protocol [I-D.sato-soos-cap] specifies that a GEC evaluates Cedar policies before every agent transition. For high-risk and regulated deployments, those Cedar policies must accurately reflect applicable legal obligations: data protection law, financial crime prevention requirements, healthcare regulations, and so on. The question CAP does not answer is: who writes those Cedar policies, and how? Writing Cedar policies by hand from legal text is not a viable path to adoption. Legal text is authored in natural language for human interpretation; Cedar is a formal policy language designed for machine evaluation. The translation between them requires both legal expertise and Cedar authoring expertise -- a rare combination. More critically, Cedar policies must be updated whenever the law changes. Regulatory amendment, judicial interpretation, and supervisory guidance can all alter the operative effect of a legal obligation. A compliance architecture that requires manual Cedar updates on every regulatory change will not be maintained correctly in practice. The Regulation Record resolves this by separating the authoring concern (compliance specialists working in structured JSON with legal vocabulary) from the compilation concern (automated translation from Regulation Record to Cedar per the Cedar Compilation Profile) and the enforcement concern (GEC evaluating Cedar at runtime, fully specified by CAP). Each layer is owned by the appropriate expert. No layer requires expertise in all three domains. 1.2. The Compilation Model Cedar is the compilation target, not the authoring language. The relationship between Regulation Records and Cedar policies is analogous to the relationship between high-level programming languages and machine code: the higher abstraction is where humans work; the lower abstraction is what machines execute; the compiler is the normative bridge between them. This document specifies the compiler -- the Cedar Compilation Profile -- as a normative mapping. Any two conforming implementations of the Cedar Compilation Profile MUST produce semantically equivalent Cedar from identical Regulation Records. This determinism is essential: it means a Regulation Record certified by a regulatory authority can be compiled by any GEC implementation and produce Cedar that the certifying authority would recognise as an accurate representation of their requirement. 1.3. Relationship to CAP CAP [I-D.sato-soos-cap] specifies runtime enforcement: what the GEC does when a Cedar policy fires. CAP-RRS (this document) specifies the governance of the policy corpus that CAP enforces: how Cedar policies are authored, certified, distributed, and kept current as law changes. The two documents are complementary and form one governance stack. CAP-RRS does not revise or supersede CAP; it extends it. A GEC implementing CAP alone has a governed enforcement engine whose policies are manually authored and unverified. A GEC implementing CAP and CAP-RRS has a governed enforcement engine whose policies are registry-sourced, certified, version-managed, and automatically updated. Version -01 of this document added worked examples for Japan regulatory encoding (APPI Article 17, FIEA Article 38) and the full conflict declaration model. Version -02 adds Sections 9, 10, and 11: the Law Reference Interface (LRI) generic model, the Statute-Primacy Rule, and the Operational Requirements for amendment and interpretation detection. These three sections complete the regulation lifecycle specification that Sections 4-8 begin. OSCAL makes regulations machine-readable. CAP makes them machine- enforceable. CAP-RRS is the bridge between the two. 1.4. Cedar as Compilation Target Cedar [CEDAR] is the policy language and evaluation engine used by GEC implementations in the SOOS protocol family. Cedar is open source, formally verified for policy decidability, and developed by Amazon Web Services. CAP-RRS does not extend Cedar. CAP-RRS specifies the governance layer above Cedar: how Cedar policies originate from legal text, who may certify them, how they are distributed, and how they are kept current as law changes. Cedar's formal decidability guarantee -- every Cedar policy evaluation terminates -- is a requirement for GEC implementations that must evaluate policy at every agent transition. Non- terminating policy evaluation is not acceptable in a governance kernel. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. CAP: The Constitutional AI Protocol enforcement specification [I-D.sato-soos-cap]. Cedar Compilation Profile: The normative mapping from Regulation Record fields to Cedar policy syntax specified in Section 5 of this document. Constitutional Mandate Registry (CMR): The signed, versioned, append-only repository of certified Regulation Record packages. Protocol specified in Section 8. GEC (Governance Execution Controller): The runtime component that enforces Cedar policies produced by the CAP-RRS compiler. Defined in [I-D.sato-soos-cap]. Law Reference Interface (LRI): (NEW in -02) The normative interface that each jurisdiction-specific statute reference binding MUST implement. Specified in Section 9. Each implementation is an LRI profile identified by a URI registered per Section 9.7. LRI Profile: (NEW in -02) A jurisdiction-specific implementation of the LRI. An LRI Profile defines how law_id, article_ref, version_identifier, amendment_detection_endpoint, and authority_id are bound to the jurisdiction's legal publication system. authority_source: (NEW in -02) The LRI block within a Regulation Record that identifies which law, which article, which statutory version, when the endorsement was made, who made it, and the endorsement's legal character (resolution_basis). resolution_basis: (NEW in -02) A controlled vocabulary field on the endorsement block that records the legal character of the endorsement act. Values: statute_clear, interpretive_ruling, internal_conflict_ resolution, cross_statute_coordination. CATALOG_VERSION_CONFLICT: (NEW in -02) A GAR event raised when an amendment posterior to a Regulation Record's endorsed_at timestamp is detected. Triggers provisional suspension and HEM escalation. Schema in Section 10.2. INTERPRETATION_SUPERSEDED: (NEW in -02) A GAR event raised when an interpretive ruling supersedes the resolution_basis of a Regulation Record's endorsement, without any change to the underlying statutory text. Schema in Section 10.3. catalog_version: (NEW in -02) A mandatory object on every distributed catalog update that carries version_id, effective_date, supersedes, amendment_ basis, published_by, and published_at. Schema in Section 10.5. Natural Breakpoint: A point in a multi-step agent mission at which stopping produces a coherent, complete deliverable of independent value. Used by HEM_TIER3_ANTICIPATORY to identify scope- reduction options. Operative Clause: The specific prohibition or permission within a legal text that applies at agent decision time and is therefore representable as a Cedar policy. Regulation Record: The structured intermediate representation of a compliance obligation, as defined in Section 4 of this document. Regulation Record Package: A signed, versioned collection of Regulation Records covering a defined legal instrument (e.g., GDPR [GDPR], BSA [BSA], APPI). Resource Policy: A Tier 3 Regulation Record governing agent resource consumption (tokens, API calls, time windows, storage). 3. Architecture Overview 3.1. The Three-Layer Stack The compliance architecture operates as three distinct layers: Layer 1 -- Law to Regulation Record: Compliance specialists extract the operative clause from legal text and represent it as a structured Regulation Record. This layer requires legal expertise. It does not require Cedar knowledge. The output is JSON in the Regulation Record schema (Section 4). Law provenance is captured in the authority_source block (Section 9). Certification is governed by Section 7. Layer 2 -- Regulation Record to Cedar: The CAP-RRS compiler applies the Cedar Compilation Profile (Section 5) to transform Regulation Records into Cedar policies. This layer is fully automated. No human authoring of Cedar for compliance purposes is required or expected. The output is a Cedar policy set suitable for loading by a CAP-conforming GEC. Layer 3 -- Cedar to Enforcement: The GEC evaluates the Cedar policy set at every agent transition. This layer is fully specified by CAP. The developer observes PERMIT or DENY with a structured reason code referencing the specific Regulation Record that fired. 3.2. Developer Experience A developer configuring compliance for a regulated agent deployment performs four operations: (1) Import certified Regulation Record packages from the CMR for all applicable legal frameworks. (2) Author Tier 2 operator policies in Regulation Record format. No Cedar knowledge required. (3) Author Tier 3 resource policies in Regulation Record format. No Cedar knowledge required. (4) Call compile(). The Cedar Compilation Profile generates the full Cedar policy set. The developer does not review or modify Cedar output except for debugging purposes. Pseudocode example: cap.import("cmr://eu.gdpr.2016/679@2.1.0") ; Tier 1 -- GDPR cap.import("cmr://eu.ai_act.2024/art14@1.0.0") cap.import("cmr://jp.appi.2003/art17@3.0.0") cap.import("cmr://us.bsa.1970/sar@3.2.1") cap.operator_policy({ record_id: "acme.data_access.v1", tier: "2", ... }) cap.resource_policy({ record_id: "acme.token_budget.v1", tier: "3", ... }) cedar_policy_set = cap.compile() gec.load_policies(cedar_policy_set) 3.3. Registry as Package Ecosystem The Constitutional Mandate Registry operates as a signed package ecosystem. Each Regulation Record Package is: * Identified by a URI: cmr://{publisher}.{instrument}@{version} * Signed by the certified publisher's Ed25519 keypair * Versioned using Semantic Versioning [SEMVER] * Accompanied by a changelog declaring which operative clauses changed between versions * Conflict-declared against known incompatible packages * Carrying a catalog_version object per Section 10.5 in every distributed update (NEW in -02) GEC implementations subscribe to update notifications for imported packages. Update handling is governed by Section 8.4. The tier architecture determines both the certification requirements (Section 7) and the post-DENY recourse availability: Tier Category Recourse on DENY ------------------------------------------------------- 0-A Absolute universal prohib. None. Ever. 0-B Qualified absolute prohib. None within scope. 1 Jurisdictional legal None within jurisdiction. 2 Operator policy Operator-defined exception path or HEM escalation. 3 Resource / usage policy Always exists: commercial, scope reduction, temporal. 4. Regulation Record Schema 4.1. Top-Level Fields A Regulation Record is a JSON object. Fields marked REQUIRED must be present. CONDITIONAL fields are required when the stated condition is met. record_id (string, REQUIRED): Unique identifier within the package. Format: {publisher_id}.{instrument_code}.{article}. Example: "eu.gdpr.2016_679.art6". MUST be stable across package versions. schema_version (string, REQUIRED): Regulation Record schema version. Current: "cap-rrs-01". tier (string, REQUIRED): CAP tier. One of: "0-A", "0-B", "1", "2", "3". jurisdiction_scope (object, REQUIRED): territories (array of string): ISO 3166-1 alpha-2 codes, or "GLOBAL" for Tier 0 records. legal_system (string): "CIVIL", "COMMON", "RELIGIOUS", "HYBRID", or "INTERNATIONAL". supranational_body (string, OPTIONAL): e.g., "EU", "UN". legal_source (object, REQUIRED for Tier 0 and 1): instrument_name (string): Full official instrument name. instrument_code (string): Short code, e.g., "GDPR". article (string): Specific article or provision. official_url (string, OPTIONAL): URL to official text. treaty_citation (string, REQUIRED for Tier 0-A): Formal international law citation. parties (integer, OPTIONAL): State party count for treaties. title (string, REQUIRED): Short human-readable title. Maximum 200 characters. operative_clause (string, REQUIRED): Plain-language statement of the prohibition or permission this record represents. Must be understandable by a compliance professional without Cedar knowledge. Maximum 500 characters. full_legal_text_summary (string, OPTIONAL): Broader legal context. Not compiled into Cedar. agent_check (object, REQUIRED): Machine-readable specification of what the GEC evaluates at decision time. Primary input to the Cedar Compilation Profile. Specified in Section 4.2. resource_policy (object, CONDITIONAL): REQUIRED when tier is "3". Specified in Section 4.3. conflict_declarations (array, REQUIRED): Known conflicts with other records. MAY be empty. Specified in Section 4.4. certification (object, REQUIRED): Certification metadata. Specified in Section 4.5. effective_date (string, REQUIRED): ISO 8601 date on which the operative clause is effective. sunset_date (string, OPTIONAL): ISO 8601 date on which the operative clause ceases effect. review_trigger (array of string, REQUIRED, minItems: 1): Events requiring this record to be reviewed. record_version (string, REQUIRED): Semantic version of this record. Pattern: "^[0-9]+\.[0-9]+\.[0-9]+$". supersedes (string, OPTIONAL): record_id of the record this record replaces. authority_source_uri (string, REQUIRED): (NEW in -02) URI of the AuthoritySource block (Section 9.2) endorsing this record. MUST match the soos.cap.authority_source_uri OTel attribute emitted at Cedar evaluation time per Section 11.4. Was OPTIONAL in -01. catalog_version (object, REQUIRED): (NEW in -02) Version metadata for this record as distributed in a catalog update. REQUIRED top-level field in every distributed catalog update. Schema specified in Section 10.5. 4.2. agent_check Object trigger (object, REQUIRED): action_scope (array of string): Cedar action namespace patterns to which this record applies. "Action::*" applies to all actions. resource_scope (array of string, OPTIONAL). principal_scope (array of string, OPTIONAL). required_context_fields (array of object, REQUIRED): Each entry specifies an IDP or GEC context field: field_name (string): Cedar context attribute name. field_type (string): "boolean", "string", "integer", "enum", or "array". field_description (string): Plain-language description. source (string): "IDP_HEADER", "IDP_CONTEXT", "GEC_STATE", "RESOURCE_STATE", or "PARTY_REGISTRY". required (boolean): Whether field must be present. prohibition_condition (object, CONDITIONAL): REQUIRED when the record represents a prohibition. condition_plain (string): Plain-language prohibition condition. condition_cedar_hint (string): Cedar expression hint for compiler implementors. NOT normative. confidence_threshold (string, OPTIONAL): For Tier 1 observation records. One of: "SUSPICIOUS", "PROBABLE", "EVIDENT". permission_condition (object, CONDITIONAL): REQUIRED when the record represents an explicit permission. Same structure as prohibition_condition. post_deny_protocol (object, REQUIRED): recourse_available (boolean): MUST be false for Tier 0-A. MUST be true for Tier 3. recourse_types (array of string, CONDITIONAL): REQUIRED when recourse_available is true. One or more of: "COMMERCIAL_UPGRADE", "SCOPE_REDUCTION", "TEMPORAL_DEFERRAL", "OPERATOR_EXCEPTION", "HEM_ESCALATION", "EXTERNAL_REPORTING". hem_trigger (string, OPTIONAL): HEM trigger class if DENY should trigger HEM escalation. reporting_obligation (object, OPTIONAL): framework (string): e.g., "BSA_SAR", "EU_AMLD_STR". deadline_hours (integer): Hours to mandatory filing. auto_escalate_on_timeout (boolean): Whether GEC escalates externally if principal does not respond before deadline. event_log_entry (string, REQUIRED): GEC Event Log entry type on DENY. e.g., "CAP_TIER1_DENY". observation_config (object, CONDITIONAL): REQUIRED when hem_trigger is "HEM_TIER1_OBSERVED" or "HEM_TIER0_OBSERVED". These trigger classes are defined in Sections 5.6 and 5.7 of [I-D.sato-soos-hem] respectively. observation_type (string): e.g., "AML", "SANCTIONS", "FRAUD", "CSAM". confidence_grades (object): Configuration for each grade (SUSPICIOUS, PROBABLE, EVIDENT): hem_urgency (string): "STANDARD", "ELEVATED", or "CRITICAL". session_suspension (boolean). escalation_targets (array of string). cluster_propagation (boolean): Whether MUST propagate to related execution agent sessions per CONF-MAD-GEC-03. 4.3. resource_policy Object (Tier 3) resource_type (string, REQUIRED): "TOKEN", "API_CALL", "TIME_WINDOW", "STORAGE", or "COMPUTE_UNIT". measurement_unit (string, REQUIRED): e.g., "tokens", "calls/hour", "seconds", "bytes". budget_field (string, REQUIRED): Cedar context attribute name for the budget value. consumed_field (string, REQUIRED): Cedar context attribute name for consumed value. estimated_cost_field (string, REQUIRED): Cedar context attribute name for estimated action cost. warning_threshold_pct (integer, REQUIRED): Consumption percentage at which HEM_TIER3_OBSERVED fires. MUST be between 50 and 95. Default: 80. anticipatory_assessment (boolean, REQUIRED): Whether GEC MUST perform Mission Viability Assessment before multi-step missions. When true, HEM_TIER3_ ANTICIPATORY fires if full mission cost estimate exceeds remaining budget. natural_breakpoint_required (boolean, REQUIRED): Whether agents MUST declare Natural Breakpoints at mission start under this constraint. recourse_types (array of string, REQUIRED): One or more of: "COMMERCIAL_UPGRADE", "SCOPE_REDUCTION", "TEMPORAL_DEFERRAL". reset_field (string, OPTIONAL): Cedar context attribute carrying budget reset datetime. upgrade_url_field (string, OPTIONAL): Cedar context attribute carrying upgrade URL. 4.4. conflict_declarations Array Each entry: conflicting_record_id (string, REQUIRED): The record_id of the conflicting record. conflict_type (string, REQUIRED): One of: "DIRECT_CONTRADICTION": Mutually exclusive GEC behaviour on the same trigger condition. "JURISDICTION_OVERLAP": Same territory, different instruments. "CONFIDENCE_GRADIENT_OVERLAP": Same observation type, overlapping confidence grades. "PRIORITY_AMBIGUITY": Both apply; neither declares precedence. conflict_description (string, REQUIRED): Plain-language description of the specific conflict. resolution_strategy (string, REQUIRED): One of: "THIS_RECORD_TAKES_PRIORITY" "OTHER_RECORD_TAKES_PRIORITY" "OPERATOR_DECLARES_PRIORITY": Operator MUST declare resolution at compile time. Compiler error if absent. "HEM_JURISDICTIONAL_CONFLICT": Irresolvable at compile time. Cedar flagged for runtime HEM Class 5 escalation. resolution_cedar_hint (string, OPTIONAL): Cedar expression hint for deterministic resolutions. 4.5. certification Object certification_tier (string, REQUIRED): "FOUNDATION", "REGULATORY_BODY", "LICENSED_PROVIDER", "OPERATOR", or "SELF". MUST be consistent with record tier per Section 7.1. certified_by (object, REQUIRED): publisher_id (string): Registered CMR publisher ID. publisher_name (string): Human-readable publisher name. publisher_keypair_id (string): Ed25519 keypair identifier. certification_date (string, REQUIRED): ISO 8601 datetime. certification_statement (string, REQUIRED): Plain-language attestation. record_signature (string, REQUIRED): Ed25519 signature over canonical JSON of this record (excluding this field), encoded as base64url. certification_expiry (string, OPTIONAL): ISO 8601 datetime. GEC MUST refuse to load after expiry without renewal. 4.6. Complete Schema Reference The normative JSON Schema (Draft 2020-12) is published at: https://cap.soos.foundation/schema/regulation-record/cap-rrs-01 The prose specification in Sections 4.1 through 4.5 is normative. The JSON Schema is informative and provided for tooling convenience. 4.7. Tier-Specific Requirements Tier 0-A: * legal_source REQUIRED. treaty_citation REQUIRED. * parties SHOULD be present. * jurisdiction_scope.territories MUST be ["GLOBAL"]. * conflict_declarations MUST be empty. * certification.certification_tier MUST be "FOUNDATION". * post_deny_protocol.recourse_available MUST be false. Tier 0-B: * legal_source REQUIRED. treaty_citation REQUIRED. * jurisdiction_scope.territories MUST be ["GLOBAL"] or defined coalition of state parties. * post_deny_protocol.recourse_available MUST be false within the prohibition scope. * certification_tier MUST be "FOUNDATION" or "REGULATORY_BODY". Tier 1: * legal_source REQUIRED. * treaty_citation OPTIONAL (required for treaty-derived national law). * certification_tier MUST be "REGULATORY_BODY" or "LICENSED_PROVIDER". * conflict_declarations SHOULD declare any known conflicts with other Tier 1 records for overlapping jurisdictions. Tier 2: * legal_source OPTIONAL. * certification_tier MUST be "OPERATOR". Tier 3: * resource_policy REQUIRED. * post_deny_protocol.recourse_available MUST be true. * certification_tier MUST be "SELF". 4.8. Worked Examples 4.8.1. Tier 0-A: Genocide Prohibition (Rome Statute) { "record_id": "int.rome_statute.art6", "schema_version": "cap-rrs-01", "tier": "0-A", "jurisdiction_scope": { "territories": ["GLOBAL"], "legal_system": "INTERNATIONAL", "supranational_body": "ICC" }, "legal_source": { "instrument_name": "Rome Statute of the International Criminal Court", "instrument_code": "ROME_STATUTE", "article": "Article 6", "official_url": "https://www.icc-cpi.int/sites/ default/files/RS-Eng.pdf", "treaty_citation": "Rome Statute of the International Criminal Court, 17 July 1998, 2187 UNTS 90, Article 6.", "parties": 124 }, "title": "Genocide -- Absolute Prohibition", "operative_clause": "No agent may perform any action that constitutes, facilitates, or contributes to acts committed with intent to destroy, in whole or in part, a national, ethnical, racial or religious group.", "agent_check": { "trigger": { "action_scope": ["Action::*"] }, "required_context_fields": [ { "field_name": "genocide_risk_assessment", "field_type": "string", "field_description": "GEC assessment of whether the action contributes to genocide risk.", "source": "GEC_STATE", "required": false } ], "prohibition_condition": { "condition_plain": "Action contributes to genocide as defined by Rome Statute Article 6.", "condition_cedar_hint": "context.genocide_risk_assessment == \"CONFIRMED\" || context.genocide_risk_assessment == \"PROBABLE\"" }, "post_deny_protocol": { "recourse_available": false, "hem_trigger": "HEM_TIER0_OBSERVED", "event_log_entry": "CAP_TIER0A_DENY" } }, "conflict_declarations": [], "certification": { "certification_tier": "FOUNDATION", "certified_by": { "publisher_id": "cap.foundation", "publisher_name": "ATP Foundation", "publisher_keypair_id":"cap-foundation-2026-01" }, "certification_date": "2026-05-01T00:00:00Z", "certification_statement": "This Regulation Record accurately represents the operative clause of Rome Statute Article 6 as ratified by 124 state parties.", "record_signature": "" }, "effective_date": "1998-07-17", "review_trigger": [ "Additional state party ratification or withdrawal", "ICC Assembly amendment to Article 6", "ICC Appeals Chamber ruling on genocide definition" ], "record_version": "1.0.0" } 4.8.2. Tier 1: GDPR Article 6 Lawful Basis { "record_id": "eu.gdpr.2016_679.art6", "schema_version": "cap-rrs-01", "tier": "1", "jurisdiction_scope": { "territories": ["AT","BE","BG","CY","CZ","DE","DK", "EE","ES","FI","FR","GR","HR","HU", "IE","IT","LT","LU","LV","MT","NL", "PL","PT","RO","SE","SI","SK"], "legal_system": "CIVIL", "supranational_body": "EU" }, "legal_source": { "instrument_name": "Regulation (EU) 2016/679 (GDPR)", "instrument_code": "GDPR", "article": "Article 6 -- Lawfulness of processing", "official_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/ ?uri=CELEX:32016R0679" }, "title": "GDPR Article 6 -- Lawful Basis for Data Processing", "operative_clause": "Processing of personal data is unlawful unless at least one lawful basis applies: consent, contract, legal obligation, vital interests, public task, or legitimate interests.", "agent_check": { "trigger": { "action_scope": ["Action::data_processing::*"], "resource_scope":["Resource::personal_data::*"] }, "required_context_fields": [ { "field_name": "lawful_basis", "field_type": "string", "field_description": "The lawful basis for processing this data.", "source": "IDP_CONTEXT", "required": true }, { "field_name": "data_category", "field_type": "string", "field_description": "Category of personal data being processed.", "source": "IDP_CONTEXT", "required": true }, { "field_name": "data_subject_consent", "field_type": "boolean", "field_description": "Whether valid consent is present.", "source": "IDP_CONTEXT", "required": false } ], "prohibition_condition": { "condition_plain": "No lawful basis is present, or consent is required but absent.", "condition_cedar_hint": "!context.lawful_basis.has_value() || (context.lawful_basis == \"CONSENT\" && !context.data_subject_consent)" }, "post_deny_protocol": { "recourse_available": true, "recourse_types": ["OPERATOR_EXCEPTION", "HEM_ESCALATION"], "hem_trigger": "HEM_JURISDICTIONAL_CONFLICT", "event_log_entry": "CAP_TIER1_DENY" } }, "conflict_declarations": [ { "conflicting_record_id": "eu.medical_act.mandatory_reporting", "conflict_type": "DIRECT_CONTRADICTION", "conflict_description": "GDPR consent revocation conflicts with mandatory disease reporting in some EU member states.", "resolution_strategy": "HEM_JURISDICTIONAL_CONFLICT" } ], "certification": { "certification_tier": "REGULATORY_BODY", "certified_by": { "publisher_id": "eu.edpb", "publisher_name": "European Data Protection Board", "publisher_keypair_id":"edpb-2026-01" }, "certification_date": "2026-03-15T00:00:00Z", "certification_statement": "This Regulation Record accurately represents the operative clause of GDPR Article 6 as interpreted by EDPB Guidelines 01/2020.", "record_signature": "" }, "effective_date": "2018-05-25", "review_trigger": [ "CJEU ruling on Article 6 interpretation", "EDPB guideline update on lawful basis", "GDPR amendment by European Parliament" ], "record_version": "2.1.0" } 4.8.3. Tier 1: AML Suspicious Transaction (BSA / FinCEN) { "record_id": "us.bsa.1970.sar_obligation", "schema_version": "cap-rrs-01", "tier": "1", "jurisdiction_scope": { "territories": ["US"], "legal_system": "COMMON" }, "legal_source": { "instrument_name": "Bank Secrecy Act (31 U.S.C. 5318(g))", "instrument_code": "BSA", "article": "31 U.S.C. 5318(g) -- Reporting of suspicious transactions" }, "title": "BSA -- Suspicious Activity Report Obligation", "operative_clause": "Financial institutions must report suspicious transactions involving possible money laundering or financial crimes. Reporting is mandatory when evidence confidence reaches PROBABLE or higher.", "agent_check": { "trigger": { "action_scope": ["Action::financial::transfer::*", "Action::financial::payment::*"] }, "required_context_fields": [ { "field_name": "aml_confidence_grade", "field_type": "string", "field_description": "AML pattern match confidence grade.", "source": "GEC_STATE", "required": false }, { "field_name": "counterparty_risk_level", "field_type": "string", "field_description": "Risk level of the transaction counterparty.", "source": "IDP_CONTEXT", "required": false }, { "field_name": "typology_match_id", "field_type": "string", "field_description": "FinCEN typology pattern match identifier.", "source": "GEC_STATE", "required": false } ], "prohibition_condition": { "condition_plain": "Transaction matches AML typology with EVIDENT confidence, or involves a sanctioned counterparty.", "confidence_threshold": "EVIDENT", "condition_cedar_hint": "context.aml_confidence_grade == \"EVIDENT\" || context.counterparty_risk_level == \"SANCTIONED\"" }, "post_deny_protocol": { "recourse_available": false, "hem_trigger": "HEM_TIER1_OBSERVED", "reporting_obligation": { "framework": "BSA_SAR", "deadline_hours": 720, "auto_escalate_on_timeout": true }, "event_log_entry": "CAP_TIER1_DENY" }, "observation_config": { "observation_type": "AML", "confidence_grades": { "SUSPICIOUS": { "hem_urgency": "STANDARD", "session_suspension": false, "escalation_targets": ["COMPLIANCE_OFFICER"] }, "PROBABLE": { "hem_urgency": "ELEVATED", "session_suspension": false, "escalation_targets": ["COMPLIANCE_OFFICER", "LEGAL_COUNSEL"] }, "EVIDENT": { "hem_urgency": "CRITICAL", "session_suspension": true, "escalation_targets": ["COMPLIANCE_OFFICER", "LEGAL_COUNSEL", "SENIOR_PRINCIPAL"] } }, "cluster_propagation": true } }, "conflict_declarations": [], "certification": { "certification_tier": "REGULATORY_BODY", "certified_by": { "publisher_id": "us.fincen", "publisher_name": "Financial Crimes Enforcement Network", "publisher_keypair_id": "fincen-2026-01" }, "certification_date": "2026-04-01T00:00:00Z", "certification_statement": "This Regulation Record accurately represents the BSA Section 5318(g) SAR obligation as implemented in 31 CFR 1020.320.", "record_signature": "" }, "effective_date": "1992-04-01", "review_trigger": [ "FinCEN rulemaking amending SAR thresholds", "BSA amendment by Congress", "FATF mutual evaluation recommendation" ], "record_version": "3.2.1" } 4.8.4. Tier 1: Japan -- Act on the Protection of Personal Information (APPI) Article 17 { "record_id": "jp.appi.2003.art17", "schema_version": "cap-rrs-01", "tier": "1", "jurisdiction_scope": { "territories": ["JP"], "legal_system": "CIVIL" }, "legal_source": { "instrument_name": "Act on the Protection of Personal Information (個人情報の保護に関する法律)", "instrument_code": "APPI", "article": "Article 17 -- Restriction on Purpose of Use", "official_url": "https://www.ppc.go.jp/en/legal/" }, "title": "APPI Article 17 -- Purpose Limitation for Personal Information", "operative_clause": "A business operator handling personal information must not handle personal information beyond the scope necessary to achieve the specified purpose of use without obtaining the consent of the principal.", "agent_check": { "trigger": { "action_scope": ["Action::data_processing::*", "Action::data_use::*"], "resource_scope":["Resource::personal_data::*"] }, "required_context_fields": [ { "field_name": "declared_purpose", "field_type": "string", "field_description": "The specified purpose of use declared at time of personal information collection.", "source": "IDP_CONTEXT", "required": true }, { "field_name": "requested_purpose", "field_type": "string", "field_description": "The purpose for which data is being used in the current action.", "source": "IDP_CONTEXT", "required": true }, { "field_name": "principal_consent_obtained", "field_type": "boolean", "field_description": "Whether the data subject has consented to this use beyond the declared purpose.", "source": "IDP_CONTEXT", "required": false } ], "prohibition_condition": { "condition_plain": "The requested purpose of use exceeds the scope of the declared purpose, and the data subject has not consented to the extended use.", "condition_cedar_hint": "context.requested_purpose != context.declared_purpose && !context.principal_consent_obtained" }, "post_deny_protocol": { "recourse_available": true, "recourse_types": ["OPERATOR_EXCEPTION", "HEM_ESCALATION"], "hem_trigger": "HEM_CEDAR_ROUTED", "event_log_entry": "CAP_TIER1_DENY" } }, "conflict_declarations": [ { "conflicting_record_id": "eu.gdpr.2016_679.art6", "conflict_type": "JURISDICTION_OVERLAP", "conflict_description": "Both records apply when a JP-domiciled business operator processes personal data of EU data subjects. GDPR and APPI share the purpose limitation principle but differ on lawful basis enumeration.", "resolution_strategy": "OPERATOR_DECLARES_PRIORITY" } ], "certification": { "certification_tier": "LICENSED_PROVIDER", "certified_by": { "publisher_id": "draft.jp.appi", "publisher_name": "Draft -- Pending Certification", "publisher_keypair_id":"PENDING" }, "certification_date": "2026-05-30T00:00:00Z", "certification_statement": "DRAFT Regulation Record for APPI Article 17. Not yet certified by a registered CMR publisher. For schema demonstration purposes.", "record_signature": "" }, "effective_date": "2022-04-01", "review_trigger": [ "Amendment to APPI Article 17 by the Diet", "PPC guideline update on purpose limitation scope", "Supreme Court ruling on APPI Article 17 interpretation" ], "record_version": "0.1.0" } 4.8.5. Tier 1: Japan -- Financial Instruments and Exchange Act (FIEA) Article 38 { "record_id": "jp.fiea.1948.art38", "schema_version": "cap-rrs-01", "tier": "1", "jurisdiction_scope": { "territories": ["JP"], "legal_system": "CIVIL" }, "legal_source": { "instrument_name": "Financial Instruments and Exchange Act (金融商品取引法)", "instrument_code": "FIEA", "article": "Article 38 -- Prohibited Acts for Financial Instruments Business Operators", "official_url": "https://www.fsa.go.jp/en/laws/index.html" }, "title": "FIEA Article 38 -- Suitability Obligation for Financial Recommendations", "operative_clause": "A financial instruments business operator must not recommend financial instruments that are unsuitable for a customer in light of the customer's knowledge, experience, financial situation, and purpose of concluding the contract.", "agent_check": { "trigger": { "action_scope": [ "Action::financial::recommendation::*", "Action::financial::solicitation::*" ] }, "required_context_fields": [ { "field_name": "customer_profile_available", "field_type": "boolean", "field_description": "Whether a suitability profile for the customer is available to the agent.", "source": "GEC_STATE", "required": true }, { "field_name": "suitability_assessment", "field_type": "string", "field_description": "Result of suitability assessment for the recommended instrument. Values: SUITABLE, UNSUITABLE, UNKNOWN.", "source": "GEC_STATE", "required": false }, { "field_name": "customer_explicit_acknowledgment", "field_type": "boolean", "field_description": "Whether customer has explicitly acknowledged and accepted suitability concerns.", "source": "IDP_CONTEXT", "required": false } ], "prohibition_condition": { "condition_plain": "The recommended financial instrument is assessed as unsuitable for the customer, or no suitability assessment is available, and the customer has not explicitly acknowledged the suitability concern.", "condition_cedar_hint": "(context.suitability_assessment == \"UNSUITABLE\" || !context.customer_profile_available) && !context.customer_explicit_acknowledgment" }, "post_deny_protocol": { "recourse_available": true, "recourse_types": ["HEM_ESCALATION", "OPERATOR_EXCEPTION"], "hem_trigger": "HEM_CEDAR_ROUTED", "event_log_entry": "CAP_TIER1_DENY" } }, "conflict_declarations": [], "certification": { "certification_tier": "LICENSED_PROVIDER", "certified_by": { "publisher_id": "draft.jp.fiea", "publisher_name": "Draft -- Pending Certification", "publisher_keypair_id":"PENDING" }, "certification_date": "2026-05-30T00:00:00Z", "certification_statement": "DRAFT Regulation Record for FIEA Article 38. Not yet certified by a registered CMR publisher. For schema demonstration purposes.", "record_signature": "" }, "effective_date": "2023-11-01", "review_trigger": [ "Amendment to FIEA Article 38 by the Diet", "FSA supervisory guideline update on suitability", "Supreme Court ruling on FIEA Article 38" ], "record_version": "0.1.0" } 4.8.6. Tier 2: Operator Data Access Policy { "record_id": "acme.agent.data_access.v1", "schema_version": "cap-rrs-01", "tier": "2", "jurisdiction_scope": { "territories": ["US","EU"], "legal_system": "HYBRID" }, "title": "ACME -- Agent Data Access Restriction", "operative_clause": "Agents may only access records of principals explicitly assigned to the current session.", "agent_check": { "trigger": { "action_scope": ["Action::data_access::*"] }, "required_context_fields": [ { "field_name": "accessing_principal_id", "field_type": "string", "field_description": "Principal whose records agent is accessing.", "source": "IDP_CONTEXT", "required": true }, { "field_name": "session_assigned_principals", "field_type": "array", "field_description": "Principal IDs assigned to current session.", "source": "GEC_STATE", "required": true } ], "prohibition_condition": { "condition_plain": "The accessing principal is not in the session's assigned principal list.", "condition_cedar_hint": "!context.session_assigned_principals .contains(context.accessing_principal_id)" }, "post_deny_protocol": { "recourse_available": true, "recourse_types": ["HEM_ESCALATION", "OPERATOR_EXCEPTION"], "hem_trigger": "HEM_CEDAR_ROUTED", "event_log_entry": "CAP_TIER2_DENY" } }, "conflict_declarations": [], "certification": { "certification_tier": "OPERATOR", "certified_by": { "publisher_id": "acme.corp", "publisher_name": "ACME Corporation", "publisher_keypair_id":"acme-ops-2026-01" }, "certification_date": "2026-05-01T00:00:00Z", "certification_statement": "ACME Corporation operator data access policy v1.", "record_signature": "" }, "effective_date": "2026-05-01", "review_trigger": [ "ACME data governance policy update" ], "record_version": "1.0.0" } 4.8.7. Tier 3: Token Budget Resource Policy { "record_id": "acme.resource.token_budget.v1", "schema_version": "cap-rrs-01", "tier": "3", "jurisdiction_scope": { "territories": ["GLOBAL"], "legal_system": "INTERNATIONAL" }, "title": "ACME -- Standard Token Budget (100,000 tokens)", "operative_clause": "Agent sessions may not consume more than 100,000 tokens per billing period. Anticipatory assessment is required for multi-step missions.", "agent_check": { "trigger": { "action_scope": ["Action::*"] }, "required_context_fields": [ { "field_name": "tokens_remaining", "field_type": "integer", "field_description": "Tokens remaining in current billing period.", "source": "RESOURCE_STATE", "required": true }, { "field_name": "action_estimated_cost", "field_type": "integer", "field_description": "Estimated token cost of pending action.", "source": "GEC_STATE", "required": true } ], "prohibition_condition": { "condition_plain": "Estimated action cost exceeds remaining token budget.", "condition_cedar_hint": "context.tokens_remaining < context.action_estimated_cost && !context.upgrade_authorized" }, "post_deny_protocol": { "recourse_available": true, "recourse_types": ["COMMERCIAL_UPGRADE", "SCOPE_REDUCTION", "TEMPORAL_DEFERRAL"], "hem_trigger": "HEM_TIER3_ANTICIPATORY", "event_log_entry": "CAP_TIER3_DENY" } }, "resource_policy": { "resource_type": "TOKEN", "measurement_unit": "tokens", "budget_field": "token_budget", "consumed_field": "tokens_consumed", "estimated_cost_field": "action_estimated_cost", "warning_threshold_pct": 80, "anticipatory_assessment": true, "natural_breakpoint_required":true, "recourse_types": ["COMMERCIAL_UPGRADE", "SCOPE_REDUCTION", "TEMPORAL_DEFERRAL"], "reset_field": "budget_reset_at", "upgrade_url_field": "upgrade_url" }, "conflict_declarations": [], "certification": { "certification_tier": "SELF", "certified_by": { "publisher_id": "acme.corp", "publisher_name": "ACME Corporation", "publisher_keypair_id":"acme-ops-2026-01" }, "certification_date": "2026-05-01T00:00:00Z", "certification_statement": "ACME standard token budget resource policy.", "record_signature": "" }, "effective_date": "2026-05-01", "review_trigger": [ "ACME pricing model update" ], "record_version": "1.0.0" } (RECONSTRUCTED in -03: Sections 4.1 through 4.8 above are the actual text carried forward from draft-sato-soos-cap-rrs-01 -- -02 carried only a bracket placeholder claiming full carry- forward, with none of the Regulation Record schema actually present. The authority_source_uri and catalog_version fields in Section 4.1 are -02's own additions, applied above. Section 4.8's worked examples are otherwise unchanged from -01: -02's addendum note said each example's authority_source block should be updated to the Section 9 format, but the specific per-example authority_source values (law_id, article_ref, endorsement details for seven different jurisdictions) are not recoverable from -01's text and are not fabricated here -- this remains an open drafting task for a future revision, not resolved by this reconstruction.) 5. Cedar Compilation Profile 5.1. Compilation Overview The Cedar Compilation Profile is the normative specification for translating Regulation Records into Cedar policies. A conforming compiler MUST produce semantically equivalent Cedar from identical Regulation Records. Semantic equivalence means the compiled Cedar produces identical ALLOW/DENY results for all possible Cedar context inputs. The compiler processes records in tier order: Tier 0-A first, then 0-B, 1, 2, 3. Within each tier, records are processed in record_id lexicographic order. 5.2. Field Mapping: agent_check to Cedar For each Regulation Record the compiler produces: (a) A Cedar forbid clause from prohibition_condition. Principal, action, and resource scopes derived from trigger fields. (b) A Cedar permit clause from permission_condition when present. (c) Cedar context type annotations for each field in required_context_fields. (d) An annotation block on each Cedar policy carrying: record_id, tier, jurisdiction_scope.territories, effective_date, and record_version. These annotations enable the GEC to produce structured DENY reason codes referencing the specific Regulation Record that fired. The condition_cedar_hint field is informative. The compiler MAY use it to guide expression generation but MUST NOT reproduce it verbatim without validation. 5.3. Conflict Surfacing at Compile Time For each conflict_declaration with resolution_strategy "HEM_JURISDICTIONAL_CONFLICT", the compiler MUST generate a Cedar policy annotation marking the conflicting trigger pattern as a HEM_JURISDICTIONAL_CONFLICT (Class 5) candidate. The GEC MUST check this annotation at runtime and fire HEM_JURISDICTIONAL_CONFLICT when both conflicting policies would fire on the same context. For deterministic resolutions, the compiler MUST generate Cedar priority annotations using the Cedar priority mechanism. 5.4. Compiler Conformance Requirements CONF-CAP02-COMP-01: A conforming compiler MUST accept all Regulation Records conforming to the Section 4 schema. CONF-CAP02-COMP-02: A conforming compiler MUST reject any Regulation Record with an invalid or expired certification signature. CONF-CAP02-COMP-03: A conforming compiler MUST surface all conflict_declarations with strategy "OPERATOR_DECLARES_ PRIORITY" as compile-time errors requiring explicit operator resolution before a Cedar policy set is produced. CONF-CAP02-COMP-04: A conforming compiler MUST produce Cedar carrying Regulation Record annotations per Section 5.2(d) on every policy clause. CONF-CAP02-COMP-05: A conforming compiler MUST NOT produce Cedar for a Regulation Record that has reached sunset_date. (RECONSTRUCTED in -03: text above is carried forward from draft-sato-soos-cap-rrs-01 Section 5, unchanged.) 6. Conflict Declaration Model 6.1. Conflict Types See Section 4.4 for conflict type definitions. 6.2. Static vs. Runtime Conflicts Static conflicts are detectable at compile time because both records apply to the same action_scope and their prohibition conditions are structurally contradictory. The compiler MUST detect and surface all static conflicts. Runtime conflicts arise only when a specific combination of Cedar context values triggers both policies simultaneously in ways not detectable from schemas alone. The compiler surfaces these as HEM_JURISDICTIONAL_CONFLICT annotations; the GEC detects them at evaluation time. 6.3. Conflict Resolution Protocol When the compiler surfaces a conflict with strategy "OPERATOR_DECLARES_PRIORITY", the operator MUST provide a signed resolution declaration before compilation proceeds: { "resolution_id": "acme.resolution.gdpr_vs_medical", "record_a": "eu.gdpr.2016_679.art6", "record_b": "eu.medical_act.mandatory_reporting", "resolution": "OTHER_RECORD_TAKES_PRIORITY", "legal_basis": "EU member state medical act takes precedence over GDPR under Article 9(2)(i) for mandatory disease reporting.", "authorized_by": "acme.legal.counsel", "authorization_date": "2026-05-15" } Resolution declarations are signed by the operator keypair and stored in the GAR audit record [I-D.sato-soos-gar]. (RECONSTRUCTED in -03: text above is carried forward from draft-sato-soos-cap-rrs-01 Section 6, unchanged.) 7. Certification Model 7.1. Publisher Tiers FOUNDATION: ATP Foundation. Certifies Tier 0-A and 0-B records only. Certification is against treaty text. REGULATORY_BODY: National or supranational regulatory authority. Certifies Tier 1 records within their statutory jurisdiction. LICENSED_PROVIDER: Third-party compliance provider licensed by a regulatory body. Certifies Tier 1 records within license scope. OPERATOR: The deploying organization. Certifies Tier 2. No external approval required. SELF: Developer or operator. Certifies Tier 3. No external approval required. 7.2. Certification Process Publisher registration: Publishers register with the CMR by submitting their Ed25519 public key, jurisdiction scope, and certification tier. FOUNDATION and REGULATORY_BODY publishers undergo identity verification before registration. Record certification: The publisher signs the canonical JSON of the Regulation Record (excluding record_signature) with their registered Ed25519 private key and encodes as base64url. Package publication: The publisher assembles certified records into a signed package and submits to the CMR. 7.3. Certification Verification A GEC loading a Regulation Record package MUST: (a) Verify the publisher's CMR registration is current. (b) Verify each record_signature against the publisher's registered Ed25519 public key. (c) Verify certification_expiry has not passed. (d) Verify certification_tier is consistent with record tier per Section 4.7. A GEC MUST NOT load a package that fails any verification. (RECONSTRUCTED in -03: text above is carried forward from draft-sato-soos-cap-rrs-01 Section 7, unchanged.) 8. Constitutional Mandate Registry Protocol 8.1. Package Structure { "package_id": "eu.gdpr.2016/679", "package_version": "2.1.0", "publisher_id": "eu.edpb", "records": [ ... Regulation Records ... ], "changelog": [ ... version entries ... ], "conflicts_with": [ ... incompatible packages ... ], "package_signature": "" } 8.2. Versioning Packages use Semantic Versioning [SEMVER]: MAJOR: An operative clause changed such that previously permitted actions may now be denied. GEC operator review REQUIRED before upgrade. MINOR: New operative clauses added. Previously permitted actions unaffected. GEC operator review RECOMMENDED. PATCH: Metadata updates only. No change to Cedar output. Automatic upgrade PERMITTED. 8.3. Update Notification On new package version publication, the CMR sends a signed Update Notification to all registered GEC subscribers: { "package_id": "eu.gdpr.2016/679", "new_version": "2.2.0", "change_type": "MINOR", "changed_records":["eu.gdpr.2016_679.art6"], "change_summary": "Updated to reflect EDPB Guidelines 05/2026", "effective_by": "2026-09-01T00:00:00Z" } 8.4. GEC Update Response Options ACCEPT: Apply the update automatically. Permitted for PATCH. RECOMMENDED for MINOR with standing regulatory currency policy. REVIEW_AND_APPROVE: Queue for operator review. Required for MAJOR changes. PIN: Pin to current version with declared expiry. CMR MUST be notified. GEC MUST refuse the pinned version after expiry. (NEW in -02: Section 8.4 now cross-references Section 10 (Statute-Primacy Rule) as the normative specification for how GECs respond to catalog updates that trigger CATALOG_VERSION_ CONFLICT or INTERPRETATION_SUPERSEDED events. The four-phase propagation workflow (Detection, Suspension, Re-publication, Re-activation) specified in [I-D.sato-soos-cap] Section 8.9 applies to all CAP-RRS catalog updates.) CONF-CAP02-REG-01: A GEC MUST NOT operate on a Regulation Record package that has reached certification_expiry without renewal or replacement. CONF-CAP02-REG-02: A GEC MUST surface MAJOR version Update Notifications to the operator within 24 hours of receipt. (RECONSTRUCTED in -03: base text above is carried forward from draft-sato-soos-cap-rrs-01 Section 8; the -02 addition to Section 8.4 is applied inline, unchanged. -02 carried only a bracket placeholder for all of Sections 5 through 8, with none of the Cedar Compilation Profile, Conflict Declaration Model, Certification Model, or CMR Protocol actually present.) 9. Law Reference Interface (LRI) (NEW in -02) 9.1. Purpose and Design Rationale Every Regulation Record encodes a specific statutory provision. That encoding is a legal act -- the endorsing authority certifies that the Cedar policy correctly represents the operative clause as the authority interprets it under the statutory version current at endorsement time. Without a normative interface for this provenance, a Regulation Record is a policy with a human-readable citation but no machine- readable link to the living statutory text. When the law changes, nothing in the Regulation Record schema (Sections 4-8) provides a mechanism to detect the change, suspend the affected Cedar policy, or verify the endorsement against the new version. The Law Reference Interface (LRI) fills this gap. The LRI is a jurisdiction-neutral generic interface that any national legal publication system can implement as an LRI Profile. Three profiles are defined in this document: Japan (e-LAWS) [ELAWS], EU (ELI) [ELI], and US (USLM) [USLM]. The LRI Profile approach parallels how OSCAL handles framework profiles: NIST 800-53 and ISO 27001 are OSCAL profiles of the same underlying OSCAL catalog format; e-LAWS, ELI, and USLM are LRI profiles of the same underlying LRI schema. 9.2. LRI Generic Schema Every Regulation Record for Tier 0, 1, or 2 MUST include an authority_source block conforming to this schema. Tier 3 resource policy records MAY omit authority_source. "authority_source": { "lri_version": "1.0", "profile": string, ; REQUIRED -- LRI ; profile URI "law_id": string, ; REQUIRED -- unique ; within profile "article_ref": string, ; REQUIRED -- resolvable ; within profile "version_identifier": string, ; REQUIRED -- statutory ; version "retrieved_at": string, ; REQUIRED -- ISO8601 ; timestamp "amendment_detection_ endpoint": string, ; REQUIRED -- URI "interpretation_endpoint": string, ; OPTIONAL -- URI | null; ; REQUIRED when ; resolution_basis is ; interpretive_ruling "endorsement": { "authority_id": string, ; REQUIRED -- URI "endorsed_at": string, ; REQUIRED -- ISO8601 "endorsement_scope": string, ; REQUIRED -- controlled ; vocab "resolution_basis": string, ; REQUIRED -- see S.9.4 "resolution_instrument_id": string, ; CONDITIONAL -- required ; when ; resolution_basis is ; interpretive_ruling "co_endorsement_required": boolean, ; REQUIRED "co_endorsement_quorum": string, ; CONDITIONAL -- required ; when ; co_endorsement_required ; is true. Values: ; "all" | "primary_only" "co_endorsers": string[],; CONDITIONAL -- array of ; authority_id URIs; ; REQUIRED when ; co_endorsement_required ; is true "endorsement_claim": string ; REQUIRED -- signed JWT } } 9.3. Five Normative LRI Requirements Every LRI Profile MUST define: LRI-1: How law_id uniquely identifies a law within the jurisdiction. Example (Japan): law_id maps to the e-LAWS law identifier (horei-ID) (e.g., "325AC0000000089"). LRI-2: How article_ref addresses a specific provision within that law. The article_ref MUST be resolvable against the profile's official law structure to a unique operative clause. Example (Japan): XPath 1.0 expression against XMLSchemaForJapaneseLaw_v3.xsd. LRI-3: How version_identifier captures the statutory version the Cedar policy was certified against. The version_identifier MUST be derivable from the amendment history of the law. Example (Japan): the PromulgationDate of the amendment in ISO8601 format. LRI-4: What amendment_detection_endpoint returns when queried with a since parameter. The response MUST enumerate all amendments with PromulgationDate or EnforcementDate posterior to the since value. LRI-5: Who may hold authority_id. The LRI Profile MUST specify the endorsement authority table: which authority class may sign endorsements for which category of law within the jurisdiction. 9.4. resolution_basis Controlled Vocabulary The resolution_basis field on the endorsement block records the legal character of the endorsement act. This field is REQUIRED. It affects which authority may endorse the record and what re-endorsement is required on amendment. +-----------------------------+------------------------------------+ | Value | Meaning | +-----------------------------+------------------------------------+ | statute_clear | The statutory text unambiguously | | | supports the Cedar policy. | | | Designated authority per LRI | | | Profile endorser table. | +-----------------------------+------------------------------------+ | interpretive_ruling | The Cedar policy is based on an | | | interpretive ruling, not clear | | | statutory text. Same authority | | | as statute_clear, but | | | resolution_instrument_id MUST be | | | populated with the ruling | | | instrument reference. | +-----------------------------+------------------------------------+ | internal_conflict_ | Two provisions of the same law | | resolution | conflict; one is chosen. Elevated | | | authority required (Cabinet Legal | | | equivalent for Japan; equivalent | | | legislative counsel body for | | | other jurisdictions). | +-----------------------------+------------------------------------+ | cross_statute_coordination | The Cedar policy spans two or more | | | statutes. co_endorsement_required | | | MUST be true. co_endorsement_ | | | quorum MUST be "all". All | | | co-endorsers must re-endorse on | | | any amendment to any statute in | | | scope. | +-----------------------------+------------------------------------+ Table 1: resolution_basis Controlled Vocabulary 9.5. Co-Endorsement Model A Regulation Record may require endorsement from more than one legally distinct authority. This arises when the Cedar policy encodes a coordination rule that spans authority chains -- for example, when disaster response protocols require coordination between prefectural and municipal command authorities, each operating under different statutory frameworks. When co_endorsement_required is true: (a) co_endorsers MUST list the authority_id URI of every required co-endorsing authority. (b) co_endorsement_quorum MUST be specified. "all" means every co-endorser must endorse before the Cedar policy is active. "primary_only" means the primary authority_id endorsement is sufficient (co-endorsers are advisory only). (c) The Cedar policy MUST NOT be loaded into the GEC's active policy set unless all co-endorsements required by the quorum rule are present and valid. (d) If any co-endorser's endorsement_claim is superseded, expires, or is revoked, the Cedar policy MUST be suspended per the Statute-Primacy Rule (Section 10), regardless of the status of other co-endorsers' endorsements. CONF-RRS-COEND-01: A GEC MUST NOT activate a Cedar policy with co_endorsement_required: true unless all required endorsements (per the quorum rule) are present and their endorsement_claims are verifiable. 9.6. interpretation_endpoint The interpretation_endpoint is an OPTIONAL LRI field that identifies the URI to query for interpretive rulings that may affect the endorsement's resolution_basis. This field is REQUIRED (even if its value is null) when the Regulation Record's resolution_basis is interpretive_ruling or when the LRI Profile specifies that interpretive rulings are machine-queryable for the jurisdiction. When non-null, the GEC MUST poll interpretation_endpoint at a cadence not exceeding 24 hours per Section 11.2. The endpoint MUST return interpretive instruments (rulings, administrative guidance, court judgments) with an effective_date and a reference to the prior interpretation they supersede. 9.7. LRI Profile URI Registry This document establishes the IANA "CAP-RRS LRI Profile URI" registry at: https://www.iana.org/assignments/cap-rrs-lri-profiles Registration procedure: Specification Required. Initial values: +---------+-------------------------------------------+----------+ | Juris. | Profile URI | System | +---------+-------------------------------------------+----------+ | Japan | https://laws.e-gov.go.jp/lri/v1 | e-LAWS | | | | XML v3 | | EU | http://data.europa.eu/eli/lri/v1 | ELI | | US | https://uscode.house.gov/lri/v1 | USLM | +---------+-------------------------------------------+----------+ Table 2: Initial LRI Profile Registry 10. Statute-Primacy Rule (NEW in -02) 10.1. Normative Rule Text Statute-Primacy Rule. A CAP-RRS catalog entry's Cedar policy derives its enforcement authority exclusively from the endorsement claim in its authority_source block. The endorsed_at timestamp establishes the version of the statutory text the Cedar policy was certified against. If the law_id and article_ref referenced in authority_source resolves -- via the profile's amendment_detection_endpoint -- to a statutory text whose amendment history contains any amendment with PromulgationDate or EnforcementDate posterior to endorsed_at, the following consequences apply automatically: (1) Provisional suspension. The Cedar policy is suspended for new agent actions. Ongoing actions already authorized under a valid SACR may complete. No new SACR may be issued citing the suspended catalog entry. The GEC MUST return SUSPENDED per [I-D.sato-soos-cap] Section 6.3. (2) CATALOG_VERSION_CONFLICT event. The GEC MUST raise a GAR event of type CATALOG_VERSION_CONFLICT per Section 10.2. (3) HEM escalation. The conflict is escalated to the designated human operator via HEM. No agent may act under the affected prohibition until one of: (a) re-endorsement by the designated authority, or (b) explicit human override logged in GAR with operator identity and stated rationale. Statute primacy is absolute. A Cedar policy does not override a statute. A GAR audit record whose authority_source traces to a superseded statutory version is valid as a historical record but does not constitute legal authorization for future actions. Re-endorsement authority depends on the resolution_basis of the original catalog entry per Table 1 (Section 9.4): statute_clear: Designated authority per the LRI Profile endorser table. interpretive_ruling: Same authority plus updated resolution_instrument_id. internal_conflict_resolution: Elevated authority (Cabinet Legal Affairs Bureau or equivalent). cross_statute_coordination: All co-endorsers must re-endorse. 10.2. CATALOG_VERSION_CONFLICT Event Schema The GEC MUST record a CATALOG_VERSION_CONFLICT event in GAR when an amendment posterior to endorsed_at is detected. { "event_type": "CATALOG_VERSION_CONFLICT", "catalog_entry_id": string, ; REQUIRED "authority_source_profile": string, ; LRI profile URI "authority_source_law_id": string, "authority_source_article_ref": string, "endorsed_at": string, ; ISO8601 "conflicting_amendment_ promulgation_date": string, ; ISO8601 date "conflict_delta_days": integer,; days between ; endorsed_at and ; amendment date "suspension_effective_at": string, ; ISO8601 timestamp "hem_escalation_id": string } 10.2.1. CATALOG_VERSION_CONFLICT_RESOLVED Event Schema (NEW in -03) (CORRECTED in -03: -02's schema for Section 10.2 specified a "resolution" field that started null at event creation and was later "populated on re-endorsement or human override" -- an in-place mutation of a GAR entry already committed to the append-only Event Log. This is the literal root specification of the same Direct Conflict pattern subsequently found implementing exactly this schema in [I-D.sato-soos-gar] Section 12.17(c) (ALE-NEW-03) and [I-D.sato-soos-cap] Section 8.9.4 Phase 4 step (5) -- both downstream documents describe correctly what this schema specifies incorrectly. The fix belongs here, at the schema's origin, and propagates outward: resolution is now a separate, causally-linked event rather than a mutated field.) The GEC MUST record a CATALOG_VERSION_CONFLICT_RESOLVED event in GAR when a suspended catalog entry is resolved via re-endorsement or human override. This event MUST NOT modify the original CATALOG_VERSION_CONFLICT event in any way; the original entry remains exactly as committed. { "event_type": "CATALOG_VERSION_CONFLICT_RESOLVED", "resolves_event_id": string, ; REQUIRED. entry_id of the ; original CATALOG_VERSION_ ; CONFLICT event this ; resolves. "type": string, ; "re_endorsement" | ; "human_override" "resolved_at": string, ; ISO8601 timestamp "resolved_by": string, ; operator KIA or ; authority_id URI "new_endorsed_at": string, ; ISO8601 timestamp "rationale": string ; REQUIRED for human_override } 10.3. INTERPRETATION_SUPERSEDED Event Schema The GEC MUST record an INTERPRETATION_SUPERSEDED event in GAR when an interpretive ruling supersedes the resolution_basis of a Regulation Record's endorsement, without any change to the underlying statutory text. INTERPRETATION_SUPERSEDED is distinct from CATALOG_VERSION_ CONFLICT. CATALOG_VERSION_CONFLICT is triggered by statutory amendment (the law text changes). INTERPRETATION_SUPERSEDED is triggered by interpretive change (the law text is unchanged but the authoritative interpretation changes). The consequences are identical -- provisional suspension, GAR event, HEM escalation -- but the required re-endorsement authority differs: an interpretive change routes to the authority that issued the superseded ruling, not necessarily the primary statutory authority. { "event_type": "INTERPRETATION_SUPERSEDED", "catalog_entry_id": string, "authority_source_profile": string, "authority_source_law_id": string, "authority_source_article_ref": string, "endorsed_at": string, ; ISO8601 "superseding_interpretation": { "issuing_authority": string, ; URI "instrument_type": string, ; "cabinet_order" | ; "ministerial_guidance" ; | "court_judgment" | ; "ietf_interpretation" "instrument_id": string, "effective_date": string, ; ISO8601 date "prior_interpretation_id":string ; id of superseded ; interpretation }, "suspension_effective_at": string, ; ISO8601 timestamp "hem_escalation_id": string } 10.3.1. INTERPRETATION_SUPERSEDED_RESOLVED Event Schema (NEW in -03) (CORRECTED in -03: same fix as Section 10.2.1, applied to the parallel schema.) The GEC MUST record an INTERPRETATION_SUPERSEDED_RESOLVED event in GAR when a suspended catalog entry under this event type is resolved. This event MUST NOT modify the original INTERPRETATION_SUPERSEDED event. { "event_type": "INTERPRETATION_SUPERSEDED_RESOLVED", "resolves_event_id": string, ; REQUIRED. entry_id of the ; original INTERPRETATION_ ; SUPERSEDED event this ; resolves. "type": string, ; "re_endorsement" | ; "human_override" "resolved_at": string, ; ISO8601 timestamp "resolved_by": string, ; operator KIA or ; authority_id URI "new_endorsed_at": string, ; ISO8601 timestamp "rationale": string ; REQUIRED for human_override } 10.4. Safe Harbor Clause Agent actions taken under a valid, non-superseded endorsement at the time of action are shielded from retroactive liability. The GAR audit record of the action is the machine-native safe-harbor instrument. The GAR record of any agent action governed by a Regulation Record MUST carry three fields that together constitute the safe harbor evidence: (a) endorsed_at: the timestamp of the endorsement that governed the action at the time it was taken. (b) prior_interpretation_id: the resolution_instrument_id of the then-authoritative interpretation, when resolution_basis is interpretive_ruling. (c) suspension_effective_at (from the INTERPRETATION_SUPERSEDED or CATALOG_VERSION_CONFLICT event that followed): the timestamp at which the subsequent change took effect. The combination of fields (a) and (c) establishes that the action was taken under a valid, non-superseded endorsement: endorsed_at is anterior to suspension_effective_at. Past actions are protected; future actions require re-endorsement. When an interpretation changes, agent actions taken under the prior interpretation are protected by the GAR audit record. The code automatically lapses, but the legitimacy of past actions is secured by the audit chain. 10.5. catalog_version Object Schema All distributed catalog updates MUST carry a catalog_version object. The catalog_version object MUST be present at the top level of every CMR package release. "catalog_version": { "version_id": string, ; REQUIRED -- semver or opaque ; string, unique within catalog "effective_date": string, ; REQUIRED -- ISO8601 date "supersedes": string, ; REQUIRED -- version_id of ; previous version, or null "amendment_basis": string, ; REQUIRED -- law amendment ; instrument ID that triggered ; this version "published_by": string, ; REQUIRED -- URI; MUST match ; endorsement.authority_id "published_at": string ; REQUIRED -- ISO8601 timestamp } A GEC MUST reject a catalog update where: (a) catalog_version is absent. (b) supersedes does not match the currently active version_id for this catalog entry. (c) effective_date is earlier than the currently active effective_date (rollback attack defense). (d) published_by does not match the endorsement.authority_id in the updated entry. 11. Operational Requirements (NEW in -02) 11.1. Amendment Detection Cadence A SOOS-compliant CAP-RRS catalog implementation MUST poll the amendment_detection_endpoint of each active authority_source at a cadence not exceeding 24 hours. On detection of a new amendment whose PromulgationDate or EnforcementDate is posterior to endorsed_at: CATALOG_VERSION_ CONFLICT MUST be raised immediately, without waiting for the next polling interval or for human confirmation. The detection mechanism is: query amendment_detection_endpoint with a since parameter equal to endorsed_at; if any amendment is returned, the conflict exists. Implementations MAY use push notification mechanisms (webhooks, event subscriptions) in addition to polling, provided the maximum detection latency does not exceed 24 hours. 11.2. Interpretation Detection Cadence When interpretation_endpoint is non-null, a SOOS-compliant CAP-RRS catalog implementation MUST poll interpretation_endpoint at a cadence not exceeding 24 hours. On detection of a new interpretive ruling whose effective_date is posterior to endorsed_at and which references the same law_id and article_ref: INTERPRETATION_SUPERSEDED MUST be raised immediately. This requirement is parallel to the amendment detection requirement and uses the same timing guarantee: maximum 24 hours from interpretive ruling publication to detection and suspension. 11.3. Maximum Suspension Window A GEC MUST NOT leave a Cedar policy in SUSPENDED state for more than 30 days without either: (a) A valid updated catalog entry received from the designated re-endorsement authority, or (b) A human override logged in GAR with operator identity and stated rationale. After 30 days in SUSPENDED state without (a) or (b), the GEC MUST treat the suspended policy as DENY for all new actions. The GEC MUST notify the operator and generate a CRITICAL Audit Alert per [I-D.sato-soos-gar] before converting SUSPENDED to DENY. This cross-references [I-D.sato-soos-cap] Section 8.9.4, which specifies the same 30-day maximum from the CAP perspective. 11.4. authority_source_uri Mandatory Field The authority_source_uri field in the Regulation Record schema (Section 4.1) is REQUIRED for all Regulation Records. This field was OPTIONAL in -01; it is REQUIRED in -02. For Japan jurisdiction implementations, the RECOMMENDED format for authority_source_uri is the e-Gov URI with article XPath: https://elaws.e-gov.go.jp/document?lawid={law_id}#{article_xpath} Example: https://elaws.e-gov.go.jp/document?lawid=415AC0000000057# /Law/LawBody/MainProvision/Article[@Num='17'] The authority_source_uri MUST be the same URI as the soos.cap.authority_source_uri OTel span attribute emitted by the GEC at Cedar evaluation time per [I-D.sato-soos-cap] Section 13.5. A mismatch between these two values constitutes a PTD inconsistency under [I-D.sato-soos-cap] Section 12a.6. 12. HEM Integration 12.1. HEM_TIER3_ANTICIPATORY (Class 8) Trigger: Before beginning a multi-step mission, the GEC determines that total estimated resource cost exceeds remaining budget under any active Tier 3 resource policy with anticipatory_assessment: true. The GEC MUST: (a) Halt mission execution before any step begins. (b) Construct an Execution Options Package (Section 9.3). (c) Route to the human principal designation chain with urgency STANDARD. (d) Await human decision before proceeding. Human decision types for Class 8: APPROVE_WITH_CONSTRAINTS: Scope reduction -- proceed to a named Natural Breakpoint only. APPROVE_WITH_PAYMENT: Commercial upgrade -- proceed with full mission after upgrade confirmation. DEFER: Temporal deferral -- await budget reset. DENY: Do not begin mission. 12.2. HEM_TIER3_OBSERVED (Class 9) Trigger: During mission execution, resource consumption reaches warning_threshold_pct in the active Tier 3 policy. The GEC MUST: (a) NOT halt execution immediately. (b) Identify the next Natural Breakpoint. (c) Construct an Execution Options Package for remaining mission. (d) Route to the human principal with urgency ELEVATED. (e) Commit to completing to the next Natural Breakpoint before stopping, regardless of human response timing. 12.3. Execution Options Package Carried in HEM escalation requests for Class 8 and 9: { "full_mission_viable": boolean, "budget_available": integer, "budget_required": integer, "shortfall": integer, "natural_breakpoints": [ { "breakpoint_id": string, "description": string, "cost_to_reach": integer, "viable": boolean, "value_delivered": string } ], "recourse_options": [ { "option_id": string, "type": string, "description": string, "viable": boolean, "cost": integer or null, "upgrade_url": string or null, "reset_at": string or null } ], "recommended_option": string } Example for "research, write report, send emails to all clients" with 45,000 tokens remaining and 95,000 required: natural_breakpoints: BP-1: Research complete. cost: 40,000. viable: true. value_delivered: "Research findings." BP-2: Report complete. cost: 60,000. viable: false. value_delivered: "Complete report." BP-3: Full mission. cost: 95,000. viable: false. value_delivered: "Research + report + emails." recourse_options: RO-1: SCOPE_REDUCTION. Proceed to BP-1 only. viable: true. cost: 40,000. RO-2: COMMERCIAL_UPGRADE. Upgrade to proceed in full. viable: true. upgrade_url: "..." RO-3: TEMPORAL_DEFERRAL. Budget resets in 6 hours. viable: true. reset_at: "2026-05-30T06:00:00Z" recommended_option: "RO-1" 12.4. Natural Breakpoint Declaration Agents operating under a resource policy with natural_ breakpoint_required: true MUST declare Natural Breakpoints at the PLAN step of the AEP execution loop before beginning multi-step mission execution. A Natural Breakpoint is a point at which stopping produces a coherent, complete deliverable of independent value. CONF-CAP02-HEM-01: A GEC implementing Tier 3 resource policies with natural_breakpoint_required: true MUST refuse to begin multi-step mission execution without a Natural Breakpoint declaration from the agent. CONF-CAP02-HEM-02: A GEC MUST NOT stop a mission mid-task on a Tier 3 resource limit when a Natural Breakpoint declaration is registered. The GEC MUST complete to the next declared Natural Breakpoint before enforcing the limit. (RECONSTRUCTED in -03: Sections 12.1 through 12.4 above are the actual text carried forward from draft-sato-soos-cap-rrs-01 Section 9.1-9.4, renumbered 9.x -> 12.x per -02's own numbering note -- -02 carried only the subsection headers with no body text at all, including the Execution Options Package schema and the CONF-CAP02-HEM-01/02 Natural Breakpoint requirements.) 13. Open Issues 13.1. Pattern-Before-Threshold (OQ-CAP-PATTERN) Detecting a prohibited pattern before any individual observation crosses the confidence threshold is not fully specified. The typology_match_id field provides partial support, but Cedar policy evaluation over event stream trajectories requires formal verification methods not yet specified. Deferred to a successor document. 13.2. Cross-Jurisdiction Tier 1 Compilation (OQ-CAP-XJURIS) When a single agent session spans multiple jurisdictions, the mechanism for selecting the correct jurisdiction-specific record at Cedar evaluation time is not yet specified. The jurisdiction_scope field provides the metadata; the runtime selection algorithm requires further specification. 13.3. Japan Interpretation Registry (JP-OQ-03, JP-OQ-04) The Japan profile requires a machine-queryable interpretation registry for Cabinet Orders, interpretive guidelines (kaisyaku-shishin), and Cabinet Legal Affairs Bureau opinions (CLB-iken). The current e-LAWS API v2 does not expose interpretive instruments. A provisional SOOS-operated registry has been scoped. The Digital Agency has been identified as the target for a native capability. Formal specification deferred to the Japan LRI profile document (draft-sato-soos-cap-rrs-jp-00, post-Vienna). 13.4. Co-Endorsement Authority for Cross-Prefectural Rules (JP-OQ-01) For Japan cross-statute coordination rules spanning prefectural governor (todofuken-chiji) authority, the question of whether individual governors or the National Governors' Association (Zenkoku Chiji-kai) provides the standing endorsement is unresolved. Deferred to the Japan LRI profile document. 14. Security Considerations Regulation Record integrity: Regulation Records are signed by the issuing authority. An implementation MUST verify the endorsement_claim signature on every package load. The CMR MUST support keypair rotation with a defined transition period. LRI amendment signal injection: (NEW in -02) An adversarial actor may attempt to inject false amendment detection signals via the amendment_detection_endpoint to force Cedar policies into SUSPENDED state without a real statutory change. GEC implementations MUST authenticate the source of amendment detection signals and MUST NOT enter SUSPENDED state on an unauthenticated signal. For registered LRI profiles, the amendment_detection_endpoint is the jurisdiction's official government URI; GEC implementations MUST verify TLS certificate chains to the government CA for these endpoints. Catalog version rollback: (NEW in -02) An attacker with access to the catalog update channel may attempt to re-publish an older catalog version with a lower restriction level. The GEC MUST reject any catalog update where catalog_version.supersedes does not match the currently active version_id, and MUST reject updates with an effective_date earlier than the currently active effective_date (see Section 10.5 conformance requirements). interpretation_endpoint authenticity: (NEW in -02) The interpretation_endpoint is a new external dependency. Implementations MUST verify interpretation_endpoint TLS certificate chains before processing returned interpretive instruments. For the provisional SOOS-operated Japan interpretation registry, implementations MUST verify the SOOS project's certificate and SHOULD pin it. Co-endorsement bypass: (NEW in -02) An attacker may attempt to activate a co-endorsement-required Cedar policy with only a subset of required endorsements. CONF-RRS-COEND-01 is the normative defense: a GEC MUST NOT activate such a policy unless all required endorsements are present and verifiable. Cedar Compilation Profile determinism: The determinism requirement (Section 5.1) is a security property: it ensures that a certified Regulation Record produces identical Cedar across all conforming compiler implementations. Agent Session Revocation: When an agent session is revoked, all CAP-RRS compiler operations and CMR update processing MUST cease. All pending HEM escalations (HEM_TIER3_ANTICIPATORY, HEM_TIER3_OBSERVED) at point of revocation MUST be finalized with completion_state PARTIAL or CLEAN per [I-D.sato-soos-mad] Section 3.6.3. 15. Privacy Considerations Regulation Records do not contain personal data. The GEC audit records produced on DENY events carry the record_id of the firing Regulation Record as metadata only. The CATALOG_VERSION_CONFLICT and INTERPRETATION_SUPERSEDED GAR events carry law identifiers and endorsement timestamps but no personal data. 16. IANA Considerations 16.1. CAP-RRS LRI Profile URI Registry (NEW in -02) This document establishes the "CAP-RRS LRI Profile URI" registry maintained at: https://www.iana.org/assignments/cap-rrs-lri-profiles Registration procedure: Specification Required. Initial values: per Table 2 (Section 9.7). 16.2. CAP-RRS Media Types IANA is requested to maintain: application/cap-regulation-record+json Regulation Record conforming to Section 4. application/cap-rrs-catalog-version+json (NEW in -02) catalog_version object conforming to Section 10.5. 16.3. CAP-RRS GAR Event Types (NEW in -02) This document registers the following GAR event types in the SOOS ALE registry defined in [I-D.sato-soos-gar]: +-------------------------------+------------------------+------+ | Event Type | Trigger | Sec. | +-------------------------------+------------------------+------+ | CATALOG_VERSION_CONFLICT | Statutory amendment | 10.2 | | | posterior to | | | | endorsed_at detected | | | INTERPRETATION_SUPERSEDED | Interpretive ruling | 10.3 | | | supersedes resolution_ | | | | basis without | | | | statutory change | | +-------------------------------+------------------------+------+ Table 3: New CAP-RRS GAR Event Types 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. [I-D.sato-soos-cap] Sato, T., "Constitutional AI Protocol (CAP)", Work in Progress, Internet-Draft, draft-sato-soos-cap-05, August 2026, . [I-D.sato-soos-hem] Sato, T., "Human Escalation Mechanism (HEM)", Work in Progress, Internet-Draft, draft-sato-soos-hem-06, August 2026, . [I-D.sato-soos-idp] Sato, T., "Intent Declaration Primitive (IDP)", Work in Progress, Internet-Draft, draft-sato-soos-idp-05, June 2026. [I-D.sato-soos-gar] Sato, T., "Governance Audit Record (GAR)", Work in Progress, Internet-Draft, draft-sato-soos-gar-07, September 2026. [I-D.sato-soos-mad] Sato, T., "Multi-Agent Delegation (MAD)", Work in Progress, Internet-Draft, draft-sato-soos-mad-04, August 2026. [SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0", 2013, . 17.2. Informative References [I-D.sato-soos-aep] Sato, T., "Agent Execution Protocol (AEP)", Work in Progress, Internet-Draft, draft-sato-soos-aep-03, August 2026. [I-D.sato-soos-kia] Sato, T., "Kernel Identity and Attestation (KIA)", Work in Progress, Internet-Draft, draft-sato-soos-kia-06, August 2026. [ROME_STATUTE] United Nations, "Rome Statute of the International Criminal Court", 17 July 1998, 2187 UNTS 90. [GDPR] European Parliament and Council, "Regulation (EU) 2016/679", 27 April 2016, OJ L 119/1. [BSA] United States Congress, "Bank Secrecy Act", 31 U.S.C. 5318(g), 1970. [CEDAR] Amazon Web Services, "Cedar Policy Language Reference", 2023, . [ELAWS] Japan Ministry of Internal Affairs and Communications / Digital Agency, "e-LAWS Law Database", . [ELI] Publications Office of the European Union, "European Legislation Identifier (ELI)", . [USLM] United States Office of the Law Revision Counsel, "United States Legislative Markup (USLM)", . Acknowledgments The Regulation Record schema, Cedar Compilation Profile, and Constitutional Mandate Registry concept emerged from SOOS KernelSpec V3 development sessions in May 2026. The Law Reference Interface generic model, Statute-Primacy Rule, and Operational Requirements (Sections 9-11) emerged from sessions in June 2026 analyzing real disaster-response (bousai) statutory conflicts in the e-LAWS corpus and the interpretive authority question identified in the AI Regulatory Reform Council Discussion Paper (Themes 21 and 22). The positioning (Law AX creates laws that can be read; SOOS creates laws that are enforced) derives from those sessions. CAP-RRS is a companion document to CAP [I-D.sato-soos-cap]; it does not revise or supersede it. Appendix A. Japan e-LAWS LRI Profile Notes This appendix documents provisional Japan profile bindings. The normative Japan LRI Profile will be specified in a separate informational document (draft-sato-soos-cap-rrs-jp-00, post-Vienna). The content here is informative. A.1. law_id Binding law_id maps to the e-LAWS law identifier (horei-ID) (e.g., "325AC0000000089" for APPI). A.2. article_ref Binding article_ref is an XPath 1.0 expression against XMLSchemaForJapaneseLaw_v3.xsd. @Num attributes use Arabic numerals, not Japanese numerals. Where a prohibition derives from multiple articles, article_ref is an array. A.3. amendment_detection_endpoint https://laws.e-gov.go.jp/api/2/updatelawlists/{date} A.4. interpretation_endpoint (Provisional) https://clawed.soosproject.com/jp/interpretations/{law_id}/ {article_ref} This is a provisional SOOS-operated registry pending Digital Agency native capability. A.5. Endorsement Authority Table (Informative) +-------------------+--------------+------------------------------+ | Law tier | LawType | Designated endorser | +-------------------+--------------+------------------------------+ | Constitution | Constitution | Cabinet Legal Affairs Bureau | | Act (horitsu) | Act | Cabinet Legal Affairs Bureau | | Cabinet Order | CabinetOrder | Cabinet Legal Affairs Bureau | | Ministerial | Ministerial | Responsible ministry legal | | | | affairs division | | Ordinance (shourei)| Ordinance | | | Prefecture | Misc | Prefectural legal affairs | | Ordinance (jourei)| | | +-------------------+--------------+------------------------------+ Table A.1: Japan Endorsement Authority Table (Informative) Appendix B. Related Work B.1. Compliance Automation Approaches No existing IETF draft specifies a structured schema for representing legal compliance obligations as machine-compilable intermediate representations, a normative compilation profile from such a schema to a formal policy language, or a signed, versioned registry protocol for distributing certified compliance packages. CAP-RRS is the first document on IETF Datatracker to address this problem space. B.2. Relationship to CAP CAP [I-D.sato-soos-cap] specifies runtime enforcement. CAP-RRS specifies the governance of the policy corpus that CAP enforces. CAP receives the catalog_version schema (Section 10.5) and the four-phase propagation workflow as normative content; both documents are normatively coupled for these additions. B.3. Relationship to SCITT The Constitutional Mandate Registry (CMR) applies SCITT principles -- signed packages, append-only publication, versioned update notifications -- to compliance artifacts (Regulation Records) rather than software artifacts. B.4. Relationship to AIPREF AIPREF specifies preference and permission signals above the GEC. CAP-RRS specifies the compiled Cedar policy set below AIPREF. The two layers compose without conflict. B.5. Relationship to OSCAL (NEW in -02) OSCAL makes regulations machine-readable. CAP makes them machine-enforceable. CAP-RRS is the bridge: it consumes OSCAL-formatted regulation records as input to the Cedar Compilation Profile. SOOS is the first protocol suite designed to enforce OSCAL-expressed controls at AI agent runtime. The CAP-RRS LRI schema parallels how OSCAL handles framework profiles: jurisdiction-specific bindings (Japan e-LAWS, EU ELI, US USLM) are profiles of the same underlying LRI interface, just as NIST 800-53 and ISO 27001 are profiles of the same underlying OSCAL catalog format. CAP-RRS is the first IETF draft to bridge the OSCAL control catalog layer and the IETF enforcement layer. Author's Address Tom Sato MyAuberge K.K. Chino, Nagano Japan Email: tomsato@myauberge.jp URI: https://soosproject.ai/