# Operating review

An operating review is a decision meeting for one live engagement. It records what happened since the previous decision, checks whether the approved arrangement still works, and chooses the next commitment. Its purpose is to stop the practice expanding, transferring, or continuing a solution without current evidence.

Source: article three, "Use operational review to choose the next action", "Use incidents to improve FDE ownership and shared platform controls", "Track adoption only when it informs an FDE decision", "Account for the review work that automation creates", and "Reassess the application when its conditions change".

## Who fills this in, and what it decides

The practice lead establishes the review before release, not after the first problem. The FDE lead prepares the evidence; the service owner supplies the operating and incident records; the business workflow owner supplies the business result. The review's completed record is the progress report: leaders read it instead of task counts. It feeds the operation decision (continue, correct, transfer, or retire) and returns work to an earlier delivery stage when the evidence requires it.

Roles named in this document:

- Practice lead: chairs the review and approves practice-level commitments.
- FDE lead: owns the delivery evidence and prepares the record.
- Business workflow owner: owns the process and confirms the business result.
- Service owner: owns deployment, support, dependencies, incidents, and technical change.
- Platform and control owners: attend when a shared capability or an approval requirement is affected.

A release is one software version, one population, one set of permitted sources, one review process, and one set of responsible people. The approved scope below is written in those terms so that any change to one of them is visible.

## Standing details

Write the approved scope in the terms users recognise: version, population, sources, review process, and responsible people. The version under review names the build and any material model, source, policy, or data change since the last review. Frequency should follow change and consequence: a controlled release needs frequent review, and a stable service can later use the receiving team's normal service cycle.

- Engagement:
- Approved scope:
- Version under review:
- Participants:
- Frequency, and why:
- Date of this review, and of the previous one:

## 1. The four evidence streams

Record each stream before interpreting any of them. Each answers a different question and supports different actions. Combining them into one score hides the distinctions that matter: a delayed integration needs a delivery commitment, high abandonment needs an output or process change, and an access failure needs the affected retrieval path paused and the affected cases checked.

| Evidence stream | Question | Evidence to record | This period | Recorded by | Supported decisions |
| --- | --- | --- | --- | --- | --- |
| Business result | Does the workflow improve eligible work? | Total effort, completion time, capacity, quality, cost, from the measurement plan | | Business workflow owner | Continue, redesign, narrow, or stop |
| Quality and control | Does the solution operate within its authority? | Factual failures, access checks, state failures, incidents | | Service owner | Release, contain, correct, or pause |
| Use and review | Can staff use the result effectively? | Eligible use, abandonment, fallback, reviewer effort, corrections | | FDE lead | Change output, training, capacity, or workflow |
| Operation and ownership | Can the enterprise sustain the service? | Health, support demand, recovery tests, receiving-team capability | | Service owner | Transfer, retain support, or defer expansion |

## 2. Adoption, with its denominator

Adoption is useful only when it explains a decision. A login count cannot show business value. The denominator is eligible cases in the period: exclude users who had no eligible case, and include eligible cases that users rejected or returned to the manual process. The service owner records the counts from application records; the FDE lead interprets them.

- Eligible cases in the period:
- Cases where the solution was used:
- Cases completed through it:
- Cases abandoned part way:
- Cases returned to the manual process:
- Users excluded because they had no eligible case:

Low use may indicate missing permissions, weak evidence, poor timing, or an unsuitable handoff. High use may still add effort or bypass a control. Connect adoption to quality, result, and support demand before changing the solution or expanding its scope.

- What the adoption figures explain, and the decision they inform:

## 3. The review work the solution creates

Faster preparation can increase the rate of cases reaching the next reviewer. If review capacity stays fixed, the queue grows and the complete process gains little. The business workflow owner records reviewer effort; the review decides whether review is now the limiting step.

- Reviewer effort per case (checking, resolving uncertainty, correcting, recording):
- How difficult cases and busy periods differ from quiet ones:
- Review is the limiting step: yes / no

If it is, the enterprise has four operating choices. The cause and the expected benefit determine which. A model's stated confidence does not, by itself, justify reducing human review; the relevant authority must approve any variation in review intensity for the actual use.

| Choice | When it fits | Chosen |
| --- | --- | --- |
| Improve the evidence the output presents | Reviewers are re-deriving work the output should have shown | |
| Add qualified review capacity | The output is sound and demand is real | |
| Narrow eligible work | Only some cases are worth the review they require | |
| Retain manual processing | The solution does not reduce total effort for this population | |

Expansion without addressing the constraint sends more work into the same queue.

## 4. Incidents since the last review

Incidents belong first to the service owner and follow the enterprise incident process. The FDE practice stays involved when the incident exposes unclear ownership, an unmet transfer condition, or a shared platform weakness, and it records the lesson in the engagement and portfolio records. The service owner completes each row.

| Incident | Contained by | Which identity performed the action | What the tool exposed, and which authorisation checks applied | Likely population of affected cases | Correction, and its owner | Evidence required before restoring the capability |
| --- | --- | --- | --- | --- | --- | --- |
| | | | | | | |

Corrective work should address the mechanism that allowed the failure, not only the prompt: excessive tool access, a permission rule enforced by model judgement, or untrusted content that influenced a privileged action. After correction, reproduce the failure under controlled conditions and test relevant variations. One successful regression case does not prove that every related failure is gone.

- What the incident exposed: unclear ownership | unmet transfer condition | shared platform weakness | none
- Corrections that belong to the platform or identity teams, and their maintenance owner:

## 5. Changed conditions since the last review

The release evidence describes the solution under particular conditions, and those do not stay fixed. The service owner maintains the inventory of consequential dependencies and the people responsible for them; each detected change is reassessed before the solution continues to rely on it. A source dependency is an unavailable or unreliable filing, data feed, or document service that the approved cases need; if one blocks the work, name the owner who can resolve it and the alternative if it stays unavailable.

| Change | Detected how | What must be reassessed | Owner |
| --- | --- | --- | --- |
| A model update | | Quality, control behaviour, latency, cost, reviewer effort, against the evaluation cases | |
| A source system changed a field's meaning | | The semantics record and the evaluation cases that depend on it | |
| A business policy changed | | Interpretations that were previously correct | |
| A new tool, region, or language | | Authority, data requirements, evaluation coverage; this is a new release decision | |

- Recovery exercise last performed on, and its result:
- Blocking source dependency, its owner, and the alternative if it stays unavailable:

## 6. The next commitment

A useful review can also conclude that another investigation would not change the next commitment. Distinguish information that would change it from information that would only make the report longer. Each finding gets a consequence, an action, an owner, a date, and the condition under which the decision is reconsidered; this creates continuity between reviews.

| Finding | Consequence | Next action | Owner | Due | Condition for reconsideration |
| --- | --- | --- | --- | --- | --- |
| | | | | | |
| | | | | | |
| | | | | | |

- Decision: continue | narrow | correct | pause | prepare expansion | transfer | retire
- If "prepare expansion", the changed condition that makes it a new release decision:
- Delivery stage the work returns to, if any:
- Recorded by:
- Next review: