Production Readiness Diagnostic
A focused review of one blocked customer workflow. It maps the evidence and decisions needed for a practical next step; it is not a guarantee or certification.
What it is
Make one blocked workflow explicit
Turn a blocked deployment into an explicit workflow map, evidence-ranked risk picture, and recommended next step.
A convincing prototype can still leave the workflow owner, system boundary, evidence, and rollout decision unclear. The diagnostic turns those unknowns into a shared production-readiness view.
Production readiness applies only to the agreed workflow and constraints. The result can support a decision to continue, narrow, redesign, or stop.
What you receive
A Production Readiness Brief and readout
- Target workflow and success criteria
- Annotated system and integration map
- Evidence-ranked blockers and risks
- Prioritized next-step recommendation
When relevant to the workflow, the brief also addresses evaluation, monitoring, failure handling, and rollback.
What I need from you
People, evidence, and safe access
- One named workflow and desired outcome
- Stakeholders who can explain the workflow and make decisions
- Named, least-privilege, customer-managed access where needed
- Representative inputs, failure cases, constraints, and deadlines
- Customer approval of AI providers and permitted data
Access is named, least-privilege, and customer-managed; shared personal credentials are never used.
Example brief: AI support reply drafts
Condensed excerpt. The workflow, evidence and findings below are fictional. This shows how a brief supports a decision; an actual brief reflects the agreed workflow and reviewed evidence.
Recommendation: narrow the proposed pilot
Limit the proposed pilot to drafts that a support agent reviews and explicitly approves. Before any sending through that path, check missing-policy handling and approval of the exact draft being sent. Keep sending without agent approval outside the pilot.
Workflow and success criteria
A support agent needs a draft based on the customer's current refund policy. The path is ticket intake, account-specific policy lookup, model draft, agent review, then the send queue.
A missing policy must flag the draft for review without inventing a refund deadline. Sending must require approval of the exact draft being sent.
Evidence-ranked blockers
Both findings below block the proposed sending path. They are ordered by where they occur: draft creation, then approval and sending.
- First: missing policy still produces a confident answer. In fictional trace E1, policy lookup times out and the draft states a refund deadline without a source. The backend owner needs to define and check the missing-policy path before it reaches the review screen.
- Second: approval can outlive an edit. In fictional trace E2, the draft changes after approval, but the send queue accepts the old approval. The application owner needs to bind approval to the draft version.
- Open question: what happens after a sending timeout? No retry evidence is available in this example. Duplicate-message risk is untested, not an observed failure.
Next action and decision owner
The workflow owner and engineering lead should agree on expected results for missing policy, an edit after approval, and a sending timeout. Use those cases to scope the fixes and the evidence needed for a limited pilot.
Model quality, permissions, cost and response time still need evidence for that pilot. This excerpt does not establish release readiness. The diagnostic recommends the work; implementation is scoped separately.
The boundary
What it does not include
This is a bounded decision-making engagement, not an open-ended audit or implementation project.
The proposal names the user-to-outcome path, systems, stakeholders, and operating constraints that form the workflow boundary.
How it works
From fit check to next decision
The work stays focused on the evidence needed to decide what should happen next.
- Confirm the workflow and fit
We agree on the user, desired outcome, systems, stakeholders, and constraints.
- Review the evidence
I examine representative inputs, failure cases, integrations, and named access where needed.
- Map the blockers
I document the system boundary and rank the assumptions, risks, and unknowns by evidence.
- Read out the brief
We review the findings and the prioritized recommendation together.
- Choose the next step
Any implementation, remediation, or follow-on engagement is scoped separately.
Price and boundary
Start with the standard scope
The starting price covers the standard scope above. Expanded workflow, access, or evidence requirements are priced in the written proposal.
Normal studio tooling is included unless agreed otherwise.
Customer-specific licenses, production usage, cloud costs, and travel are stated in the proposal.
Any revision cycle is stated in the proposal; the public offer makes no revision promise.
Starting prices exclude VAT and are set independently in each currency, not converted live. Applicable taxes are confirmed in the proposal.
Good fit
A useful first step when
- One customer workflow has a concrete deployment blockage.
- An owner can make scope and next-step decisions.
- The relevant stakeholders and representative evidence are available.
- The team needs a bounded production-readiness view before implementation.
Before work starts
Qualify, agree, then begin
The website is a commercial summary. The written proposal and contract confirm the binding scope, timing, price, taxes, expenses, and terms.
- Send a short email
Describe the desired workflow, current blockage, constraints, and decision-makers.
- Check the fit
We use a short call if it helps confirm the smallest useful scope.
- Review the documents
Paid work follows a written proposal and contract, then an invoice.
Discuss the diagnostic
A short email about the workflow, blockage, constraints, and decision-makers is enough to start.