corp-v1-channel-scope/references/decision-readiness.md

Scope decision-readiness pattern

Use this pattern when Epics or Features in IN_DESIGN have open product questions and need an approval decision under the active authority contract.

Decision-readiness matrix

Item	Scope-owned open dependencies	Decision implication
<EPIC-ID>	<QUESTION-IDS>	Review Epic direction independently from child Features. Epic approval does not authorize Feature solution work.
<FEATURE-ID>	<QUESTION-IDS>	Unconditional approval is not ready. A conditional approval must preserve these questions as named conditions and unresolved Architecture risks.

Keep dependency lists consistent with the canonical Epic and Feature pages. Other channels may propose additional risks, but they must not silently rewrite Scope dependencies.

Epic-page readiness block

Do not leave the Epic decision boundary only in the aggregate Roadmap. On each unapproved Epic page, place a readiness block beside the approval record:

No **Approved for Solution** gate is recorded for `<EPIC-ID>`. Its delivery status remains **IN_DESIGN** and unconditional approval is blocked while `<EXACT-QUESTION-IDS>` remain open.

An actor permitted by the active authority contract may approve `<EPIC-ID>` conditionally, but the decision must name every unresolved question it carries forward—or an equally explicit scope condition—and Architecture must preserve those conditions as unresolved risks.

The first proposed decision package is `<QUESTION-IDS>`: `<SHORT DECISION SUMMARY>`. This ordering is a proposal, not approval. Approval of this Epic would not approve any child Feature; each Feature requires its own explicit authorized decision.

The Epic's exact question IDs must match the Roadmap matrix and canonical question register. When no first package is justified by dependency order, omit that paragraph rather than inventing one.

Feature-page readiness block

Do not leave the exact decision boundary only in the aggregate Roadmap. On each unapproved Feature page, place a short readiness block beside the approval record:

No **Approved for Solution** gate is recorded. The Feature remains **IN_DESIGN** and unconditional approval is blocked while `<EXACT-QUESTION-IDS>` remain open.

An actor permitted by the active authority contract may approve `<FEATURE-ID>` conditionally, but the decision must name every unresolved question it carries forward—or an equally explicit scope condition—and Architecture must preserve those conditions as unresolved risks.

The exact question IDs must match both the Feature's canonical dependencies and its Roadmap matrix row. A generic phrase such as "open questions remain" is insufficient for a reviewable conditional decision.

Approval evidence

A valid Approved for Solution gate decision records:

• actor identity and authority basis;
• decision date;
• exact stable Epic or Feature ID;
• explicit Approved for Solution wording;
• scope conditions and unresolved questions;
• source Discord message or reviewed documentation evidence.

Do not infer approval from an Epic decision, question closure, silence, documentation merge, CI result, delivery status, delivery activity, or release planning.

Conditional approval

Open questions prevent unconditional readiness, but they do not prohibit an authorized actor from granting conditional solution approval. If that happens:

1. Preserve every named condition in the Scope approval record.
2. Hand the open questions to Architecture as unresolved risks.
3. Require Architecture requirements and decisions to reference those conditions.
4. Keep implementation, Focus admission, version, release, and deployment gates separate.

Review ordering

When Scope, Architecture, Kanban, and release-readiness PRs depend on one another:

1. Review the correction to the earliest authoritative layer first.
2. Refresh downstream branches if the merge changes their base or evidence.
3. Validate and cite CI at each new exact head SHA.
4. Treat independent PRs independently; do not manufacture ordering where no content dependency exists.