Origin
Prestruct exists because most software projects are governed only after the fact — by review processes that catch some problems, by audits that find others, by incidents that surface the rest. The cost of that pattern is well understood: rework, drift, scope confusion, and the slow erosion of intent across the gap between what was meant, what was specified, and what was built. Prestruct sits upstream of that gap. It is a pre‑execution intelligence platform — the architecture, governance, and defensibility argument are produced before the code is. The system the team builds is the system the team specified, because the specification was treated as the first piece of engineering, not a document to write afterward.
Design
A user arrives with a raw idea, a problem space, or an existing artifact. The pipeline runs them through Entry Mode Detection, Strategic Discovery if triggered, Original Intent capture, validation, structural mapping, hierarchy and level diagnosis, architecture, system design, and master specification. Every stage produces a stored, versioned artifact. Every stage runs alignment against the Original Intent Record. The pipeline ends in a hardened specification, a non-technical brief, a machine-readable export, and an artifact vault — and is optionally extensible into build orchestration and prompt generation for downstream Claude Code workflows.
Structure
Twenty-one locked principles govern the system. The Original Intent Record is write-once and immutable; nothing downstream can rewrite the anchor. Alignment checkpoints fire at targeted stages and produce corrected artifacts when material or critical drift is detected. A dual-model architecture has a primary model generate and a secondary model perform adversarial gap detection — the pipeline never halts on secondary failure. Agents are introduced into a system architecture only when structural mapping identifies a need that deterministic logic cannot meet; every proposed agent passes a four-outcome decision gate before acceptance. Severity-governed alignment language ensures that informational, minor, material, and critical findings are surfaced in calibrated tone. No artifact may promote past Generated state until its plain-language brief exists.
Defense
Principle 21 is the defining structural move. Every hardened master specification must contain a complete governance model and a defensibility argument — regardless of whether the user explicitly defined them. If the user defines governance fully, the system uses it. If partially, the system completes it and marks the additions as system-inferred. If not at all, the system generates a baseline appropriate to the system type and the detected risk surface.
The governance model answers: who can act, what the system can do, what the system cannot do, what happens when something goes wrong, how actions are traceable, who approved the boundaries. The defensibility argument answers: what controls existed before deployment, how scope was bounded, what threat surface was assessed, what failure modes were considered, what a reasonable organization would have done. No hardened specification reaches source-of-truth state without both. The artifacts that govern the build exist before the build, by enforcement, not by hope.
Status
Internal tool. Currently used to specify Atlas North systems and selected external engagements. Twenty-one principles locked. Dual-model pipeline operational. SprintiQ export and Claude Code build-orchestration paths integrated.
