Screen: Scope Governance
web/scope.html. The internal queue for client asks, boundary decisions, change requests,
billing-impact items, and approval-gated scope memos.
Purpose
Use Scope whenever an ask might change the implementation plan, budget, timeline, or client expectations. It keeps the decision internal until a person approves a client-visible memo — the default is silence to the client, not an automatic notification.
Classifications
| Classification | Meaning |
|---|---|
| Inside scope | The current project already covers the ask |
| Needs clarification | The team should ask a question before committing |
| Change request | Can create a scope memo |
| Billing impact | Can create a scope memo |
| Rejected | Keeps an internal record without publishing anything |
Client asks become scope events
New client-originated requests appear as client asks. Classifying one converts it into an internal scope event, so the queue always has a decision record — even a "rejected" ask leaves a trace of what was asked and why it wasn't actioned.
Guardrails are guidance, not gates
Guardrail matches compare an ask against the project's recorded scope boundary. They inform review; they do not automatically approve or reject anything.
Approval path
"Create memo" drafts a scope_change approval. The memo does not reach the client until the
approvals queue approves it — see the Approvals API. A duplicate
pending memo is reused rather than creating a second one.
Visibility
Scope is lead/admin only. The Client Portal never exposes raw scope events — clients see only approved updates and released deliverables, never the internal deliberation that produced them.
Where the code lives
sable-agents-demo/web/scope.htmlsable-agents-demo/web/api/scope.js,_scope.js,_scope_governance.js