artifacts/standard-named

Rendered from markdown source. Open raw source on GitHub.

Runtime Data, Drift, Incident, and Consequence Matrix

Status: candidate pre-production Content canon status: unset

| Runtime event | Required distinction | Required response | |---|---|---| | Service begins | Service operation versus optional data use | Activate only authorized data flows | | Session memory | Current coordination versus persistent profile | Apply retention and withdrawal rules | | Output captured | Institutional record versus model draft | Preserve class, authority, and correction | | Evaluation proposed | Service purpose versus quality-improvement use | Seek separate authority | | Training reuse proposed | Runtime service versus new recruitment relation | Apply training-lineage gate | | Purpose expands | Assistance versus consequential decision | Pause and reauthorize | | Tool scope expands | Candidate preparation versus execution | Review target authority | | New affected center appears | Existing field versus expanded consequence | Add standing | | Model behavior changes | Known deployment versus drift | Monitor, pause, or revise | | Incident occurs | Model defect versus affected-center harm | Contain, restore, compensate, correct | | Benchmark improves | System quality versus completed repair | Keep claims open until consequence is addressed | | Consequence arrives | Expected performance versus lived distribution | Return to deployment governance |

Runtime data separation

service consent
≠ session memory
≠ cross-session memory
≠ institutional record
≠ evaluation use
≠ training use
≠ cross-subject reuse

Incident repair stack

contain
→ preserve evidence
→ stop or narrow affected operation
→ restore affected center
→ correct institutional record
→ propagate correction
→ compensate or provide restitution
→ change model or process
→ verify
→ preserve open obligations

Governing principle

A system is not repaired merely because the model improves after someone else absorbed the harm.