Decision and execution framework — revision 1.4

How to use the framework

At each gate, record Proceed, Revise, Hold, or Stop, with an owner, evidence revision, rationale, and next review date. A stage can be revisited; approval of an old revision does not approve changed scope. Assign a stable initiative ID at intake and carry it through requirements, architecture decisions, commits, tests, releases, and benefit reviews.

For this narrative the initiative is HIS-027. Checklist completion means the corresponding stage has been developed in the story. Real adoption requires replacing fictional evidence with actual evidence and securing real approvals. The final column provides a route back when a gate fails.

Narrative status	Step and question	Accountable owner	Required artifact / exit evidence	Gate and return path
[x]	01 Intake: what happened, and who is affected?	Sponsor	Problem statement, observed trigger, owner, immediate containment	Accept investigation; unsupported request returns for evidence
[x]	02 Discover: what is the current process and actual failure?	Product owner	Workflow, sample cases, baseline definitions, counterexamples	Confirm problem; revise intake if it is a different problem
[x]	03 Inventory: what already exists and who owns it?	Architect	Systems/data inventory, contract assumptions, record authority, extension candidates	Confirm viable interfaces; hold for system-owner validation
[x]	04 Define outcomes: what measurable result justifies work?	Sponsor / finance	Benefits hypothesis, baseline, thresholds, cost boundary, non-goals	Approve bounded discovery spend; stop if value cannot justify intervention
[x]	05 Develop requirements: what must users and systems do?	Product owner	Versioned functional/nonfunctional requirements, examples, exception policy, acceptance criteria	Agree minimum scope; unresolved policy returns to process owner
[x]	06 Choose a solution: configure, extend, buy, build, or change process?	Architect / sponsor	Hard constraints, weighted options, sensitivity, cost estimates, reversible decision	Conditional choice; infeasible options fail regardless of score
[x]	07 Validate assumptions: can the decisive dependencies work?	Engineering / system owners	Time-boxed spike, interface and entitlement confirmation, failure-path evidence	Confirm choice or return to step 06; spend cap is enforced
[x]	08 Design: where do records, trust, and failure boundaries live?	Architect / security	Data model, contracts, threat review, failure recovery, retention decisions	Approve design; material cost/scope changes revisit step 06
[x]	09 Fund and plan: can the staffed team deliver and support it?	Engineering manager / finance	Dependency plan, skill capacity, scope slices, cost forecast, operating owner	Fund a bounded increment; staffing gaps reduce scope or revise dates
[x]	10 Standardize: what baseline is worth maintaining?	Platform lead	Versioned template, generated diff, ownership, exception and upgrade procedure	Accept baseline; use reviewed starter if automation cost exceeds benefit
[x]	11 Implement: can one business flow run end to end?	Engineering lead	Reviewed commits, migrations, adapters, feature controls, requirement links	Admit candidate to verification; incomplete slices stay out of release
[x]	12 Verify: does the exact candidate meet the contract?	QA / security	Automated checks, negative tests, access tests, recovery proof, artifact identity	Reject missing/failed evidence; return defects to step 11
[x]	13 Accept: can real users safely operate it?	Product owner	Observed UAT, training, accessibility, exception handling, support readiness	Approve exact scope/build or revise requirements and implementation
[x]	14 Release: can a bounded rollout be operated and reversed?	Service owner	Change approval, deployment digest, backout plan, reconciliation, support coverage	Pilot only; failed preconditions hold promotion
[x]	15 Operate and learn: what happens when assumptions fail?	Service owner	Incident evidence, recovery, owner, corrective requirement, regression case	Maintain/disable affected path; material findings reopen earlier gates
[x]	16 Evaluate outcomes: did the business benefit and should it expand?	Sponsor / finance	Comparable outcome data, adoption, full costs, limitations, expansion decision	Proceed to next bounded cohort or stop/rework; do not infer success from usage alone
[ ]	Execute enterprise rollout	Sponsor / service owner	Branch-specific validation, capacity, training, funding, repeated gate evidence	Future work beyond initial case; approval required for each rollout wave
[ ]	Retire the interim spreadsheet after evidence period	Process owner / records owner	Complete reconciliation, retention decision, read-only archive, user signoff	Future work; prohibit dual writable coordination stores after cutover
[ ]	Review long-term continuation or retirement	Portfolio board	Operating value, support cost, successor options, export/recovery and decommission plan	Future quarterly review; retirement includes credentials, jobs, access, and data disposition

Required analysis within every step

• Inputs and evidence: distinguish an observation, an assumption, a target, and a demonstrated result.
• People and competing needs: include the operator, system owner, customer impact, and decision authority.
• Alternatives: record at least one plausible rejected alternative and why it lost at this stage.
• Failure and exceptions: ask what happens when data is stale, unavailable, disputed, duplicated, or corrected.
• Deliverable: produce a reviewable artifact with an ID/revision and a named owner.
• Exit and feedback: identify the gate outcome, what would invalidate it, and which earlier step must reopen.

Decision rules

1. Test a process-only change before assuming new software is necessary. Business policy must be understandable without an application screen.
2. Identify the record owner before selecting a UI. The strongest interface is not necessarily the correct system of record.
3. Apply hard constraints first, then weighted preferences. A low-cost option that cannot enforce authorization or recover safely is ineligible.
4. Treat estimates as ranges. Include licensing, integration, data work, training, support, security, upgrades, and exit costs.
5. Validate the assumption most likely to reverse the choice before committing the delivery budget.
6. Fund a vertical business slice with measurable value. Count dependencies and skills, not interchangeable person-hours.
7. Keep requirement-to-release evidence tied to revisions and artifact identity. Failed, skipped, unknown, and stale are different states.
8. Design reconciliation and human exceptions alongside the successful path. Notifications never constitute transaction confirmation.
9. Measure customer and operator outcomes with stable definitions and an appropriate comparison group. A dashboard trend is not proof of causation.
10. Give the application an operating owner, an upgrade path, and a retirement path before expansion.

Framework changes discovered in the story

Revision	Discovered at	Gap in initial framework	Change incorporated in the checklist	Consequence
1.0	Start	Initial sixteen-stage structure	Intake → inventory → options → delivery → outcomes	Baseline process
1.1	Step 02	Faster processing can hide premature promises	Add failure definitions, exclusion reasons, and counterexamples to discovery	Benefits measure failed commitments as well as time saved
1.2	Step 07	A timeout may hide a successful upstream reservation	Require replay, lookup, and reconciliation proof before design approval	No blind retries; unknown state becomes a first-class requirement
1.3	Step 13	Supervisor override rules did not establish usable coverage	Add shift coverage, delegated authority, and observed exception UAT	Business acceptance depends on workable delegation, not just permissions
1.4	Step 15	A healthy application can have a stalled reconciliation queue	Add queue age, reconciliation lag, and stale-source monitoring to operational gates	Monitoring reports processing health and data freshness separately

Future changes must add a row with the trigger and affected gates. Do not silently modify acceptance criteria after seeing results; record the new revision and rerun affected checks.