Architecture storyProfessionalA fictional production incident about a correct rollback that did not repair the work already produced by two behavioral releases.
MeridianClear is a fictional capital-markets operations company. Banks and investment firms use its platform to turn signed trading agreements and later amendments into structured terms that booking, risk, and client-operations systems can use.
Five finance terms are enough for this story. An agreement contains the original legal terms. An amendment changes them later. Structured terms are the machine-readable proposal extracted from those documents. Booking commits an approved operational revision. A collateral requirement is one downstream calculation that uses the booked terms.
MeridianClear built TermWeaver, an AI application that proposes structured terms from signed documents. It reduced repetitive reading, but it did not decide what a contract meant and it could not book anything.
Mira Sen (the AI platform architect responsible for immutable behavior manifests, inference-attempt evidence, routing, and recovery coordination) owned the path from document input to a reviewable proposal. A contract-operations analyst checked the proposal against the source. A second approver provided four-eyes authorization before booking. Legal Product owned clause-precedence policy. The Booking Platform owned committed revisions. Risk and Margin owned collateral calculations and client notices derived from those revisions.
Architecture storyAdvancedA fictional production incident about correctly routed reasoning work that consumed its useful deadline.
IonWeave Semiconductor is a fictional chip manufacturer. Its fabrication plants run hundreds of tightly controlled tools that deposit, etch, measure, and clean material during chip production. A stopped tool is expensive. An unsafe restart is worse.
IonWeave built ToolSage, an internal AI assistant for line engineers. When a fabrication tool raised an alarm, ToolSage received a sealed machine-state snapshot, maintenance notes, and the approved runbook revision. It drafted a cited troubleshooting plan. It did not clear interlocks, change a recipe, or send commands to equipment. It had no equipment credentials.
Yuna Park (the inference reliability lead responsible for model routing, reasoning policy, and admission) owned the path from a ToolSage request to a completed model response.
A line engineer checked the response against the machine state shown by the tool. An equipment owner alone could authorize an approved runbook step or take manual control. The useful outcome was therefore not “model produced text.” It was “owner received enough verified information to decide safely while the incident was still actionable.”
The Tool Control Gateway sealed the alarm code, interlock bit, recent sensor state, maintenance notes, tool support status, recipe revision, and current runbook. ToolSage then applied route policy TS-31 to those authoritative fields.
Known routine alarms used Torch-Triage-12B/r2026.07.2, prompt template TRC-5, with no adaptive reasoning and at most 600 output tokens. Novel recipe alarms and active safety interlocks used Torch-Reason-70B/r2026.07.1, also with TRC-5, with an adaptive 800–8,000-token and at most 1,000 output tokens. Both ran on the fictional IonServe/r4.8.1 runtime.
TS-31 did not ask a model whether an interlock was active. It read interlock_active, supported-tool state, and recipe revision from the gateway and registry. Model utility came after hard eligibility. If a request was eligible, the selected model proposed a plan; the engineer verified it; the equipment owner decided what happened next.