System profile worksheet
Use this worksheet to define the service boundary before selecting ORF requirements. Create a separate profile for materially different deployments, user groups, data classifications, or tool permissions.
Outcome: an approved description of what the system does, what it must not do, which journeys matter, what can fail, and what evidence may be collected.
1. Document control
| Field | Record |
|---|---|
| System name and ID | Enter: service name and stable inventory ID |
| Business/product owner | Enter: accountable role and contact |
| Technical owner | Enter: accountable engineering role and contact |
| Version/status | Select: Draft / Approved / Retired |
| Last approved / next review | Enter: dates and review cadence |
| Related risk assessment | Link: approved AI, security, privacy, and architecture records |
| ORF source version | Enter: framework release or commit used |
2. Purpose, limits, and oversight
| Question | Record |
|---|---|
| What problem does the system solve? | Describe: intended outcome and supported user journey |
| What must it not be used for? | List: prohibited decisions, advice, data, actions, and user groups |
| Who uses or is affected by it? | List: direct users, operators, reviewers, and affected parties |
| Where does it operate? | Enter: channels, environments, hours, and support model |
| What could have material consequences? | Describe: recommendations, decisions, communications, transactions, or infrastructure actions |
| Where is human oversight required? | Describe: approval, handover, review, and intervention points |
| What fallback and recourse exist? | Describe: safe degradation, complaint, correction, and appeal paths |
Example — public guidance assistant
Intended use: explain approved policy and application steps with citations. Prohibited use: determine eligibility, provide legal advice, access case records, or submit an application. Human handover is required for uncertainty, policy exceptions, complaints, and suspected sensitive cases.
3. Components and capabilities
Record only material components. Use stable identifiers so telemetry can show exactly which version handled an interaction.
| Component | ID/version and owner | Data/classification | Capability or side effect | Scope decision |
|---|---|---|---|---|
| Model | Enter: model/deployment ID; owner/provider | Enter: allowed input/output classes | Generate, classify, embed, or reason | In / Out / Shared |
| Prompt or instruction | Enter: prompt/policy version; owner | Enter: embedded data or secrets | Controls goals and constraints | In / Out / Shared |
| Retrieval or memory | Enter: index/store version; owner | Enter: source classification | Reads or writes contextual data | In / Out / Shared |
| Tool, API, or external action | Enter: tool ID and permission scope | Enter: parameters/results classification | Read, create, update, delete, communicate, or transact | In / Out / Shared |
| Guardrail or policy service | Enter: control/version; owner | Enter: inspected content | Allow, block, redact, route, or escalate | In / Out / Shared |
| Human-review service | Enter: queue/workflow; owner | Enter: reviewer access | Approve, correct, contain, or recover | In / Out / Shared |
4. Material journeys
| Journey | Trigger and expected outcome | Components and external actions | Potential impact | Human/control point |
|---|---|---|---|---|
| Example: policy question | User asks how to apply; receives cited guidance | Web → guardrail → retrieval → model → citation check | Incorrect guidance may delay support | Handover on weak citation or uncertainty |
| Enter: journey name | Describe: start and safe outcome | List: components, tools, and state changes | Describe: people, data, service, or financial impact | Enter: approval, stop, or review point |
5. Material failure scenarios
| Failure | Cause or path | Impact and existing control | Evidence needed | Owner |
|---|---|---|---|---|
| Example: obsolete source used | Retrieval ranks withdrawn policy first | User receives incorrect instructions; citation check and handover should catch it | Index version, source IDs, ranking, response link, control outcome | Retrieval owner |
| Example: tool outcome unknown | Timeout occurs after an external create request | Duplicate or unconfirmed external state; idempotency and reconciliation required | Tool request ID, attempts, timeout, final external state | Integration owner |
| Enter: material failure | Describe: initiating condition and propagation | Describe: consequence and current control | List: logs, metrics, traces, or review evidence | Enter: accountable role |
6. Data and telemetry handling
| Data class | Where it may appear | Approved capture | Retention and access | Required protection |
|---|---|---|---|---|
| User prompt and model response | Application, trace, evaluation sample | Select: Full / Redacted / Reference / None | Enter: duration and authorised roles | Redaction, encryption, access audit, deletion |
| Retrieved content or memory | Retrieval span, restricted evidence store | Select: IDs only / Excerpt / Full / None | Enter: duration and authorised roles | Classification check and source-level access control |
| Tool parameters and results | Tool event, application audit log | Select: Metadata / Redacted / Full / None | Enter: duration and authorised roles | Secret filtering and field allowlist |
| Human annotation or decision | Review system and evidence register | Select: Label / Summary / Full notes | Enter: duration and authorised roles | Reviewer identity, integrity, and purpose limitation |
7. Boundary record
- Architecture diagram: link the approved component view.
- Data-flow diagram: include telemetry and restricted-evidence paths.
- External services and owners: list contractual and operational dependencies.
- Out-of-scope components: state the verifiable reason for exclusion.
- Trace-context boundaries: identify where identifiers are created, transformed, or lost.
- Reassessment triggers: model, prompt, data, tool, permission, user, channel, or risk changes.
8. Approval
| Role | Decision and reviewer | Date | Conditions or review trigger |
|---|---|---|---|
| Product owner | Select: Approve / Revise; enter reviewer | Enter date | Enter conditions or None |
| Technical owner | Select: Approve / Revise; enter reviewer | Enter date | Enter conditions or None |
| Security/privacy | Select: Approve / Revise / Not required; enter reviewer | Enter date | Enter conditions or rationale |
| Risk/governance | Select: Approve / Revise; enter reviewer | Enter date | Enter risk tier and reassessment trigger |
Next: Select requirements.