Skip to content

ORF resource kit

Use these artefacts together. Each one answers a different implementation question and produces an input for the next stage.

Artefact Use it to answer Complete when Primary owner
System profile What system, journey, data, and consequences are in scope? The boundary, material journeys, failure scenarios, and data handling are approved. Product and technical owners
Requirements register Which of the 61 ORF items apply and what action does the matrix require? Every ORF ID has a decision, rationale, owner, phase, and waiver state. Risk and delivery lead
Telemetry design How will each selected item be produced, protected, stored, and used? Schemas, metric contracts, trace propagation, protection, and reliability targets are approved. Engineering and platform owners
Runbook What will operators do when a signal indicates harm or failure? Trigger, triage, containment, reconciliation, escalation, and recovery have been exercised. Operations and incident owner
Evidence register Can the team substantiate the recorded status of each selected requirement? Implementation, query, test result, owner, issue, and review date are linked. Review and control owners
Implementation-readiness checklist Is ORF implementation evidence ready for internal review? Required evidence is verified and authorised decision-makers record a go/no-go decision through the organisation's process. Product owner and reviewers
  1. Complete the system profile before assigning a risk tier.
  2. Apply the ORF matrix in the requirements register.
  3. Convert selected items into engineering contracts in the telemetry design.
  4. Build dashboards, alerts, and runbooks around decisions operators must make.
  5. Link test and operating evidence in the evidence register.
  6. Use the implementation-readiness checklist within the organisation's existing review and approval process.

Worked examples

Use the examples together: one illustrates an end-to-end ORF lifecycle for a consequential service, while the other shows observability patterns in a working LLM and RAG application.

  • Public-service guidance assistant

    A fictional High-Risk service carried from system profile and requirement selection through protected evidence, incident response, and an illustrative go-live decision.

    Follow the end-to-end example →

  • LLM Observability Reference Implementation

    A practical reference implementation in an illustrative Low-Risk deployment context, showing generation and RAG traces, evaluation scores, feedback, and safe failures. Singapore property data is the sample dataset.

    Explore the implementation example →

Design references

  • Visual walkthrough — decision flow, reference architecture, dashboard, and trace examples.
  • Metric examples — calculations, denominators, interpretation, and actions.

Prompts are intentional

Cells beginning with Enter, Select, Link, or Describe are completion prompts. Rows labelled Example show the expected level of detail and should be replaced with system-specific information.

These artefacts complement—not replace—security, privacy, architecture, operational, and responsible-AI governance records.