Responsible AI & Governance · 2 to 3 hours

Specify a review and escalation workflow

Specify how disputed AI feedback is re-reviewed, corrected, and escalated, with server-side authorization, artifact-bound approval, deadlines, and concurrency rules, then prove the rules with acceptance fixtures.

Medium

Hands-on

Hands-on workflow specification

3 h

Jump to

Overview

Turn governance policy into a review and escalation workflow: explicit states, server-side authorization, approvals bound to the exact reviewed output, and deadlines that never approve by default. Practice on ten acceptance fixtures, a dispute workflow, and an escalation case for a fictional feedback platform.

Study time: 2 to 3 hours

Interview format: Hands-on workflow specification with acceptance fixtures and an escalation case

By the end you can

Specify review and dispute workflows as explicit states, transitions, actors, and preconditions
Enforce authorization on the server and apply transitions atomically with an expected revision
Bind approvals to the exact artifact, evidence revision, and policy version, and recheck them at publication
Predict workflow outcomes from a fixed check order and test stored state and downstream effects
Convert arrival rate and handling time into reviewer capacity and measure whether review catches errors
Take an escalation from containment through a verified remedy to closure

Prerequisites

Helpful background: Familiarity with HTTP APIs, database transactions, and role-based access control helps.

This topic covers oversight, impact, and release accountability. Security & Privacy covers technical attack and exposure controls.

Define the system boundary

Governance applies to the assembled system: model, prompts, retrieval, tools, interface, reviewers, and downstream consumers. Outputs that change learner records, such as scores, need stronger review than hints a learner can ignore. Keep an inventory with an owner, purpose, affected people, data categories, dependencies, release identifier, and review date.

Build a risk register with evidence

Worked example

Field	Example
Risk ID	R-017
Scenario	A valid alternative solution receives a failing score
Affected people	Learners using less common but correct approaches
Cause hypothesis	Rubric and examples overfit a preferred implementation
Control	Broader fixtures, expert adjudication, accessible dispute path
Evidence	Evaluation report E-12 and review sample E-19
Owner	Feedback quality owner
Residual uncertainty	Limited coverage of advanced asynchronous solutions
Decision and review trigger	Restrict score use; reassess after dataset expansion

Keep the scenario concrete: "bias exists" tells nobody what to test. Separate observed incidents from hypothetical risks and record your confidence in the cause. A control needs an owner, a deadline, and evidence that it operates; a planned control is not an implemented one. The NIST AI RMF Playbook suggests actions for this work; adapt them rather than treating them as a mandatory checklist.

Translate policy into a review contract

Decide which outputs may be delivered automatically and which need review. Route on observable conditions such as missing evidence, conflicting test results, an unsupported task type, or a user dispute, not on the model's self-reported confidence alone. Represent review-required, approved, rejected, expired, and superseded states explicitly, and tie each approval to the exact artifact and policy revision reviewed.

Review workflow specification

The review contract for the fictional platform in the fixtures below:

Current state	Event	Actor	Preconditions	Result
Draft	Submit	Generator	Artifact and evidence revisions fixed	Pending review
Pending review	Approve	Queue reviewer	Every required evidence item present; the reviewer can open each one; reviewed artifact hash, evidence revision, and policy version equal the stored ones	Approved; approval bound to the reviewer, artifact hash, evidence revision, and policy version
Pending review	Reject	Queue reviewer	Reason recorded	Rejected
Pending review	Deadline reached	Scheduler	No valid decision before the deadline	Expired and escalated to the queue lead; never approved by default
Approved	Binding changes	Generator (output or evidence) or policy service (policy)	New output, material evidence revision, or new policy version	Draft with the new binding; the old approval is superseded
Approved	Publish	Publisher	The approval's artifact hash, evidence revision, and policy version still equal the stored ones at commit time	Published; score written to the learner's progress record once; one learner notification
Published	Restrict	Incident owner	Reason recorded	Restricted: explanation visible; score stops counting and shows as under review; investigation opened
Published	Withdraw	Incident owner	Reason recorded	Withdrawn: explanation and score hidden and removed from progress totals; learner sees an under-review notice; investigation opened
Published, Restricted, or Withdrawn	Correction published	Publisher	A corrected item for the same submission has just been published	Superseded: kept in history; its score leaves progress totals and the corrected score replaces it

Rejected and Expired are final for that artifact revision; new output starts again as a Draft. Some workflows need two independent reviewers or more states; derive them from the use case rather than adding ceremonial approvals.

Concurrency and authorization

Authorize every state-changing action on the server; a hidden approval button is not an access-control boundary. Derive the actor's identity from the authenticated session, never from a request field.

Apply transitions atomically with an expected revision. If two reviewers act on the same pending item, one succeeds and the other sees the changed state instead of overwriting the first decision.

Bind approval to a content hash or immutable artifact ID, evidence revision, and policy version, and recheck the binding when publication commits. A retried publication request must not publish twice.

The feedback-review fixture

Worked example

Suppose a coding-practice platform shows learners AI-drafted feedback on their solutions: an explanation and a practice score from 0 to 5 that counts toward their progress record. A model drafts each item, a reviewer approves it, a publisher service publishes it, and learners can dispute a published score.

Item F-31 is the draft feedback for learner Lee's solution S-88:

Field	Value
Revision	4 (the record version; every applied transition adds 1)
Artifact hash	h1 (the exact explanation and score)
Evidence revision	ev3 (hidden-test results and the rubric)
Policy version	p7 (current)
Review deadline	48 hours after submission

Actors. Identity always comes from the authenticated session, never from a request field.

Actor	May do
Rina, Kai	Approve or reject items in this queue; can open all evidence
Omar	Approve or reject items in this queue; his access to the hidden-test results has lapsed
Lee	Dispute their own results once published
Generator	Submit drafts and write new model output or evidence for an item
Policy service	Move items to a new policy version
Publisher	Publish items
Dana	Restrict or withdraw published items (incident owner)
Scheduler	Fire deadline events

Check order. Each command goes through these steps, and the first failing step decides the outcome.

Authorize the actor for the event. Failure: refused as unauthorized; nothing changes; a denied-attempt log entry is written.
Publish only: if the idempotency key was already applied, return the stored outcome and change nothing.
Compare the expected revision with the stored one. Mismatch: conflict; nothing changes; the caller is shown the current state.
Check that the table allows the event from the current state. Otherwise: refused as an invalid transition.
Check preconditions in table order. Failure: refused with the specific reason, which is returned to the actor and logged; no audit event; the state does not change. If a reviewer cannot open required evidence, the queue lead is also alerted to reassign the item or restore access.
Apply atomically: new state, revision plus 1, one audit event.

Disputes. Only the learner a result belongs to may dispute it. A dispute is not an item transition: after step 1 it skips steps 2 to 6 and follows this rule instead. It may be filed against a Published, Restricted, or Withdrawn item. It leaves the item's state and revision unchanged, creates an Open case record with an owner from the dispute rota, writes one audit event linking the case to the item revision, and gives the learner the case ID and due time. A decision is due within 5 days, or before the contest results become final for a dispute filed during a contest window.

Contest load. During the weekly 8-hour contest window, disputes arrive at about 12 per hour and each re-review takes about 15 minutes. Two qualified reviewers are on shift, and contest results become final 2 hours after the window closes.

Acceptance fixtures

Acceptance tests should inspect stored state and downstream effects, not only HTTP status codes.

Predict the outcome

Predict the acceptance fixtures

Each row starts from its own stated record for item F-31; rows are independent. Use the actors, transition table, and check order from the context. Predict the outcome, the stored state afterward, and the audit and downstream effects before you reveal them.

Fixture	Start	Command	Outcome	Stored state after	Audit and downstream effects
A1. Authorized reviewer approves an unchanged, complete item	Pending review, rev 4; h1, ev3, p7; evidence complete	Rina: Approve, expected rev 4, reviewed h1, ev3, p7	?	?	?
A2. Unauthorized user submits an approval	Pending review, rev 4	Lee (learner session): Approve, expected rev 4; the request body says reviewer "rina"	?	?	?
A3. Reviewer submits a stale expected revision	Approved, rev 5 (Rina approved at rev 4)	Kai: Reject, expected rev 4, reason recorded	?	?	?
A4. Output changes after approval, then publication is attempted	Approved, rev 5; approval bound to h1, ev3, p7	(a) Generator: Binding changes (new output h2), expected rev 5. (b) Publisher: Publish, key P-1, expected rev 6	?	?	?
A5. Required evidence is missing	Pending review, rev 4; ev3 lacks the hidden-test results	Rina: Approve, expected rev 4	?	?	?
A6. Deadline passes without review	Pending review, rev 4; 48 hours pass with no decision	Scheduler: Deadline reached, expected rev 4	?	?	?
A7. Duplicate publication request	Approved, rev 5; approval valid for h1, ev3, p7	Publisher: Publish, key P-7, expected rev 5; after a timeout, the identical request is sent again	?	?	?
A8. Published output is withdrawn	Published, rev 6	Dana: Withdraw, expected rev 6, reason "explanation quotes another learner's code"	?	?	?
A9. User disputes a result	Published, rev 6	Lee: Dispute F-31, reason "valid approach penalized"	?	?	?
A10. Reviewer cannot open the source evidence	Pending review, rev 4; evidence complete	Omar: Approve, expected rev 4	?	?	?

Reviewer interface and capacity

Show the input, proposed output, rubric, evidence, and known limitations, separate model claims from verified facts, and let reviewers correct, reject, escalate, or ask for more information.

Estimate capacity from arrival rate, handling time, and staffing. If 60 cases arrive per hour and each needs five minutes, the workload is 60 x 5 = 300 reviewer-minutes, or five reviewer-hours, per hour before breaks and rework. One reviewer cannot sustain it, and exactly five leaves no headroom.

Never clear a backlog by silently approving expired items. Reduce intake, restrict automation, add qualified capacity, or change the product contract, and track queue age alongside throughput.

Evaluate the controls

Measure errors caught, errors missed, unnecessary escalations, reviewer disagreement, and time to resolution. Include blind samples so reviewers cannot rely only on the model's framing.

Keep denominators and uncertainty in slice comparisons: ten failures in twenty cases and ten in ten thousand mean different things, and a small sample may be inconclusive. A higher override rate might mean a worse model, more vigilant reviewers, or a changed case mix.

Data lifecycle and audit records

For each data category, document purpose, access, retention rule, deletion path, and derivatives, with an accountable owner instead of indefinite collection.

Audit events identify the actor, action, timestamp, artifact revision, policy revision, decision reason, and evidence references. Protect them from changes, restrict access, and store references instead of full sensitive prompts. A complete audit trail does not mean keeping everything forever.

Escalations, incidents, and remedies

An escalation needs a named owner, a visible response state, and a due time that leads somewhere other than silent closure. Keep what is needed to reproduce the failure, and personal details only where the case needs them.

Match containment to the evidence: restricting a class of outputs is reversible and often better than waiting or withdrawing everything. A remedy corrects affected records through the same review and publication controls as any other output, and changes whatever let the failure through. "Prompt updated" is an action, not evidence of a fix. Tell the affected person what changed without exposing anyone else's data.

Escalation case: a disputed score

Diagnose

Escalate a disputed score

Lee files dispute D-12 against published item F-31 (revision 6): a score of 2 out of 5 on an interval-merging exercise. The solution passes all 14 hidden tests. In the dispute, Lee explains that they use a screen reader and write one statement per line with short landmark comments so they can navigate the code by ear. The published explanation says "Readability: verbose, non-idiomatic structure (minus 3)."

The audit trail shows that Rina approved F-31 under policy p7 after 40 seconds. The review screen showed the model's explanation and score first, with the hidden-test results in a collapsed panel.

The case owner pulls the passing submissions for this exercise from the last 30 days:

Slice	Passing submissions	Readability penalty of 2 or more points
One statement per line with landmark comments	34	31
All other passing submissions	1,166	60

Say who owns D-12, what you preserve as evidence, and where Lee's accessibility details may be stored.
Compute the penalty rate for each slice. Say what the comparison does and does not show, and how you would test the cause directly.
Decide whether to contain similar outputs while investigating. If you do, name the workflow action, who performs it, and its scope.
Say what the F-31 approval suggests about the review setup, name one change, and explain how blind samples would show whether the change worked.
Describe the remedy for Lee and for other affected learners using the workflow rules, the conditions for closing D-12, and what Lee is told.

Completion checklist

I can predict all ten acceptance fixtures and name the check that decides each one.
I can explain why an approval cannot publish a changed artifact.
I can turn arrival rate and handling time into reviewer-hours and say what to change when staffing falls short.
I can take a dispute from filing to verified closure without exposing another person's data.

Sources

NIST AI RMF Playbook Suggested actions organized by the AI RMF functions, meant to be adapted to a system rather than followed as a checklist.
NIST AI Risk Management Framework Voluntary framework for managing AI risks; context for risk registers, accountability, and oversight.
OWASP Authorization Cheat Sheet Recommends denying by default and validating permissions on every request.
RFC 9110: HTTP Semantics Section 13 defines conditional requests such as If-Match, used to prevent lost updates when several clients change the same resource.

The coding-practice platform, workflow rules, fixtures, figures, and rubric are original synthetic teaching material about a fictional application. They describe engineering controls only: they do not establish compliance with any law, regulation, or sector requirement, and no deployed workflow was tested. Study times and readiness thresholds are editorial estimates. Framework and standard references are as of November 2026.

Practice the interview question

Answer it in your own words before you look at the reference answer.

2 of 3

Previous: Make human oversight meaningful Back to Responsible AI & Governance

Next: Govern AI outputs that may be repurposed