Request Lifecycle
CanonicalPurpose
The request lifecycle defines how any material Axodus request moves from creation to archive without losing context, authority, validation, or accountability.
Scope
Requests may originate from users, clients, DAOs, internal nuclei, governance bodies, ACS agents, Coder, or engineering work. They may involve Business services, DAO plugins, governance proposal support, Academy reward policy, Trading strategy access, Marketplace listing, ACS automation, documentation, or technical implementation.
Standard Lifecycle
flowchart LR
A["Created"] --> B["Intake"]
B --> C["Classification"]
C --> D["Analysis"]
D --> E["Validation"]
E --> F["Governance Check"]
F --> G["Scope"]
G --> H["Approval"]
H --> I["Handoff"]
I --> J["Execution"]
J --> K["Delivery"]
K --> L["Acceptance"]
L --> M["Accountability"]
M --> N["Archive"]Lifecycle Stages
- Created: request enters Runtime with raw context.
- Intake: request context and missing information are captured.
- Classification: domain, type, risk, owner, and required reviews are identified.
- Analysis: ACS or human review evaluates assumptions, risks, and options.
- Validation: responsible human or domain owner validates interpretation.
- Governance check: formal governance review is identified when required.
- Scoping: deliverables, boundaries, milestones, and acceptance criteria are defined.
- Approval: correct authority approves, rejects, defers, or conditions the scope or action.
- Execution handoff: approved context moves to Coder, operator, governance executor, or another implementation actor.
- Execution: approved work is performed.
- Monitoring: progress, blockers, milestones, and delays are tracked.
- Change control: new or changed requirements are classified and reviewed.
- Delivery: output is submitted with known limitations.
- Acceptance: requester or owner accepts, rejects, or requests revision.
- Accountability: material decisions and actions are recorded.
- Archive: final context, links, and lessons are preserved.
Lifecycle Variants
Low-risk documentation may use a simplified flow: created, intake, classification, scoping, handoff, delivery, acceptance, archive.
Business client requests normally add ACS analysis, Business validation, approval, milestone updates, change control, and acceptance records.
DAO plugin requests require governance check, constitutional review, technical scope, security review, governance approval, delivery, execution receipt, and archive.
Treasury actions require risk analysis, treasury review, governance review, authorized execution, execution receipt, accountability report, and archive.
ACS automation requests require permission review, security review when sensitive, governance review when authority expands, monitoring, and accountability record.
Exit Conditions
Runtime items may exit as completed, rejected, deferred, superseded, blocked, cancelled, or archived. Every exit must include a reason, next action, successor link, or archive record as applicable.
Invariants
Every request must have a status and next action or exit condition. Validation must happen before commitment. Governance checks must happen before sensitive execution. Acceptance must reference scope. Archive must preserve decisions and links.