SOOS Working Group T. Sato
Internet-Draft MyAuberge K.K.
Intended status: Standards Track 10 June 2026
Expires: 10 December 2026
Constitutional AI Protocol -- Regulation Record Specification (CAP-RRS)
draft-sato-soos-cap-rrs-01
Abstract
Compliance with applicable law should be a package import, not a
Cedar authoring problem.
The Constitutional AI Protocol (CAP) [I-D.sato-soos-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-01 specifies what the
Governing Enforcement Component (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 (Section 4), the
Cedar Compilation Profile that governs how Regulation Records are
translated into Cedar policies (Section 5), the conflict
declaration model (Section 6), the certification model governing
which publishers may certify records at each tier (Section 7),
and the versioning and update protocol for the Constitutional
Mandate Registry (Section 8).
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 10 December 2026.
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-01
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. HEM Integration
9.1. HEM_TIER3_ANTICIPATORY (Class 8)
9.2. HEM_TIER3_OBSERVED (Class 9)
9.3. Execution Options Package
9.4. Natural Breakpoint Declaration
10. Open Issues
11. Security Considerations
12. Privacy Considerations
13. IANA Considerations
14. References
14.1. Normative References
14.2. Informative References
Acknowledgments
Appendix B. Related Work
B.1. Compliance Automation Approaches
B.2. Relationship to CAP
B.3. Relationship to SCITT
B.4. Relationship to AIPREF
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-01 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-01). 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-01
CAP-01 [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-01 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-01; it extends it. A GEC implementing CAP-01 alone has a
governed enforcement engine whose policies are manually authored
and unverified. A GEC implementing CAP-01 and CAP-RRS has a
governed enforcement engine whose policies are registry-sourced,
certified, version-managed, and automatically updated.
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.
The relationship is analogous to the relationship between a
high-level programming language and its target instruction set.
Compliance specialists work at the Regulation Record level,
in structured JSON with legal vocabulary. The CAP-RRS compiler
translates Regulation Records into Cedar per the Cedar
Compilation Profile (Section 5). GEC implementations evaluate
the resulting Cedar at runtime per CAP-01. Each layer is owned
by the appropriate expert; no layer requires expertise in all
three domains.
Why Cedar and not another policy language: 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.
Cedar's open-source status and AWS stewardship make it
appropriate as a normative reference for an IETF standards-track
document.
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-01:
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 (Governing Enforcement Component):
The runtime component that enforces Cedar policies produced
by the CAP-RRS compiler. Defined in [I-D.sato-soos-cap].
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. Distinguished from
definitional, procedural, and enforcement provisions that
do not require Cedar representation.
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, BSA, HIPAA).
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). 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-01-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-01. The
developer observes ALLOW 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://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
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.
This recourse taxonomy is the clearest single articulation of
why tiers are structurally distinct: not merely by severity,
but by whether a governed path forward exists after DENY.
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.
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": "<Ed25519 sig base64url>"
},
"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": "<Ed25519 sig base64url>"
},
"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": "<Ed25519 sig base64url>"
},
"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": "<PENDING>"
},
"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": "<PENDING>"
},
"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": "<Ed25519 sig base64url>"
},
"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": "<Ed25519 sig base64url>"
},
"effective_date": "2026-05-01",
"review_trigger": [
"ACME pricing model update"
],
"record_version": "1.0.0"
}
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.
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].
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.
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": "<Ed25519 over canonical JSON>"
}
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.
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.
9. HEM Integration
9.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.
9.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.
9.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"
9.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.
10. Open Issues
10.1. Pattern-Before-Threshold (OQ-CAP-PATTERN)
Detecting a prohibited pattern before any individual
observation crosses the confidence threshold -- by reasoning
over a trajectory of observations -- 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.
10.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.
11. Security Considerations
Regulation Record integrity depends on publisher Ed25519
keypair security. Keypair compromise would allow injection
of fraudulent records. The CMR MUST support keypair rotation
with a defined transition period. GEC implementations MUST
verify record_signature on every package load.
The Cedar Compilation Profile 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
This document operates within the SOOS session lifecycle model.
When an agent session is revoked -- whether by operator action,
a CAEP session-revoked signal, or a CAP constitutional violation
-- this document's protocol obligations are superseded by the
MAD session revocation procedure [I-D.sato-soos-mad]
Section 3.6.6.
Implementations MUST NOT continue CAP-RRS compiler operations
or CMR update processing after receiving a session revocation
signal. All pending CAP-RRS-triggered 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, and committed to
the Event Log [I-D.sato-soos-gar] before the session closes.
12. 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.
13. IANA Considerations
IANA is requested to register the following media type:
application/cap-regulation-record+json
This media type identifies a Regulation Record conforming
to the schema defined in Section 4 of this document.
14. References
14.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-03, May 2026,
<https://datatracker.ietf.org/doc/draft-sato-soos-cap/>.
[I-D.sato-soos-hem]
Sato, T., "Human Escalation Mechanism (HEM)",
Work in Progress, Internet-Draft,
draft-sato-soos-hem-04, May 2026,
<https://datatracker.ietf.org/doc/draft-sato-soos-hem/>.
[I-D.sato-soos-idp]
Sato, T., "Intent Declaration Primitive (IDP)",
Work in Progress, Internet-Draft,
draft-sato-soos-idp-04, May 2026.
[I-D.sato-soos-gar]
Sato, T., "Governance Audit Record (GAR)",
Work in Progress, Internet-Draft,
draft-sato-soos-gar-02, May 2026.
[SEMVER] Preston-Werner, T., "Semantic Versioning 2.0.0",
2013, <https://semver.org/>.
14.2. Informative References
[I-D.sato-soos-mad]
Sato, T., "Multi-Agent Delegation (MAD)",
Work in Progress, Internet-Draft,
draft-sato-soos-mad-02, May 2026.
[I-D.sato-soos-aep]
Sato, T., "Agent Execution Protocol (AEP)",
Work in Progress, Internet-Draft,
draft-sato-soos-aep-01, June 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,
<https://docs.cedarpolicy.com/>.
Acknowledgments
The Regulation Record schema, Cedar Compilation Profile,
and Constitutional Mandate Registry concept emerged from
SOOS KernelSpec V3 development sessions in May 2026.
The discussion of tier-specific recourse availability,
the compliance-as-package-management model, the
Natural Breakpoint Declaration, and the HEM_TIER3
trigger classes originated in those sessions.
CAP-RRS is a companion document to CAP-01
[I-D.sato-soos-cap]; it does not revise or supersede it.
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.
Existing approaches to AI compliance encoding are either
natural-language frameworks (EU AI Act conformance
declarations, model cards) or proprietary policy-as-code
systems that do not interoperate. Neither provides the
compilation determinism guarantee (Section 5.1) or the
certification chain (Section 7) that CAP-RRS specifies.
B.2. Relationship to CAP
CAP [I-D.sato-soos-cap] specifies runtime enforcement: what
the GEC does when a Cedar policy fires. CAP-RRS specifies
the governance of the policy corpus that CAP enforces. The
two documents are complementary layers. 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 an enforcement engine whose policies are
registry-sourced, certified, version-managed, and
automatically updated as law changes.
B.3. Relationship to SCITT
The SCITT (Supply Chain Integrity, Transparency and Trust)
architecture [draft-ietf-scitt-architecture] provides
transparency and integrity for software artifacts. The
Constitutional Mandate Registry (CMR) specified in Section 8
applies analogous principles -- signed packages, append-only
publication, versioned update notifications -- to compliance
artifacts (Regulation Records) rather than software artifacts.
CAP-RRS does not profile SCITT; the architectural parallel
is noted for the benefit of implementors familiar with SCITT.
B.4. Relationship to AIPREF
The AIPREF working group addresses AI preferences and
permissions at the model and service layer. CAP-RRS operates
at the governance kernel layer, below AIPREF: CAP-RRS
specifies the compiled Cedar policy set that the GEC enforces;
AIPREF specifies the preference and permission signals that
operators and users declare above the GEC. The two layers
compose without conflict.
Author's Address
Tom Sato
MyAuberge K.K.
Chino, Nagano
Japan
Email: tomsato@myauberge.jp