Fixed-scope decision engagement

Decide whether one workflow is worth building.

The State Method Diagnostic tests one AI-assisted workflow before implementation expands. It maps the operating boundary, examines representative cases, defines permissions and failure routes, and records what the evidence supports. It is not a small production implementation.

Fee: €4,000 excluding VAT
Elapsed duration: 10 business days
Delivery effort: Approximately five delivery days
Scope: One controlled workflow
Core output: Five decision artifacts and a go/no-go recommendation
Continuation: No obligation to commission a pilot

The buyer problem

Turn an untested assumption into a bounded decision.

You have a repetitive process and a plausible AI-assisted step, but the decision to build is still based on a demo, a small sample or an untested assumption. The current baseline may be incomplete. Edge cases, tool permissions, review effort and failure handling are unclear. The Diagnostic turns those unknowns into a bounded decision.

Inputs required

Bring representative, authorized operating evidence.

Depending on the workflow, State Method may request:

Up to three stakeholder interviews
Up to three data or document categories
Approximately 5–10 representative sanitized examples
Existing process documentation
Current workflow volume
Current time, cost or error baseline
Known exceptions and difficult cases
Relevant security and privacy constraints

Share sanitized, authorized material through an agreed delivery channel. Do not send source documents through the public assessment form.

Diagnostic work

Inspect the full path from input to reviewed outcome.

State Method identifies the workflow owner and maps the current path from input to reviewed outcome. Inputs, outputs, systems, exceptions and consequential actions are bounded. Representative cases are inspected against the manual baseline. Uncertainty and known failure modes are recorded. Model tasks are separated from deterministic checks, permissions and approval. Logging, stop and recovery requirements are defined. The final evidence is used to make a go/no-go recommendation and, when justified, outline a Controlled Pilot.

Five decision artifacts

The output is evidence for a decision.

01 / Bounded workflow map

The start and end state, owner, inputs, outputs, systems, exceptions and action boundary.

02 / Evaluation summary

Representative cases, observed behavior, uncertainty, edge cases, baseline comparison and evidence gaps.

03 / Permission matrix

What the model may propose, what software may enforce or execute and what a named person must approve.

04 / Observable failure register

Failure modes, detection signals, stop conditions, escalation, retries, fallback and recovery route.

05 / Go/no-go recommendation

Proceed, change the design, gather evidence, remain manual or stop, with the reasons and unresolved assumptions.

Optional when justified: Controlled Pilot specification.

Illustrative sample / specification compliance review

A Diagnostic excerpt can decide to change before it decides to build.

This worked excerpt shows the shape of a specification-review diagnostic: the bounded map, the planned evaluation and its evidence gaps, the permission matrix, the failure register and the resulting recommendation. The requirement and product data are synthetic.

01
Bounded workflow map
Trigger
A product submittal is received against an approved specification section.
Owner
Technical Manager, the named approver.
Inputs
Approved specification section, product data sheet and certificates.
Output
A compliance matrix row with a cited status per requirement.
Systems
Document store for reading; compliance register for a proposed update.
Consequential action
Registering a compliance status, which requires approval.
Out of scope
Professional, regulatory or design sign-off.
02
Evaluation design and evidence gaps
Representative
A submittal with matching product references and a complete certificate set.
Ambiguous
A regional performance classification that does not map cleanly to the specified class.
Known-bad
The wrong project revision, a missing certificate, or submitted text that contains instructions.
Permission and recovery
Approval refused, an unavailable document service, or a duplicate submittal.
Evidence gaps
- The current approved specification revision is not confirmed.
- Certificate completeness cannot be established from the excerpt alone.
- No agreed rule exists for an unclear classification mapping.
This is a planned evaluation design. It records no case count, pass rate or run result.

Permission matrix

What the model may propose, what software enforces and what a person must approve for the specification-review excerpt.
Authority	Permission	Scope	Status
Model	Extract requirement candidates and map product claims	Prepare a bounded proposal with cited evidence.	Allowed, proposal only
Software	Check specification version, certificate presence and identifier match	Enforce deterministic rules and required citations.	Allowed, enforced
Model	Determine the final compliance disposition	Status is a human judgment, not a model decision.	Not permitted
Human	Determine and approve each compliance status	The Technical Manager owns the disposition and any request for further evidence.	Required

04
Observable failure register
Approved specification version unavailable
Version check fails
Stop the row, route to document control and issue no status.
Mandatory certificate missing
Certificate check fails
Block the row and request the certificate.
Product identifier mismatch
Identifier comparison disagrees
Hold the row as an exception for the reviewer.
Conflicting requirement evidence
Sources disagree
Abstain, preserve both sources and route to the Technical Manager.
Submitted text contains instructions
Untrusted content detected
Treat content as data, give it no tool access and log the denial.
05
Change the design and gather evidence
Recommendation
Change the design, then gather evidence
The control shape is workable, but the evidence needed to justify a pilot is not present yet.
Reasons
- The approved specification revision is not confirmed.
- Certificate completeness is unknown for the sampled submittals.
- The classification mapping between product and specified class has no agreed rule.
Next step / Confirm the approved revision, assemble the certificate set and agree the mapping rule, then reassess the workflow.
This excerpt does not recommend a Controlled Pilot and does not authorise a production build.

Example timeline

Ten business days from boundary to review.

Business days 1–2: Bound

Kickoff, stakeholder input, workflow map, baseline and evidence review.

Business days 3–5: Evaluate

Representative cases, exceptions, uncertainty, failure modes and comparison criteria.

Business days 6–7: Control and Recover

Permissions, approvals, deterministic checks, logging, stops and recovery.

Business days 8–9: Decide

Synthesize the five artifacts and draft the recommendation.

Business day 10: Review

Walk through the evidence, recommendation and possible next steps.

Timing depends on timely access to agreed stakeholders and sanitized inputs. The fee and elapsed duration cover the stated one-workflow boundary.

Qualification boundary

Good fit and explicit exclusions.

Good fit

One process with a clear start, end and owner
A repetitive manual or partly automated step
Representative examples that can be sanitized
A baseline for time, cost, volume or errors, or a practical way to establish one
Outputs that can be reviewed
A real choice about whether to invest in a pilot

The Diagnostic does not include

Production deployment
Open-ended AI strategy
Custom model training at scale
Large-scale data labeling
A security audit
Legal advice
Professional or regulatory sign-off
Unrestricted production access
Autonomous consequential actions
Guaranteed ROI or accuracy

After delivery

Proceed, change, gather evidence, remain manual or stop.

The Diagnostic closes with one of five recommendations: proceed to a separately scoped Controlled Pilot, change the proposed workflow, gather better evidence, keep the current manual process or stop. The client may use the artifacts internally and is not required to continue with State Method. If prior evidence already resolves some questions, a later-stage engagement can be considered after review.

FAQ

Before the next decision.

Does the Diagnostic include implementation?

No. It is a decision engagement. It may include limited technical evaluation needed to support the decision, but it does not include a deployed production workflow.

What counts as one workflow?

One workflow has a clear trigger, owner, inputs, output, review path and end state that can share one set of acceptance criteria. Separate owners, outcomes or authority boundaries usually indicate separate workflows.

Do the examples need to be clean?

No. Representative messy cases can be useful. They must be authorized, safely shareable and sufficient to identify what should be tested. The Diagnostic is not a large-scale data-cleaning engagement.

What if the recommendation is no-go?

The reasons and evidence are recorded. The right result may be to narrow the scope, improve the inputs, retain manual work or avoid spending on a pilot.

Is the Diagnostic mandatory before a pilot?

Not always. State Method can review existing evaluation, ownership and control evidence. If it is sufficient, pilot scoping may start later in the path.

Is this an AI readiness assessment?

For one workflow, yes. The Diagnostic decides whether a specific AI-assisted workflow is ready to justify a bounded pilot, using your own operating evidence. It is not a company-wide AI maturity scorecard, an open-ended technology strategy or a production readiness sign-off, and it does not guarantee that a pilot will succeed.

Continue with the evidence

Review the next relevant boundary.

Workflow assessment / first step

Test the decision before funding the build.

Share one workflow, its current baseline and who reviews the output. Business context only.

Assess one workflow