Governance: framework-mapping registry + generate_governance_report projection (AIGP / EU AI Act / GDPR / NIST / ISO 42001 / MRC / TAG / DBCFM)

[bokelley]

Draft WG Issue: Framework-mapping registry and governance-report projection

Suggested title: Governance: framework-mapping registry + generate_governance_report projection (AIGP / EU AI Act / GDPR / NIST AI RMF)

Suggested labels: governance, rfc-track, discussion

---

Background

A question raised in conversations with IAPP that doesn't have a clean answer in the spec today: how does a privacy/compliance professional verify an AdCP campaign against the frameworks they already use (AIGP, EU AI Act, GDPR, NIST AI RMF, ISO 42001, MRC, TAG, …)?

The audit trail exists today via get_plan_audit_logs (campaign governance, 3.0 experimental). What's missing is the projection from raw audit entries into per-requirement evidence checklists that an external compliance reviewer can act on.

This issue proposes:

1. A new sibling registry — static/registry/frameworks/ — for framework-mapping specs
2. An SDK helper generateGovernanceReport() that joins audit logs to a framework spec
3. A gap analysis of where the protocol does not yet carry the data a full AIGP/NIST projection would require

This is intentionally not an RFC. The mechanical pieces (framework registry, projection helper) are straightforward. The architectural pieces (agent self-declaration, consent context, lawful basis, incident hooks) need WG discussion before anyone commits to a spec.

What we have today

Framework requirement	AdCP surface
Audit logging (AI Act Art. 12, GDPR Art. 30)	get_plan_audit_logs.entries[], plan_hash (JCS-canonicalized)
Human oversight (AI Act Art. 14, GDPR Art. 22)	human_review_required, escalations[], drift_metrics
Special-category data (GDPR Art. 9, AI Act Art. 10)	10 restricted_attributes + signal declarations
Annex III high-risk verticals	eu_ai_act_annex_iii.json registry policy + 13 sibling regulations
Data subject contestation (Art. 13/22)	brand.data_subject_contestation
Oversight-erosion detection	drift_metrics (escalation rate, auto-approval rate, human override rate)

This is enough surface to support EU AI Act Annex III and GDPR Articles 9, 12, 13, 14, 22, 30 projections today.

Proposed: framework-mapping registry

static/registry/
  policies/          (existing — runtime enforcement)
  policy-categories/
  attributes/
  frameworks/        (new — post-hoc reporting checklists)
    eu_ai_act.json
    gdpr.json
    aigp.json        (IAPP partnership candidate)
    nist_ai_rmf.json
    iso_42001.json
    colorado_ai_act.json
    mrc.json
    tag.json
    dbcfm.json

Tier 1 frameworks (initial registry): EU AI Act, GDPR, AIGP, NIST AI RMF, ISO/IEC 42001, Colorado AI Act, MRC, TAG, DBCFM.

Tier 2 (defer to v2): CCPA/CPRA + state privacy bundle, WFA Global Media Charter, OECD AI Principles, UK GDPR, LGPD.

Each framework file declares versioned requirements:

{
  "framework_id": "eu_ai_act",
  "version": "1.0.0",
  "name": "EU AI Act (Regulation (EU) 2024/1689)",
  "requirements": [
    {
      "requirement_id": "art_14_human_oversight",
      "framework_section": "Art. 14",
      "requirement_text": "...",
      "protocol_scope": "in",
      "evidence_sources": [
        {"kind": "policy_evaluated", "policy_id": "eu_ai_act_annex_iii"},
        {"kind": "audit_entry", "query": {"type": "check", "mode": "advisory_with_human_review"}}
      ],
      "classifier": {"satisfied_when": "evidence.length > 0 AND drift_metrics.escalation_rate >= thresholds.escalation_rate_min"}
    }
  ]
}

Same publication bar as policies/ (versioned, sourced, exemplars required, CI-checked).

Bidirectional linking — framework_references[] on PolicyEntry

Today policy entries reference frameworks only in prose (eu_ai_act_annex_iii.json mentions Art. 10/12/13/14/22 in the policy body; us_fha_targeting.json cites 42 U.S.C. 3604(c) the same way). The PolicyEntry schema has no structured field for this.

If we add frameworks/ without back-references, the mapping drifts. Proposed addition to PolicyEntry:

{
  "policy_id": "eu_ai_act_annex_iii",
  // ...
  "framework_references": [
    {"framework_id": "eu_ai_act", "requirement_ids": ["art_10_data_governance", "art_12_logging", "art_14_human_oversight"]},
    {"framework_id": "gdpr", "requirement_ids": ["art_9_special_category", "art_22_automated_decisions"]}
  ]
}

CI gate: every framework_references entry resolves against an actual frameworks/*.json requirement; every framework requirement's evidence_sources resolves against an actual policies/*.json. The two registries cross-validate.

Side benefit: enables "what policies satisfy AIGP §4.2.1?" queries without grepping prose.

Proposed: generate_governance_report (SDK helper, not a protocol task)

Lives in @adcp/sdk and adcp Python. Takes (auditLog, frameworkId), returns:

{
  "framework": "eu_ai_act",
  "framework_version": "1.0.0",
  "plan_id": "...",
  "plan_hash": "...",
  "results": [
    {
      "requirement_id": "art_14_human_oversight",
      "status": "satisfied" | "partial" | "gap" | "not_applicable" | "out_of_protocol_scope",
      "evidence": [...],
      "narrative": "..."
    }
  ]
}

Why not a protocol task: the buyer already has the audit log, the framework spec is a static published artifact, and the join is local. Making it a task would force every governance agent to ship projection logic and re-deploy when frameworks version. SDK-side projection lets framework registry updates flow without agent redeploys.

Optional: AAO hosts the same code behind adcontextprotocol.org/governance-report for buyers who don't import the SDK.

Gap analysis — what we'd need to add for full AIGP/NIST coverage

The gaps below are blockers for AIGP §4 and NIST AI RMF Govern/Map/Measure/Manage projections, not for EU AI Act / GDPR.

Easy fixes (field additions)

Gap	Fix	Framework relevance
Lawful basis declaration	Add lawful_basis enum to sync_plans	GDPR Art. 6, AIGP §3
Consent context pass-through	Add consent_context block (TCF / GPP / GPC) to plan + check_governance	GDPR, ePrivacy, AIGP §3
Cross-border transfer declaration	Add data_transfers[] to plan or agent declaration	GDPR Ch. V, AIGP §4

Architectural (WG discussion needed)

Gap	Why it's architectural
Governance-agent self-declaration — model identity, training data, red-team artifacts, accountable contact	AIGP §4 and NIST AI RMF Govern/Map require the AI system to declare what it is. adagents.json says who an agent represents, not what it is. Same gap David Porzelt's DBCFM analysis hit from a different angle (German law: who's accountable). Probably needs a new agent.json or extension to adagents.json.
Incident / breach notification hook	No protocol event for "something went wrong, notify these parties." Required by GDPR Art. 33, NIST Manage. Would need a new event type and notification flow.
Bias / fairness testing artifacts	NIST AI RMF wants pointers to bias-testing results. Currently nothing. Probably stays out-of-protocol-scope but needs a declarative pointer field.
Lifecycle decommissioning	"Agent retired, what happens to plans?" — not in spec.

Two-track proposal

Track 1 — ship now (3.1 / 3.2):

• framework_references[] field on PolicyEntry + CI cross-validator
• static/registry/frameworks/: EU AI Act, GDPR, MRC, TAG, DBCFM (we already have most of the source material)
• generateGovernanceReport() SDK helper in @adcp/sdk and adcp Python
• Optional hosted renderer at AAO

Track 2 — spec work (3.2 / 3.3):

• Field additions: lawful_basis, consent_context, data_transfers[]
• Agent self-declaration spec (cross-references DBCFM accountability work, feat: structured business entity data for B2B invoicing #1605/feat: proposal lifecycle — draft/committed status, finalization, IO signing #1664)
• Incident notification hook
• Then: aigp.json, nist_ai_rmf.json, iso_42001.json, colorado_ai_act.json framework entries (AIGP partnership candidate)

Asks for WG

1. Concept ack: is frameworks/ the right home, or should this fold into policies/? (My read: separate — different lifecycle, many-to-many to policies, includes out-of-scope items.)
2. Agent self-declaration: appetite for adding this as a 3.2 item? Where does it live — extension to adagents.json, new agent.json, or a new task?
3. External partnerships: AIGP is IAPP's IP — joint authorship is an AAO-side decision, not WG, but flagging here so the WG sees the path. MRC and TAG mappings are similar (their checklists, our projection).

Related

• GDPR Article 22 explicit signaling for automated decisions #2394 — GDPR Art. 22 enforcement (this issue is the reporting counterpart)
• feat: structured business entity data for B2B invoicing #1605, feat: proposal lifecycle — draft/committed status, finalization, IO signing #1664 — DBCFM business entities / accountability
• static/registry/policies/eu_ai_act_annex_iii.json — already covers most of the runtime enforcement side
• skills/adcp-governance/SKILL.md — current campaign-governance task surface

[bokelley]

Triage

Classification: RFC / Proposal
Bucket: spec / protocol, governance, registry / discovery
Status: ready-for-human

What the experts said:

• ad-tech-protocol-expert: frameworks/ as a sibling to policies/ is architecturally correct — enforcement semantics ≠ reporting semantics; merging them pollutes governance-agent evaluation signals. framework_references[] on PolicyEntry is non-breaking (optional field; additionalProperties: false just needs an explicit property entry + a new governance_framework_requirement x-entity type). Track 1 can ship without WG sign-off. Track 2 (agent self-declaration, new schema fields) cannot. CI cross-validator: forward-reference integrity should hard-fail; orphan requirements (framework requirements with no policy match) should warn only, since some NIST AI RMF requirements are intentionally out-of-protocol-scope.
• adtech-product-expert: The central design question is whether the link is bidirectional (Option A) or unidirectional (Option B) — annotating existing registry entries with framework_references[] adds maintenance burden with no runtime enforcement benefit; a unidirectional cross-index keeps PolicyEntry schema-stable. Also: get_plan_audit_logs is experimental with no retention-period or chain-of-custody guarantee; DPOs will ask about this before trusting any compliance projection. AIGP/IAPP has IP encumbrances; validate the pattern with NIST AI RMF + GDPR first, then approach IAPP.

My take: Everything in Track 1 is non-breaking and executable once the A-vs-B linking direction is settled. Track 2 (agent self-declaration cross-referencing #1605/#1664 and #2854, lawful_basis, consent_context, data_transfers[]) needs WG discussion before any spec commitment.

The one design choice that blocks Track 1:

Option A — bidirectional (as proposed): PolicyEntry grows optional framework_references[]

// eu_ai_act_annex_iii.json — structured back-reference on policy entry
+ "framework_references": [
+   { "framework_id": "eu_ai_act", "requirement_ids": ["art_12_logging", "art_14_human_oversight"] },
+   { "framework_id": "gdpr",      "requirement_ids": ["art_22_automated_decisions"] }
+ ]

Enables "which policies satisfy AIGP §4.2.1?" reverse queries. CI enforces bidirectional integrity. Requires schema edit to policy-entry.json and propagating annotations to existing registry entries.

Option B — unidirectional cross-index: PolicyEntry schema unchanged

// frameworks/eu_ai_act.json — frameworks reference policies, not vice versa
{
  "requirement_id": "art_14_human_oversight",
  "evidence_sources": [
    { "kind": "policy_evaluated", "policy_id": "eu_ai_act_annex_iii" }
  ]
}

Zero migration burden on existing registry entries. Reverse lookup requires querying framework files. New frameworks ship without touching existing policies/*.json.

@bokelley, your call:

1. A or B for the linking direction?
2. SDK helper vs. hosted API vs. governance protocol task for generateGovernanceReport()? (A task model handles audit-trail write-back naturally — relevant for NIST AI RMF GV.6.1 and ISO 42001 §9.1 — but SDK placement avoids forcing governance-agent redeploys when framework registries version. Hosted API avoids both downsides but adds an infrastructure dependency.)

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code

[pkras]

thinking: Option A wins on a basis that this is not real-time. Governance checks are normally pre-campaign (a la plan approval) or post-campaign (audit/reporting).

[sangilish]

I think the most useful first slice is the evidence projection path, not a new protocol task.

A small Track 1 artifact could be:

1. start with EU AI Act + GDPR requirements that can already be evidenced from get_plan_audit_logs,
2. define the framework requirement rows and evidence-source selectors,
3. project a sample audit log into satisfied | partial | gap | not_applicable | out_of_protocol_scope,
4. explicitly mark gaps where AdCP does not yet carry enough evidence.

That keeps the reporting layer local/SDK-shaped, avoids forcing governance-agent redeploys for framework-version changes, and gives compliance reviewers a concrete output before Track 2 fields are decided.

[bokelley]

Yes, please go ahead with this slice.

Scope I’d like to preserve:

• start with EU AI Act + GDPR rows that current get_plan_audit_logs evidence can actually support,
• include a sample audit log input and projected output statuses,
• explicitly mark gap and out_of_protocol_scope rows,
• keep this local/SDK-shaped for now, not a new protocol task.

If this turns into actual committed frameworks/*.json registry files, we still need to settle the framework-to-policy linking direction. A doc/prototype can proceed before that.

[bokelley]

Triage — update

Classification: RFC / Proposal (doc/prototype slice)
Bucket(s): governance, registry / discovery
Status: ready-to-implement
Milestone: 3.2.0

Prior status was ready-for-human pending @bokelley's A/B call. @bokelley authorized on 2026-06-12: "go ahead with this slice… keep local/SDK-shaped… a doc/prototype can proceed before [linking direction is settled]." @pkras has already signalled Option A (2026-05-03).

My take: The EU AI Act + GDPR projection doc/prototype is non-breaking and fully executable with the existing protocol surface. Full framework registry files and SDK helper remain deferred until the A/B linking-direction call is confirmed.

Implementation brief:

• New docs/governance/compliance-projection.mdx (or docs/governance/framework-projection.mdx): one table per framework — EU AI Act Annex III + GDPR Arts 9/12/13/14/22/30 — mapping each requirement to the get_plan_audit_logs fields that carry evidence (entries[], plan_hash, human_review_required, escalations[], drift_metrics). Each row carries an explicit status column: satisfied / partial / gap / out_of_protocol_scope. Gap rows include a one-line narrative explaining what field addition would close them.
• Companion JSON sample in the doc: a representative get_plan_audit_logs response as input → projected output object matching the generateGovernanceReport() shape from the issue body. Shows a concrete gap row (e.g., lawful_basis absent) and an out_of_protocol_scope row (e.g., bias-testing artifacts).
• Draft prototype registry files static/registry/frameworks/eu_ai_act.json + gdpr.json marked "x-status": "draft" — illustrates the requirement/evidence-source/classifier shape without CI enforcement or PolicyEntry back-references. Back-references wait for A/B resolution.
• No PolicyEntry schema changes. No framework_references[]. Changeset: --empty.

Still deferred: framework_references[] on PolicyEntry (A/B pending), generateGovernanceReport() SDK code (lives in @adcp/sdk), Track 2 field additions (lawful_basis, consent_context, data_transfers[]), AIGP/NIST/ISO 42001/Colorado AI Act entries.

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code