The incident archive

Failures are factory material.

INCIDENT / 01

The tests passed. The game still looked wrong.

Fighter passed its geometry checks and still fell short of the product bar. The factory had measured whether the interface fitted. It had not measured whether the interface worked as a composition.

Factory incident28 September 2026
6 minute read

Method: the incident archive publishes reviewed lessons from project work. Private repository records are not reproduced.

Factory learning

A failure should change a control.

The incident archive contains one published incident. The pattern register below collects risks in the reviewed project work. These are controls to keep, not six more incident reports.

PLATE 03

Turn a failure into a control

28.09.26
Turn a failure into a controlThe loop is only complete when the changed control is rerun against the same failure class and the result is recorded.LOFTWAH SOFTWARE FACTORY · TURN A FAILURE INTO A CONTROLOBSERVESee the outcomeUse the real screen.TRACEBind the claimUse the exact revision.CONTAINLimit the harmStop unsupported action.CHANGEUpdate the controlFix gate or product.RECHECKSame failure classProve and record.THE CONTROL TRAVELS WITH THE LESSON
  1. Observe · See the outcomeUse the real screen.
  2. Trace · Bind the claimUse the exact revision.
  3. Contain · Limit the harmStop unsupported action.
  4. Change · Update the controlFix gate or product.
  5. Recheck · Same failure classProve and record.
The loop is only complete when the changed control is rerun against the same failure class and the result is recorded.

AI and factory failure patterns

Fluent output still needs evidence.

The examples come from recurring project risks. Each one needs a control that survives the next run.

  1. Confident invention at a source gap

    Leave unknowns visible. Require a source for each factual claim and keep expansion behind the parity gate.

  2. Passing checks used to certify feel

    Tests can miss hierarchy, pacing and play quality. Inspect the screen in the real flow and intended viewport.

  3. Old proof attached to new code

    Bind a result to the exact source or release, then repeat the check after a change.

  4. One percentage hides changed scope

    Record what the denominator includes and when it changes. Name the work that remains.

  5. Simulation stands in for people and hardware

    Software checks cannot prove the device, environment or human path. Observe each physical boundary directly.

  6. Polish covers missing information

    Label promotional art, show the product state and next proof, and remove claims the source cannot support.