Test technical feasibility with disposable prototypes

Why use this

1. A developer considering a technical idea may be tempted to build the full system before testing its riskiest assumption. A disposable prototype can also become misleading if its success criterion is vague or its shortcuts are later treated as production design.

2. This job could turn the idea into observable questions and a reviewed sequence of bounded experiments. Keeping prototype evidence separate from production requirements helps the owner decide what to pursue, revise or abandon.

Why an agent / simpler alternative

Useful judgment

Identify the uncertain assumptions, compare alternative tests and distinguish a narrow demonstration from broader feasibility.

Simpler alternative

Use a quick manual experiment when one clear question can be answered directly.

Unsuitable when

The workflow would deploy throwaway code, exceed resource limits or claim production readiness from a narrow prototype.

Proposed inputs

1. Name

   Idea/risk brief

   Owner

   Technical owner

   Minimum scope

   Desired outcome, constraints and uncertain assumptions

   Quality check

   Separate must-have behavior from optional ambitions

2. Name

   Test boundaries

   Owner

   Owner

   Minimum scope

   Allowed tools, resources, data and disposal expectations

   Quality check

   Define observable acceptance and stopping criteria

Access and setup — proposed or unknown

Proposed minimum

1. Draft a paper experiment plan with synthetic inputs; no prototype code, installs, terminal execution or paid services.

Compatibility unknowns

1. Current tool availability, environment isolation, dependencies and runtime compatibility are unknown.

External actions requiring approval

1. Prototype execution, data access, installations, resource spending and external publication requires explicit plan approval.

Expected deliverable and review checks

Proposed artifact

Feasibility-plan candidate with ordered questions, proposed fixtures, comparison criteria and unresolved scope decisions.

Critical checks

1. Tie each test to a risk; define what failure means; distinguish proposed results from observed evidence; preserve disposal boundaries.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   The prototype avoids the difficult edge case

   Why it matters

   A successful demo misses the main risk

   Proposed response

   Include the edge case before interpreting feasibility.

2. Signal

   A shortcut becomes an implementation commitment

   Why it matters

   Temporary choices silently shape production

   Proposed response

   Label disposable assumptions and document what would need redesign.

Effort and cost — unknown

Setup work

1. Agree test order and resource limits.

Ongoing review

1. Owner reviews actual future evidence before expanding scope.

Unknowns

1. Technical feasibility, prototype effort, dependency constraints and costs are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent an import-tool idea with uncertain file size, malformed-input handling and offline behavior; propose a bounded test sequence.

Acceptance checks

1. Prioritize observable risks; include failure cases; code nothing and issue no feasibility verdict.

Stop conditions

1. Stop if acceptance criteria or experiment authority is unclear.

Limits

1. A prototype plan cannot establish technical feasibility, scalability or production readiness.