THE MACHINERY · THE FOUNDATION
The system underneath the method.
The machinery that makes the plan happen the same way every time: a qualified base each project starts from, so the effort goes to your problem. The plumbing is already built.
- FOR A TECHNICAL LEADER
- The checks, gates, and review structure a project inherits instead of rebuilding, laid out layer by layer.
- WHAT IT IS MEASURED BY
- Time to first safe change: from authorized work to a small production-capable change with proof attached.
- WHAT IT IS BUILT FROM
- Five layers: a governing method, durable structure, specialist reasoning, enforced controls, external proof.
- HOW IT SCALES
- Four capability profiles, and the rule is to take the smallest one that satisfies the acceptance contract.
- WHERE IT STANDS
- The deterministic profile is built and self-checking; the AI, workflow, and product profiles are still in qualification.
WHY IT EXISTS
The problem comes first, and the platform work stays small.
Every project needs sound requirements, clear boundaries, tests, security review, and evidence that the result works. Rebuilding those controls from scratch on each engagement consumes time and produces uneven results: the same plumbing, rebuilt worse, under deadline.
The foundation carries the proven parts forward. Each new project starts from a qualified base with the checks already standing, so the budget goes to the customer's problem. The measured quantity is time to first safe change: how quickly authorized work becomes a small production-capable change with verification and remote proof behind it.
THE FIVE LAYERS · WHAT DOES WHAT
- The method governs
- Customer truth, outcomes, risk, acceptance, and release decisions live in one written method that every project inherits. Sessions and chat are caches; the repository is the authority.
- Structure is durable
- Each piece of work carries a spec, a plan, and a task list as committed artifacts, so a decision made in week one is still auditable in month six.
- Specialists reason
- Work is classified before it starts, and each class routes to its own discipline. A database change gets tenant and concurrency proof. An auth change gets a threat model. An AI task gets fixtures, validators, and an eval suite.
- Machinery enforces
- Strict typing, architecture boundaries, security and secrets checks, requirement traceability, and fitness tests run as gates, not reminders. What can be written as a rule is a check.
- Proof is external
- Remote CI exercises the exact candidate commit. Consequential work then gets a reviewer who did not build it. One reads the code; the other certifies it.
SMALLEST CAPABLE SYSTEM
Four profiles, and the smallest one that fits wins.
Not every project needs every mechanism. Work starts at the smallest profile that satisfies the acceptance contract, and reaching for a bigger one is an architecture decision that has to be argued in the plan, not a default. A deterministic service does not need a workflow runtime. A bounded AI task does not need authentication.
| Profile | What it adds | Fits when |
|---|---|---|
| A · Deterministic service | Typed core, ports and adapters, unit and integration tests, the full verify chain. | Requirements are deterministic: no AI, no durable runtime. |
| B · Bounded AI task | Everything in A, plus typed model I/O, structured outputs, provenance, validators, an eval suite, and a qualified provider record. | A bounded model task exists: extract, classify, summarize, rank. |
| C · Durable workflow | Everything above, plus durable execution for work that must survive restarts, waits, and resumes. | Work has to outlive a process: retries, long-running steps, resumable state. |
| D · Human-in-the-loop product | Everything above, plus identity, authorization, UI, authorized human decisions, and full recovery behavior. | People must authenticate and authorize actions inside the workflow. |
Adding a capability a smaller profile already covers is recorded as a decision with a forcing requirement, never slipped in because it felt professional.
THE GATE LINE
What each check covers.
Every project inherits the same stage vocabulary. A required stage cannot quietly go missing; skipping is legal only for stages declared optional, and a declared skip is itself a recorded decision.
- Structure
- Format, lint, strict typechecking, architecture boundaries
- Behavior
- Unit and integration tests; eval fixtures where AI is involved
- Trust
- Security scan, secrets scan, supply-chain gate, threat model where boundaries move
- Meaning
- Requirement traceability: every material requirement links to its evidence, owner, and proof
- Release
- The verify chain binds evidence to the exact commit; remote CI proves that commit, not an earlier one
Local green is a claim. Remote CI on the exact candidate commit is the proof, and evidence binds to that commit, so yesterday's green cannot launder today's change.
THE COMPOUNDING LOOP
Every project inherits the last project's scars.
Delivery systems mostly repeat their failures. This one is built to convert them instead. Three loops turn each escape into a permanent guard:
- Engineering escapes
- A defect that reaches production gets reproduced and converted into a permanent deterministic check. The failure class cannot silently reopen.
- AI quality escapes
- A field failure gets sanitized, reproduced offline, and added to the eval fixtures. Prompt, model, or validator remediation requalifies against the same eval.
- Significant failures
- An escaped serious defect gets a committed problem record: why the wrong behavior was possible, which control failed to catch it, and a close-out that requires an explicit prevention decision.
Field evidence sits above all of it. A deployed capability that its users do not use is not complete, and production behavior can reopen any earlier decision. Adoption, friction, failures, and cost are recorded per workflow and fed back into the plan.
WHERE IT STANDS
Where the foundation stands today.
Qualification runs on a ladder: unimplemented, skeleton, experimental, factory-proven, production-qualified. Today the deterministic profile carries a real skeleton and a working verify chain, at the experimental tier. The AI, workflow, and product profiles are unqualified: the contracts are written, the evidence is still being earned. The status is published in the foundation's own records.
WHAT IT IS NOT
A product factory cannot make customer truth for you.
The foundation can make delivery consistent; it cannot substitute for discovery, customer evidence, an explicit decision, or real use. A clean local build does not establish production readiness. Deployment is not complete until the intended workflow has been read back and observed in use.
Specialist disciplines reason, automated gates enforce, fitness tests detect drift, remote CI proves the change, and an independent reviewer certifies it.