Manager / Approver

Guidance for approvers who define boundaries, review evidence, and authorize proportional security work.

This page defines the manager/approver lane for setting authorization boundaries, testing proportionality, and deciding whether work proceeds under governed scope.

1. Problem this page solves

Approval quality collapses when authority limits, scope boundaries, and evidence standards are implicit.

This page gives a first-pass approval path so authorize/reject/escalate decisions are explicit, auditable, and tied to documented gates.

2. What you should understand after reading

After this page, you should understand:

the role boundary: authorize, reject, or escalate governed work; do not run the technical workflow
what must be known before approval
which decisions you own vs what you defer
how to separate observed records from inferred confidence
which pages to read first and which detail to ignore initially

3. Mechanism-first role path

Must know first before approval

Before approving any request, require:

a specific objective and expected outcome
explicit in-scope target and action boundaries
proposed workflow path and escalation conditions
defined evidence standard for acceptance/review

Read first (in order)

Decisions you own in this role

Decision	What you own	Primary pages
Authorization decision	Approve, reject, or pause based on objective legitimacy, scope clarity, and control readiness	Governance, Authorization Model
Boundary definition	Set allowed targets, action limits, timing, and escalation expectations before execution begins	Authorization Model, Is This In Scope?
Proportionality check	Require the least disruptive path that can satisfy the objective	Governance, Do I Need to Escalate?
Evidence acceptance standard	Define and enforce minimum evidence needed for post-run review and accountability	What Evidence Is Required?, Evidence

Defer initially

Defer these until your first approval-review cycle is complete:

low-level tool execution specifics and operator command detail
integration implementation detail in Integration Author
receipt field-by-field internals in Receipt Spec

4. Observed vs inferred

Layer	What is observed	What is inferred
Approval input and record	request objective, scope declarations, approver identity/time, decision state, documented conditions	that the plan is complete, safe, or sufficient under unseen conditions
Post-execution review	receipt-linked artifacts, explicit failures, escalation events, timestamps, evidence package contents	conclusion correctness, long-term risk reduction, or full business impact

Treat inferred conclusions as judgment calls that require explicit rationale, not as direct observations.

5. Role-specific trust assumptions

Operate with these assumptions explicit:

Approval quality depends on input quality: weak scope/objective/evidence input drives weak approvals.
Recorded approval is not validated approval: the system records who approved and when, but cannot prevent poor decisions.
Scope enforcement is configuration-backed: if in-scope.txt is wrong, approved boundaries are wrong.
Proportionality remains human-controlled: no workflow can replace approver judgment on business risk tradeoffs.
Receipts attest events, not decision correctness: they prove what ran and what was captured, not whether approval choices were right.

See Threat Model for full trust boundary context.

6. Next-page handoff

Next, read Integration Author to translate approval boundaries and evidence expectations into integration and runbook interfaces.