Change Requests
DraftStatus: Draft
Version: 0.1.0
Last Updated: 2026-05-16
Owner: Axodus Business
Purpose
Change requests preserve transparency when clients, DAOs, partners, or internal teams ask for new features, altered requirements, expanded scope, changed timelines, or new deliverables after a scope or delivery baseline is approved.
Meaningful changes must be logged, classified, reviewed, and either accepted, rejected, deferred, or converted into a new scope.
Scope
This page applies to approved Business work where new information or new demands may affect scope, timeline, cost, risk, governance, security, or acceptance.
Definition
A change request is a formal record of a requested change after scope or delivery baseline. It is not an informal chat message, hidden extra work, automatic commitment, proof that the original scope was wrong, or a path around governance.
Triggers
Triggers include new features, changed deliverables, changed acceptance criteria, new integrations, accelerated timeline, budget changes, discovered governance impact, added security requirements, changed objective, dependency changes, tokenomics or reward rules, Marketplace payment rules, Trading access rules, or expanded ACS permissions.
Classification
Change requests may be classified as clarification, bug fix, minor adjustment, scope expansion, scope reduction, timeline change, cost or resource change, governance impact, security impact, new project, rejected, or needs clarification.
Required Fields
A change request should record the change request identifier, original request identifier, requester, date, description, reason, affected deliverables, requested priority, classification, scope impact, timeline impact, cost or resource impact, risk impact, governance impact, security impact, ACS analysis, decision, approval authority, updated scope reference, and notes.
Flow
- Requester describes the change.
- Business creates a change request record.
- ACS compares the change to the approved scope and identifies impacts.
- Business validates classification and determines whether the change can be handled.
- Governance or security review occurs when triggered.
- Decision is recorded: approve, approve with adjustment, reject, defer, require governance, require security review, or convert to a new project.
- Scope, milestones, budget, timeline, and acceptance criteria are updated if approved.
- Requester receives transparent communication.
- Approved changes are delivered.
- Change record is archived.
Impact Assessment
Business should assess impact on scope, timeline, cost, risk, governance, quality, and requester expectations. New ideas after approval may require additional time, cost, resources, review, or governance approval.
Governance Triggers
Governance review may be required if the change adds a governance plugin, affects DAO federation or product access, changes treasury or revenue distribution, affects token rewards or unlocks, modifies Marketplace fees, affects Academy reward policy, changes Trading access or risk policy, expands ACS authority, or modifies public claims about Axodus.
Anti-Patterns
Anti-patterns include verbal-only changes, silent scope absorption, redefining success after delivery, and handling governance-sensitive changes without review.