4 min read
A fictional marketplace team asks an agent to add partial refunds. The sentence sounds small. It touches payments, order state, accounting events, customer messages, and support runbooks. The feature becomes manageable only when each stage produces a decision or evidence artifact. This is an explicitly fictional composite, used to expose a repeatable engineering decision without inventing a customer result.
A governed AI feature development workflow moves work through eight connected stages: intake, planning, specification, development, review, checks, documentation sync, and delivery. Each stage reduces a different uncertainty. The workflow should scale by risk, preserve human decision authority, and end with an honest receipt of what was and was not proved.
Intake and planning expose the real surface
Intake identifies the request, requester, affected product behavior, and likely risk. Planning then maps modules, owners, reuse options, dependencies, rollback, and unresolved decisions. For the refund story, that means payment state and accounting are visible before an agent edits a controller.
NIST AI Risk Management Framework helps bound this point. This is voluntary risk guidance, not certification or proof of a product outcome.
| Lens | What to inspect |
|---|---|
| 1 | Stage 1-2: scope |
| 2 | Stage 3: intent |
| 3 | Stage 4-6: change and evidence |
| 4 | Stage 7-8: shared memory and receipt |
The numbers and labels above are a diagnostic, not benchmark data. Replace them with repository evidence before using the model in a staffing or investment decision.
Specification gives reviewers an independent target
Specification records acceptance criteria, invariants, failure behavior, and proof methods. It should be versioned for the current attempt. Without that baseline, a reviewer compares code with memory. With it, the team can ask whether the refund amount, authorization rule, duplicate request behavior, and event trail match the agreed target.
The sequence matters because later evidence depends on earlier intent. Skipping one step transfers uncertainty to a reviewer who has less time and often less context.
Development, review, and checks separate responsibilities
Development performs bounded edits. Review challenges design and implementation. Checks execute what can be tested deterministically. Keeping the worker and final reviewer separate reduces self-confirmation, but no separation creates a correctness guarantee. Evidence stays bounded by test and oracle quality.
Google DORA 2025 adds a second boundary. The report is observational, so associations should not be presented as universal causation.
:::mistake **Mistake:** Collapsing eight different questions into one long prompt. **Fix:** Let each stage produce the smallest artifact needed for the next accountable decision. :::The correction is deliberately procedural. A workflow can be inspected, rehearsed, and improved. A warning without an owner or artifact rarely survives the next busy sprint.
Documentation and delivery preserve the result
Documentation sync updates every affected surface, then delivery records status, decisions, checks, and known blind spots. In paqad-ai v1.67.0, the public framework describes risk lanes, specialist roles, automatic checks, and local audit records. Treat these as product mechanisms to inspect, not independent outcome proof.
paqad-ai v1.67.0 was the current public release when this article was verified on July 21, 2026. Its public repository describes local workflows, risk routing, specialist roles, deterministic checks, documentation sync, and audit records. Those are product mechanisms, not independent proof that a team will achieve a specific outcome.
Use the broader AI workflow audit guide to map the operating system, compare the evidence bar with production-ready AI code, and use the consultant selection guide when outside ownership is being considered.
The decision rule for this article is: Use the lightest lane that preserves the evidence and human authority required by the feature’s risk.
Frequently Asked Questions
Do all features need all eight stages?
No. Use risk-based lanes. A copy change can pass through a compressed path, while payments, permissions, deletion, and migrations should retain the fuller evidence and authority model.
What makes the workflow provider agnostic?
The repository owns specifications, rules, decisions, and evidence. Providers can execute parts of the process with different enforcement levels, but the durable state does not belong to one chat host.
Does an evidence receipt prove correctness?
No. It records what ran, what passed, what failed, and what remains outside coverage. That makes a human decision more informed without turning limited checks into a guarantee.
What next?
If this failure pattern exists in your repository, install paqad-ai and test the decision tool above on one real feature. Keep the evidence local, inspect provider permissions, and retain human authority for the final risk decision.
