Human-in-the-loop vs human-in-time: oversight before impact

Learn in your browser · Chapter 01 of 07

A human control is useful only if it can change an outcome that matters. Start with the action and its consequences, then decide where people belong. The phrase human-in-time is a teaching label in this workbook, not a recognised accreditation, legal category or universally agreed standard.

Mickai's Trust Agent principle is that AI should remain under meaningful human control. That does not require a person to approve every harmless formatting step. It requires deliberate boundaries: what may happen automatically, what needs a specific decision, what must be prevented, and who can change those rules. Sovereignty includes decision rights as well as possession of data or models. A locally hosted system can still remove a person's practical control if it acts before they can intervene.

Our case is Alder Quay Services, a fictional maintenance business. Its assistant, Relay, reads synthetic service tickets, drafts replies, proposes goodwill credits and suggests customer-account changes. All names, amounts, timings and policies in this workbook are invented teaching assumptions. Relay may prepare drafts without approval. Under the example policy, any external send, financial credit or bank-detail change requires an authorised person before execution. The policy is intentionally conservative for practice; it is not a universal threshold.

Scroll sideways to see every column.

A common weak design notifies a manager after a tool call and describes the manager as in the loop. That may support detection and recovery, but cannot prevent the completed action. An effective design separates proposal from execution and blocks the latter until its conditions are met. For genuinely reversible, low-consequence actions, bounded automation with monitoring may be reasonable after a documented assessment. Treat reversibility as a tested property with time and scope limits, not a comforting adjective.

1. Write one action in concrete terms: actor, target, data, operation and maximum effect. Avoid labels such as manage customers.
2. Draw the sequence from input to committed effect. Mark every place the effect can escape, including secondary tools and queued jobs.
3. Name affected people and plausible harms from the action and from delaying it. Assign a consequence owner.
4. Choose prevention, bounded automation or detection-and-recovery for each action class. State why the choice fits the consequence.
5. For a preventive human gate, measure the available window and the full intervention path: queue, review, decision delivery and enforcement.
6. Specify the failure state. If the person cannot decide in time, the system must follow that stated policy rather than silently treating absence as consent.

def intervention_margin(window, queue, review, delivery, enforcement):
    values = (window, queue, review, delivery, enforcement)
    if any(value < 0 for value in values):
        raise ValueError('Durations must be non-negative')
    return window - sum(values[1:])

late = intervention_margin(12, 5, 8, 1, 1)
early = intervention_margin(30, 5, 8, 1, 1)
assert late == -3
assert early == 15
assert intervention_margin(15, 5, 8, 1, 1) == 0
print({'late_margin_seconds': late, 'early_margin_seconds': early})

This calculation is an arithmetic illustration, not a latency benchmark or a safety proof. Zero margin leaves no reserve; positive margin still depends on correct measurements, variation and working enforcement. A human cannot reliably supervise a millisecond actuator by watching a dashboard. Such systems need domain-appropriate automatic bounds and separately designed human authority over operation, configuration and recovery. Do not transplant this business-workflow exercise into a safety-critical controller.

Learn in your browser · Chapter 02 of 07

A person touching a device, authenticating to an account and approving a particular operation are different events. Meaningful control depends on the combination appropriate to the action. No single green badge should collapse all of them into a claim that the action is trustworthy.

Begin with claims, not products. Identity describes who an account is associated with under an enrolment process. Authentication concerns evidence that the claimant controls an authenticator. Presence concerns a defined interaction. Understanding concerns whether the relevant decision information was comprehended. Intent concerns the decision about this action. Authority concerns whether the person may make that decision now. A system can have strong evidence for one claim and weak evidence for another.

NIST SP 800-63B-4 distinguishes authentication intent from passive capture: an explicit response can establish intent to authenticate under that mechanism. That is narrower than proof that someone understood and approved a customer-account change. W3C WebAuthn Level 2 likewise distinguishes user presence from user verification. A presence test indicates an interaction under the authenticator's rules; it is not, by itself, user verification or proof that the application transaction was understood. These are technical reference concepts, not a global legal definition of consent.

Scroll sideways to see every column.

In Alder Quay, an accounts officer can approve a £300 service credit but cannot change bank details without a separate verified request and designated finance approval. Being the same physical person does not erase that distinction. A manager's recorded voice or familiar face is insufficient evidence of identity or authority. A call can be spoofed, relayed or misunderstood; even a real manager can lack the relevant permission. Use an independent established contact route when verifying a sensitive request, with procedures that do not depend on the suspicious message itself.

1. List each claim needed for the action: account association, authentication strength, current authority, action-specific intent and any independent business verification.
2. For each claim, identify the evidence source, trust boundary, expiry and failure mode. Mark unknowns rather than substituting a confidence-looking icon.
3. Bind the application decision to material details the person can inspect. Do not label a generic sign-in success as transaction approval.
4. Check authority for this target, amount, organisation and purpose at the point of use; handle revoked or changed roles explicitly.
5. Plan accessible alternatives for people who cannot use the preferred interaction. Preserve equivalent decision information and control rather than requiring one physical gesture from everyone.
6. Choose data-minimising evidence. Prefer a scoped decision record over retaining raw voice, face video or a full workstation recording.

A comprehension question can reveal a misunderstanding, but passing it is not proof of full understanding. Similarly, a declaration that someone is not under duress does not establish that fact. Specify honest evidence labels in the interface and in audit exports. An evidence gap should produce an actionable route such as seek clarification or hold for verification, not a misleading percentage called human certainty.

Learn in your browser · Chapter 03 of 07

An approval is useful only if the system executes the action that was approved, under the conditions that made the decision valid. This chapter specifies a state machine and final gate. It is an architecture exercise, not production security code.

Relay must propose a bounded operation rather than receive an unrestricted instruction to do whatever the reviewer intended. A proposal identifies an action type, organisation, resource, relevant current version, material payload, policy version and expiry. For a credit, material details include the amount, currency, customer and reason. For a bank change, the destination is material. Changing any material field invalidates the prior decision and requires a fresh proposal.

OWASP's Transaction Authorization guidance supports separating authentication from transaction authorisation, presenting significant transaction details, limiting authorisation validity and checking it immediately before execution. OWASP's general Authorization guidance also calls for server-side permission checks on each request. The architecture below applies those principles to the fictional workflow. A browser button, hidden form field or model-generated statement of approval is not the trusted decision service.

Scroll sideways to see every column.

Example approval envelope, invented data only
proposal_id: P17
organisation_id: alder-quay-demo
operation: issue_credit
customer_id: demo-customer-42
customer_version: 4
amount_minor_units: 30000
currency: GBP
reason_code: delayed_service
policy_version: credit-policy-3
expires_at: explicit server-controlled timestamp
action_digest: digest of canonical material fields
reviewer_id: authorised account reference
decision: approve
decision_event_id: unique one-use approval reference

A digest can help detect differences in a canonical representation, but a digest alone provides no authorisation or provenance. Define exactly which fields it covers and how the representation is produced. Excluding the customer or currency would make a matching digest misleading. Protect approval records using an appropriate trusted service and access controls; if signatures are used, manage and verify the keys and their scope. Cryptography does not repair an incorrect policy or a deceived reviewer.

Checking the target version and applying the mutation must be coordinated at the actual write boundary, for example through an appropriate conditional update. A separate read followed by an unconditional write leaves another race. If the external service cannot enforce the required condition, record the unresolved integration limit and hold the affected release claim.

1. Separate the proposal service from the service holding execution permission. Deny direct tool routes that bypass the final gate.
2. Create an immutable proposal version from validated material fields. Display those same fields with evidence, consequences and alternatives.
3. Capture an affirmative approve or deny decision from an eligible reviewer. Do not allow the model to supply the decision or upgrade a role.
4. At execution, recheck current authority, policy, expiry, one-use decision reference, action equality and target resource version.
5. Make checking and consuming approval atomic with respect to competing execution attempts where the system permits it. Use a defined idempotency mechanism for external effects and test its scope.
6. If the target changed, the decision expired or a check is unavailable, follow the documented hold or denial path. Reconcile uncertain external outcomes before retrying.

The average approach stores approved=true beside a mutable task and trusts the worker to inspect it. The stronger approach defines the authorised object, identifies every material change, enforces a versioned state transition in the trusted execution path, and tests hostile or accidental substitutions. It also states the remaining risk: an approved action can still be based on incomplete evidence. Oversight is one layer, alongside access boundaries, validation and independent checks.

Learn in your browser · Chapter 04 of 07

A technically correct gate can still produce poor decisions if its reviewer sees only the model's preferred answer, lacks training or faces an impossible queue. Design the human operating model with the same care as the API.

A reviewer needs more than Approve and Reject buttons. Show the proposed effect, the source evidence, the policy that applies, important uncertainty, changes since a previous proposal and the consequences of delay. Make alternatives real: reject, request clarification, escalate, amend through a new proposal or pause the workflow. A model summary can help navigation, but it must not replace access to the relevant underlying evidence.

In the example, Relay recommends a £300 credit because a synthetic ticket says a technician missed an appointment. The reviewer also sees that the service record lists a completed visit and that the ticket came from an unverified channel. A weak interface displays a green recommendation and hides the disagreement below the fold. A stronger interface makes the contradictory records visible, explains what is and is not verified, and offers Hold for clarification without punishing the reviewer for taking it.

Scroll sideways to see every column.

Capacity is part of control design. Suppose three trained reviewers each require an average of 45 seconds per synthetic case. Their arithmetic upper bound is 3 × 3600 / 45 = 240 cases per hour before breaks, interruptions, escalations or variation. A burst of 50 cases in ten minutes is an arrival rate equivalent to 300 per hour during that interval. It exceeds that nominal service rate. The calculation is not a staffing forecast; measure realistic review distributions and bursts before setting service targets.

1. Define the skills and authority required for each action class. Train using conflicting evidence and plausible incorrect recommendations, not only clean examples.
2. Design an evidence packet with progressive detail, clear action consequences and accessible alternatives. Keep the decision controls consistently placed.
3. Measure queue wait, review time, escalation time, expired proposals and disagreement outcomes using synthetic trials first.
4. Compare arrivals with realistic capacity, including absence and peak demand. Add limits to the automation's proposal rate before queues become unmanageable.
5. Route overflow to hold, bounded alternatives or a designated on-call process. Preserve the approval rule instead of auto-approving under pressure.
6. Review quality and challenge rates alongside speed. Do not reward raw approval volume in a way that discourages scrutiny.

W3C's explanation of WCAG 2.2 Timing Adjustable describes options for user control over time limits and relevant exceptions. This course does not certify WCAG conformance. In our design, business validity and reading time are separate: when a proposal becomes stale, preserve the person's notes, obtain fresh evidence and issue a new proposal rather than forcing a rushed click. A security timeout may end a session while a recoverable draft remains available through an appropriate re-authentication path. Accessibility must be considered in the actual threat and workflow context.

Learn in your browser · Chapter 05 of 07

A stop button is a claim about a system boundary. Test what it stops, how quickly, and what may already have escaped. Recovery needs a separate plan because preventing a new action and reversing an old one are not the same operation.

For Alder Quay's account workflow, the defined safe state is to hold new bank changes and preserve the existing account record while an authorised team investigates. For some other systems, stopping immediately could create additional harm. This workbook's business example is not a universal emergency-stop design. A competent domain owner must choose the relevant safe state and the controls needed to reach it.

Draw three populations of work: proposals not yet approved, approved work waiting to execute and operations already sent to an external service. A local pause can stop the first two if every execution path consults the gate. It may not cancel the third. The response must establish the external operation's status, preserve evidence and choose a separately authorised correction where needed. Do not report all work stopped merely because the dashboard changed colour.

Scroll sideways to see every column.

Silently failing open makes unavailable controls look successful. However, failing closed is not the end of the design: a prolonged hold may harm customers or service continuity. Define an escalation and, where justified, a constrained manual route with named authority, limited scope and retrospective reconciliation. Emergency access is not a standing alternate credential for the agent. Its use should be visible, controlled and reviewed.

1. Define what the stop affects: action types, tenants, workers, queued jobs and credentials. Name an operator who can invoke it independently of the agent.
2. Instrument transitions using stable identifiers and time sources appropriate to the system. Record where ordering remains uncertain.
3. Inject one failure at a time in an isolated synthetic environment, then test selected combinations such as role revocation during a retry.
4. For every test, write the expected state and side-effect count before execution. Capture the observed result, not only a screenshot of a success banner.
5. Reconcile uncertain external effects before retrying. Use the external service's actual operation identifiers and idempotency contract where available.
6. Restore service in a controlled order: verify the fault, reconcile pending work, revalidate authority, refresh stale proposals and approve the restart.

A useful test report distinguishes simulated results from observations of the real integration. Passing a unit test of a state machine does not prove that a worker, credential path or third-party API respects it. Test failure paths, role changes, duplicate delivery and concurrency at the appropriate layers. Avoid publishing latency or safety percentages from a handful of synthetic runs as if they measured general performance.

Learn in your browser · Chapter 06 of 07

An evidence record should help answer a defined question without collecting everything about everyone. An attestation is a scoped statement supported by evidence; it is not proof that a decision was wise, lawful in every region or made by an uncoerced person.

For Alder Quay, a useful claim is: the execution service recorded credit C81 after a decision for proposal P17, with its listed checks satisfied. Supporting evidence links proposal version, decision event, authority evaluation, execution attempt and observed result. A much broader claim, such as a human fully understood and legally authorised everything, requires evidence the event record does not contain. State the narrower claim and the remaining uncertainty.

Scroll sideways to see every column.

A signature can support verification that a statement came from a key holder and was not altered under the chosen verification process. It does not establish that the original observation was true, that the signer had the business authority claimed or that omitted events never occurred. Store the verification method and evidence scope. Distinguish event ordering inferred from logs from ordering established by an actual transactional mechanism; clock timestamps alone may not settle a race.

1. Write the question each record must answer, such as whether the approved target matched the executed target.
2. Collect the minimum fields needed for that purpose, using references where appropriate. Classify sensitivity and separate public verification data from private evidence.
3. Define who can create, read, change and delete records, with suitable protection and auditability for those actions.
4. Set a reasoned retention and deletion policy considering applicable obligations and disputes. Avoid inventing one duration for all jurisdictions and all evidence.
5. Test retrieval, access denial, redaction and the ability to explain a missing or uncertain event. Verify the actual mechanism before making a tamper-evidence claim.
6. Write the attestation in narrow language and have its owner confirm that the evidence supports every clause.

Legal and standards references must be scoped and versioned. The NIST AI RMF is voluntary guidance; NIST's current page says version 1.0 is being revised. It is not a law or a Mickai certification scheme. Use it as a structured risk reference where appropriate, and record the version used. Engineering patterns in this course do not by themselves demonstrate conformance with a standard or a legal duty.

Scroll sideways to see every column.

Choose jurisdiction using the actual deployment, people affected, processing and organisational roles, not merely the vendor's address. Record separate rows when more than one region matters. This workbook does not provide exhaustive worldwide legal coverage. The owner of a legal question should resolve it against current primary material, with qualified advice where needed; the engineer should meanwhile state the uncertainty and avoid making the affected release claim.

Learn in your browser · Chapter 07 of 07

The capstone joins architecture, reviewer operations, failure handling and evidence into one reviewable decision. The aim is not to produce a confident-looking document. It is to expose the conditions under which a system may act and the gaps that prevent a justified release.

The capstone transfers Relay's account-control lessons to procurement. Alder Quay wants to buy ten replacement pump assemblies for GBP 75,000 from a fictional verified supplier. The agent can draft a purchase order but cannot release it. Release creates the supplier obligation and is the consequence boundary. Use the supplied synthetic procurement lab and design the surrounding human process; no real supplier, payment or personal information belongs in this exercise.

Budget ten hours for reading, exercises, chapter review, the procurement lab and assessment preparation. This is an author estimate, not measured learner completion data. Work through the chapters in order: the consequence map determines the claims, the claims determine the gate, and the gate determines the tests. Keep separate notes for decisions, uncertainty and observed evidence. Running the example is the beginning of the capstone, not a completed assurance assessment.

Scroll sideways to see every column.

Downloadable synthetic lab bundle, supplied alongside this workbook:
  approval_lab.py
  test_approval_lab.py

Run with Python 3.10 or later, without external packages:
  python approval_lab.py
  python test_approval_lab.py

Expected baseline: 27 tests pass.
Expected lost-response sequence: uncertain, uncertain, committed.
Expected supplier operation count: 1.

The lab lock orders checks and mutation within one process. It does not provide durable transactions, authentication, secure clocks, crash recovery, distributed locking, cross-service atomicity or independent audit storage. The supplier dictionary simulates idempotency; it is not a real network. The content digest binds fields in this exercise but does not prove identity, intent or truth. Keep these exclusions in your dossier. Do not copy the fixture into a production authorisation endpoint.

1. Create a scope page naming the action, affected party, consequence boundary, owner, assumptions and excluded systems.
2. Add the claim-and-evidence matrix, proposal envelope, authority rules and transition diagram. Identify every execution path.
3. Attach the reviewer screen sketch, training scenarios, capacity assumptions, accessible alternatives and overflow procedure.
4. Add the stop, reconciliation and restart runbooks, plus at least eight tests with expected outcomes written before rehearsal or execution.
5. Assemble the privacy and evidence policy, jurisdiction register and the exact assurance statement you are prepared to defend.
6. Have a reviewer challenge the dossier, record unresolved findings and produce a go, hold or stop decision tied to those findings.

Scroll sideways to see every column.

Use the rubric for learning review: above 80 out of 100 is the target, and an unresolved critical bypass prevents a ready-for-release recommendation even with a high total. This is a capstone review rule, separate from the online exam. A reviewer must not award testing points for an invented runtime result. A well-evidenced hold can be an excellent learning outcome when it identifies a genuine unresolved risk.

Before starting the exam, read the assessment instructions and privacy notice for the name, attempt information and certificate fields that are stored or disclosed, and how to seek correction or review. Do not put real customer records, credentials, confidential employer material or biometric recordings into workbook answers or exams. A chapter-review mark saved in this browser is a study aid, not a completed assessment. Do not assume browser notes are encrypted or that every feature stores information only on your device.

Written responses in this course are practice for human review and do not earn automated certificate points. Keyword matching can accept disconnected terms and reject valid reasoning. The assessment materials separate 40 multiple-choice knowledge questions from seven written prompts. A scored practical assessment would need a separate agreed marking and appeal process; the course certificate records the knowledge assessment, not professional competence or a production release decision.

Take the official Mickai exam using the course exam link.

Pass requirement: strictly above 80 percent.
With 20 equally weighted questions, 16 correct fails and 17 passes.
Written practice and the capstone are ungraded learning activities.
The named, dated educational certificate has a verification page.