How it works · proposed product journey
A clear path from
request to evidence.
Each step has a purpose. Each consequential action needs permission. An uncertain result calls for review.
The agent does the work.
The process keeps it accountable.
This is the intended lifecycle, currently being implemented. The walkthrough uses authored examples, not a connected system.
Explore the walkthrough ↗- 01
Understand
Capture a versioned work request. Check what is clear, what is missing and what would block a useful plan.
- 02
Plan
Describe the proposed changes, scope, assumptions, risks and checks. Readiness to plan is separate from permission to act.
- 03
Ask
Present the exact scope and evidence to an eligible person. Record their reason, decision and the context they reviewed.
- 04
Act within limits
Use an isolated environment and short-lived permissions bound to the approved action and resources.
- 05
Verify independently
Check the actual result against evidence from the system of record. A tool claiming success is not enough.
- 06
Hand back
Show the verified outcome and its audit trail. Failures and uncertain outcomes return to a human path.
When things change
Permission has a context.
A changed plan or resource can invalidate an earlier approval. A timeout can mean the outcome is unknown. The design calls for a fresh review or reconciliation, rather than assuming permission or repeating the action.
Start with one useful workflow
What would a good
first outcome look like?
Choose a bounded use case, name the human decisions and define the evidence you would need.
Plan your pilot ↗