The TPS framework
Governed agentic development — built on 70 years of manufacturing discipline
Toyota Production System eliminated defects at scale by making quality the responsibility of the system, not the individual. ticketyboo applies the same seven principles to AI-assisted software development.
The problem
Agents don't break systems. Ungoverned agents do.
An AI coding agent will do exactly what it's asked — no more, no less. Without a governing contract, "what it's asked" is informal, inconsistent, and unverifiable. The output ships. The drift compounds.
No standard work
Each agent session starts from scratch. No constraints, no forbidden patterns, no agreed stack. The agent improvises.
No built-in quality
Output is reviewed by the same humans who specified the work. The inspector and the specifier are the same person.
No measurement
There is no score. No trend. No way to know whether the estate is getting better or worse over time.
Seven mechanisms
TPS distilled to agentic development
Each TPS principle maps to a specific mechanism in the ticketyboo framework. Together they form a closed loop — from first prompt to signed evidence.
TPS Principle 1 — Standardised Work
DevContract
The standard as code
TPS: Every task has a defined sequence. No variation.
devcontract.json defines what the agent is allowed to build — 8 clause families. Stack, cost, security, quality, compliance, architecture, audit, delivery. The standard is in the repository. Version-controlled. Machine-readable. Binding.
Config surface: .tickety/devcontract.json
TPS Principle 2 — Jidoka (Autonomation)
Contract Injection
The standard in every session
TPS: Machines stop automatically when defects are detected.
The contract is injected into agent context before the first prompt. The agent cannot proceed outside the contract's scope. Every session. Automatically. The developer does not have to remember to include it — the system does.
Config surface: .clinerules / system prompt injection
TPS Principle 3 — Andon Cord
Gate Verdict
Violations stop the line
TPS: Any worker can halt the line when quality fails.
Gate CLI returns CONTRACT_BREACHED with clause trace. The build stops. The evidence is signed. Not a warning — a block. The line does not resume until the violation is resolved or explicitly accepted with an audit record.
Config surface: gate_cli.py / CI gate step
TPS Principle 4 — Built-in Quality
Evidence Bundle
The signed delivery receipt
TPS: Quality is designed into the process, not inspected in at the end.
Every gate run produces a signed evidence bundle — tamper-evident, time-stamped, clause-mapped. Not a chat log. Not a PR description. A cryptographically-bound document that proves what contract was in force and what every clause verdict was.
Config surface: evidence.json output
TPS Principle 5 — Poka-Yoke (Mistake-Proofing)
Forbidden Pattern Detection
Wrong choices cannot ship
TPS: Physical constraints prevent incorrect assembly.
Forbidden resources, forbidden patterns, and forbidden secrets locations are checked before merge. The check is deterministic: match = FAIL, no grey area. The agent is also less likely to write forbidden patterns when the contract is in context — probabilistic pre-execution reduction, deterministic post-execution block.
Config surface: cost.forbidden_resources, architecture.forbidden_patterns
TPS Principle 6 — Kanban
Dependency Graph
Fix what unblocks the most first
TPS: Work is pulled only when downstream capacity exists.
RST scoring maps dependency risk across the estate. Remediation is sequenced by RST score and downstream leverage, not project politics. Priority = (Risk × Leverage) / Effort. The entity that unblocks the most downstream work gets fixed first.
Config surface: service-index.json / estate scan output
TPS Principle 7 — Kaizen (Continuous Improvement)
The Continuum
Progress visible. Regression cannot hide.
TPS: Every worker is responsible for incremental improvement.
RST scores trend over time. Position history is immutable — you cannot retroactively change a past score. Drift is detected before it compounds. The estate improves or it doesn't — and you can see which. The measurement is continuous and public.
Config surface: Continuum dashboard / RST trend API
The measurement model
Rickety · Sickety · Ticketyboo
Nine-point float scale. R1–R3 (critical risk) · S1–S3 (managed debt) · T1–T3 (governed and evidence-backed). Every repository scored. Every trend tracked.
Rickety
Undocumented, untested, critical dependencies exposed. No contract. No evidence. Agents operating without constraints will make this worse, not better. High remediation priority. Intervention required.
- No contract in force
- No evidence produced
- High-risk findings open
Sickety
Partially governed. Known debt, intermittent failures, compliance gaps. A contract exists but coverage is incomplete. Measurement has started. The work is visible — the question is whether it's being closed.
- Contract present, gaps remain
- Drift detection active
- Issues being worked
Ticketyboo
Contracted, assured, evidence-backed. Every build governed. RST score maintained above T1.0. Drift detected within one gate cycle. Position history proves the trajectory. Audit-ready.
- Full contract coverage
- Signed evidence at every gate
- Continuous compliance active
How it fits together
Contracting + Assurance
The framework has two halves. Together they answer the two questions every governed build must answer.
How do you contract with an AI coding agent?
The standard must exist before work begins — not as a prompt, not as a suggestion, but as a schema-validated document the agent binds against in every session.
- Define the standard (DevContract)
- Inject it into context (Contract Injection)
- Forbid the wrong choices (Poka-Yoke)
- Sequence the work (Dependency Graph)
Solved when: the agent cannot begin a session without the standard in its context.
How do you assure that what was asked for is what was done?
The receipt must be machine-readable, cryptographically bound to the contract, and verifiable by any party — not just the system that produced it.
- Run the checks (Gate Verdict)
- Sign the evidence (Evidence Bundle)
- Measure the outcome (Continuum / RST)
Solved when: a machine-readable receipt proves the deliverable was evaluated against a specific contract version.
Start with the contract
Drop a devcontract.json into your repo. The rest of the framework follows.