Applications

Examples

Three examples of how declarations and decisions are recorded. All factories, organizations, people and figures are fictional.

This page is a summary. The full records and YAML are in specs/examples/ (written in Japanese).

1. Point versus line improvement

Keep, find, try / point-vs-line-improvement.md

Situation

At Kitahara, a fictional parts factory, two improvements start at the same time. Improvement A automates daily reports with a spreadsheet macro. Improvement B collects equipment operating data on a small industrial PC to make stoppage causes visible. Three months later both are judged effective, and on average A (30 minutes a day) looks larger than B (20 minutes a day).

A year later, the company changes its report format. A's macro stops working, its author has moved to another team, and the reports go back to manual work. When the work changed, nothing remained. B is rolled out to line 2 in about half the effort of line 1, and the quality control section, which nobody asked, requests the data. When the PC's operating system reaches end of support, the team updates it without stopping the line.

What was declared

• A: residual_assets empty, no spread signals declared → treated as a point improvement
• B: a standard OS image, a factory-wide stoppage code system, the skill to switch to a spare unit, and the equipment configuration record are each declared in residual_assets with a holder. spread_signals.expected: cheaper second use, unsolicited pull. blast_radius declares that it never writes to control systems

Decisions

B's Expand is recorded as a decision that updates the blast_radius declaration, before and after, without changing the chapter. The signals were not the only basis: switchover drills had shown that the widened scope could still be recovered. A is not a bad improvement. It is enough to decide in advance whether to keep it small or end it when the format next changes.

2. Custody across handovers

Keep, pass on / custody-handover.md (machine-readable case)

Situation

A company lets an LLM-based auto-responder handle first-line customer inquiries, running at night and on holidays with nobody watching. A person in the IT department closes the decision "refund and cancellation inquiries are never completed by the auto-responder; they are always escalated to a human" (Proceed). When the model is replaced, classification behaviour changes; when that person moves on, nobody knows the basis.

What was declared

• value_intent: what is protected is not the automation rate but the continuity of customer trust
• re_derivation_basis: the premises and evidence, such as the need for humans to absorb what the classifier of the time missed
• review_triggers: model replacement, a change of refund or cancellation policy, a large shift in the escalation rate, a change in the underlying regulation — events, not the calendar

Decisions

1. The owner's transfer is appended to custody_chain, with confirmation that the successor can re-derive the judgment
2. The vendor replaces the model and a review trigger fires. The new model is more accurate, but what is protected is trust, not accuracy, so the successor rejects the shortcut "more accurate, so automate it", updates the basis and decides Proceed
3. The result is recorded as last_reaffirmed, renewing the tenure

Approval at a gate starts responsibility; it does not sustain it. Without a handover record, it cannot be verified across the handover that responsibility did not disappear (axiom A1).

3. A factory AI agent

Close, try, AI extension / factory-agent-safe-loop.md

Situation

A factory introduces an AI agent that interprets sensor data (temperature, vibration, current), detects anomalies, proposes equipment control actions and plans maintenance. A late decision causes physical damage and production loss; an unnecessary stop from a wrong decision also costs production.

Design decisions

• Separate the physical and semantic loops — the AI never operates the control system directly. A boundary sits before any AI proposal reaches the real world, and an operator closes the decision before instructions go to the control system
• Decide in advance which decision closes which severity — for an imminent safety risk, the on-site operator checks the evidence, stops the equipment and narrows the scope (Limit). For degradation within the safe range, the maintenance engineer holds it until the next maintenance cycle (Defer). For an ambiguous signal, the guard verdict is unknown and it is held until evidence is complete (Defer)
• Check that sensors reflect reality before the AI interprets them; if a fault is suspected, stop the AI's interpretation and switch to an on-site check
• Keep field knowledge — the AI presents hypotheses and evidence; experienced engineers add context and equipment history and decide. The log keeps the AI's hypothesis and the human assessment separate
• Design the halt — the halt owner is a role always present on site. Physical safety interlocks work independently of the AI's halt
• Do not add to the operators' load — if alerts increase, improve filtering rather than widening the AI's autonomy

For the loops, see the AI extension; for the responsibility boundaries involved (B2, B3, B6, B9, B10, B15), see taxonomy.md.