# description
Typed EU AI Act Article 73 serious-incident RECORD attestation. Cycle 1074 closes the gap the platform documented against itself in /docs/eu-ai-act-mapping.md (cycle-807 honest disclosure): 'the platform LACKS (i) a typed serious-incident.v1 attestation kind'. This schema is that kind. It binds the FACTS of a serious incident — {affected high-risk system, severity category per Article 3(49), became-aware timestamp, applicable reporting-window tier, out-of-band incident-narrative sha256, corrective measures, authority reference} — to a cryptographic signature so a provider/deployer holds a tamper-evident, independently-verifiable record of what they knew and when. ⚠ SCOPE / HONEST LIMIT (mirrors the cycle-807 + cycle-806 disclosures in /docs/eu-ai-act-mapping.md): this attestation is SUPPORTING EVIDENCE, NOT the Article-73 filing itself. The provider/deployer MUST still file the actual serious-incident report with their national market-surveillance authority within the applicable window (Article 73(2)/(3)); IntelligencePro does NOT auto-file and does NOT determine conformity. It is ALSO not a defense for an Article-5 PROHIBITED practice — NEVER use this kind to represent a prohibited practice (untargeted scraping, workplace/education emotion recognition, most real-time public remote biometric identification) as 'handled'; serious-incident reporting is a HIGH-RISK-system obligation, a different regime. Three EU clocks (see /.well-known/control-mapping.json#enforcement): Article 5 prohibitions live 2025-02-02; Article 50 transparency + Article 73 serious-incident + Article 99 penalties live 2026-08-02; standalone Article 6 + Annex III high-risk conformity-assessment deferred to 2027-12-02 (Digital Omnibus). Sister surfaces: ip.vulnerability.disclosure.v1 (software-CVE-shaped disclosures), ip.high-risk-classification.v1 (Annex III classification), ip.governance.compliance.v1 (compliance bundle). Cross-ref [[wedge]] + [[verification-recipe]] + /docs/eu-ai-act-mapping.md#article-73-serious-incident-reporting.

# $comment
Discovery: https://ip.tekton.cc/.well-known/ip-knowledge.json (full descriptor) | Free dry-run: POST https://ip.tekton.cc/api/credentials/dry-run with body {kind:"serious-incident.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). Reporting-window tiers per Regulation (EU) 2024/1689 Article 73(2)/(3)/(7) — verified against /docs/eu-ai-act-mapping.md (cycle-796 correction: these are the AI-Act tiers, NOT the GDPR Article-33 72h window).

# x-controlMappingRefs.$comment
Cycle 1074. Article 73 (reporting of serious incidents) is the load-bearing binding; Article 72 (post-market monitoring) is the upstream obligation that surfaces incidents; Article 26(5) puts the parallel monitor-and-inform duty on deployers.

# x-controlMappingRefs.euAiAct[].note
Serious-incident record — typed kind closing the cycle-807 documented gap (i). Supporting evidence, NOT the filed report.

# x-controlMappingRefs.euAiAct[].note
Post-market monitoring — the upstream obligation under which serious incidents are detected (enum severityCategory maps Article 3(49)).

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

# properties.incidentId.description
Unique RFC 4122 UUID v4 or v7 — this serious-incident record's canonical identifier. Stable across the initial report and any Article 73(7) supplementary records that reference it via supersedes. Lets a consumer dedupe retries and link the record to its ip.attestation.event.v1 wire row via ipAttestationEventId.

# properties.deployedSystemSha256.description
Canonical content-hash identifier of the deployed high-risk AI system the incident involves. Same sha256: + 64-hex form as ip.high-risk-classification.v1.subjectArtifactId — the record BINDS to the system's content, not its URL, so re-hashing the bytes confirms which exact system version the incident attaches to.

# properties.severityCategory.description
The serious-incident category per Regulation (EU) 2024/1689 Article 3(49): an incident or malfunctioning that directly or indirectly leads to (a) the death of a person [=death] OR serious harm to a person's health [=serious-harm-to-health]; (b) serious and irreversible disruption of the management or operation of critical infrastructure [=critical-infrastructure-disruption]; (c) infringement of obligations under Union law intended to protect fundamental rights [=fundamental-rights-infringement]; (d) serious harm to property or the environment [=serious-harm-to-property-or-environment]. Issuer-asserted legal characterization — the platform does NOT adjudicate which category applies.

# properties.reportingWindowTier.description
The applicable Article 73(2)/(3) reporting-window tier the reporter determined, measured from becameAwareAt: '15d-default' = any serious incident (Article 73(2)); '10d-death' = where the incident involved a person's death; '2d-widespread-or-critical-infrastructure' = widespread infringement OR a critical-infrastructure incident (Article 73(3)). Article 73(7) permits an INITIAL incomplete report (use supersedes to link the later complete one). OPTIONAL + ISSUER-ASSERTED: the platform does NOT enforce a tier-vs-severityCategory mapping (the legal determination of the applicable window is the reporter's responsibility — e.g. 'widespread' turns on how many persons were affected, which the bytes can't decide). Aligned to /docs/eu-ai-act-mapping.md (cycle-796 correction — these are the AI-Act tiers, NOT the GDPR Article-33 72h window).

# properties.incidentNarrativeSha256.description
Sha256 of the canonical bytes of the out-of-band incident narrative (what happened, the causal link to the AI system, affected parties). The narrative itself stays OUT-OF-BAND: incident detail routinely contains personal data / sensitive operational facts, and the cycle-398 PII linter rejects inline free-text at issuance. This sha binds the attestation to the narrative the reporter holds without leaking it on-chain — same posture as rationaleSha256 on judgments.

# properties.occurredAt.description
Optional epoch ms when the incident occurred (or the best-known onset, if a range). >= 2020-01-01 (1577836800000) sanity floor. Distinct from becameAwareAt — the Article 73 reporting clock runs from awareness, not occurrence, but both are evidentially useful. When both occurredAt and becameAwareAt are present, becameAwareAt MUST be >= occurredAt (you cannot become aware of an incident before it occurred); the dry-run validator enforces this (cycle 1192, keyword becameAwareAtBeforeEarlier).

# properties.becameAwareAt.description
Epoch ms when the provider/deployer became aware of the serious incident. This is the CLOCK-START for the Article 73(2)/(3) reporting window — the reportingWindowTier is measured from here. >= 2020-01-01 sanity floor. The Ed25519 signature over this field gives a tamper-evident record of the awareness timestamp a reporter's window is computed against.

# properties.reportedToAuthorityAt.description
Optional epoch ms when the reporter actually filed the serious-incident report with the national market-surveillance authority. ABSENT means not-yet-filed OR not-recorded-here — absence is NOT an assertion that no filing occurred (the filing happens out-of-band on the authority's channel). Present lets an auditor compare (reportedToAuthorityAt - becameAwareAt) against the reportingWindowTier. When both becameAwareAt and reportedToAuthorityAt are present, reportedToAuthorityAt MUST be >= becameAwareAt (you cannot file the report before you became aware of the incident); the dry-run validator enforces this (cycle 1198, keyword reportedToAuthorityAtBeforeEarlier).

# properties.marketSurveillanceAuthorityRef.description
Optional free-form reference to the authority the report was/will be filed with + any case/reference number the authority issued (e.g. 'BNetzA DE / case 2026-AIA-00417'). 0..512 chars. Issuer-asserted; the platform does NOT contact or verify the authority. PII-linted at issuance like all free-text — keep it to authority + reference, no personal data.

# properties.correctiveMeasuresSha256.description
Optional sha256 of the canonical bytes of the corrective / mitigation measures the reporter took or plans (Article 20 corrective-actions duty + Article 73 follow-up). Out-of-band like incidentNarrativeSha256; binds the measures record to this incident attestation.

# properties.reporterDid.description
DID of the entity filing this record. did:web for institutional reporters (the provider organization, the deployer organization, an authorized representative); did:key for individuals. The Article 73 primary reporting obligation is on the PROVIDER; deployers have a parallel monitor-and-inform duty (Article 26(5)) — see reporterRole. The audit-trail layer records this DID so a regulator can verify the reporter's identity at attestation time.

# properties.reporterRole.description
Optional role of reporterDid relative to the incident. Article 73 places the primary serious-incident reporting obligation on the PROVIDER of the high-risk system; a DEPLOYER who identifies a serious incident must inform the provider (Article 26(5)) and, where the provider can't be reached, may report directly; an authorized-representative (Article 22) acts for a non-EU provider. Issuer-asserted.

# properties.supersedes.description
Optional incidentId of an EARLIER record this one supplements or corrects. Article 73(7) explicitly allows an initial INCOMPLETE report followed by a complete one — set supersedes to the initial record's incidentId so a consumer walking the records sees the supplementation chain (initial → complete) rather than two unrelated incidents.

# properties.chain.description
Optional upward link to a parent attestation that establishes the affected system's provenance or classification. When the incident record ships standalone, omit chain; when it should bind to the system's high-risk classification or compliance bundle, set chain.parentSha256 to the parent's canonical-JSON sha256.

# properties.chain.properties.parentSha256.description
Sha256 of the canonical-JSON bytes of the parent attestation. Honest-disclosure: the platform does NOT verify parent-existence at issuance (same posture as the cycle-484 substrate across the schema family). Consumers resolve against their own attestation registry.

# properties.chain.properties.parentKind.description
Parent kind identifier — the classification that marked the system high-risk, the governance bundle that wraps its compliance evidence, or the experiment receipt for the model version involved.

# properties.chain.properties.parentAttestationId.description
Optional UUID of the parent attestation — convenience for consumers that index by id rather than by sha256. Carried on all chain-bearing schemas per the cycle-484 substrate contract.

# properties.notes.description
Optional free-form issuer commentary (PII-linted at issuance) — e.g. 'Root cause traced to a distribution shift in the credit-scoring model; model rolled back to the prior experiment-receipt version; FRIA re-run scheduled.' 0..2000 chars. Captured in the audit trail so a regulator following the record gets the reporter's reasoning without an out-of-band email.

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

# properties.signature.description
Optional Ed25519 signature over canonicalJSON(this record minus signature + publicKey) — lets a downstream consumer verify the record was attested by reporterDid without round-tripping the platform. Verify recipe: /docs/verification-recipe.md L2. ⚠ INTEGRITY GAP (aa-824-P0-1): chain.* is 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 MUST treat chain.* as ADVISORY pointer-shape; for full-integrity verification including chain pointers, fetch the W3C DataIntegrityProof envelope from /credentials/<sha>/v1 (which signs the FULL canonical-JSON body including chain). Migration target: v2 schema slug widens the pre-image.

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