Epismo
Get started

v1 Published snapshot

Validate a Solution Through a Proof of Concept

Use when an FDE or solution consultant must reduce a specific technical or business uncertainty through a bounded PoC and support a credible Go, Iterate, or No-Go decision. This covers test design through evidence review, not full production deployment. Do not confuse a polished demo or passing local script with proof of customer value.

Back to playbook

Starting inputs

proposedSolution *

Candidate solution, integration or capability to test.

string

customer *

Customer or workstream identifier.

string

artifacts

Optional requirements, sample data, architecture, prior test reports.

array

constraints

Optional limitations: time, budget, security, data, environments, stakeholder access.

array

decisionQuestion *

Decision this PoC must make possible.

string

Steps

  1. 1

    Choose the highest-risk assumptions and decision rule

    Define the intended workflow and the few assumptions most able to invalidate the solution: user value, data adequacy, technical feasibility, quality, latency, reliability, security or economics. Compare them with existing customer evidence. Write explicit falsifiable hypotheses and thresholds for Go, Iterate and No-Go, including failure severity and the human decision maker. Explain why a cheaper non-build test would or would not suffice. Gate: test outcomes can meaningfully change a named decision before any build begins.

  2. 2

    Design a safe and representative evaluation

    Select representative scenarios, edge cases, realistic volume, negative tests, baseline alternative and ground-truth labeling. Specify metrics with units and denominators; for AI systems include hallucinations, unsafe actions and human-review requirements as appropriate. Document dataset provenance and access limits. Avoid production data movement or external service calls without authorized scope; synthetic data cannot establish real-world effectiveness by itself. Gate: the protocol would expose a meaningful failure rather than merely demonstrate a happy path.

  3. 3

    Build only enough to test the assumptions

    Implement or configure the smallest reversible working slice using available approved tools and access. Keep prototype shortcuts and missing production controls visible. Track deviations from evaluation protocol, dependencies and failure conditions. If execution is unavailable, provide a precise run sheet and expected observations instead of pretending to have run tests. Do not provision infrastructure, spend money or expose data outside existing authorization. Gate: the implementation is tied to predefined tests and limitations are explicit.

  4. 4

    Evaluate results against the precommitted criteria

    Run authorized tests and preserve raw results, failure examples, timestamps, configuration and sample size. Compare each metric with its threshold, baseline and uncertainty; separate reproducible results from anecdotes. For AI, assess failure severity and where human intervention is necessary. Distinguish tests not run, tests failed and tests passed only in controlled conditions. Reject post-hoc threshold shifting without recording the change. Gate: material claims are independently inspectable and untested claims are not presented as validated.

  5. 5

    Make the Go, Iterate, or No-Go recommendation

    Consolidate business value, technical findings, deployment gaps, expected cost and unresolved blockers. Compare options: progress to a time-boxed pilot, change scope and retest, or stop. Obtain the authorized sponsor's decision for any irreversible commitment; do not treat an agent recommendation as approval. Produce a concise decision report including reasons for the recommendation and the strongest counterargument. Gate: a sponsor can choose using evidence, limitations and explicit conditions rather than demo appeal.