using-procedural-architecture
Using Procedural Architecture
Overview
A procedure is a directed structure of stages with state, flow, decision points, and capacity — treat it as one, or it calcifies into ad-hoc steps that nobody can audit, change, or scale.
This pack treats a procedure as an abstract object: a graph of stages, each with declared inputs, an exit artifact, and a defined relationship to decision points that select among successors. The shape of that graph — its dependencies, its branching, its grain, its capacity — is the artifact this pack designs and audits. A wizard is a procedure. A troubleshooting tree is a procedure. A training curriculum is a procedure. A multi-stage approval pipeline is a procedure. A decision pipeline is a procedure. The same structural discipline applies whether the procedure is run by a human, by an LLM, by a team, or by a queue of jobs.
In smell-name vocabulary, "step" is the colloquial alias for "stage" — the catalog uses god-step, mystery-step, and ladder-of-trivials because the smells are recognized under those names. Outside the smell catalog, prefer "stage."
Three roles over one shared corpus: a producer ("thinker") that constructs decompositions forward — goal in, stages out, dependencies declared, decision points enumerated, exit artifacts named, audience parameters stated; a critic ("checker") that adversarially audits a proposed decomposition backward — defects in, findings out, with severity and evidence on every finding; and an analyst that characterizes flow properties (capacity, soundness, stochastic behavior) when structural review alone is insufficient. The roles read the same 13 reference sheets with different epistemics. If the producer and critic always agree, the critic is rubber-stamping — that is a bug in the pipeline, not a feature.