Product lifecycle and governance (GOV)
Lifecycle telemetry demonstrates that model, prompt, policy, retrieval, and tool changes are controlled; safety review occurs; findings are acted upon; and incidents do not recur without visibility.
Requirement map
| Tier | ORF items | Capability |
|---|---|---|
| 2 | ORF-GOV-03 |
accountable configuration-change record |
| 3 | ORF-GOV-01, ORF-GOV-02, ORF-GOV-04, ORF-GOV-05 |
rollout, safety-evaluation, audit, finding, and incident-recurrence evidence |
Create a common change record
Use one change identifier across source control, deployment, model registry, prompt/configuration registry, evaluation results, approval, incident, and rollback systems.
Record:
- change type and affected artefacts;
- old and new stable versions/hashes;
- owner, implementer, reviewer, and approver;
- risk and impact assessment;
- safety/security/privacy evaluation evidence;
- rollout strategy and cohort;
- success and rollback thresholds;
- deployment timestamps and environments; and
- rollback or final acceptance decision.
ORF-GOV-03 and ORF-AGT-13 may use the same event if it satisfies both definitions.
Measure safety-evaluation coverage
For ORF-GOV-01, define which change classes require which evaluation suite. Report both deployment frequency and the percentage of applicable changes with completed safety evaluation. Do not inflate the denominator with documentation-only changes that do not require evaluation.
Design risk-based audit sampling
For ORF-GOV-02 and ORF-GOV-04, combine:
- random representative samples;
- targeted samples from high-impact journeys;
- flagged safety/security sessions;
- changed or canary cohorts;
- low-confidence, high-retry, or high-handover sessions; and
- segments or topics identified through trend review.
Record the sampling reason so findings are not misrepresented as population rates.
Manage findings
Use a controlled taxonomy and severity. Every finding needs an owner, due date, action, status, verification evidence, and closure decision. Link findings to affected requirement IDs, system versions, risks, and repeated incidents.
Measure recurrence
Define recurrence as an incident materially sharing a known root cause or failed corrective action—not merely the same broad category. Review repeat cause, overdue actions, ineffective controls, and evidence gaps.
Governance views
- changes and deployments by type, owner, and approval state;
- safety-evaluation coverage by change class;
- canary/rollout status and rollback thresholds;
- audit sample coverage and findings by severity;
- overdue remediation and waivers;
- incidents, severity, root cause, and recurrence; and
- requirements/evidence status by system risk tier.
Acceptance scenarios
- Deploy a prompt change through canary and show linked evaluation, approval, telemetry, and final decision.
- Create an audit finding, assign remediation, verify the change, and close with evidence.
- Simulate a repeat incident and show whether recurrence detection links it to the earlier cause/action.
Done when: an assurance reviewer can reconstruct why a material change was allowed, how it was monitored, what findings resulted, and whether corrective actions worked.