In this article
Last updated September 18, 2026
4 min read
A single workflow for every AI-assisted change sounds consistent.
It usually becomes either too weak for risky work or too heavy for ordinary work.
If every copy edit needs a frozen specification and several specialist reviews, people will bypass the process.
If every access-control change follows the same path as a button label, the process cannot claim meaningful control.
The answer is proportional workflow.
Complexity and sensitivity are different
Complexity describes how difficult the work is to understand and execute.
Sensitivity describes the consequence of getting it wrong.
A large internal refactor can be complex and reversible.
A three-line change to an authorisation condition can be simple and highly sensitive.
Use both dimensions. Complexity can suggest the lane. Sensitivity should set the minimum.
A practical three-lane model
Fast lane
Use for small, reversible changes with clear local proof and no sensitive boundary.
Typical controls:
- concise goal;
- narrow scope;
- relevant repository rule;
- direct deterministic checks;
- lightweight review receipt.
The fast lane should still record what changed and what proved it. Light does not mean invisible.
Graduated lane
Use for everyday feature work with meaningful product behaviour and several affected artifacts.
Typical controls:
- module and boundary plan;
- reuse and rule-drift checks;
- acceptance criteria with proof methods;
- scoped implementation;
- separate review;
- deterministic test, type, lint, and build results;
- documentation sync;
- human decisions where ambiguity crosses an owned boundary.
This is the default path for work that is neither trivial nor unusually sensitive.
Full lane
Use when the change is wide, hard to reverse, or touches security, privacy, access, money, regulated data, critical
operations, or a public contract.
Typical controls:
- formal intake and risk record;
- frozen specification;
- human-confirmed invariants;
- story or execution breakdown;
- specialist architecture, security, data, or performance review;
- stronger traceability and mutation or health checks;
- explicit rollback;
- human verdict with recorded reason;
- sealed evidence package.
The full lane should not guarantee safety. It should make the standard, evidence, decisions, and remaining uncertainty
more complete.
Route before the agent commits to a solution
Risk routing works best before implementation.
Ask:
- Which users and data can be affected?
- Does the change alter permissions, identity, payment, or audit behaviour?
- Does it change a public interface or persistence model?
- Can it be rolled back cleanly?
- How many modules and providers are involved?
- Is the current specification complete?
- Which specialist evidence is required?
The answers should produce a lane and a reason.
Allow escalation, not silent downgrade
Work changes as the repository is explored.
A fast-lane task can reveal a data migration. A routine feature can expose a missing security decision. The workflow
must be able to escalate and preserve completed evidence.
Downgrading should require an explicit reason and authorised owner. Otherwise schedule pressure will gradually turn
every lane into the fastest one.
Measure whether lanes work
Track:
- how often work escalates;
- defects and correction by lane;
- review time;
- bypass attempts;
- inconclusive verdicts;
- changes later judged misrouted;
- sensitive work detected after implementation began.
The goal is not to prove the router is always right. It is to improve the routing policy with evidence.
How paqad-ai uses lanes
paqad-ai’s feature-development design includes fast, graduated, and full paths, with sensitivity providing a minimum
floor. The selected lane changes the planning, specification, review, checks, and human-decision requirements.
That is what a team orchestration should do: keep everyday work moving while making consequential work earn stronger
evidence.
One workflow can still define the system.
It should contain more than one path.
Install paqad-ai: https://github.com/Eliyce/paqad-ai/
Source notes
- Product mechanism: first-party details from the current
Eliyce/paqad-ai repository. - NIST AI RMF Core, voluntary guidance on mapping scope,
impacts, oversight, and go/no-go decisions.