ChiefOSby ConversintStart free
Menu
← Back to the library
Research and business strategy

Capability feasibility planning

Plan and run a bounded capability-feasibility investigation when a question such as 'can AI do X?' needs several independent tests rather than a one-shot answer. Use for capability spikes, technical due diligence, production-readiness research, and ranked go/no-go recommendations. Produces a cited per-spike record and synthesis; it does not deploy a system, spend funds, or delete artifacts without separate authorization.

Works with the context you provideVersion 3.0.0Historical revision

# Capability feasibility planning

Use this method to turn a fuzzy capability question into a small, evidence-led set of tests and a decision-ready recommendation. It is for questions where several assumptions must be tested independently, not for a simple research answer or a vendor comparison.

Host operations and boundaries

Read `references/host-operations.md` before using a host's research, agent, artifact, or version-control capability. If a requested operation is not available or authorized, return the proposed dispatch, artifact, or cleanup plan instead. Do not claim a test ran when it was only reasoned about.

Every external factual claim in a spike record or synthesis needs an inline source and a Sources section. Keep observations, assumptions, measurements, and unknowns distinct.

Six-phase workflow

1. **Intake.** Lock the decision to support, audience, scope, constraints, evidence already available, and artifact destination. Ask only for gaps that change the test or decision. 2. **Candidate spikes.** Propose three to five testable plays. For each, state the capability assumption, success signal, and the single most important risk. 3. **Risk screen.** Do a lean source check for policy, legal, safety, data, integration, or capability blockers. Mark each play as proceed, reframe, or stop, and explain why. 4. **Dispatch.** Run independent spikes in parallel only when the host supports it and their evidence does not depend on one another. Run dependent spikes in order. Use `references/spike-template.md` and `references/subagent-dispatch.md`; record failures and thin evidence rather than smoothing them over. 5. **Synthesize.** Read every completed spike record and create a ranked synthesis using `references/synthesis-template.md`. Separate what was demonstrated from what remains a hypothesis, and state the next smallest decision or experiment. 6. **Cleanup.** Inventory temporary scaffolding separately from deliverables. Show paths, purpose, and tracked status, then wait for a fresh explicit approval before deletion. Keep deliverables and evidence needed for the decision.

Output

Each spike record includes the question, assumption, method, evidence, result, production blockers, sources, and created artifacts. The synthesis includes a bottom line, status table, ranked recommendations, deferred items, confidence limits, and the next action.

Quality rules

- Do not invent a threshold, benchmark, policy clearance, or measured result. - A simulated response is not evidence about an untested target system. - Stop or reframe when a blocker invalidates the original play. - Keep analysis separate from deployment, publication, procurement, and other external changes.