ORF implementation-readiness checklist
Use this to prepare ORF evidence for an internal implementation-readiness review after implementation and verification. It complements—and does not replace—security, privacy, architecture, operational, responsible-AI, or go-live approval processes.
For each item, retain a link or case reference in the evidence register. An unchecked item requires an explicit blocker, owner, date, and authorised decision; it must not disappear into meeting notes.
Blocking conditions
Do not record ORF implementation readiness when any of these conditions applies. The organisation's authorised decision-makers retain responsibility for any go-live decision:
- a Mandatory ORF item is not Verified;
- a waiver is used for a Mandatory item or has expired;
- material telemetry contains unapproved sensitive content;
- operators cannot reconstruct a representative material incident;
- telemetry loss or redaction failure can silently invalidate safety evidence; or
- an external action can end in unknown state without reconciliation.
1. Scope and accountability
- Intended use, prohibited use, users, impacts, system boundary, and material journeys are approved.
- Risk tier and telemetry data-handling assessment are approved and linked.
- All 61 ORF IDs have a decision in the requirements register.
- Mandatory items are Verified; permitted waivers are approved and unexpired.
- Every selected requirement, dashboard, alert, runbook, and review has one accountable owner.
- Reassessment triggers cover material model, prompt, data, tool, permission, user, and channel changes.
2. Telemetry design and protection
- Session/query/task/request/trace identifiers propagate through each material journey.
- Relevant model, prompt, policy, retrieval, tool, agent, and deployment versions are captured.
- Schemas and metric contracts state required fields, formula, eligible population, window, dimensions, coverage, owner, and action.
- Sensitive content capture is minimised, approved, and separated from general telemetry where required.
- Secrets and disallowed fields are tested against expected and adversarial application paths.
- Restricted evidence access, audit, retention, export, screenshot, and deletion controls are tested.
3. Reliability and integrity
- Schema failure, event/trace loss, collector/export failure, queue pressure, and ingestion delay are monitored.
- Dashboards visibly indicate stale, incomplete, or untrusted evidence.
- Telemetry failure behaviour is approved for consequential decisions and actions.
- Flagged safety/security evidence has appropriate integrity protection and case linkage.
- Time, ordering, deduplication, retry, late-event, and unknown-state behaviour are tested.
4. Operational readiness
- Service, agent, safety/security, user-experience, and governance views support named decisions.
- Critical alerts route to tested runbooks without placing sensitive content in notifications.
- Normal, refusal, malicious, tool, timeout, partial-state, human, privacy, change, and pipeline-failure scenarios were tested as applicable.
- An operator can reconstruct a representative incident within the agreed target time.
- Rollback, safe degradation, interruption, external-state reconciliation, and restoration approval are exercised.
- On-call, platform, security/privacy, product, and governance escalation paths are current.
5. Governance and improvement
- Change classes, required evaluations, rollout thresholds, and rollback authority are defined.
- Operational, safety/quality, security/privacy, and ORF assurance review cadences are scheduled.
- Residual gaps have owners, dates, acceptance authority, and visible expiry/review conditions.
- Verification evidence includes environment, release, date, result, reviewer, and limitations.
- Post-launch monitoring period, success criteria, and early rollback triggers are agreed.
6. Readiness summary
| Area | Status | Evidence and open action |
|---|---|---|
| Scope and accountability | Select: Ready / Conditional / Blocked | Link: profile, register, and open action |
| Telemetry and protection | Select: Ready / Conditional / Blocked | Link: design, privacy/security evidence, and open action |
| Reliability and operations | Select: Ready / Conditional / Blocked | Link: tests, dashboards, runbooks, and open action |
| Governance and review | Select: Ready / Conditional / Blocked | Link: approvals, cadence, waiver, and open action |
7. Decision record
| Role | Decision and reviewer | Date | Conditions, actions, and expiry |
|---|---|---|---|
| Product owner | Select: Go / Conditional / No-go; enter reviewer | Enter date | Enter: condition, owner, due date, expiry—or None |
| Technical/operations owner | Select: Go / Conditional / No-go; enter reviewer | Enter date | Enter: condition, owner, due date, expiry—or None |
| Security/privacy | Select: Go / Conditional / No-go / Not required; enter reviewer | Enter date | Enter: condition or approved rationale |
| Risk/governance | Select: Go / Conditional / No-go; enter reviewer | Enter date | Enter: residual risk, next review, and reassessment triggers |
Conditional is time-bounded
A Conditional decision must identify the accepted gap, accountable owner, compensating control, due date, expiry, and authority that will confirm closure. If those fields are absent, treat the decision as No-go.
After launch, keep the evidence register current and follow reviews and governance.