# Make an AI Initiative Value and Scale Decision Workflow ID: AMO-W-000015 Workflow URL: https://amo.ng/workflows/ai-initiative-value-and-scale-decision ## Outcome An evidence-backed investment decision package containing a benefits realization bridge, root-cause value-leakage diagnosis, accepted-outcome economics, residual risk, and an authorized Scale, Hold, Redesign, or Stop recommendation. ## Before you begin - Approved business case, benefit assumptions, baseline, decision gates, and accountable sponsor - Post-deployment operating, adoption, throughput, quality, review, rework, risk, and outcome evidence - Provider, infrastructure, integration, support, maintenance, labor, and control costs - Accepted-outcome definition, measurement window, allocation rules, and rejected or escalated work - Current dependencies, constraints, alternatives, and scale or stop decision horizon ## Step 1 — Reconcile the approved value case to realized benefits **Prompt** AI Benefits Realization Evidence Bridge **Instructions** Extract the approved benefit claims, build their lineage to operational and financial evidence, bridge baseline to actual results, adjust for quality and attribution limits, and state which benefits are realized, partial, unsupported, or not yet measurable. **Input for this step** Supply the approved business case, baselines, assumptions, benefit owners, deployment scope, actual operating evidence, financial records, quality and risk evidence, and measurement period. **Carry forward** Carry the benefits register, baseline-to-actual bridge, realized and unrealized value, attribution limits, confidence, and evidence gaps into value-leakage diagnosis. **Review note** The benefit owner and finance reviewer confirm baseline definitions, attribution, recognized benefits, exclusions, and unsupported claims. **Prompt ID** AMO-P-000278 **Prompt URL** https://amo.ng/prompts/ai-benefits-realization-evidence-bridge **Prompt content** Reconcile the approved AI business case with post-deployment operational and financial evidence. Produce a defensible working artifact that accountable owners can use to decide which benefits were realized, displaced, delayed, double-counted, or unsupported. Context and inputs to use: - Approved AI business case: [Approved AI business case] - Deployment period and relevant measurement window: [Deployment period] - Baseline definition, assumptions, volumes, rates, and counterfactual used in the original case: [Baseline definition and assumptions] - Post-deployment operational evidence, including KPI extracts, process measures, adoption data, service levels, error rates, cycle times, throughput, quality data, or control logs: [Post-deployment operational evidence] - Financial actuals and cost data, including labor, vendor, cloud, tooling, support, implementation, training, rework, run-rate, and one-time costs: [Financial actuals and cost data] - Known external changes or confounders, including demand shifts, pricing changes, policy changes, staffing changes, process redesign, vendor changes, macro factors, seasonality, or parallel initiatives: [Known external changes or confounders] - Benefit owners and decision authority, including finance owner, product owner, operational owner, data owner, and any approval forum: [Benefit owners and decision authority] Evidence discipline: - Use only the evidence provided. Do not claim that any source system, report, approval, test, audit, or transaction record was inspected unless it is included in the inputs. - Separate observed evidence from inference. Label assumptions, estimates, and judgment calls explicitly. - Preserve uncertainty. Where evidence is incomplete, state what is missing, why it matters, and how it affects confidence. - Do not redesign the pre-pilot ROI plan. This is a post-implementation benefits realization bridge against the approved case. - Do not treat adoption, usage, model output volume, or automation counts as financial benefit unless the operational-to-financial conversion is evidenced or reasonably supported. - Do not recognize the same benefit twice across labor, productivity, capacity, revenue, cost avoidance, quality, or risk categories. - Do not assign causality to the AI initiative where the evidence only supports correlation or partial contribution. Working method: 1. Extract the original benefit claims from the approved business case. - Identify each promised benefit, metric, baseline, target, timing, owner, financial value, and stated assumption. - Preserve the original wording where possible. 2. Build a benefit lineage register. For each claimed benefit, trace: - Original claim - Business case source or section, if provided - Baseline metric and value - Target metric and value - Actual post-deployment metric and value - Operational evidence used - Financial evidence used - Conversion method from operational movement to financial value - Accountable owner - Evidence gaps - Preliminary status: realized, partially realized, displaced, delayed, double-counted, unsupported, or not yet measurable 3. Build a baseline-to-actual bridge. For each material benefit, show the movement from baseline to actual: - Baseline value - Business case target - Actual observed value - Absolute movement - Percentage movement - Timing variance versus expected realization date - Volume, rate, mix, quality, and adoption effects where evidenced - External or confounding factors that may explain part of the movement 4. Calculate quality-adjusted realized benefit. For each benefit with enough evidence, calculate or estimate: - Claimed business case benefit - Gross observed benefit before adjustments - Timing adjustment for delayed or accelerated realization - Quality adjustment for error, rework, customer impact, control failures, or service degradation - Attribution adjustment for non-AI drivers and confounders - Displacement adjustment where savings moved cost, effort, risk, or workload elsewhere - Double-count exclusion where the same value appears in multiple benefit lines - Net recognized realized benefit - Confidence level: high, medium, low, or unsupported Show the calculation logic in plain language. If exact calculation is not possible, provide a bounded estimate only if the evidence supports the bounds; otherwise mark the benefit unsupported and explain the missing evidence. 5. Define attribution limits. - Identify which benefits can reasonably be attributed to the AI initiative, which are only partially attributable, and which cannot be attributed based on the evidence. - Explain the strongest alternative explanations for observed changes. - Identify any benefits that appear to be enabled by AI but realized through other changes such as process redesign, headcount decisions, pricing, demand changes, or manual workarounds. 6. Prepare the benefits realization decision record. Include: - Decision required from the finance owner and relevant benefit owners - Recommended realization status for each benefit - Net recognized benefit total, separated from unsupported or delayed benefits - Costs included and costs excluded, with rationale - Material caveats and unresolved evidence gaps - Required owner confirmations before the record is used externally - Follow-up actions, owner, and due date where evidence is missing or benefits are delayed Output format: A. Evidence Boundary Note - State what evidence was provided. - State what was not provided but would materially improve confidence. - State the measurement window used. - State any limits on causality, completeness, or financial recognition. B. Benefit Lineage Register Provide a table with these columns: - Benefit ID - Original benefit claim - Benefit category - Original baseline - Original target - Expected realization timing - Actual evidence observed - Financial evidence observed - Accountable owner - Evidence gap - Proposed status C. Baseline-to-Actual Bridge Provide a table with these columns: - Benefit ID - Baseline - Target - Actual - Movement versus baseline - Movement versus target - Timing variance - Operational driver evidenced - Confounders or external changes - Bridge conclusion D. Quality-Adjusted Benefit Calculation Provide a table with these columns: - Benefit ID - Claimed benefit value - Gross observed value - Timing adjustment - Quality adjustment - Attribution adjustment - Displacement adjustment - Double-count exclusion - Net recognized benefit - Confidence level - Calculation notes E. Attribution Limits and Unsupported Claims Separate into: - Benefits strongly supported by evidence - Benefits partially supported or partially attributable - Benefits delayed or not yet measurable - Benefits displaced to another cost, team, risk, or workload - Benefits double-counted or overlapping - Benefits unsupported by the provided evidence F. Benefits Realization Decision Record Provide: - Recommended decision: recognize, partially recognize, defer, reject, or escalate - Net recognized benefit total - Deferred benefit total - Unsupported benefit total - Key reasons for the decision - Required confirmations from finance owner, product owner, operational owner, data owner, or other named accountable owners - Open evidence requests - Risks if the organization uses the benefit claim without resolving gaps Completion checks before finalizing: - Every recognized benefit traces back to an approved business case claim and at least one post-deployment evidence item. - Operational movements are not converted into financial value without an explicit conversion method. - Delayed, displaced, double-counted, and unsupported benefits are not included in the recognized total unless clearly justified. - Observations, assumptions, and inferences are visibly separated. - The final decision record is suitable for review by the finance owner and named benefit owners, but does not claim their approval unless it is included in the evidence. ## Step 2 — Diagnose where expected AI value is leaking **Prompt** AI Adoption Value Leakage Diagnosis **Instructions** Map the value flow from capability to accepted operational outcome. Identify supported leakage mechanisms across adoption, task selection, workflow integration, output quality, review, rework, exceptions, downstream capacity, incentives, and benefit capture. **Input for this step** Use the benefits bridge with workflow evidence, adoption and task mix, quality, review and rework, queue and exception data, training and policy constraints, owner interviews, and known operating changes. **Carry forward** Carry the leakage ledger, quantified or bounded loss bridge, root mechanisms, intervention hypotheses, owners, and observable recovery tests into unit-economics analysis. **Review note** The process owner and product owner verify the operating mechanisms and reject interventions based only on unsupported adoption assumptions. **Prompt ID** AMO-P-000281 **Prompt URL** https://amo.ng/prompts/ai-adoption-value-leakage-diagnosis **Prompt content** Diagnose why measured AI capability is not becoming realized operational value for the process below. Separate adoption leakage, workflow leakage, quality leakage, control leakage, capacity leakage, rework leakage, and measurement leakage. Do not produce a generic AI adoption roadmap or ROI plan; the job is to explain the value gap and define evidence-backed recovery actions. Input to use: - Business process or function: [Business process or function] - AI capability or system introduced: [AI capability or system introduced] - Expected value case: [Expected value case] - Actual operating results: [Actual operating results] - Adoption and workflow evidence: [Adoption and workflow evidence] - Quality, control, and rework evidence: [Quality, control, and rework evidence] - Accountable owners and operating constraints: [Accountable owners and operating constraints] Evidence rules: - Treat provided facts, metrics, dates, artifacts, and firsthand observations as evidence. - Label estimates, explanations, and causal links as inference unless directly evidenced. - Do not claim access to systems, logs, tests, approvals, user interviews, dashboards, or financial records unless they are included in the input. - Preserve uncertainty. State what is unknown, what evidence would reduce uncertainty, and whether the missing evidence blocks a decision. - If the evidence is too thin to quantify a loss, provide a bounded qualitative assessment and specify the minimum evidence needed to quantify it. Diagnostic method: 1. Define the expected value flow from available AI capability to realized operational value. 2. Identify the observable handoffs where value can leak: user adoption, task selection, workflow integration, output quality, review controls, throughput capacity, exception handling, rework, measurement, and benefit capture. 3. Compare the expected value case against actual operating results. Separate volume effects, quality effects, cycle-time effects, labor-mix effects, risk/control effects, and measurement effects where possible. 4. Identify root leakage mechanisms before proposing interventions. Do not assume low adoption is the only cause. 5. Distinguish symptoms from mechanisms. Example: “low usage” is a symptom; “users avoid the tool because outputs require unplanned specialist review” is a leakage mechanism if supported by evidence. 6. Consider whether measured AI capability is being trapped by downstream constraints, approval queues, exception rates, policy limits, data quality, incentive conflicts, training gaps, workflow redesign gaps, or unmanaged rework. 7. Preserve existing operational constraints. Do not recommend broad transformation unless the evidence shows incremental recovery actions cannot address the leakage. Required deliverable: 1. Value-flow map Create a concise map showing: - AI capability available - Intended user or workflow touchpoint - Expected behavior change - Expected operational effect - Expected financial, service, risk, or capacity value - Actual observed path - Known breakpoints or uncertain handoffs 2. Leakage mechanism ledger Provide a ledger with these columns: - Leakage category - Observed evidence - Inference about mechanism - Value affected - Likely owner - Confidence level: High, Medium, or Low - Missing evidence - Immediate diagnostic check Use these leakage categories where relevant: - Adoption leakage - Workflow leakage - Quality leakage - Control or approval leakage - Capacity leakage - Rework leakage - Measurement leakage - Benefit capture leakage 3. Evidence-backed loss bridge Build a bridge from expected value to realized value. Use available numbers where provided. If numbers are missing, use directional bands and explain the basis. Include: - Starting expected value - Loss or dilution from adoption - Loss or dilution from workflow fit - Loss or dilution from quality or rework - Loss or dilution from controls or review load - Loss or dilution from capacity constraints - Loss or dilution from measurement or attribution error - Realized value observed - Unexplained residual gap 4. Intervention hypotheses For each major leakage mechanism, define a testable recovery hypothesis: - Hypothesis - Evidence that supports it - Evidence that contradicts or weakens it - Smallest safe intervention - Expected movement in adoption, quality, cycle time, cost, risk, or capacity - Leading indicator to monitor - Timeframe for signal - Risk if wrong 5. Owner-specific recovery plan Create an owner-specific plan using the named owners or the most likely accountable roles from the input. Include only actions supported by the diagnosis. For each action, specify: - Accountable owner, such as process owner, product owner, operations owner, finance owner, data owner, risk/control owner, or enablement owner - Decision required - Evidence required before action, if any - Recovery action - Completion criterion - Verification method - Dependency or constraint 6. Decision view Conclude with: - Most likely primary leakage mechanism - Secondary leakage mechanisms - Whether the current evidence supports intervention, further diagnosis, or pausing expansion - Highest-value next diagnostic check - Decisions each accountable owner should make next - What would change your conclusion Completion criteria: - The diagnosis explains the gap between available AI capability and realized operational value, not merely whether users adopted the tool. - Every material claim is tied to evidence, inference, or stated uncertainty. - The recovery plan assigns accountable owners and observable completion criteria. - No recommendations depend on unavailable inspections, unverified approvals, or assumed system behavior. ## Step 3 — Calculate cost per accepted outcome **Prompt** AI Operating Cost Attribution and Unit Economics Model **Instructions** Define the cost boundary and accepted-outcome denominator, allocate provider, infrastructure, labor, review, rework, failure, escalation, support, and control costs, then test cost-quality sensitivity and variance. **Input for this step** Provide realized-benefit and leakage findings, cost records, usage and workload volumes, accepted and rejected outcomes, retries, escalation, review effort, allocation policy, time window, and finance constraints. **Carry forward** Carry unit economics, denominator quality, allocation rules, cost variance bridge, sensitivities, confidence, and control decisions into the portfolio scale decision. **Review note** The finance owner and process owner approve the accepted-outcome definition, cost boundary, allocations, and any proxy assumptions before economics inform investment. **Prompt ID** AMO-P-000280 **Prompt URL** https://amo.ng/prompts/ai-operating-cost-attribution-and-unit-economics-model **Prompt content** Build a defensible AI operating cost attribution and unit economics model for the workflow below. The purpose is to attribute model, tool, retrieval, infrastructure, review, support, failure, and rework costs to accepted AI outcomes so accountable owners can compare true unit economics across workflows and variants. Context to provide: - AI workflow or product: [AI workflow or product] - Accepted outcome definition: [Accepted outcome definition] - Analysis period: [Analysis period] - Workflow variants to compare: [Workflow variants to compare] - Cost evidence and usage exports: [Cost evidence and usage exports] - Quality and rework evidence: [Quality and rework evidence] - Accountable owners: [Accountable owners] Evidence rules: - Use only the evidence provided. Do not claim that a source, export, invoice, log, ticket, approval, or test was inspected unless it is included in the input. - Separate observed facts, calculated values, assumptions, and inferences. - If evidence is missing, label it as missing and explain how it affects confidence or comparability. - Preserve uncertainty with ranges or confidence notes where point estimates are not supported. - Treat the accepted-outcome definition, analysis period, cost and usage sources, and comparable workflow boundaries as blocking when they are missing or materially conflicting. Request all blocking items in one consolidated clarification and do not calculate the affected unit economics until they are resolved. Continue with non-blocking gaps only as explicit Unknown or provisional inputs, with their effect on formulas, confidence, and comparability. - Do not create a general AI spend governance brief or a quality/latency experiment plan. Stay focused on cost attribution and accepted-outcome unit economics. Build the working artifact with these sections: 1. Cost Boundary Map Create a boundary map for the selected [AI workflow or product] covering the full operating cost chain for [Analysis period]. Include, where evidenced: - Model inference or subscription costs - Tool execution costs - Retrieval, embedding, vector database, search, or storage costs - Application, orchestration, logging, monitoring, and infrastructure costs - Human review, approval, escalation, and exception-handling costs - Support, customer operations, and internal operations costs - Failure, incident, reversal, refund, remediation, and rework costs - Evaluation, sampling, QA, audit, and oversight costs directly tied to production operation For each cost category, state whether it is included, excluded, partially included, or missing; identify the cost owner from [Accountable owners] where possible; and explain the rationale. 2. Accepted-Outcome Measurement Define the denominator for unit economics using [Accepted outcome definition]. Specify: - What counts as an accepted outcome - What does not count - How retries, duplicates, partial completions, escalations, rejected outputs, and reworked outputs should be treated - Any quality threshold required before an outcome is counted - The evidence source used for the count If the accepted-outcome count cannot be established from [Quality and rework evidence], provide a defensible interim method and list the validation needed from the product owner, finance owner, or operations owner. 3. Allocation Rules Design allocation rules that assign costs to accepted outcomes and to [Workflow variants to compare]. For each rule, include: - Cost pool - Allocation driver - Formula - Required evidence - Owner responsible for validating the driver - Known weakness or bias - When the rule should be replaced with a more precise method Prefer causal allocation drivers over broad averages. Use broad averages only when more precise evidence is unavailable, and label them clearly. 4. Accepted-Outcome Unit Economics Create a unit economics table for each workflow variant in [Workflow variants to compare]. Include: - Accepted outcome volume - Gross operating cost - Cost excluded or not yet evidenced - Cost per accepted outcome - Cost per attempted outcome, if attempt counts are available - Human review cost per accepted outcome - Failure and rework cost per accepted outcome - Infrastructure and retrieval cost per accepted outcome - Confidence level for each major figure Show formulas and make assumptions explicit. Do not overstate precision. 5. Variance Bridge Build a variance bridge explaining differences in cost per accepted outcome across variants or periods. Attribute variance where evidence supports it to: - Volume and utilization - Model selection or token/input-output mix - Tool calls and external service usage - Retrieval depth, indexing, or storage patterns - Review rates and escalation rates - Failure, rejection, incident, or rework rates - Infrastructure utilization or fixed-cost absorption - Support burden For each variance driver, state whether the driver is observed, calculated, inferred, or currently unverified. 6. Cost-Quality Sensitivity Analyze how unit economics change under plausible changes to quality and control variables, such as: - Acceptance rate - Human review rate - Escalation rate - Rework rate - Failure or incident rate - Retrieval depth or tool usage - Model choice or routing mix Use ranges when evidence is incomplete. Identify which variables most affect cost per accepted outcome and which quality controls appear economically justified. 7. Control Decisions Provide a decision table for the accountable owners. Include: - Decision under consideration - Economic rationale - Quality or risk tradeoff - Evidence supporting the decision - Evidence still missing - Owner who should approve or validate the decision - Completion check Focus on concrete controls such as routing changes, review thresholds, retrieval limits, escalation criteria, failure handling, logging improvements, or measurement changes. 8. Model Integrity Checks Before finalizing, perform these checks using the provided evidence: - Every included cost has an owner, source, allocation rule, and treatment in the model. - Accepted-outcome counts match the stated definition or are flagged as provisional. - Rejected, failed, duplicated, escalated, and reworked outputs are not accidentally counted as accepted outcomes unless justified. - Fixed, variable, and step costs are not mixed without explanation. - Variant comparisons use the same boundary unless differences are explicitly disclosed. - No unavailable inspection, execution, approval, or source verification is claimed. Final output format: - Cost boundary map - Allocation rule table - Accepted-outcome unit economics table - Variance bridge - Cost-quality sensitivity table - Control decision table - Missing evidence register - Owner verification checklist Write in direct finance and operating language suitable for review by the finance owner, product owner, operations owner, and data owner. Avoid generic governance language and unsupported certainty. ## Step 4 — Issue the Scale, Hold, Redesign, or Stop recommendation **Prompt** AI Initiative Scale, Stop, or Redesign Decision Brief **Instructions** Evaluate the combined evidence against the approved gates, compare counterfactual options, test scale economics and risk boundaries, and prepare an authorized next-decision brief. **Input for this step** Provide the original initiative gates, benefits bridge, leakage diagnosis, accepted-outcome economics, operational dependencies, residual risks, alternatives, commitments, decision horizon, and accountable owners. **Carry forward** Produce the final Scale, Hold, Redesign, or Stop recommendation, gate dispositions, evidence map, conditions, dissent or uncertainty, authorized next actions, owners, and re-review triggers. **Review note** The initiative sponsor, finance owner, process owner, product owner, and relevant risk reviewers make the investment and operating decision. **Prompt ID** AMO-P-000279 **Prompt URL** https://amo.ng/prompts/ai-initiative-scale-stop-or-redesign-decision-brief **Prompt content** Prepare a decision brief for one AI initiative. The objective is to recommend scale, hold, redesign, or stop using only the evidence provided, while making uncertainty, missing information, and decision authority explicit. Inputs to use: - Initiative name: [Initiative name] - Decision owner: [Decision owner] - Pilot or operating scope and timeframe: [Pilot or operating scope and timeframe] - Evidence package: [Evidence package] - Current constraints and non-negotiables: [Current constraints and non-negotiables] - Decision options under consideration: [Decision options under consideration] - Next decision date or trigger: [Next decision date or trigger] Evidence discipline: - Distinguish observed evidence from inference. Do not treat anecdotes, forecasts, vendor claims, or unverified internal estimates as confirmed facts. - Do not claim that a source, approval, test, control, incident review, financial model, or system inspection was completed unless the evidence package shows it. - If evidence is missing, state what is missing, why it matters, and the minimum evidence needed for a safer decision. - Preserve uncertainty. Use confidence levels only when tied to evidence quality. - Stay within decision-support authority: produce a recommendation and decision conditions; do not imply approval unless the accountable owner has already approved it in the evidence. - Avoid generic AI governance commentary. Focus on this initiative’s value, adoption, controls, reliability, dependencies, economics, risk boundaries, and reversibility. Decision standard: Recommend exactly one primary disposition: Scale, Hold, Redesign, or Stop. Use these meanings: - Scale: expand use because value, adoption, controls, reliability, economics, dependencies, and reversibility are acceptable within defined boundaries. - Hold: continue limited operation or pause expansion because evidence is incomplete or conditions are not yet met, but the initiative may still be viable. - Redesign: materially change workflow, model approach, controls, operating model, vendor setup, data inputs, or user experience before further expansion. - Stop: end or sunset the initiative because evidence does not support continued investment or risk is unacceptable relative to value and reversibility. Deliver the brief in the following format: 1. Decision frame - Initiative: state the initiative and operating scope. - Decision needed: state the decision being made now. - Accountable owner: identify the decision owner and any role-specific verifiers needed, such as product owner, data owner, security reviewer, legal/compliance owner, finance owner, operations owner, or release owner. - Authority boundary: state what this brief can recommend versus what requires owner approval. - Time boundary: state the next decision date or trigger. 2. Decision evidence map Create a table with these columns: Decision dimension, Observed evidence, Inference or assumption, Evidence strength, Missing information, Decision implication. Include these dimensions at minimum: - Intended business value - Realized value or leading indicators - User adoption and workflow fit - Output quality and reliability - Control effectiveness and exception handling - Data, model, vendor, and system dependencies - Security, privacy, compliance, and policy constraints - Operating support and ownership capacity - Scale economics and marginal cost - Reversibility, rollback, and exit cost 3. Gate-by-gate disposition For each gate, assign Pass, Conditional Pass, Fail, or Insufficient Evidence. Explain the reason in 2 to 4 sentences per gate. Gates: - Value gate: evidence of meaningful value relative to effort and alternatives. - Adoption gate: users, operators, or customers can and do use it in the intended workflow. - Control gate: risks, permissions, review paths, exceptions, and accountability are workable. - Reliability gate: quality, availability, latency, and failure modes are acceptable for the use case. - Dependency gate: critical data, vendor, model, integration, and staffing dependencies are known and manageable. - Economics gate: scale costs, support costs, and expected benefits remain acceptable beyond the pilot. - Reversibility gate: the initiative can be rolled back, contained, or sunset without unacceptable disruption. 4. Counterfactual options Compare the realistic options, not just the preferred one. Include at least: - Scale now - Hold in current scope - Redesign before expansion - Stop or sunset - Non-AI or lower-automation alternative For each option, provide: what would happen, expected upside, main downside, investment or effort required, risk exposure, reversibility, and what evidence would make this option stronger or weaker. 5. Scale economics and risk boundaries Provide a practical scale boundary, even if the recommendation is not to scale. Include: - Unit or marginal cost drivers, using provided evidence only. - Expected cost changes at expanded volume. - Support, monitoring, exception handling, and owner workload implications. - Benefits that are evidenced versus speculative. - Risk ceilings that should not be exceeded. - Required controls before expansion. - Stop-loss triggers or rollback conditions. - Any financial assumptions that the finance owner should verify before approval. 6. Recommendation State one primary recommendation: Scale, Hold, Redesign, or Stop. Then provide: - Rationale tied to the gates and evidence map. - Conditions required before execution. - Evidence that argues against the recommendation. - Residual risks the owner would knowingly accept. - What would change the recommendation. 7. Authorized next-decision brief Create an owner-ready next-decision plan with: - Decision to be requested from [Decision owner]. - Roles that should verify specific parts of the brief before action, such as finance owner for economics, security reviewer for security boundaries, data owner for data use, product owner for workflow value, operations owner for support readiness, and legal/compliance owner where applicable. - Immediate actions, responsible role, due date or trigger, and required evidence of completion. - Metrics or observations to collect before the next decision. - Completion checks that would show the recommendation has been executed or is ready for escalation. - Explicit statement of any unresolved blockers. Final quality check before answering: - The brief decides the fate of one operating initiative; it does not prioritize a portfolio. - Observations and inferences are clearly separated. - Missing information is visible and decision-relevant. - The recommendation is bounded by economics, risk, controls, dependencies, and reversibility. - No unavailable inspection, approval, test, or execution is claimed. ## Completion criteria The workflow is complete when: - Approved benefit claims reconcile to observed operational and financial evidence with attribution limits. - Value leakage is traced to supported mechanisms rather than usage symptoms alone. - Cost per accepted outcome includes quality, rework, escalation, control, and operating costs with stated allocation rules. - Scale, Hold, Redesign, or Stop gates use explicit evidence, uncertainty, owners, and next-decision triggers. - The recommendation is decision support and does not claim that funding, scaling, redesign, or shutdown occurred.