Craft Is Data
A named pipeline is not a second engine. It is a compact policy record describing how one recurring task shape should enter the existing engine. The row names the shape, explains it to humans, carries the brief template, lists required proof stages, sets a review default, and may hint which brain usually fits.
This design separates the stable from the variable. Claims, status transitions, review rounds, attachments, and landing records remain code because their invariants must be identical. Task instructions and stage choices become data because operators need to refine them as the craft becomes better understood.
Data-driven does not mean free-form. Live Crucible requires a unique kebab-case name, a nonblank template, and a stage-name list whose entries, if any, are nonblank. It accepts the review default as a boolean, stores it in SQLite as 0 or 1, and returns it as a boolean; the default brain remains an advisory hint. It does not yet own a global stage vocabulary, so inspecting stage spelling remains operator work rather than an enforced invariant.
The row is also inspectable. A pipeline list can show title, version, review default, required stages, and archival state without reading source code. That turns workshop configuration into an operational surface Dad can reason about directly.
The Minimum Useful Row
Keep only fields that change how work is admitted, authored, reviewed, or proven. A visual preference belongs in the UI; a required stage belongs in the row. A secret does not belong in either. The schema is a product boundary, so each field needs an owner and a reason.
A useful audit takes one row and asks what would happen if each field changed. If no externally observable behavior or brief text changes, the field is likely decorative or misplaced. If changing it bypasses validation, the row is carrying executable code in disguise.