Jidoka Instruction Architecture
Build quality into agent instructions
One instruction architecture for humans and agents. Eight layers each hold a single job. Checks stop the line the moment a layer drifts.
Instructions sprawl. Nothing stops the drift.
Prompts pile up. Layers restate each other. Jobs go stale. Nobody notices until an agent misbehaves. Jidoka takes the Toyota path and builds quality into the process itself. In one layered architecture, every layer owns a single job and carries a machine-checkable budget. A defect then traces to exactly one layer. The line stops before the defect ships.
Eight layers. Most general to most specific.
Each layer loads at the right moment and owns one concern. Auto-loaded layers stay budgeted, so context never bloats. On-demand layers disclose only when the work calls for them.
Harness mechanics: turns, tool calls, the completion signal. Nothing about your project.
Project identity: what it is, who it serves, and where to find its jobs and checklists.
Contribution standards and the jobs each persona hires the work to do.
One persona: voice, skill routing, and scope constraints. It sets boundaries. It does not give steps.
Cross-cutting protocols shared across agents: memory, coordination, approval.
The complete, imperative steps for one domain of work. They need no tribal knowledge.
The data a procedure consults: templates, worked examples, lookup tables.
Binary verification at a pause point. It confirms. It does not explain.
What agents align to, and how alignment holds.
Three well-publicized ideas answer the halves of the problem. Together they explain why the layers have the shape they have. They also explain why the checks stop the line.
How quality holds. The process builds in quality. Inspection afterward does not. The checks halt at the first defect. They never pass one downstream.
What agents align to. Every layer traces to the progress a persona seeks in a specific circumstance. No layer traces to a feature list.
How alignment holds under load. Structured instructions keep humans and agents consistent in how they apply existing knowledge.
Two gates. One at entry, one at exit.
Checklists never teach. They confirm. If you must explain an
item, the procedure above it is incomplete. A semantic
<read_do_checklist> or
<do_confirm_checklist> tag wraps each gate.
Every pause point in the repository is then one
rg search away. You need no map.
Read each item, then do it. The gate loads constraints into memory before the first line of work. At that moment, one missed constraint sends everything in the wrong direction.
rg '<read_do_checklist'
Do from memory, then pause and confirm. The gate verifies that you missed nothing before a commit, merge, or release. The checks stay independent. They do not interrupt you mid-flow.
rg '<do_confirm_checklist'
Adopt it in three lines.
Install the skill pack. Tell Claude to set it up.
Then wire the jidoka binary (or
npx @forwardimpact/jidoka) into your checks, so the
line stops at the first drifted layer. Read the full standard in
the
layered instruction architecture guide.