A disciplined path from observed work to a justified system.
We begin with the work as it currently exists. We study the workflow, define the claim being tested, declare the evidence required for a decision and preserve the reasoning behind every outcome.
The method is designed to reduce uncertainty before major engineering begins. It does not assume that every opportunity should continue or that software is always the correct response.
The requested feature is not automatically the real problem.
People often describe an operational failure through the software they imagine should exist. That suggestion can be useful, but it does not prove that the proposed feature addresses the cause of the failure.
We separate the observed work from the suggested implementation. The workflow, participants, incentives, records, exceptions and consequences must be understood before engineering becomes the main investment.
Research is not a delay placed in front of building. It is the work required to determine what deserves to be built.
Choose a feature, build it and then search for evidence that the decision was correct.
Observe the work, define what must change, test the proposed workflow and then decide whether engineering is justified.
Twelve stages organised around three decisions.
The method is structured enough to preserve evidence and flexible enough to match the claim being tested. A simple claim may require a short investigation. A difficult system opportunity may require several cycles of observation, revision and testing.
Stages 01–04
Stages 05–08
Stages 09–12
Build a dependable record of the current operation.
The investigation begins by establishing what is happening, who is involved and whether the opportunity is accessible enough to study.
Capture the opportunity as a problem, not a feature brief.
Record what appears to be failing, who is affected, why the issue matters and what solution has already been suggested—without treating that suggestion as the conclusion.
OPPORTUNITY RECORD
Determine whether the real work can be examined.
Confirm that the relevant workflow, participants, records and decision owners are accessible enough to support a credible investigation.
ACCESS ASSESSMENT
Study how the work currently happens.
Identify the sequence, participants, ownership, records, handoffs, dependencies, exceptions and recurring failure points within the existing workflow.
WORKFLOW RECORD
Separate symptoms from the operational problem.
Describe the repeated failure, its consequences and the conditions under which it occurs. Avoid defining the problem as the absence of a specific feature.
PROBLEM DEFINITION
Turn the proposed change into a claim that can be examined.
The investigation moves from understanding the current workflow to defining what is expected to change and what evidence would justify the next decision.
State what change is expected and for whom.
Define the proposed workflow change, the people expected to benefit and the observable result that would support further investment.
TESTABLE CLAIM
Declare the decision boundaries before results are known.
Record what evidence would support continuation, require revision, justify rejection or show that the investigation should close.
DECISION CRITERIA
Choose the smallest credible way to examine the claim.
Select a test that can produce useful evidence without prematurely committing to full engineering. The test may use structured documents, simple tools, manual operation or a focused prototype.
TEST PLAN
Run the proposed workflow under defined conditions.
Assign roles, preserve the operating record, observe participant behaviour and capture exceptions while the test is active.
TEST RECORD
Determine what the evidence actually supports.
The final phase separates the result of the claim from the validity of the process used to test it.
Preserve behaviour, outcomes and exceptions.
Record what participants did, what changed, what failed, what required manual compensation and what evidence remains incomplete.
EVIDENCE RECORD
Check whether the process can justify a conclusion.
Confirm whether the declared method was followed, whether the evidence is traceable and whether changes or exceptions weakened the test.
PROCESS REVIEW
Continue, revise, reject or close.
Compare the evidence with the declared criteria and preserve the reasoning behind the outcome. A rejected claim may still result from a valid investigation.
DECISION RECORD
Define what must exist if further investment is justified.
Identify the workflow rules, ownership, records, statuses, exceptions, automation and software required to support the validated operation.
SYSTEM BOUNDARY
A useful investigation does not require a positive result.
The purpose of the method is to improve the next decision. Continuation is one valid outcome, but it is not the only useful one.
The evidence supports another stage of investigation, implementation or investment.
The underlying problem may remain valid, but the claim, workflow, criteria or test must change.
The tested claim is not sufficiently supported under the declared conditions.
The opportunity no longer justifies active work under the current conditions.
The outcome of a claim and the validity of the process are different questions.
A favourable-looking result does not create dependable evidence when the method was invalid or the record is incomplete. A rejected claim may still result from a valid and useful investigation.
The declared method was followed and the available evidence supports the claim under the stated conditions.
The declared method was followed, but the evidence does not sufficiently support the claim.
The result may appear favourable, but the process cannot justify a dependable conclusion.
The available record is insufficient to support acceptance or rejection.
Software is one part of the system.
A practical system is the complete operating relationship required to make the validated workflow dependable.
- The sequence, conditions and actions that define how the work should proceed.
- The people or roles responsible for each stage, decision and exception.
- The states that show where work is, what has happened and what must happen next.
- The evidence, decisions and changes that must remain traceable.
- The conditions that fall outside the expected path and how they should be handled.
- The repeatable actions required to maintain the system.
- The tasks that can be performed reliably without unnecessary manual effort.
- The technical layer that strengthens the validated workflow where engineering is justified.
Engineering should strengthen these relationships rather than hide their absence.
Every investigation should leave a usable record.
We preserve more than the final decision. The record should make it possible to understand what was observed, what changed, what was tested and why the work continued—or stopped.
- OPPORTUNITY RECORD
- ACCESS ASSESSMENT
- WORKFLOW RECORD
- PROBLEM DEFINITION
- TESTABLE CLAIM
- DECISION CRITERIA
- TEST PLAN
- TEST RECORD
- EVIDENCE RECORD
- PROCESS REVIEW
- DECISION RECORD
- SYSTEM BOUNDARY
Rejected, revised, closed and unresolved work should remain connected to the evidence that produced the outcome.
The record protects us from repeating unsupported assumptions without context.
Bring the work, the access and the difficult question.
We can begin without a finished product specification. A credible starting point is a meaningful operational problem, access to the workflow and a willingness to let the evidence determine what happens next.