Result-to-Decision Test Card
For each result that could matter—including an invalid or inconclusive result—what decision would change?
It also asks what running the test consumes and what can be preserved before the test begins.
Before an expensive, destructive, or consequential test, record what each plausible result would change and what running the test consumes. Before a change that is costly or difficult to reverse, record what it may close and what must be preserved.
Use these worksheets alongside the test, change-control, and review processes you already have. They add three practical questions; they do not replace engineering judgment or required controls.
Start empty or explore an invented example. Record possible results and the decisions they would change, then copy, print, or save your draft. No account required.
Open the browser Test CardThe browser workspace saves its own draft format. The original fillable PDFs and v0.2 JSON records remain below.
Choose the record that matches the decision. The PDF is for ordinary use; the JSON template and schema are available for software or AI-assisted workflows.
For each result that could matter—including an invalid or inconclusive result—what decision would change?
It also asks what running the test consumes and what can be preserved before the test begins.
What could this action open, preserve, narrow, or close—and when does reversal stop being practical?
It records reopening requirements, preservation actions, and who has authority to approve the change.
What happened, what decision followed, and where did reality differ from the original plan?
Complete it after the action so predictions and observations remain separate and can be compared.
Do not create a parallel process just to use it. Add the worksheet to a test-readiness review, test approval, change request, deviation, release, or similar gate.
A team has one qualified prototype left. It proposes a destructive thermal test to decide whether to proceed to a larger build.
Record whether the evidence supports it as open, conditional, unknown, or no longer reachable under the stated conditions.
A route may be closed while a recovery route remains possible. Record how well that recovery is supported.
Record whether the proposed action is expected to open, preserve, narrow, close, or reopen an option.
The schemas use controlled values so records can be compared: path_standing is open, conditional, unknown, assessed_unreachable, or exactly_unreachable; recovery_status is none_identified, candidate, supported, or verified; and path_effect is opens, preserves, narrows, conditions, forecloses, reopens, or unknown.
They connect possible results to decisions, show what the action itself consumes, make predicted effects and reversal conditions explicit, and preserve a separate record of what happened.
They do not prove that a route is impossible, authorize anyone to act, or replace safety, quality, regulatory, test-planning, design, or change-control requirements.
We do not yet know whether these worksheets improve decisions in other teams. That is why feedback about wasted effort, missed questions, and added paperwork matters.
What changed? What was confusing? How long did it take? Positive and negative results are equally useful.