How three builds actually work.

1. Provocation, people and capability

Problem: “human in the loop” often names a person without proving that person has evidence, time, authority, a fallback path, or a durable record. The intended users are people inspecting an AI-assisted decision in education, employment, health, law, business, content or another consequential workflow. The tool converts answers into eight scored dimensions, a Strong/Partial/Weak grade, prioritized repairs and a copyable review protocol.

2. What the user does

1. Choose Quick Check or Detailed Design.
2. Describe the decision and possible impact.
3. Answer structured questions about reviewer competence, capacity, timing, evidence access, authority, escalation, recording and testing.
4. Submit the form.
5. Read an eight-dimension result, total score out of 16, grade, repair priorities and generated protocol.

3. Architecture and data

Components: Next.js App Router page → React client form in @rn/forms → deterministic scoring → ProtocolResult renderer. The paired visual uses a client component and an imported HumanLoopReveal; reduced-motion users receive manual tabs instead of autoplay.

Input: browser form strings and selected values. Transformation: each of eight dimensions becomes 0, 1 or 2; total determines Strong (13–16), Partial (8–12), or Weak (0–7). High-risk answers prepend timing, authority and evidence warnings when weak. State: React memory only. Output: assessment object and formatted protocol. Retention: the inspected implementation does not send or persist answers; page copy says answers stay in the browser.

4. Intelligence boundary

Deterministic: all scoring, grade thresholds, gap text, priority ordering and protocol assembly. AI/model/agent calls: none found. External APIs or database: none found in the runtime path. This tool evaluates the design of AI oversight; it does not itself use AI to evaluate the answers.

5. Workflow, branches and safeguards

The main branches are Quick versus Detailed intake, three-level answers per dimension, high-risk priority elevation, result generation, and the reduced-motion visual path. Missing or low-quality answers score down rather than triggering retries. Human intervention happens outside the software: a responsible team must change the real workflow. Safeguards include no account requirement, browser-local processing, explicit non-compliance boundary, keyboard-native form controls, focus styling, semantic fieldsets, live result navigation and a manual reduced-motion experience.

6. Build process and evaluation

The public making record documents five stages: v0 expert-language form; v1 eight-dimension diagnostic; v2 plain-language rewrite; v3 exhibition worktable and screening-room presentation; v4 release gates for provenance, freshness, accessibility, fixtures, parity, lineage, privacy/security and performance. The structural rejection was v0: it required users to perform the analysis the tool was supposed to provide.

7. Reproduce it exactly enough to test the logic

1. Create a Next.js page containing a client-side React form.
2. Define the eight dimensions and three answer levels for each.
3. Map each answer to 0, 1 or 2.
4. Sum to 16 and apply the published thresholds.
5. Collect every dimension below 2 into repair priorities.
6. If risk is High, move weak timing, authority and evidence repairs to the front.
7. Assemble the protocol from the submitted facts and dimension notes.
8. Keep processing local; add no network request.
9. Add a reduced-motion manual equivalent for the paired visual.
10. Test every answer branch, empty selections, keyboard use, 200% text zoom and the no-network claim.

8. Evidence and unresolved gaps

• Implemented source: 001-A page; packages/forms/src/index.tsx; 001-B reduced-motion component.
• Primary-source map: NIST AI RMF 1.0, Regulation (EU) 2024/1689 Article 14, and UK ICO human-review guidance, checked 2026-08-15.
• The composite score is explicitly a product heuristic, not a legal or safety grade.
• Not evidenced in the inspected runtime: server storage, authentication, telemetry, model calls, automated source checking, or production security testing results.
• Registry metadata still describes version 0.1 / Building while the public routes contain later v1.0-style implementation language; release status needs reconciliation.

1. Provocation, people and capability

Problem: two organizations can each appear controlled while responsibility disappears during transfer. The demonstration maps five actors—product owner, contract operation, data service, authorized provider and affected person—and four handoffs. It checks whether responsibility, evidence, permission, acceptance, deadline, incident duty, record and recourse are explicit.

2. What the user does

1. Inspect the prefilled organization chain and four handoffs.
2. Read the status and coverage result.
3. Select “Remove data transfer controls” to blank permission, incident duty and recourse for X02.
4. Observe the chain fall from intact to responsibility gaps.
5. Export the current organizations, handoffs, assessment and boundary as JSON, or reset to an empty chain.

3. Architecture and data

Components: Next.js page → React client demonstration → assessRegulatedHandoffs in the shared decision-engine package. Input: typed organization and handoff objects held in source. Transformation: a field is complete only when trimmed length is at least eight characters; identifiers must resolve; organizations must be linked. The engine translates the regulated map into Build 016’s legal-workflow schema and runs that inherited assessment too. State: React memory only. Output: status, percentage coverage, responsibility gaps, orphan organizations, inherited workflow status and version. Export: browser-generated JSON Blob.

4. Intelligence boundary

Deterministic: completeness checks, graph linkage, coverage calculation, status decision and inheritance into Build 016. AI/model/agent calls: none found. External APIs/database: none found. The regulatory examples are curated text, not retrieved or validated at runtime.

5. Ordered logic

1. Check every organization’s role, authority, accountable owner and governing source.
2. For each handoff, confirm both endpoint IDs exist.
3. Check nine required handoff fields.
4. Require market, bounded regulated activity and affected people.
5. Identify organizations that appear in no handoff.
6. Translate the map into Build 016 nodes and handoffs.
7. Run the inherited legal-workflow assessment.
8. Calculate complete objects divided by total objects.
9. Return CHAIN UNDEFINED, RESPONSIBILITY GAPS or ACCOUNTABILITY INTACT.

6. Safeguards and evaluation

The interface says no regulated, health, client or personal data is transmitted or retained. It labels itself an architecture demonstration—not legal advice, compliance certification, product-quality approval, consent validation or authority to act. The destructive-looking reset only clears in-memory demo state. Export is user-initiated and local. Native buttons and descriptive text support keyboard use; however, the page does not evidence a completed formal accessibility test report.

7. Reproduce it

1. Define the organization and handoff TypeScript types exactly.
2. Create a fixed organization list and a handoff list with stable IDs.
3. Implement the eight-character completeness function.
4. Validate endpoints before scoring a handoff.
5. Collect missing fields as human-readable gaps.
6. Map the data into the Build 016 workflow engine and preserve its status.
7. Calculate coverage and choose the three-state result.
8. Render every field so a person can see why the status occurred.
9. Add a controlled failure button and local JSON export.
10. Test full, broken, empty, unknown-ID and orphan-organization fixtures.

8. Evidence and unresolved gaps

• Implemented source: RegulatedHandoffLab.tsx and assessRegulatedHandoffs in packages/release/src/decision-engines.ts.
• Documented engine record: data/build-017-engine-v1.json, version 017.1.0.
• Named sources: FDA Contract Manufacturing Arrangements for Drugs: Quality Agreements; 45 CFR 164.504; both recorded checked 2026-08-17.
• The source record classifies the inherited workflow and responsibility-gap rubric as product heuristics.
• Registry says Planned, version 0.0, with null URLs even though /017/a and /017/b are implemented. This is a canonical-status defect, not proof that the runtime is absent.
• Not evidenced: real market configuration, jurisdiction engine, authentication, data storage, automated legal updates, real incident routing, unit-test results, or review by counsel/regulator.

1. Provocation, people and capability

Problem: island shocks create connected effects across food, power and care, while decisions can hide weak ownership or invalid allocations. The current build is a bounded rehearsal for choosing one of three synthetic shocks, one of three interventions, zero to five capacity units and whether an accountable owner is confirmed.

2. What the user does

1. Select port interruption, grid outage or severe storm.
2. Select restore port flow, deploy microgrid or open community hubs.
3. Choose capacity units from zero to five.
4. Confirm or remove the accountable owner.
5. Read BLOCKED or REHEARSED, direct fit or tradeoff, three consequence meters and a gate trace.
6. Copy the JSON decision record.
7. In the paired visual, open the decision room and reveal the 17 declared direct dependencies within the 001–100 sequence.

3. Architecture and data

Components: Next.js page → React DecisionRoom → pure TypeScript scenario engine. The paired Convergence component imports the engine’s lineage constant. Input: four local values. Static data: a three-row shock table, expected intervention per shock, fixed clock and 17 build IDs. Transformation: three gates run in sequence; after the first failure, later gates become NOT_RUN. A matching intervention reduces each consequence only if no gate stopped execution. State: React memory only. Output: frozen result object and JSON export copied to the clipboard.

4. Intelligence boundary

Deterministic: every output. AI/model/agent/data pipeline: none found. Forecasting: none. External action: hard-coded false. “Scenario platform” currently means a small synthetic rule engine and interface, not a digital twin, optimization model, live data system or emergency tool.

5. Ordered logic

1. Validate capacity is an integer from 0 through 5.
2. Require accountable owner.
3. Require at least two capacity units.
4. Stop evaluation after the first failed gate; mark subsequent gates NOT_RUN.
5. Look up the shock’s base food, power and care values.
6. Compare the selected intervention with the one fixed match for that shock.
7. If gates pass and intervention matches, reduce each consequence by min(2, units − 1).
8. Clamp each consequence at zero.
9. Return BLOCKED or REHEARSED, DIRECT or TRADEOFF, trace, consequences, lineage and the non-operational notice.

6. Safeguards and accessibility

Fail-closed sequential gates prevent a rehearsal from passing with invalid capacity, no owner or inadequate capacity. The result explicitly states it has no external effect and is not a forecast or emergency instruction. The copy operation handles missing clipboard access and exposes success/failure through a status region. Form labels, output and meter elements are present. No evidence was found for real emergency data handling, threat modeling, disaster-professional review or a formal accessibility report.

7. Reproduce it

1. Define the four-value scenario input union types.
2. Create the shock consequence table and intervention-fit table.
3. Implement the three ordered gates and NOT_RUN behavior.
4. Apply the reduction only after all gates pass and fit is direct.
5. Freeze and export the result with the explicit external-effect false flag.
6. Build labeled controls and render the three consequence meters plus trace.
7. Add clipboard failure handling.
8. Render all 100 build IDs and mark the 17 declared lineage dependencies.
9. Test all 3×3×6×2 = 108 input combinations.
10. Verify no network request or external action occurs.

8. Evidence and unresolved gaps

• Implemented source: DecisionRoom.tsx, Convergence.tsx and packages/release/src/build100-scenario-engine.ts.
• The fixed direct lineage is 001, 020, 030, 034, 038, 040, 046, 047, 058, 063, 069, 071, 074, 077, 084, 095 and 099.
• Registry says Planned, version 0.0, with null URLs even though /100/a and /100/b are implemented.
• No build-100 engine JSON record was found at the parallel data path used by Build 017.
• Not evidenced: source justification for numeric consequence values, causal model, live island data, probability, geospatial data, optimization, multi-intervention allocation, cost, uncertainty, user accounts, persistence, collaboration, APIs, agents or external effects.
• “Complete preceding capability stack” is a registry aspiration. The inspected runtime directly imports only the scenario engine and its fixed lineage list; it does not execute 99 earlier builds.