The Process

The 3×3 Diagnostic is a systems analysis process that makes delivery risk visible, ownership explicit, and produces decision-grade release signal.

It is delivered in three stages. Each stage is fixed in scope and time-boxed. You do not have to proceed beyond any stage.

Inside the 3×3 Diagnostic

1. Baseline

Fixed scope. Time-boxed. Journey-led. This stage establishes reality and sets a baseline for what “good” looks like today.

We identify high-risk journeys, expose assumptions, and make ownership explicit. The aim is clarity: “this works today” versus “we assume it does”.

No automation obligation.

2. Systemic Analysis

Boundary-led. Seam-focused. System-level. This is the stage previously formalised as the 3×4 approach.

We trace failure paths through boundaries and seams, identify where signal is lost, and surface whether automation is economically viable.

This stage produces the decision: what must change, what can be governed, and what should be accepted or deferred.

3. Automation (optional)

Optional. Targeted. High-signal only. This is not a test suite expansion programme.

If you choose to proceed, we implement only what creates trustworthy signal for the specific risks identified. No theatre, no vanity coverage, no noisy duplication.

It is valid to stop after Stage 2.

What you leave with at each stage

After Stage 1: Baseline

Three high-consequence journeys selected for risk, not convenience
Intent, assumptions, and ownership made explicit for each journey
Where silent failure is currently possible, and how you would know
A clear statement of what “good” looks like for those journeys today

After Stage 2: Systemic Analysis

A boundary and seam map for the journeys, showing where signal is lost
Failure paths traced, including detection gaps and hidden dependencies
A view on economic testability: what is viable, what is not, and why
The decision surfaced: what to fix, accept, or defer, with named owners

After Stage 3: Automation (optional)

A small set of high-signal checks or observations aligned to the identified risks
Automation only where it produces trustworthy signal, across UI, API, or both
Noise reduction: remove duplication and flake that distort confidence
A maintainable structure your team can extend without degrading signal

Where BDD fits

We use a light-touch BDD style to keep intent explicit and to prevent automation becoming ambiguous. Each scenario is extended with:

And if this fails, the upshot is ___
And the owner is ___

That ensures failures map to consequence, and ownership stays unambiguous.

If you already have automation, we do not replace it. We classify what is genuine release signal, reduce noise, and protect what matters. If automation is not economically viable, we make that visible and explain what would have to change for trustworthy signal to exist.