Requirements register worksheet

Use this register to convert the complete ORF catalogue into explicit applicability, obligation, ownership, and delivery decisions. Do not start from a favourite tool or dashboard; start from the approved system profile and risk tier.

Outcome: all 61 ORF IDs have a recorded decision, and every selected item has an implementation use, owner, phase, and acceptance path.

1. Register metadata

Field	Record
System and profile version	Enter: stable system ID and approved profile version
Risk tier and approval	Enter: Low / Medium / High, decision date, and approver
ORF source version	Enter: framework release or commit used
Register owner	Enter: accountable role and contact
Approval / next review	Enter: decision date, review date, and reassessment triggers

2. Apply the matrix

The ORF priority tier describes how foundational an item is. The system risk tier determines the required action.

Priority tier	High-Risk system	Medium-Risk system	Low-Risk system
Tier 1	Mandatory	Mandatory	Good-to-Have
Tier 2	Mandatory	Mandatory but Waivable	Good-to-Have
Tier 3	Mandatory but Waivable	Good-to-Have	Good-to-Have
Tier 4	Good-to-Have	Good-to-Have	Good-to-Have

See Risk and requirements matrix for the governing definitions.

3. Selection decision

Use one row for every ORF ID. “Not applicable” is a playbook record status, not an ORF matrix action. It requires a verifiable fact showing that the requirement's subject does not exist anywhere in the approved scope, plus a reviewer and reassessment trigger—not cost, effort, or lack of tooling.

ORF ID	Tier/type and matrix action	Applicability fact	Decision and operational use	Rationale
Example: ORF-AGT-04	Tier 2 trace; Mandatory	Multi-service query–retrieval–model–tool journey exists	Select; incident reconstruction and trace-coverage alerting	End-to-end correlation is required to investigate failures
Example: ORF-PERF-07	Tier 4 metric; Good-to-Have	Representative group-labelled test set is not yet approved	Plan for later phase	Fairness risk remains relevant; data and review protocol are prerequisites
Enter: ORF-___	Enter: tier, type, and matrix action	Describe: relevant component, journey, or verifiable absence	Select: Implement / Defer / Not applicable / Waiver requested; state use	Explain: risk, evidence need, decision basis, reviewer, and reassessment trigger where relevant

4. Delivery record

Keep long schemas and metric definitions in the telemetry design; link them here.

ORF ID	Planned implementation and evidence	Delivery phase	Owner and target	Waiver or dependency
Example: ORF-AGT-04	OpenTelemetry trace context; coverage dashboard; propagation test	Phase 1 foundation	Platform observability lead; 2026-Q4	No waiver; depends on gateway propagation
Example: ORF-PERF-07	Governed offline evaluation by approved segments	Phase 3 analytics	Model assurance lead; after dataset approval	Data-governance dependency; no waiver required
Enter: ORF-___	Link: design, query/dashboard, test, or evidence location	Select: Phase 1 / 2 / 3 / Backlog	Enter: one owner and date	Enter: waiver ID, blocker, or None

5. Decision quality checks

• All 61 ORF IDs were considered against the current system profile.
• The approved risk tier was mapped to the matrix correctly.
• Mandatory items have no waiver.
• Every Not applicable record states a testable system condition, reviewer, and reassessment trigger.
• Every permitted waiver includes risk rationale, compensating controls, approver, and expiry.
• Good-to-Have items have an explicit implement/defer decision rather than being silently omitted.
• Material system-specific risks not covered by ORF have additional telemetry requirements.
• Every selected item has one operational use, owner, phase, and acceptance test.
• Content handling, access, retention, and deletion are addressed before implementation.

Next: Design the telemetry. After implementation begins, track supporting evidence in the evidence register.