A six-stage workflow for shaping and shipping user-facing product experiences—from defining the journey and interface direction, through an implementation contract and first running surface, to final experience hardening.
View process casefile ↗Automation is the output.This is what decides whether it should run.
This is a simplified public version of how one person works with AI under clear limits and review: start from the source accepted as current, match the effort to the size of the job, produce one thing that can be checked, expect some of it to come back, keep the decisions that matter human, and treat approving the work and letting it go out as two different steps. Not every task takes every step. The architecture decides which ones apply.
No stage selected.
View this map as text
- New Work enters Frame Boundary + Ground Truth.
- Select Route branches to Contained Change, Module Bay, or Pause / Stop.
- Stopping is a valid designed outcome.
- The light and full routes both lead to the same Bounded Candidate.
- The candidate goes to Review.
- fail → Return to Owning Concern → frame, route, or module inside the same run
- pass → Human Decision
- Human Decision remains human.
- hold / reject → Held; no external action follows
- accept → Accepted Candidate
- Accepted Candidate is not authorization. Separate Authorization must be crossed before Compiled Output.
- Retain Durable Learning follows Compiled Output and ends the map. It does not automatically start a future run.
Process casefiles
See how the methods work in practice.
Each casefile opens one reusable workflow to show why it exists, how work moves, where human judgment matters, what evidence survives, and where the method stops being useful.
WHY ARCHITECTURE MATTERS
The failure usually begins before the model answers.
Doing the step well is only part of it. Whether a result can be trusted, changed, or stopped depends on the limits set beforehand, how mistakes get sent back, how replaceable the parts are, and having clear points where a human decision is required.
Capability is not Reliability
Reliability
A stronger model can do more inside a step. It still needs boundaries, accepted truth and a way to know when work should not advance.
Linear is not Durable
Durable
A happy path is easy to automate. Durable systems make correction, withholding and stopping part of the design before anything fails.
Coupled is not Scalable
Scalable
When the tool, model and decision logic are fused together, even small changes can become rewrites. Modularity lets parts evolve without collapsing the operating contract — the agreement the other parts depend on.
Automated is not Autonomous
Autonomous
Execution can be delegated without delegating consequential judgment. Acceptance and external action remain separate human decisions.
DURABLE SYSTEM ANATOMY
Designed to change without losing its spine.
The six properties below keep a process changeable without making its boundaries, review, or authority implicit.
Define legal moves.
Objective, exclusions, source authority and stop conditions define where execution is allowed.
boundedSwap mechanisms, keep contracts.
Tools or models can change inside a module without rewriting the decisions around it.
swappableMake the result reviewable.
One bounded candidate becomes the exact thing that can pass, return, be held or be accepted.
checkableLet work stop cleanly.
Pause, withhold and stop are designed outcomes rather than exceptional crashes or forced completion.
stoppableSend failure to its owner.
Review can return work to frame, route or module instead of patching the nearest downstream symptom.
recoverableKeep judgment explicit.
Accepting a result says the work is good. Authorizing it says the work may go out — a deploy, a publish, a send.
human-decidedMECHANISMS AGAINST BRITTLE AUTOMATION
Failure mode → design response → consequence.
Each control answers a specific failure mode. Read the sequence from cause, to control, to the consequence the control makes possible.
Failure mode
Scope drift
The system quietly expands the job while execution continues.
Design response
Boundary + no-touch scope
Objective, exclusions and stop conditions exist before execution.
Consequence
The assignment stays explicit.
A more capable model can still exceed it. Because the limits were written down first, review can spot where the result departs from the brief.
Failure mode
Bad premise
Production begins from stale, incomplete or contradictory source truth.
Design response
Ground truth before candidate
Source authority is resolved before downstream work compounds the error.
Consequence
The premise can be checked.
The candidate can be reviewed against something explicit.
Failure mode
Cosmetic retry
A review failure is patched downstream instead of correcting its cause.
Design response
Return to owning concern
The process routes correction to frame, route or module.
Consequence
The next attempt starts further back in the same run.
Iteration becomes directional instead of repetitive.
Failure mode
Premature action
A successful candidate is treated as permission to publish, deploy or send.
Design response
Human decision + separate authorization
Acceptance and external action remain structurally distinct.
Consequence
Execution cannot outrun authority.
Irreversible action requires its own explicit gate.