# Allocate an AI Investment Portfolio Under Constraints

Workflow ID: AMO-W-000023
Workflow URL: https://amo.ng/workflows/allocate-ai-investment-portfolio-under-constraints

## Outcome

A portfolio allocation package containing comparable initiative evidence, work-design choices, control and routing economics, concentration exposure, dependency and option-value analysis, funding tiers, conditions, and explicit defer or stop decisions.

## Before you begin

- AI initiative inventory, approved outcomes, maturity, realized evidence, remaining investment requests, and accountable sponsors
- Task and workforce evidence, quality and capacity constraints, transition risk, and alternative operating designs
- Review demand, reviewer capacity, queue and rework evidence, control effectiveness, and avoided-loss assumptions
- Model-routing workload slices, accepted-outcome quality, latency, reliability, capacity, and cost evidence when material
- Vendor spend, contracts, capability dependencies, switching options, and concentration constraints
- Available capital, risk capacity, dependencies, non-negotiables, decision horizon, and portfolio authority

## Step 1 — Establish the work-design evidence boundary

**Prompt**

Automation Displacement and Augmentation Evidence Review

**Instructions**

For each initiative, determine which work should be automated, augmented, redesigned, or retained using task evidence, quality effects, capacity, transition risk, and accountable ownership.

**Input for this step**

Provide initiative scopes, task and workflow evidence, quality and capacity data, exception patterns, role impacts, constraints, alternatives, and intended outcomes.

**Carry forward**

Carry the task-level operating design, evidence limits, transition risks, capacity claims, owners, and alternative designs into reviewer-control economics.

**Review note**

Process, workforce, product, legal, and employee-relations owners decide role and transition actions within their authority; this analysis does not authorize displacement.

**Prompt ID**

AMO-P-000315

**Prompt URL**

https://amo.ng/prompts/automation-displacement-augmentation-evidence-review

**Prompt content**

Review whether specific work should be automated, augmented, redesigned, or retained. Base recommendations on task-level operating evidence and outcome requirements rather than model capability demonstrations or generic labor-saving assumptions.

Inputs:
- Process, task inventory, roles, handoffs, decisions, service outcomes, and accountability: [Process tasks roles and outcomes]
- Volume, time, queue, cost, error, rework, variability, seasonal load, skill, and user-impact evidence: [Baseline workload and performance evidence]
- Pilot scope, adoption, accepted outcomes, AI attempts, reviewer intervention, exceptions, latency, cost, and observed limitations: [AI pilot and operating evidence]
- Safety, legal, privacy, security, quality, bias, customer, employee, and operational failure evidence: [Quality risk and exception evidence]
- Staffing, specialist capacity, training, labor commitments, change readiness, redeployment options, and transition limits: [Workforce capacity and transition constraints]
- Process owner, role owners, people/HR reviewer, legal/privacy reviewer, finance reviewer, and executive decision authority: [Decision rights and accountable owners]

Do not treat time saved per attempt as released capacity. Do not invent job impact, adoption, attrition, productivity, or quality results. Distinguish observed operating evidence from inference. Separate task automation from role elimination, assisted work from autonomous work, theoretical potential from observed operation, and gross time savings from rework, review, exception, coordination, and transition effort.

Review:

1. Decompose work at the decision-relevant level.
   Map tasks, inputs, outputs, variability, tacit judgment, interaction, authority, dependencies, failure consequences, and current owner. Avoid labels so broad that distinct work is hidden.

2. Establish the baseline.
   Record volumes, time, queue, quality, rework, cost, skill, demand variability, and outcome evidence with periods and sources. Mark missing measures.

3. Assess AI operating evidence.
   For each task, compare attempted, accepted unchanged, corrected, rejected, escalated, failed, and unmeasured outcomes. Include setup, prompting, context gathering, validation, review, exception handling, and downstream correction.

4. Determine the appropriate work mode.
   Consider Retain, Assist, Automate bounded task, Automate with review, Redesign process, Consolidate demand, or Stop low-value work. State why the mode fits the evidence and which authority remains with the accountable role.

5. Model capacity and role effects.
   Calculate capacity released only when workload can actually be removed, avoided, absorbed, or redeployed. Identify new work, bottlenecks, skill shifts, supervision, peak capacity, and exception ownership.

6. Assess distributional and transition risk.
   Review who bears errors, monitoring, learning, workload intensification, accessibility impacts, or skill erosion. Identify employment, consultation, legal, or accommodation questions for the responsible reviewers without offering legal conclusions.

7. Design a reversible transition.
   Specify scope, owners, training, shadow period, dual-run if justified, acceptance gates, workload and quality monitoring, escalation, rollback, and a review date. Use the smallest viable change.

8. Make the decision.
   Provide task-level dispositions and a role/process implication; do not generalize beyond supplied evidence.

The process owner approves task redesign, the data or privacy owner approves sensitive-data use, and the workforce or legal reviewer addresses role and employment consequences. For each recommendation, require acceptance evidence with an expected observation, actual observation when measured, outcome guardrail, and reversal condition. The review may recommend a disposition but does not authorize staffing or production changes.

Record approval from the process owner for task redesign and approval from the relevant data, privacy, workforce, or legal owner before consequential changes.

Required deliverable:

# Automation Displacement and Augmentation Evidence Review

## Task and Outcome Map
| Task | Current owner | Required outcome/authority | Variability/judgment | Failure consequence | Baseline evidence |
|---|---|---|---|---|---|

## AI Operating Evidence
| Task | Attempts | Accepted/corrected/rejected | Review/exception effort | Quality/risk | Evidence limit |
|---|---:|---|---|---|---|

## Work-Mode Decisions
| Task | Retain/assist/automate/redesign/stop | Evidence rationale | Authority retained | Required control | Owner |
|---|---|---|---|---|---|

## Capacity and Transition Effects
| Role/team | Work removed | New work | Net capacity evidence | Skill/change need | Risk |
|---|---|---|---|---|---|

## Transition Plan
| Phase | Scope | Evidence gate | Training/ownership | Stop or rollback trigger |
|---|---|---|---|---|

## Decision Summary
- Tasks approved for change:
- Tasks retained:
- Capacity claim supported:
- Claims not supported:
- Required people/legal/privacy reviews:
- Reassessment date:

Completion requires task-level evidence, explicit retained authority, a credible net-capacity bridge, and a reversible transition that does not turn a capability demo into an unsupported workforce decision.


## Step 2 — Model reviewer burden and control economics

**Prompt**

Reviewer Burden and Control Economics Model

**Instructions**

Quantify review demand, capacity, queue delay, rework, control effectiveness, and avoided loss to determine whether review gates are proportionate and sustainable for each material initiative.

**Input for this step**

Use the work-design findings with workload volumes, review times, staffing and cost, queue and rework data, failure exposure, control outcomes, service levels, and alternatives.

**Carry forward**

Carry reviewer capacity, full control cost, delay, effectiveness, avoided-loss ranges, bottlenecks, and redesign options into routing economics.

**Review note**

Process, control, risk, and finance owners approve workload, effectiveness, cost, and avoided-loss assumptions.

**Prompt ID**

AMO-P-000311

**Prompt URL**

https://amo.ng/prompts/reviewer-burden-control-economics-model

**Prompt content**

Build an economics model for the review controls applied to an AI-assisted workflow. Quantify review labor, queue delay, rework, escalation, and avoided loss so owners can decide where full review, sampling, automation, or redesign is justified.

Inputs:
- Workflow stages, eligible volume, risk tiers, current review rules, escalation triggers, and service targets: [Workflow volume and review policy]
- Reviewer handling time, wait time, shifts, capacity, utilization, queue age, skill mix, and compensation or loaded-cost evidence: [Reviewer time queue and staffing evidence]
- Acceptance, correction, rejection, escalation, defect escape, incident, repeat-review, and downstream outcome evidence: [Quality incident and rework evidence]
- Error consequences, delay costs, accepted risk, value per accepted outcome, and financial assumptions with sources: [Cost value and risk assumptions]
- Sampling, tiering, stronger automated checks, workflow changes, tooling, staffing, and elimination options: [Alternative control options]
- Budget, labor, policy, legal, quality, process-owner, finance-reviewer, and risk-owner constraints: [Constraints and accountable owners]

Do not treat reviewer time as zero cost or every caught defect as avoided loss. Do not invent wages, volumes, handling times, defect rates, or causal savings. Separate observed evidence, calculations, assumptions, and inference from unquantified consequences. Preserve quality and authority requirements even when a cheaper option appears attractive.

Model:

1. Define the control objective.
   State what the review is intended to prevent or decide, the population covered, service requirement, risk tiers, and non-delegable approvals.

2. Build the demand and capacity model.
   Calculate review arrivals, handling workload, available productive capacity, utilization, queue behavior, skill constraints, and surge exposure from supplied evidence. Show formulas and units.

3. Attribute full review cost.
   Include direct review time, context gathering, rework, repeat review, escalations, calibration, training, management, tooling, queue delay, and downstream waiting. Avoid double-counting shared costs.

4. Measure control yield.
   Quantify, where evidence permits, accepted unchanged, corrected, rejected, escalated, and escaped defects by risk tier. Distinguish defects detected from harm actually avoided.

5. Estimate consequence and uncertainty.
   Use ranges or scenarios for avoided loss and delay value when causal evidence is incomplete. Identify unquantified safety, legal, trust, or approval consequences that remain decision constraints.

6. Compare control designs.
   Model current review, risk-tiered review, statistically defensible sampling, automated pre-check plus reviewer, specialist escalation, capacity addition, and workflow redesign. Show cost, delay, residual risk, capacity headroom, and evidence needs.

7. Stress test.
   Vary volume, handling time, defect prevalence, reviewer availability, false-negative rate, and consequence assumptions. Identify breakpoints where the control misses its SLO or becomes uneconomic.

8. Recommend a bounded design.
   Choose Retain, Tier, Sample, Automate pre-checks, Add capacity, Redesign, or Suspend the workflow. State protected categories that remain fully reviewed, owner authority, trial period, and monitoring.

Use ChatGPT as an analysis workspace for the supplied measurements and assumptions, not as evidence that timing studies, recalculations, or control tests occurred. For each recommended review policy, provide acceptance evidence with the expected observation, actual observation when measured, owner, and decision threshold. Label unexecuted calculations and proposed policy changes as proposed, and do not claim approval or implementation without supplied evidence.

Required deliverable:

# Reviewer Burden and Control Economics Model

## Control Objective and Population
- Workflow and decision:
- Review population/risk tiers:
- Non-delegable approvals:
- Service target:

## Assumption and Evidence Ledger
| Variable | Value/range | Unit | Observed/calculated/assumed | Source | Sensitivity |
|---|---:|---|---|---|---|

## Demand, Capacity, and Queue Model
| Scenario | Review volume | Work hours | Capacity | Utilization | Queue/delay | SLO result |
|---|---:|---:|---:|---:|---:|---|

## Cost and Control Yield
| Risk tier | Full review cost | Correction/rejection yield | Escaped defects | Delay cost | Avoided-loss evidence |
|---|---:|---:|---:|---:|---|

## Alternative Designs
| Design | Cost/outcome | Delay | Residual risk | Capacity headroom | Evidence gap | Authority boundary |
|---|---|---|---|---|---|---|

## Recommendation and Monitoring
- Decision:
- Protected full-review scope:
- Trial/transition:
- Metrics and stop conditions:
- Finance, process, quality, and risk owners:

Completion requires formula transparency, explicit uncertainty, capacity and queue effects, and a design that preserves required owner approvals rather than pricing them away.


## Step 3 — Evaluate model-routing economics when material

**Prompt**

Model Routing Economics Decision Brief

**Instructions**

Run this step for initiatives using multiple model routes or considering routing changes. Otherwise record Not applicable. Compare accepted-outcome quality, latency, reliability, capacity, switching, and full cost by workload slice.

**Input for this step**

Provide workload slices, routing policy, model performance and accepted-outcome evidence, volumes, latency, retries, failures, review and rework, prices, capacity, switching costs, and constraints.

**Carry forward**

Carry the routing policy options, unit economics, quality and reliability trade-offs, capacity limits, sensitivity, and decision gates into concentration review.

**Review note**

Product, engineering, finance, risk, and release owners approve routing changes and accepted quality or reliability trade-offs.

**Prompt ID**

AMO-P-000312

**Prompt URL**

https://amo.ng/prompts/model-routing-economics-decision-brief

**Prompt content**

Prepare an economics decision brief for routing AI workloads across models, providers, configurations, or local and hosted routes. Optimize for accepted outcomes and service constraints, not headline token price.

Provide:
- Task types, risk tiers, languages, modalities, context sizes, tool needs, user segments, volumes, and service requirements: [Workload slices and service requirements]
- Model/provider capabilities, context, tools, regions, data terms, availability, and compatibility evidence: [Model route capability evidence]
- Slice-level accepted-output quality, retries, reviewer rework, latency distribution, errors, fallbacks, token/tool usage, and cost: [Quality latency reliability and cost results]
- Forecast volume, concurrency, rate limits, capacity, reserved spend, discounts, minimums, and contract terms: [Volume capacity and commercial constraints]
- Safety and compliance limits, fallback compatibility, portability, migration, concentration, and outage constraints: [Risk fallback and switching constraints]
- Product, finance, model, service, security/privacy, and release owners plus monitoring and change limits: [Decision owners and monitoring limits]

Do not compare routes using different task populations without adjustment. Do not invent benchmark equivalence, prices, acceptance rates, or capacity. Distinguish observed evidence from inference. Separate vendor list price, contracted marginal cost, allocated fixed cost, and full cost per accepted outcome. A cheaper route is not admissible for a slice it cannot safely or reliably serve.

Decision method:

1. Define route eligibility by slice.
   List mandatory capability, data, policy, tool, context, latency, and reliability requirements. Exclude routes that fail a non-negotiable constraint before economic comparison.

2. Normalize evidence.
   Align time period, workload, units, quality definition, accepted-output rule, retries, cache behavior, and reviewer intervention. Flag non-comparable tests and missing production evidence.

3. Build full route economics.
   Calculate cost per attempt and per accepted outcome using supplied inputs. Include tokens, tools, retrieval, infrastructure, retries, fallbacks, validation, review/rework, failed outcomes, and allocated commitments where decision-relevant.

4. Model latency and reliability consequences.
   Use distribution or percentile evidence rather than averages alone. Include rate-limit failure, queueing, cold starts, timeouts, and fallback amplification. Quantify only when supplied data permits.

5. Compare routing strategies.
   Evaluate single route, rule-based slice routing, staged escalation, confidence/validator routing, portfolio routing, and local/hosted split. Include operational complexity, observability, testing, fallback compatibility, and switching burden.

6. Stress test assumptions.
   Vary volume, acceptance, token use, review rate, outage, price, discount, model quality, and traffic mix. Identify route changes and economic breakpoints.

7. Select a routing policy.
   For each slice, choose primary route, fallback or escalation, eligibility gate, budget guardrail, monitoring, and reassessment trigger. Preserve owner authorization for high-risk or data-restricted slices.

Use ChatGPT to compare the supplied routing evidence and scenarios; do not claim that benchmarks, failovers, or cost measurements were executed unless results are provided. The service owner approves routing constraints and the release owner authorizes production changes. For every candidate route, state the expected observation, actual observation when available, acceptance evidence, unresolved service-contract gap, and rollback condition.

Record approval from the service owner for routing constraints and approval from the release owner before any production routing change.

Required deliverable:

# Model Routing Economics Decision Brief

## Workload and Eligibility Matrix
| Slice | Volume | Mandatory requirements | Eligible routes | Excluded route/reason | Owner |
|---|---:|---|---|---|---|

## Evidence Normalization Ledger
| Route/slice | Evidence period | Quality/acceptance basis | Latency basis | Cost basis | Comparability gap |
|---|---|---|---|---|---|

## Route Economics
| Route/slice | Cost/attempt | Acceptance rate | Cost/accepted outcome | P95 latency | Reliability | Review/rework | Confidence |
|---|---:|---:|---:|---:|---:|---:|---|

## Strategy Comparison
| Strategy | Expected economics | Quality/risk | Complexity | Capacity | Concentration/switching exposure |
|---|---|---|---|---|---|

## Routing Decision
| Slice | Primary route | Escalation/fallback | Eligibility gate | Budget guardrail | Stop/review trigger |
|---|---|---|---|---|---|

## Assumptions and Reassessment
List decision-critical assumptions, breakpoints, evidence gaps, monitoring owners, and changes that require a new routing decision.

Completion requires comparable slice-level evidence, full cost per accepted outcome, exclusion of inadmissible routes before optimization, and a monitorable policy with clear fallback limits.


## Step 4 — Assess vendor cost concentration and switching exposure

**Prompt**

AI Vendor Cost Concentration Risk Review

**Instructions**

Quantify spend and capability concentration, contract and capacity exposure, switching constraints, alternative coverage, and the economics of mitigation across the portfolio.

**Input for this step**

Provide provider spend and forecasts, initiative dependencies, contracts, commitments, pricing, capacity limits, portability and migration evidence, alternatives, incidents, and risk tolerance.

**Carry forward**

Carry the concentration map, stress scenarios, switching and mitigation costs, contractual constraints, dependency risks, and accepted residual exposure into allocation.

**Review note**

Procurement, finance, legal, security, architecture, and portfolio owners approve commercial actions and accepted concentration risk.

**Prompt ID**

AMO-P-000313

**Prompt URL**

https://amo.ng/prompts/ai-vendor-cost-concentration-risk-review

**Prompt content**

Review concentration risk across an organization's AI vendors and providers. Combine spend exposure with technical, data, operational, contractual, and capability dependency to support a mitigation and funding decision.

Inputs:
- Vendors, products, models, regions, workloads, business processes, criticality, and owners: [AI vendor portfolio and workload map]
- Invoices, usage, allocated spend, credits, minimums, commitments, forecast, and accepted-outcome volumes: [Spend usage and commitment evidence]
- Pricing schedules, renewal dates, termination rights, data-return/deletion terms, portability, liability, and service commitments: [Contract pricing and exit terms]
- APIs, proprietary features, prompts, tools, fine-tunes, embeddings, data stores, identities, integrations, skills, operating runbooks, and service dependencies: [Technical operational and data dependencies]
- Qualified alternatives, benchmarks, migration estimates, compatibility tests, capacity, parallel-run, and switching evidence: [Alternative vendor and migration evidence]
- Concentration limits, continuity requirements, budget, procurement owner, finance reviewer, service owner, security/privacy reviewer, and executive approver: [Risk limits and accountable owners]

Do not infer substitutability from marketing claims or model rankings. Do not invent prices, migration duration, alternative capacity, or negotiated rights. Distinguish committed versus avoidable spend, revenue dependency versus operating convenience, and theoretical alternative versus tested exit path.

Review:

1. Define concentration dimensions.
   Measure supplied spend share, workload share, critical-process share, data custody, proprietary asset dependency, regional reliance, and operational expertise concentration. Avoid reducing all exposure to spend percentage.

2. Build dependency chains.
   Trace each critical workload through vendor capabilities, models, APIs, tools, storage, identities, quotas, contracts, and internal operating skills. Identify single points of failure and hidden second-order dependencies.

3. Normalize economics.
   Separate consumed spend, commitments, credits, fixed integration costs, variable usage, switching cost, double-run cost, exit fees, and stranded investment. Link costs to time period and workload.

4. Assess switching and exit readiness.
   Review data export/deletion, prompt and tool portability, behavioral equivalence, evaluation assets, observability, alternative capacity, contractual notice, transition skills, and rollback. Mark untested claims.

5. Model concentration scenarios.
   Compare vendor price increase, service degradation, model retirement, contract change, regional restriction, security incident, capacity loss, and strategic exit. State impact ranges using supplied evidence.

6. Evaluate mitigations.
   Consider negotiated protections, workload diversification, compatibility layer, secondary route, escrow/export controls, capacity reservation, contract restructuring, or accepted concentration. Include ongoing complexity and quality cost.

7. Make a decision.
   Choose Accept and monitor, Mitigate contractually, Diversify selected workloads, Build exit readiness, Renegotiate, or Begin transition. Assign funding and owner actions without automatically requiring multi-vendor architecture.

Use Claude to structure and challenge the supplied commercial and technical evidence; it must not claim vendor testing, negotiations, or failover exercises occurred without results. The commercial owner proposes funding, while service, security, legal, and finance owners approve changes in their domains. For every mitigation, record acceptance evidence, expected observation, actual observation when available, residual concentration, and exit or rollback condition.

Use Claude only as an analysis workspace for supplied evidence. Do not claim that vendor testing, negotiations, failover exercises, approvals, or mitigation actions occurred unless the corresponding evidence is supplied. Record approval from the commercial owner and each accountable service, security, legal, and finance owner before implementing a change.

Required deliverable:

# AI Vendor Cost Concentration Risk Review

## Portfolio Exposure
| Vendor | Spend share | Workload/criticality share | Data/capability dependency | Contract horizon | Owner |
|---|---:|---|---|---|---|

## Dependency and Single-Point Map
| Workload | Critical dependency | Substitutability evidence | Failure consequence | Alternative readiness |
|---|---|---|---|---|

## Economic Exposure Ledger
| Exposure | Amount/range | Avoidable/committed | Time horizon | Evidence | Uncertainty |
|---|---:|---|---|---|---|

## Scenario and Mitigation Analysis
| Scenario | Operating/financial impact | Existing protection | Mitigation option | Cost/complexity | Residual risk |
|---|---|---|---|---|---|

## Concentration Decision
- Decision:
- Accepted concentration boundary:
- Funded mitigations:
- Contract asks:
- Exit-readiness work:
- Trigger for transition:
- Owners and review date:

Completion requires a combined spend and capability view, evidence-based alternative readiness, explicit transition economics, and a proportionate choice rather than an assumed requirement to diversify everything.


## Step 5 — Allocate capital and define reallocation gates

**Prompt**

AI Portfolio Capital Allocation Brief

**Instructions**

Compare initiatives using realized evidence, remaining option value, dependencies, strategic constraints, risk capacity, and the prior economic findings. Make explicit funding trade-offs under the available capital constraint.

**Input for this step**

Provide initiative evidence and requests, work-design, reviewer, routing and concentration findings, budget and risk limits, dependencies, commitments, alternatives, time horizon, and decision criteria.

**Carry forward**

Produce the final funding tiers, conditions, deferred or stopped initiatives, dependency map, milestone evidence, owners, reallocation triggers, dissent, and uncertainty.

**Review note**

The accountable portfolio and finance owners make capital decisions after initiative sponsors and relevant risk owners record their evidence and conditions.

**Prompt ID**

AMO-P-000314

**Prompt URL**

https://amo.ng/prompts/ai-portfolio-capital-allocation-brief

**Prompt content**

Prepare a capital allocation brief across a portfolio of AI initiatives. Recommend which initiatives to fund, stage, hold, redesign, or stop while respecting shared capital, specialist capacity, risk, data, platform, and change constraints.

Provide:
- Initiatives, stage, decision horizon, requested funding, current commitments, and accountable sponsors: [Portfolio initiatives and decision horizon]
- Approved case, realized benefits, accepted outcomes, adoption, quality, cost, risk, delivery evidence, and unresolved assumptions per initiative: [Initiative evidence and current state]
- Available budget, engineering, data, security, review, procurement, change, and operating capacity: [Resource capital and capacity constraints]
- Technical and business dependencies, shared platforms, vendor concentration, sequencing, regulatory exposure, and correlated risks: [Dependencies risks and shared capabilities]
- Strategic outcomes, must-do commitments, hurdle rules, risk appetite, and evidence standards: [Strategic objectives and allocation rules]
- Investment committee, finance owner, product/process owners, risk reviewers, and decision authority: [Governance owners and decision rights]

Do not rank initiatives from sponsor estimates as if they were comparable realized evidence. Do not invent benefits, probability, cost, or capacity. Distinguish observed portfolio evidence from inference. Separate sunk cost from future decision, committed spend from avoidable spend, and strategic option value from unsupported optimism. Do not collapse consequential risk into one weighted score.

Allocation method:

1. Normalize initiative state.
   Record stage, approved outcome, evidence maturity, realized result, next decision, remaining investment, time to evidence, reversibility, dependencies, and owner. Identify incompatible units and unsupported claims.

2. Separate funding obligations.
   Distinguish mandatory remediation/compliance, keep-the-lights-on, committed transition, evidence-generating option, growth investment, and speculative exploration. Make non-discretionary claims traceable.

3. Assess evidence-adjusted value.
   Evaluate realized or validated benefit, remaining uncertainty, incremental cost, adoption capacity, accepted-outcome economics, strategic relevance, and downside. Use ranges and scenarios when inputs are uncertain.

4. Map constraints and dependencies.
   Build a capacity and dependency view across teams, data, platforms, vendors, reviews, change windows, and users. Identify initiatives that compete for the same bottleneck or unlock several others.

5. Define portfolio choices.
   Compare baseline commitments with alternative allocation packages. Show which initiatives are Fund, Stage with evidence gate, Hold, Redesign, Stop, or Retain as option. Include freed resources and lost option value.

6. Stress test.
   Test lower benefits, higher cost, delayed adoption, vendor price change, risk event, capacity reduction, and dependency delay. Identify decisions robust across plausible cases.

7. Recommend allocation.
   Specify capital and scarce-capacity allocation, evidence milestones, release of funds by gate, stop conditions, dependency actions, and owners. Avoid funding all initiatives partially when concentration is needed to learn or deliver.

Use Claude to reconcile the supplied portfolio evidence and scenarios; do not present recalculations, funding approvals, or delivery outcomes as completed unless evidence is supplied. The finance owner controls the capital envelope, initiative owners attest delivery evidence, and the accountable portfolio owner approves allocation decisions. Each recommendation must include acceptance evidence, expected observation, actual observation when available, dependency condition, and a funded-stage exit gate.

Required deliverable:

# AI Portfolio Capital Allocation Brief

## Initiative Evidence Ledger
| Initiative | Stage | Approved outcome | Realized/validated evidence | Remaining ask | Time to next evidence | Owner |
|---|---|---|---|---:|---|---|

## Constraint and Dependency Map
| Resource/dependency | Available capacity | Competing initiatives | Bottleneck/unlock effect | Owner |
|---|---:|---|---|---|

## Evidence-Adjusted Portfolio View
| Initiative | Incremental value evidence | Incremental cost | Risk/uncertainty | Reversibility | Strategic role | Decision |
|---|---|---:|---|---|---|---|

## Allocation Scenarios
| Scenario | Funded initiatives | Capital/capacity use | Expected evidence/outcome | Trade-offs | Failure trigger |
|---|---|---|---|---|---|

## Recommended Allocation
| Initiative | Fund/stage/hold/redesign/stop | Amount/capacity | Gate before next release | Stop condition | Accountable owner |
|---|---|---|---|---|---|

## Portfolio Decision Notes
- Unfunded but retained options:
- Shared capability investments:
- Correlated risks:
- Rebalance date and evidence required:

Completion requires allocation within actual capital and capacity, explicit opportunity costs, evidence gates for uncertain initiatives, and named stop conditions rather than automatic continuation.


## Completion criteria

The workflow is complete when:

- Each initiative has comparable evidence for outcomes, maturity, dependencies, remaining option value, risks, and requested capital.
- Automation, augmentation, redesign, or retention choices are evidence-based rather than inferred from job titles or adoption alone.
- Review burden and model-routing economics are included where material or marked Not applicable with a reason.
- Vendor concentration and switching constraints are quantified or bounded.
- Fund, conditionally fund, defer, redesign, or stop decisions reconcile to the capital and risk constraints, with owners, milestones, evidence gates, and reallocation triggers.