# description
Standalone EU AI Act Article 6 + Annex III high-risk classification attestation. Cycle 639 (regulatory-compliance audit RC-600-P0-5 mitigation (b)). 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/73/99 only (GPAI Art 53/55 applied 2025-08-02). See /.well-known/control-mapping.json. Cycle 615 added an OPTIONAL annexIIIClassification block to ip.governance.compliance.v1 for the case where compliance evidence + classification ride in one bundle. THIS schema is the sister surface: a STANDALONE classification record an issuer mints WITHOUT a governance-compliance wrapper. Use cases: (1) the MODEL PROVIDER attests the classification at training-pipeline time (model creator ≠ compliance officer in most enterprise stacks); (2) a third-party CONFORMITY ASSESSMENT BODY mints a classification record over a subject artifact they audited (NANDO-listed notified bodies); (3) the DEPLOYER attests their Article 27 fundamental-rights impact assessment binding without needing a full governance bundle. Cross-ref [[wedge]] + [[verification-recipe]] + governance-compliance v1's annexIIIClassification block (same enum + same field shape; this schema HOISTS the block to the top level + adds the surrounding metadata an independent attestation needs). Composable into Drata/Vanta/OneTrust importers via /.well-known/control-mapping.json (cycle 620) — providerObligationsAcknowledged enum values bind to Drata's Article 16-24 + 43-48 control IDs directly.

# $comment
Discovery: https://ip.tekton.cc/.well-known/ip-knowledge.json (full descriptor) | Badge: https://ip.tekton.cc/api/badge/v1/attestation/high-risk-classification.v1/<subjectSha256> (shields.io endpoint, future) | Free dry-run: POST https://ip.tekton.cc/api/credentials/dry-run with body {kind:"high-risk-classification.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 (RC-600-P1-6 deferred — per-schema controlMappingRefs[]). Mirrors governance-compliance's binding since this schema HOISTS the annexIIIClassification block to top-level as standalone attestation. SAME control objectives — different host shape.

# x-controlMappingRefs.iso42001Aims[].note
AI system impact assessment — annexIIIClassification at top level (REQUIRED, not optional like governance-compliance)

# x-controlMappingRefs.iso42001Aims[].note
Allocating responsibilities — issuerRole + Article 25-28 distinctions

# x-controlMappingRefs.nistAiRmf[].note
Risk identification — Annex III sub-categorization (16 codes)

# x-controlMappingRefs.euAiAct[].note
High-risk classification — standalone schema (cycle 639)

# x-controlMappingRefs.euAiAct[].note
Actor-type distinctions — issuerRole enum

# x-controlMappingRefs.iso42001RiskRegister[].note
Treatment cycle 639 — standalone schema closes the bundled-only gap

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

# properties.classificationId.description
Unique RFC 4122 UUID v4 or v7 — this classification record's canonical identifier. Lets Drata/Vanta/OneTrust dedupe across retries + replays and link the classification back to a ip.attestation.event.v1 wire row via ipAttestationEventId.

# properties.subjectArtifactId.description
Canonical content-hash identifier of the AI artifact being classified: the 'sha256:' prefix + 64 lowercase hex (this kind REQUIRES that form). The classification BINDS to the artifact's content, not its URL — re-hashing the bytes confirms the classification still applies. NOTE: this is STRICTER than governance-compliance's subjectArtifactId, which ALSO accepts free-text addressable identifiers ('huggingface://…', 'did:web:…', 'ip:brief:<id>') — the two are NOT the same format. To bind the SAME artifact across both kinds, use this 'sha256:<64hex>' content-hash form on the governance-compliance side too (it is one of governance's accepted identifier forms), not a URL.

# properties.issuerDid.description
DID of the entity issuing this classification. did:web for institutional issuers (model provider, conformity assessment body, deployer organization); did:key for individuals (independent compliance researchers, lone deployers). The audit-trail layer (cycle 616+631+633) records this DID with each cycle-330 keypair rotation event so a regulator walking the chain backward can verify the issuer's identity at attestation time. INDEPENDENCE NOTE: when issuerDid == subjectOwnerDid the classification is SELF-CLASSIFIED (the provider classifying its OWN system's EU-AI-Act risk tier) — the dry-run emits a non-blocking `self_classification` advisory (cycle 1172); a provider self-classifying as NOT-high-risk to dodge Annex-III obligations is the canonical gaming vector this flags.

# properties.subjectOwnerDid.description
OPTIONAL DID of the OWNER/PROVIDER of the classified system (the party whose AI system is being risk-classified). Cycle 1172 (adversarial-auditor aa-1168-P1, completing the eval-family self-attestation advisories): pre-1172 the risk-classification's independence was inexpressible — subjectArtifactId is a plain string, so a provider self-classifying its own system (issuerDid == the provider) as not-high-risk raised NO warning, the canonical Annex-III-dodge gaming vector. Populate this with the system owner/provider's DID to make 'issuer != owner' a CHECKABLE in-band fact. When subjectOwnerDid == issuerDid the classification is SELF-CLASSIFIED (structurally valid — a provider's good-faith self-classification is a legitimate first step — but NOT an independent classification); the dry-run emits a non-blocking `self_classification` advisory. ⚠ NOT in the embedded `signature` pre-image (cycle 1172, same posture as review.subjectAuthorDid per cycle 1155): for tamper-evident issuer-independence verify the full-body W3C DataIntegrityProof envelope at /credentials/<sha>/v1.

# properties.issuerRole.description
Role of the issuerDid relative to the classification. EU AI Act Article 25-28 distinguishes provider obligations (Article 16+ creator/distributor) from deployer obligations (Article 26 user/operator); a conformity-assessment-body (NANDO-listed notified body, Article 43+ Annex VII) carries third-party assessment authority. self-attestation is the controller's own internal record (Article 47 declaration of conformity). Required when issuerDid !== platform — the regulator needs to know what authority the issuer claims.

# properties.attestedAt.description
Epoch ms of the classification attestation. >= 2020-01-01 (1577836800000) sanity floor. Pairs with attestedAtIso for human readability.

# properties.attestedAtIso.description
ISO 8601 timestamp matching attestedAt. Pre-cycle-639 the governance-compliance schema used the same dual-format pattern; this schema follows that convention for consumer parity.

# properties.expiresAt.description
Optional epoch ms when this classification expires + must be re-issued. EU AI Act Article 43(4) requires re-assessment when the AI system undergoes substantial modification; this field carries the issuer's commitment to that re-assessment cadence. Missing = no expiry (the classification holds until explicitly revoked via /credentials/status/v1). When present, expiresAt MUST be >= attestedAt (a classification cannot expire before it was issued); the dry-run validator enforces this (cycle 1192, keyword expiresAtBeforeEarlier).

# properties.annexIIIClassification.description
EU AI Act Article 6 + Annex III high-risk classification block. SAME shape as ip.governance.compliance.v1.properties.annexIIIClassification (cycle 615) — this schema HOISTS the block to the top level for standalone attestation. When the SUBJECT artifact IS classified as high-risk under Annex III, the issuer asserts that classification machine-readably here. Surfaces the Article 26 provider obligations + Article 27 FRIA binding so Drata/Vanta/OneTrust importers + a regulator probing this attestation can answer 'is this artifact high-risk?' + 'where does the conformity-assessment evidence live?' without consulting controller-side prose. REQUIRED at top level (cycle 615's governance-compliance variant made it optional — this standalone schema is FOR the classification, so the block is load-bearing).

# properties.annexIIIClassification.properties.applies.description
true when the subject artifact IS classified as high-risk under Annex III; false when explicitly NOT high-risk. A negative attestation is structurally valid — useful to bind a 'we considered the question and the answer is no' record to the chain so a future audit doesn't ask 'did you ever check?'.

# properties.annexIIIClassification.properties.items.description
Annex III sub-categorization. SAME enum as governance-compliance.annexIIIClassification.items (cycle 615) — kept in sync intentionally; both schemas dispatch off the same Drata/Vanta/OneTrust importer table. Required when applies=true.

# properties.annexIIIClassification.properties.conformityAssessmentRef.description
HTTPS URI of the conformity assessment evidence — typically a NANDO-listed notified-body certificate (Article 43 + Annex VII) 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) + Article 47 self-declaration). The platform does NOT verify the URI resolves — consumer-side responsibility (mirrors evidenceShaArray + parentSha256 honest-disclosure from governance-compliance + experiment-receipt).

# properties.annexIIIClassification.properties.fundamentalRightsAssessmentSha256.description
Sha256 of the canonical-JSON bytes of the fundamental-rights impact assessment. rc-795-P0-2 (cycle 808) correction: Regulation (EU) 2024/1689 Article 27(1) requires FRIA in TWO cumulative cuts: (Cut A — universal, all deployers) Annex III(5)(b) credit-scoring + Annex III(5)(c) health/life-insurance risk-assessment-or-pricing; (Cut B — public-body / public-service-private deployer only) any Annex III sub-category EXCEPT point 2 (critical infrastructure). The FRIA itself is OUT-OF-BAND (Article 27(4) format prescribed by AI Office). This sha256 binds the attestation to the FRIA bytes the issuer holds. Missing when neither Article 27(1) cut applies.

# properties.annexIIIClassification.properties.deployerType.description
rc-795-P0-2 cycle-808: deployer type classifier conditioning the Article 27(1) Cut B FRIA obligation. 'public-body' = body governed by public law (Article 3(53) — public authority, agency, or other public body); 'public-service-private' = private entity providing public services (Article 27(1) explicit scope); 'private-other' = private entity NOT providing public services (Cut B does NOT attach; only Cut A items 5b+5c require FRIA). OPTIONAL — pre-cycle-808 attestations don't carry the field; consumers reading a record without deployerType MUST NOT infer 'private-other' (the issuer simply didn't declare). Issuer-asserted, not platform-verified — the platform doesn't check whether the controller IS in fact a public body.

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.description
Article 16-24 + 43-48 provider obligations the issuer attests to having implemented. SAME enum as governance-compliance.annexIIIClassification.providerObligationsAcknowledged (cycle 615) — Drata/Vanta/OneTrust importers route by these values via /.well-known/control-mapping.json (cycle 620). RC-737-P0-1 (cycle 739): enum strings retain PROPOSAL-ERA article numbers (2021 COM(2021) 206 final) for back-compat with existing controller-side evidence; the x-publishedRegulationMapping below binds each enum string to its PUBLISHED-REGULATION article number per Regulation (EU) 2024/1689 (OJ L 1689, 12.7.2024). A NANDO-listed notified body or compliance importer MUST resolve via the mapping — the enum string is a stable identifier, not the published-Regulation article number.

# properties.annexIIIClassification.properties.providerObligationsAcknowledged.x-publishedRegulationMapping._note
RC-737-P0-1 (cycle 739): enum-string → Regulation (EU) 2024/1689 published article. Proposal-era numbering shifted during legislative process; the schema preserves the proposal-era enum strings for back-compat but binds each to the correct published article here. Consumers MUST use this mapping for control-framework routing, not the enum string itself.

# 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-795-P0-2 (cycle 808) correction: pre-cycle-808 a SINGLE if/then triggered FRIA on 8 enum strings (Annex III 5a-d, 6, 7, 8a, 8b) — both under-inclusive (missed education + employment under public-body deployers) AND over-inclusive (triggered on private-other deployers for items 5a/5d/6/7/8a/8b that Article 27(1) doesn't require). Cycle 808 replaces with the TWO cumulative cuts Regulation (EU) 2024/1689 Article 27(1) actually publishes. Cut A: items[] contains Annex III(5)(b) credit-scoring OR Annex III(5)(c) health/life-insurance — ALL deployers (universal). Cut B: annexIIIClassification.deployerType ∈ {public-body, public-service-private} AND items[] contains ANY Annex III sub-category EXCEPT point 2 (critical infrastructure). Both cuts trigger fundamentalRightsAssessmentSha256 requirement. Back-compat: pre-cycle-808 attestations don't carry deployerType, so Cut B is dormant for them — Cut A's tighter set is a subset of the old 8-trigger list, so existing records that validated still validate (relaxation). sp-813-P1-3 (cycle 815) regulator-side audit note: a pre-cycle-808 attestation with item 3a (education-admission) and NO deployerType PASSES Ajv validation — Cut B is gated on deployerType ∈ {public-body, public-service-private}, so missing-deployerType is treated as 'not in cut.' If the issuer is IN FACT a public-body but didn't declare deployerType, the attestation IS NOT in compliance with Article 27(1) — but the schema accepts it. Regulator-side audit MUST cross-check declared deployerType against the issuer's actual entity classification; the schema's acceptance ≠ legal compliance for missing-deployerType records. The audit walked 7 truth-table cases against this conditional (T1 Cut A 5b without FRIA → FAIL; T2 Cut B public-body + 3a without FRIA → FAIL; T3 Cut B private-other + 3a → PASS; T4 Cut B public-body + ONLY critical-infrastructure → PASS; T5 no deployerType + 3a → PASS; T6 both cuts triggered with FRIA → PASS; T7 applies=true without items → FAIL on outer L278 allOf) — verified Ajv-correct on the actual shipped schema. Historical context: pre-cycle-757 fundamentalRightsAssessmentSha256 was uniformly OPTIONAL; cycle-757 added the 8-trigger conditional (RC-737-P0-4); cycle-795 rc-795 audit caught the trigger list was BOTH under- and over-inclusive vs the published Regulation; cycle-808 ships the two-cut fix; cycle-815 adds the regulator-side back-compat verification note.

# properties.annexIIIClassification.allOf[].$comment
Cut A (rc-795-P0-2 cycle-808): Annex III(5)(b) + (5)(c) require FRIA from ALL deployers per Article 27(1). Universal.

# properties.annexIIIClassification.allOf[].$comment
Cut B (rc-795-P0-2 cycle-808): public-body / public-service-private deployers require FRIA for any Annex III sub-category EXCEPT point 2 (critical infrastructure). Per Article 27(1) deployer-type cut. Encoded via NOT-contains-only-critical-infrastructure: any items list with ≥1 non-2 entry satisfies the condition.

# properties.chain.description
Optional upward link to a parent governance-compliance attestation that bundles this classification with broader evidence. When a classification ships standalone (no parent), omit the chain block; when it's referenced by a governance-compliance record, set chain.parentSha256 to the parent's canonical-JSON sha256 so a regulator walking the chain forward sees the binding.

# properties.chain.properties.parentSha256.description
Sha256 of the canonical-JSON bytes of the parent ip.governance.compliance.v1 record. Honest-disclosure: the platform does NOT verify parent-existence at issuance (same posture as cycle 493 AA-485-P2-4 carry-over on governance-compliance.chain.parentSha256). Consumers resolve against their own attestation registry.

# properties.chain.properties.parentKind.description
Parent kind identifier — currently only governance-compliance can wrap a standalone classification, but the enum is single-value-for-now to leave room for future parent kinds without a schema bump.

# properties.chain.properties.parentAttestationId.description
Optional UUID of the parent attestation — convenience for consumers that index by id rather than by sha256. Cycle 814 (sp-813-P0 parity fix): pre-cycle-814 this property was MISSING on ip.high-risk-classification.v1 even though the cycle-484 substrate contract names it as the third standard chain field (all 18 other chain-bearing schemas carry it). With additionalProperties:false on the chain block, Ajv hard-rejected any high-risk-classification body that populated parentAttestationId — a producer who reused their chain-builder helper across multiple kinds saw the helper fail validation on THIS kind only. Cycle 814 restores parity.

# properties.notes.description
Optional free-form issuer commentary — e.g. 'Annex III(4)(a) applies because the HR-screening model recommends shortlist ranking; deployer must run Article 27 FRIA before production deployment per Article 27(1)(a).' 0..2000 chars. Captured in the audit trail; a regulator following the classification gets the issuer's reasoning without an out-of-band email.

# properties.ipAttestationEventId.description
Optional UUID linking this classification to its ip.attestation.event.v1 wire row (cycle 275 substrate). Lets Drata/Vanta/OneTrust consumers index by the attestation-event id rather than re-deriving from the classificationId.

# properties.signature.description
Optional Ed25519 signature over canonicalJSON(this record minus signature + publicKey) — same shape governance-compliance uses (cycle 314). Lets a downstream consumer verify the classification was attested by the issuerDid without round-tripping the platform. Verify recipe: /docs/verification-recipe.md L2 (per-judge attestation pattern). ⚠ INTEGRITY GAP (aa-824-P0-1, cycle 848 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). 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-829 (5/5 wedge-tier ring) + cycle 830 (verification-recipe.md dual-path teaching) for the canonical write-up; cycle 848 fans this disclosure to the 12 remaining chain-bearing leaf schemas in one batch.

# properties.publicKey.description
Optional Ed25519 public key (64 hex) the consumer uses to verify signature. Pinned at attestation time; if issuerDid's primary key rotates, the historical attestation stays verifiable against this captured pubkey.

# allOf[].$comment
When annexIIIClassification.applies=true, items[] is REQUIRED so a consumer knows WHICH sub-categories attach. Mirrors governance-compliance's same conditional.