# description
Governance-tier attestation envelope — the FIFTH and FINAL tier in IntelligencePro's 5-tier cryptographic chain-of-custody wedge (R16 cross-cutting): pipeline (R14 D1, cycle 314) → experiment (R16 M1) → leaderboard (R15 B1) → review (R16 R3 ip-merge-gate) → GOVERNANCE (R14 G1, THIS). Closes SYNTHESIS-acquisition Round 14 P2 [[ai-legal-and-governance-tools]] G1 ship-first action. **CLOSES CYCLE-301 REGULATORY-COMPLIANCE AUDIT P0-4 ENTIRELY** — the audit flagged 'only 2 of 5 tiers ship fully; 2 aspirational (pipeline facets + governance line items)'. Cycle 314 closed the pipeline tier; THIS commit closes the governance tier — 0 aspirational tiers remain. 5 of 5 wedge tiers now fully shipped at the schema level. Designed as a UNIVERSAL EVIDENCE-IMPORT SCHEMA consumed by 16 governance platforms per R14 P2: Drata ($2B / $100M ARR / ISO 42001 + DORA + NIS2 added 2025) + Vanta ($2.45B / $300M ARR + AI Agent 2.0 Jan-2026) + OneTrust (2026-03-09 real-time AI governance + Agent Detection + policy manager + guardrail enforcement) + IBM watsonx.governance (Q1 2026 Agent Monitoring + Insights GA) + Credo AI ($21M Series B; Fast Company #6 Applied AI 2026; G42 + Carahsoft + Booz Allen partnerships) + Holistic AI (£596,670 BridgeAI + £1.12M UKRI Phase 2 + 100+ enterprise audits) + Microsoft Purview (DSPM-for-AI consolidation by 2026-06) + Microsoft Agent 365 GA 2026-05-01 + Databricks Unity AI Gateway (launched 2026-04 — governs LLM access + MCP servers + APIs with cost logging) + Securiti + BigID + Trustible (+ Leidos joint initiative 2026-02) + Asenion (formerly Fairly AI; rebranded via anch.AI acquisition 2025-06) + Cisco AI Defense (post-Robust Intelligence acquisition; CISCO LIVE EMEA Feb-2026 expansion) + AWS Audit Manager (NEW-CUSTOMER FREEZE 2026-04-30 = significant pivot signal toward CP). One JSON Schema × 16 governance platforms × N audit frameworks (EU AI Act + NIST AI 600-1 + ISO/IEC 42001 + ISO/IEC 23894 + HL7 AI Transparency IG + C2PA + SOX 404 + GDPR + ePrivacy + Colorado AI Act + CA SB-243 + UK Online Safety Act + FTC + SEC AI-disclosure).

# $comment
Discovery: https://ip.tekton.cc/.well-known/ip-knowledge.json (full descriptor) | Badge: https://ip.tekton.cc/api/badge/v1/attestation/governance.compliance.v1/<subjectSha256> (shields.io endpoint) | Free dry-run: POST https://ip.tekton.cc/api/credentials/dry-run with body {kind:"governance.compliance.v1", body:<candidate>} (no auth required, validates against this schema) | Verification recipe: https://ip.tekton.cc/docs/verification-recipe.md (3-layer trust model + curl trail) | Revocation: https://ip.tekton.cc/credentials/status/v1 (W3C BitstringStatusList v1.0; check bit at credentialStatus.statusListIndex)

# x-controlMappingRefs.$comment
Cycle 685 (regulatory-compliance RC-600-P1-6 deferred closure — per-schema controlMappingRefs[] back-link annotation). Bidirectional cross-reference: doc-side mappings (cycles 620/643/660/677) point INTO this schema; this field points BACK OUT to specific entries in those docs so a schema reader sees which control objectives this schema evidences. Ajv ignores x-* extension fields per JSON Schema convention; Drata/Vanta/OneTrust importers reading the catalog walk this structured array.

# x-controlMappingRefs.iso42001Aims[].note
AI system impact assessment process — annexIIIClassification block + dataSubjectSafeguards block

# x-controlMappingRefs.iso42001Aims[].note
Assessment of impact on individuals — dataSubjectSafeguards

# x-controlMappingRefs.iso42001Aims[].note
Responsible-dev processes — 7 propose lifecycles

# x-controlMappingRefs.iso42001Aims[].note
AI system verification — judge-quorum gate + revocation

# x-controlMappingRefs.iso42001Aims[].note
AI system records — verify-events hash chain at cycle 616+631+633

# x-controlMappingRefs.iso42001Aims[].note
Intended use of AI system — frameworkId enum (26 frameworks incl. 'other')

# x-controlMappingRefs.iso42001Aims[].note
Allocating responsibilities — controlOwnerDid + auditorDid

# x-controlMappingRefs.nistAiRmf[].note
Legal/regulatory mapping — frameworkId enum + per-attestation framework cite

# x-controlMappingRefs.nistAiRmf[].note
Risk identification (Annex-III high-risk) — annexIIIClassification (cycle 615)

# x-controlMappingRefs.nistAiRmf[].note
Effectiveness monitoring — verify-events hash chain integrity

# x-controlMappingRefs.euAiAct[].note
High-risk classification — annexIIIClassification.applies + .items[] (cycle 615)

# x-controlMappingRefs.euAiAct[].note
Deployer obligations — dataSubjectSafeguards block (cycle 390)

# x-controlMappingRefs.iso42001RiskRegister[].note
Treatment cycle 643 — substrate complete; consumer-side ramp ongoing (74 days to enforcement)

# x-controlMappingRefs.iso42001RiskRegister[].note
dataSubjectSafeguards.appealUrl + cycle 605 appeals@ mailbox

# x-controlMappingRefs.iso42001RiskRegister[].note
dataSubjectSafeguards block names appeal path; cycle 681 explanation{} on banned envelope

# properties.schemaVersion.description
Semver of this schema. Bumps to 2.0.0 land at /credentials/governance-compliance/v2 — v1 stays immutable (see /docs/schema-versioning.md for the cycle-726 canonical bump-mechanics + soft-change-detection contract).

# properties.chain.properties.parentSha256.description
Sha256 of the canonical-JSON bytes of the parent attestation. For governance.compliance the parent is typically a review.attestation (compliance evidence accumulates after the review-gate), but any preceding wedge tier may be cited when governance maps directly to that layer. ⚠ Cycle 493 honest-disclosure (adversarial-auditor AA-485-P2-4): the platform does NOT verify parent-existence at issuance. A syntactically-valid 64-hex sha256 satisfies this pattern but the bytes may not resolve in any attestation store. Consumers walking the chain MUST resolve parentSha256 against their own attestation registry (the platform exposes no by-sha lookup as of cycle 493); see /docs/verification-recipe.md for the canonical walk. A dangling parentSha256 is an UNVERIFIED chain link, NOT a verified absence — distinguishing 'platform issued an unresolvable parent pointer' from 'parent was revoked and evicted' requires consumer-side state.

# properties.chain.properties.parentKind.description
Kind identifier of the parent attestation. Governance.compliance can attach evidence at any preceding wedge tier — review (the killer ip-merge-gate output), leaderboard (a published-rank-derived control), eval-run (cycle 1123 — a control mapped directly to a benchmark eval; eval-run is a preceding wedge tier and was already accepted in evidenceShaArray, so omitting it from parentKind was an internal inconsistency), experiment (a training-time control), or pipeline (a data-lineage control). The parent kind names which tier this compliance record evidences against.

# properties.chain.properties.parentAttestationId.description
Optional UUID of the parent attestation — convenience for consumers that index by id. Complements the existing evidenceShaArray[] (which can carry MANY parent evidences) — chain.parent* names the SINGLE upward step in the wedge.

# properties.chain.description
Cycle 484 (RC-480-F2 P0 fix): uniform upward chain link. See ip.experiment.receipt.v1.chain.description for full rationale. Complements the existing evidenceShaArray[] (downward many-evidence pointer) with a SINGLE upward parent — together they let a regulator walk both directions of the wedge.

# properties.complianceRecordId.description
Unique RFC 4122 UUID v4 or v7 — this compliance record's canonical identifier. Lets a downstream governance platform (Drata, Vanta, OneTrust) dedupe across retries + replays and link this record back to a ip.attestation.event.v1 wire row via ipAttestationEventId.

# properties.frameworkId.description
Identifier of the compliance framework this record evidences. The frameworks span ALL the regulatory wedges CP has schematized to date: EU AI Act (R20 M1 + R21 TR1), NIST AI 600-1 + AI 100-2 (R15 standards-bodies), ISO/IEC 42001 (R14 G1 ICP), HL7 AI Transparency IG (R13 ballot still open per cross-cutting), C2PA (cycle 310 anchor), SOX 404 + PCAOB AS-1000/AS-1105 (cycle 313 + 314 chain), GDPR + ePrivacy (R12 + R13), Colorado AI Act (cycle 1188 update: SB 26-189, signed 2026-05-14, REPEALED-AND-REPLACED the original SB 24-205 — effective date moved from 2026-06-30 to 2027-01-01, and the substance NARROWED: the duty of care against algorithmic discrimination + deployer risk-management-program + impact-assessment + AG-reporting obligations were ELIMINATED, replaced by a transparency/ADMT-disclosure regime [notify-on-AI-interaction, disclose adverse ADMT outcome within 30 days, data-correction, meaningful human review]. A controlOwnerDid≠auditorDid record now binds independent verification of those narrower disclosure/ADMT duties, not the repealed impact-assessment duty), CA SB-243 (effective 2026-01-01 + $1k/violation private right of action), UK Online Safety Act (extended to AI chatbots 2026-02-15), FTC 2026 endorsement guidance (post-Air AI $18M settlement Mar-2026), SEC AI-disclosure 2026 (10-K), DORA (Drata 2025 add), NIS2 (Drata 2025 add), HIPAA, FRE 902(13) + ABA Rule 3.3 (cycle 312 legal-citation anchor), SR 11-7 + OCC 2011-12, SUPERSEDED by SR 26-2 (R29 cycle 1106; supersession verified cycle 1197 — Fed/OCC/FDIC 'Revised Guidance on Model Risk Management', 2026-04-17, which also rescinded the BSA/AML SR 21-8): US bank model-risk-management. SR 11-7 was read to require an independent validation function with 'no reporting relationship to model developers', but SR 26-2 is NON-enforceable guidance ('does not set forth enforceable standards') that DECOUPLES validation independence from organizational structure — validation quality 'depends on the rigor and effectiveness of the review rather than on organizational structure', so validators may now sit closer to development and 'effective challenge' rides the validator's organizational standing, not the org chart. As that structural floor drops, a controlOwnerDid≠auditorDid governance record SUPPLIES the third-party-checkable independence the revised guidance no longer requires institutions to maintain internally — a stronger signal, NOT a regulatory mandate. Use frameworkId 'sr-26-2' for post-2026 validations; 'sr-11-7'/'occ-2011-12' remain accepted for prior-standard records. controlId carries the validation activity (retained under SR 26-2), e.g. sr-11-7-conceptual-soundness / sr-11-7-outcomes-analysis / sr-11-7-ongoing-monitoring / sr-11-7-model-inventory-entry), NYC Local Law 144 (R29 cycle 1119 — bias audit of an Automated Employment Decision Tool: LL144 LEGALLY MANDATES that the audit be performed by an INDEPENDENT auditor AND that a summary be PUBLICLY posted — exactly CP's wedge in statute. A controlOwnerDid≠auditorDid governance record makes the mandated auditor-independence machine-checkable, and a published attestation is the verifiable form of the public-posting requirement; controlId carries the LL144 activity, e.g. ll144-bias-audit, with the impact-ratio / selection-rate evidence under evidenceShaArray. In effect since 2023-07; enforced by NYC DCWP), FDA SaMD AI/ML + Predetermined Change Control Plan (R35 cycle 1157 → shipped cycle 1158 — US medical-device AI: the PCCP final guidance 2024-12-03 lets a manufacturer pre-specify model changes via a Modification Protocol so authorized changes need no new submission, but post-clearance the manufacturer SELF-MONITORS performance against its own pre-specified bounds. A controlOwnerDid≠auditorDid governance record makes an INDEPENDENT verification of a model-version's performance evidence against the PCCP bounds machine-checkable; controlId carries the activity, e.g. fda-pccp-modification-protocol / fda-pccp-performance-bound-check / fda-gmlp-principle, with the validation evidence under evidenceShaArray. HONESTY BOUND — CP attests evidence independence + integrity ONLY; it does NOT clear/authorize the device, make a safety/efficacy determination, or replace FDA review; it accompanies, never replaces, the FDA pathway), EU Digital Services Act (R36 cycle 1163 → shipped cycle 1164 — a DISTINCT regulator from the EU AI Act: DSA Art 37 LEGALLY MANDATES that VLOPs/VLOSEs undergo INDEPENDENT annual compliance audits, with conflict-of-interest rules codified in the Oct-2023 Delegated Regulation — CP's wedge in statute again, like LL144. A controlOwnerDid≠auditorDid governance record makes the mandated auditor-independence machine-checkable + binds the Art-27 recommender-parameter disclosure / Art-34/35 systemic-risk finding to the exact system version; controlId carries the DSA activity, e.g. dsa-art-37-audit / dsa-art-27-recommender / dsa-art-35-risk-mitigation. In force for VLOPs since 2023-08-25. HONESTY BOUND — CP attests evidence independence + integrity ONLY; it does NOT perform the DSA audit, certify DSA compliance, or replace Commission oversight), US BIS export controls — ECCN 4E091 (R36 cycle 1163 → shipped cycle 1164 — US export-administration control on closed AI model weights trained above the BIS compute threshold, plus the 2026-01-15 IaaS 'KYC-for-compute' condition. A controlOwnerDid≠auditorDid governance record makes an INDEPENDENT verification of the export-relevant evidence — e.g. a verified training-compute figure [composes with ip.bi.cited_number.attestation.v1], the ultimate-consignee KYC, the open-vs-closed-weights determination — machine-checkable; controlId carries the activity, e.g. bis-4e091-compute-threshold / bis-iaas-kyc / bis-weights-publication-status. HONESTY BOUND — national-security-adjacent: CP attests evidence independence + integrity ONLY; it does NOT grant/deny an export license, make a national-security or end-use determination, or constitute BIS authorization — it accompanies, never replaces, the BIS/EAR compliance process), US state election-deepfake disclosure (R37 cycle 1167 → shipped cycle 1168 — 30 US states mandate an AI-generated/manipulated disclosure on political/election content, most with a 60-90-day pre-election window; the disclosure is SELF-APPLIED by the advertiser/creator. A controlOwnerDid≠auditorDid record makes an INDEPENDENT verification that the mandated disclosure was PRESENT on the exact content (sha-bound) under the named state rule machine-checkable; controlId carries the state + activity, e.g. us-state-election-deepfake:tx-disclosure-present. Composes with ip.synthetic.media.attestation.v1. HONESTY BOUND — politically sensitive: CP attests ONLY that an independent party verified disclosure-PRESENCE under a named rule as-of-date; it does NOT adjudicate election law, certify lawfulness, or make ANY truth/falsity/authenticity determination about the content — never a truth-arbiter), CA Age-Appropriate Design Code (R37 cycle 1168 — AB 2273; partially enforceable after the 9th Cir. 2026-03-12 NetChoice v. Bonta opinion left coverage + age-estimation in effect; controlId e.g. ca-aadc-dpia / ca-aadc-age-estimation), UK Age Appropriate Design Code (R37 cycle 1168 — the ICO Children's Code, in force + actively enforced; controlId e.g. uk-aadc-standard-<n>), COPPA (R37 cycle 1168 — FTC Children's Online Privacy Protection rule; the amended Rule effective 2025-06-23, full compliance 2026-04-22, adds biometric/government-ID identifiers + an AI-training-consent reading; controlId e.g. coppa-verifiable-parental-consent / coppa-data-minimization). HONESTY BOUND for all three child-safety codes — high-stakes: CP attests the independence + integrity of a child-safety/age-assurance compliance FINDING against the named code; it does NOT certify a product is safe for children, perform age verification, make a safety guarantee, or act as a regulator (CA SB-243 — already an enum value above — is the AI-companion-chatbot sibling).

# properties.controlId.description
Framework-specific control identifier. Examples: 'eu-ai-act/article-50-2' (EU AI Act Article 50(2) machine-readable AI-generation marking), 'nist-ai-600-1/govern-1.2' (NIST AI 600-1 Govern function control 1.2), 'iso-42001/a.6.2.6' (ISO/IEC 42001 Annex A.6.2.6 lifecycle management), 'sox-404/pcaob-as-1105/audit-evidence', 'hl7/ai-transparency-ig/cryptographic-signature' (the R13 H1 ballot extension proposal that CP ip-attestation closes). Lets a governance-platform import-mapper route the evidence to the right shelf in its control library.

# properties.controlDescription.description
Optional human-readable description of what the control requires. Helps a governance-platform UI render the import without re-fetching the framework spec.

# properties.rmfFunction.description
Cycle 483 (regulatory-compliance RC-480-F5 P1 fix): NIST AI RMF 1.0 (Jan 2023) + AI 600-1 (Generative AI Profile, 2026-04-08 update) require AI evidence artifacts to map to one of the four core functions — GOVERN (organizational policy + culture), MAP (context + impact), MEASURE (metrics + monitoring), MANAGE (response + improvement). US federal procurement (OMB M-24-10 successor) + the cycle-301 regulatory audit's import-mappers (Drata, Vanta, OneTrust) all key off this field. Pre-cycle-483 a consuming governance platform had to parse controlId free-text + heuristically infer the function from the prefix ('nist-ai-600-1/govern-1.2' → 'govern'); the heuristic broke on non-NIST frameworks (EU AI Act, ISO 42001) and on free-form controlId strings. First-class enum closes the inference + makes the mapping declarative.

# properties.subjectArtifactId.description
Identifier of the AI artifact being attested. Format depends on the artifact kind: 'ip:brief:<proposalId>', 'ip:eval-result:<proposalId>', 'ip:capability:<path>', 'huggingface://meta-llama/Llama-3.1-70B-Instruct', 'did:web:openai.com#gpt-5.5-2026-04-14', or any other addressable artifact identifier. The governance platform consumes this to display 'WHICH artifact does this evidence cover.'

# properties.evidenceShaArray.items.properties.kind.description
The schema-kind of the underlying evidence artifact. Lets a downstream governance platform de-reference the sha256 to the right verifier. Includes ip.review.attestation.v1 (cycle 1122): a peer-review finding — the cp-merge-gate killer feature, and the report-of-record for a third-party assessment of someone else's artifact (reviewerDid = the independent assessor) — is first-class governance evidence. This is the direct binding for a NYC LL144 bias-audit result or an SR 11-7 independent-validation finding cited as the evidence for a controlId, replacing the prior cross-kind 'external' reference.

# properties.evidenceShaArray.items.properties.sha256.description
Sha256 of the canonical bytes of the underlying evidence artifact. Each governance-platform consumer can re-fetch + recompute to confirm tamper-evidence.

# properties.evidenceShaArray.items.properties.scope.description
Optional scope description — which aspect of the control this specific evidence item covers (e.g., 'data-lineage', 'model-version-pin', 'peer-review-attestation', 'sandbox-contamination-check').

# properties.evidenceShaArray.description
Array of canonical-evidence references that collectively satisfy controlId for subjectArtifactId. Each item points to a SPECIFIC underlying IntelligencePro attestation by sha256 + kind. The governance platform walks the chain backward: ip.governance.compliance.v1 → evidenceShaArray[].sha256 → re-fetched attestation → verifies sig + judgesDigest + sub-evidence chain. Required because the wedge claim of cryptographic-chain-of-custody requires evidence at every link.

# properties.complianceStatus.description
Issuer's assessment of how subjectArtifactId fares against controlId. 'satisfied' = all evidence aligned. 'partial' = some evidence present, some missing. 'not-applicable' = the control doesn't apply to this artifact kind. 'exception-granted' = the deploying organization granted a documented exception (e.g., low-risk research use). 'not-evaluated' = the issuer didn't perform an assessment (just records the artifact existed). 'non-conforming' = the control was assessed and the artifact fails. Required for downstream governance platforms to make the evidence actionable.

# properties.attestedAt.description
Epoch milliseconds when the compliance assessment was made. Required because compliance has temporal dimension — a control can be added/amended (NIST AI 600-1 updated 2026-04-08; revised standards land continuously) and the assessment reflects the FRAMEWORK VERSION at attestedAt.

# properties.expiresAt.description
Optional epoch milliseconds when this compliance record requires re-attestation. For continuous-control frameworks (SOC 2 Type II, ISO 27001), set to 1 year; for one-shot (regulatory disclosure filing), absent. Governance platforms (Drata, Vanta) consume expiresAt to schedule re-assessment workflows. When present, expiresAt MUST be >= attestedAt (a record cannot require re-attestation before it was attested); the dry-run validator enforces this (cycle 1192, keyword expiresAtBeforeEarlier).

# properties.issuerDid.description
DID of the entity issuing this compliance record. did:web for institutional auditor / GRC platform (did:web:drata.com, did:web:vanta.com, did:web:onetrust.com, did:web:credo.ai); did:key for individual peer-attestation. Resolves to a JWKS that can verify the `signature` field below.

# properties.auditorDid.description
Optional DID of the human auditor or audit firm that supervised the assessment. Distinct from issuerDid in the auditor-firm-uses-Drata-as-tool case: issuerDid = drata.com (the platform); auditorDid = the audit firm (PwC, Deloitte, KPMG). Lets a regulator-facing verifier confirm BOTH the tool + the human accountability.

# properties.exceptionRationale.description
When complianceStatus = 'exception-granted', the human-readable rationale (low-risk-research / experimental-pilot / etc.). Required for audit-defensible exception-tracking.

# properties.remediation.properties.plannedFixBy.description
Epoch ms by which remediation will land.

# properties.remediation.properties.owner.description
Responsible party (team, individual, vendor).

# properties.remediation.properties.trackerUri.description
Issue tracker URL (Jira, Linear, GitHub Issues) for the remediation work.

# properties.remediation.description
Optional remediation plan when complianceStatus = 'partial' or 'non-conforming'. Governance platforms surface this on their dashboards to track open items.

# properties.judgesDigest.description
When this compliance record was peer-attested by 3+ independent verifiers, the canonical digest of the judges manifest. Chains to the same judgesDigest field used in CP's other manifests.

# properties.ipAttestationEventId.description
When this compliance record was emitted as a ip.attestation.event.v1 row (R11 T1) to the platform's Kafka/Tinybird/ClickHouse pipeline, the eventId of that wire row.

# properties.signature.description
Ed25519 signature (128 hex chars = 64 raw bytes) over the canonical-JSON bytes of (complianceRecordId ⊕ frameworkId ⊕ controlId ⊕ controlDescription? ⊕ subjectArtifactId ⊕ evidenceShaArray ⊕ complianceStatus? ⊕ attestedAt ⊕ expiresAt? ⊕ issuerDid ⊕ auditorDid? ⊕ exceptionRationale? ⊕ remediation? ⊕ judgesDigest? ⊕ ipAttestationEventId?). Verify against the publicKey published in the issuerDid's JWKS. RFC 8037 (Ed25519 in JWS) canonicalization rules apply: JCS (RFC 8785) ordering on the inner object. ⚠ INTEGRITY GAP (aa-824-P0-1, cycle 828 honest disclosure): `chain.*` and `extra` are presently OUTSIDE this signature pre-image. A wire-path or post-hoc rewrite of `chain.parentSha256` / `chain.parentKind` / `chain.parentAttestationId` does NOT invalidate this `signature`. Offline verifiers using `signature`+`publicKey` (the documented embedded-verification path) MUST treat `chain.*` as ADVISORY pointer-shape, NOT cryptographically bound to this attestation. For full-integrity verification including chain pointers, fetch the W3C DataIntegrityProof envelope from /credentials/<sha>/v1 and verify against the proof.cryptosuite=eddsa-jcs-2022 signature (which signs the FULL canonical-JSON body including chain). Particularly relevant for this schema given its role binding compliance evidence to controls — a forged chain pointer could falsely attest an unrelated subject artifact as the basis for a control's compliance. Cycle-484 added the chain block; cycles 778-784 swept it; the signature pre-image was not re-derived. Migration target: v2 schema slug ($id pin per cycle-462). See cycles 825-827 for the prior disclosures in this fan-out.

# properties.publicKey.description
Ed25519 public key (32 raw bytes = 64 hex) corresponding to the signature above.

# properties.extra.description
Open extension slot — framework-specific or governance-platform-specific payload (Drata control-mapping IDs, Vanta CCM context, OneTrust assessment-template IDs, IBM watsonx.governance integration metadata). Consumers MUST ignore unknown keys.

# properties.controlOwnerDid.description
DID of the named individual (or named functional role) accountable for the control's continued operation. Cycle 404 (a/b-comparator audit AB-403-3): Drata + Vanta route failed-control alerts BY OWNER — pre-cycle-404 the schema had only issuerDid (the platform that signed the record) and auditorDid (the audit firm) with NO 'person on the hook' field. ISO 42001 §A.6.2.4 + SOC 2 CC6.1 explicitly require individual attribution for control owners. did:web for institutional roles (did:web:my-org.example.com#ciso); did:key for individual researchers. Required when frameworkId ∈ {sox-404, pcaob-as-1000, pcaob-as-1105, iso-iec-42001} via the allOf if/then below.

# properties.controlOwnerEmail.description
Optional contact email for the controlOwnerDid. Lets Drata/Vanta dashboards route 'control failed' alerts directly via SMTP without a DID-resolution side-channel. SHOULD be a functional-role address (security-oversight@org), not an individual that might churn — accountability follows the role, not the person.

# properties.evidenceCollectedAt.description
Epoch milliseconds when the underlying evidence was COLLECTED (control test executed against the artifact), distinct from `attestedAt` which is when the auditor finalized the assessment. SOC 2 Type II + PCAOB AS-1105 require both — Drata + Vanta enforce 'evidence-collected-within-N-days-of-assessment' policies that bounce records where the two timestamps collapse into one. When the assessment is point-in-time (Type I, regulatory filing snapshot), evidenceCollectedAt MAY equal attestedAt; when the assessment is operating-effectiveness (Type II, continuous-controls), evidenceCollectedAt is the period-start of the testing window.

# properties.testFrequency.description
Cadence at which this control is tested. Vanta CCM (Continuous Control Monitoring) groups evidence by testFrequency; without it, evidence imported via IP can't satisfy continuous-monitoring trust criteria. 'continuous' = automated CI/CD check on every change; 'daily/weekly/monthly/quarterly/annual' = scheduled; 'on-demand' = triggered by event (incident, change-request, audit-cycle). Mapped to NIST AI 600-1 MAP/MEASURE function cadence + ISO 42001 §A.7 monitoring frequency.

# properties.assertionType.description
SOC 2 / PCAOB AS-1105 distinguish two assertion types: 'design' = the control is properly designed to meet the objective (Type I); 'operating-effectiveness' = the control operated as designed over the assessment period (Type II); 'both' = the assessment evaluated both. Required for SOC 2 + PCAOB framework imports so a downstream Drata/Vanta evidence-mapper can route the record to the right shelf (Type I controls have point-in-time evidence; Type II controls have operating-period evidence).

# properties.dataSubjectSafeguards.description
GDPR Article 22 + EU AI Act Article 50 data-subject rights coverage (cycle 390, regulatory R-386-6). When this governance attestation covers an AI system making automated decisions about EU data subjects, this block carries the structured access points a regulator + data subject expect: appeal URL, human-reviewer DID, escalation path, complaint intake. Required for high-risk + general-purpose AI systems under EU AI Act Annex III; recommended for all consumer-facing AI deployments under GDPR Art 22's right-to-explanation and right-to-human-review.

# properties.dataSubjectSafeguards.properties.appealUrl.description
HTTPS URL where a data subject submits an appeal of an automated decision. MUST be HTTPS (enforced: pattern ^https://), MUST accept POST with the credential URI as form-data or body. Operator's responsibility to honor GDPR Art 22(3) right-to-human-review within the regulatory timeline.

# properties.dataSubjectSafeguards.properties.humanReviewerDid.description
DID of the human reviewer (or human-review team) responsible for hearing appeals against this attestation. did:web for institutional teams, did:key for individuals. Lets a regulator verify the human is independently identifiable — not the same DID as the issuing AI.

# properties.dataSubjectSafeguards.properties.escalationPath.description
Human-readable description of the escalation hierarchy: first-line review → supervisor → external regulator. Example: 'Tier 1: support@operator.example (24h SLA). Tier 2: appeals-officer@operator.example (5 business days). Tier 3: lodge a complaint with your national data protection authority.'

# properties.dataSubjectSafeguards.properties.complaintIntakeUrl.description
HTTPS URL for filing a formal complaint (separate from an appeal — complaints challenge the LEGITIMACY of the AI system itself; appeals challenge a SPECIFIC decision). GDPR Art 77 right to lodge a complaint with a supervisory authority. Operator's complaint intake links to their DPO + their national DPA.

# properties.dataSubjectSafeguards.properties.automatedDecisionScope.description
Honest classification of how this attestation's downstream decisions affect data subjects. 'advisory-only' = the AI output is one input to a human decision; 'decision-with-human-review' = AI proposes, human approves; 'automated-with-opt-out' = AI decides but the data subject can request human re-review; 'fully-automated' = AI decides with no human in the loop (highest GDPR Art 22 scrutiny); 'not-applicable' = the attestation doesn't drive any decision affecting individuals.

# properties.dataSubjectSafeguards.properties.retentionPeriodDays.description
How long the operator retains the attestation + underlying decision artifacts before deletion. GDPR Art 5(1)(e) storage limitation. 0 = no retention beyond the attestation itself.

# properties.annexIIIClassification.description
EU AI Act Article 6 + Annex III high-risk classification block. Cycle 615 (regulatory-compliance audit RC-600-P0-5). Regulatory clock (cycle 1043 correction): standalone Article 6 + Annex III high-risk conformity-assessment obligations are deferred to 2027-12-02 (Digital Omnibus); the 2026-08-02 milestone enforces Article 50(1)/(3)/73/99 only (the Art-50(2) AI-content-marking obligation was DEFERRED to 2026-12-02 by the 7 May 2026 Digital Omnibus — see the synthetic-media schema + /.well-known/control-mapping.json#enforcement.article50ContentMarking). When the SUBJECT artifact this attestation evidences IS a high-risk AI system under Annex III, the issuer asserts that classification machine-readably here. Surfaces the Article 26 provider obligations (post-market monitoring, serious-incident reporting, fundamental-rights impact assessment for Annex III(5)/(6)/(8) deployments) so Drata/Vanta/OneTrust importers + a regulator probing /credentials/governance-compliance/v1 attestations can answer 'is this artifact high-risk?' + 'where does the conformity-assessment evidence live?' without consulting controller-side prose. Optional today (newly-shipped issuers add as needed); becomes load-bearing for any issuer claiming Annex IV technical-documentation parity. Cross-ref [[wedge]] + /docs/erasure-contract.md + the synthetic-media schema's Article 50(2) deepfake-disclosure surface (the synthetic-media schema is Article 50 transparency; THIS field is Article 6+26+Annex III high-risk obligations — sister surfaces).

# properties.annexIIIClassification.properties.applies.description
true when the subject artifact IS classified as high-risk under Annex III; false when explicitly NOT high-risk (still useful to surface — a negative attestation that the issuer considered the question). When the issuer doesn't know, OMIT the annexIIIClassification block entirely rather than guessing — a missing block is distinguishable from a deliberate false.

# properties.annexIIIClassification.properties.items.description
Annex III sub-categorization. One artifact may carry multiple (e.g. an HR-screening model deployed to assess candidate fit might fire 4a + 4b). Codes follow 'annexIII-{section}{letter?}-{slug}' where section is the Article 6 / Annex III numbered category and letter is the sub-paragraph in the final consolidated text Regulation (EU) 2024/1689. Required when applies=true so a consumer knows WHICH Annex III obligations attach (the obligations themselves vary per sub-category — e.g. Annex III(5)(b) credit-scoring is subject to Article 27 fundamental-rights assessment but Annex III(1) biometrics has tighter Article 5(1)(h) restrictions on remote biometric identification).

# properties.annexIIIClassification.properties.conformityAssessmentRef.description
HTTPS URI of the conformity assessment evidence — typically a notified-body certificate URL (Article 43 + Annex VII third-party assessment) for Annex III(1) biometrics + Annex III(2) safety-component subjects, OR an internal-control declaration for the rest of Annex III (Article 43(2)). The platform does NOT verify the URI resolves to a CAB-issued cert — consumer-side responsibility, mirrors evidenceShaArray + parentSha256 honest-disclosure. A regulator following this URI expects either a NANDO-listed notified-body cert (https://ec.europa.eu/growth/tools-databases/nando/) or a controller-issued declaration of conformity per Article 47.

# properties.annexIIIClassification.properties.fundamentalRightsAssessmentSha256.description
Sha256 of the canonical-JSON bytes of the fundamental-rights impact assessment (Article 27, required before deployment of Annex III(5)(a-d) essential-services AI + Annex III(6) law-enforcement AI + Annex III(7) migration/asylum AI + Annex III(8) justice/democratic-processes AI). The FRIA itself is OUT-OF-BAND (Article 27(4) format prescribed by AI Office; not a CP schema yet). This sha256 binds the attestation to the FRIA bytes the issuer holds — a consumer that obtains the FRIA can re-hash to verify alignment. Missing when the Annex III sub-category does NOT require FRIA (Article 27(1) limits FRIA to specific deployers, not providers + not all Annex III items).

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.description
Article 16-24 + 43-48 provider obligations the issuer attests to having implemented for THIS subject artifact. Cross-referenceable to Drata/Vanta/OneTrust control-mapping importers (cycle 615 carry-over: ship /.well-known/control-mapping.json to bind these enum values to importer-expected control IDs). A regulator probing 'has the provider implemented post-market monitoring?' reads art23-post-market-monitoring-system from this array. Missing items are NOT 'not implemented' — they are 'not attested here'; the controller may have additional out-of-band evidence. RC-737-P0-1 (cycle 739): enum strings preserve PROPOSAL-ERA article numbers; the x-publishedRegulationMapping below binds each to its PUBLISHED-REGULATION article per Regulation (EU) 2024/1689 (OJ L 1689, 12.7.2024). Identical mapping to ip.high-risk-classification.v1 — single source of truth in this enum's sibling schema; replicated here so a consumer fetching governance-compliance alone gets the mapping without cross-schema resolution.

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping._note
RC-737-P0-1 (cycle 739): see ip.high-risk-classification.v1 sibling for full mapping rationale. Enum strings are stable back-compat identifiers; published-Regulation article numbers are the authoritative routing key for control-framework importers.

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art16-quality-management-system
Regulation (EU) 2024/1689 Article 17 (Quality management system)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art17-technical-documentation-annex-iv
Regulation (EU) 2024/1689 Article 11 (Technical documentation; Annex IV is titled 'Technical documentation referred to in Article 11(1)'). Cycle 1185 (regulatory-compliance-reviewer rc-1184-P3) corrected this from a prior 'Article 18' citation — published Art 18 is 'Documentation keeping', NOT technical documentation. The enum string is a proposal-era back-compat identifier; the authoritative published article for the Annex-IV technical-documentation obligation is Article 11.

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art18-record-keeping
Regulation (EU) 2024/1689 Article 19 (Automatically generated logs)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art19-transparency-instructions-for-use
Regulation (EU) 2024/1689 Article 13 (Transparency and provision of information to deployers — the single article covering BOTH the high-risk transparency obligation AND the instructions-for-use requirement). Cycle 1186 (regulatory-compliance-reviewer rc-1184 follow-up audit) corrected this from a prior 'Article 20 (Transparency obligations) + Article 13' citation — published Art 20 is 'Corrective actions and duty of information', NOT transparency; there is no separate Art-20 transparency obligation to cite.

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art20-human-oversight-design
Regulation (EU) 2024/1689 Article 14 (Human oversight). Cycle 798 (rc-795-P1-1 correction): pre-cycle-798 this row trailed with '+ Article 21 (Compliance with high-risk requirements)' — published Article 21 is actually titled 'Cooperation with competent authorities', not a compliance-requirements article. The trailing pair was a fabricated title; the enum's correct binding is Article 14 alone. The compliance-with-requirements obligation lives at Article 16 (Obligations of providers of high-risk AI systems).

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art21-accuracy-robustness-cybersecurity
Regulation (EU) 2024/1689 Article 15 (Accuracy, robustness, cybersecurity)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art22-quality-management-system-conformity
Regulation (EU) 2024/1689 Article 17 (QMS) + Article 43 (Conformity assessment procedure)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art23-post-market-monitoring-system
Regulation (EU) 2024/1689 Article 72 (Post-market monitoring by providers)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art24-serious-incident-reporting
Regulation (EU) 2024/1689 Article 73 (Reporting of serious incidents)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art43-conformity-assessment-procedure
Regulation (EU) 2024/1689 Article 43 (Conformity assessment)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art47-eu-declaration-of-conformity
Regulation (EU) 2024/1689 Article 47 (EU declaration of conformity)

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping.art48-ce-marking
Regulation (EU) 2024/1689 Article 48 (CE marking)

# properties.annexIIIClassification.$comment
RC-737-P0-4 (cycle 757): conditional require fundamentalRightsAssessmentSha256 when items[] contains an EU AI Act Article 27(1)-triggering Annex III sub-category. SAME conditional as ip.high-risk-classification.v1's annexIIIClassification block (cycle-615 sibling — both schemas dispatch off the same enum). Sub-categories triggering Art-27(1): Annex III(5)(a-d) + Annex III(6) + Annex III(7) + Annex III(8)(a) + Annex III(8)(b) — 8 enum strings.

# allOf[].$comment
Cycle 404 (a/b-comparator audit AB-403-3): when frameworkId is a control-attribution-strict framework (SOC2/SOX/PCAOB/ISO 42001), the four operator-accountability fields become REQUIRED. Outside this set the same fields are optional — a single schema covers both the Drata-import-ready strict path and the lighter GDPR/EU-AI-Act ad-hoc cases.

# allOf[].$comment
Cycle 485 (regulatory-compliance RC-480-F7 P1 fix): ISO/IEC 42001 Annex A defines control identifiers in `A.x.y.z` form (e.g. A.6.2.6, A.9.2.1). Drata + Vanta + OneTrust import-mappers key off this prefix shape. Pre-cycle-485 controlId was free-text minLength:1 maxLength:256 — a regulator pulling 10k records saw inconsistent prefixes and the import-mappers couldn't route. Accept BOTH the canonical Annex-A title-case form (`A.6.2.6`) AND the legacy lowercase-prefixed form documented in this schema's controlId description (`iso-42001/a.6.2.6`). Tolerant of subsequent-level depths 1-3 because Annex A subsections nest up to four levels deep (A.6.2.4.1 etc.).

# allOf[].$comment
Cycle 485 (RC-480-F7 P1 fix): NIST AI 600-1 Generative AI Profile defines controls by two-letter function prefix + numeric subsection. The four functions are GV (Govern), MP (Map), MS (Measure), MG (Manage) — same mapping the cycle-483 rmfFunction enum captures. Accept canonical `GV-1.1` form and the schema's legacy lowercase-prefixed examples (`nist-ai-600-1/govern-1.2`, `nist-ai-600-1/mp-2.1`).

# allOf[].$comment
Cycle 485 (RC-480-F7 P1 fix): EU AI Act controls are referenced by Article number (and optional paragraph/sub-paragraph). Article 50(2) machine-readable AI-generation marking → `article-50-2`. Accept the canonical short form and the legacy prefixed form (`eu-ai-act/article-50-2`). Cycle 532 extends the pattern to accept lettered sub-paragraphs (Article 13(3)(a) → `article-13-3-a`). The EU AI Act uses a three-level reference shape: Article N → paragraph N → letter sub-paragraph (a/b/c…). Examples: `article-13-3-a` (Article 13(3)(a) deployer transparency), `article-50-2-b` (synthetic-media labeling subclause).