Stage 3 / Production workflow engineering
A Production System hardens the workflow behavior supported by prior evidence. It defines how the system is accessed, monitored, changed, stopped, recovered and owned in operation. Every engagement is custom-scoped.
The buyer problem
A successful pilot still leaves production questions. Identities and permissions may change. Tools fail. Queues back up. Model or input distributions drift. Reviewers need a practical interface and support needs an escalation route. Production work addresses these operating responsibilities rather than assuming the pilot can simply be switched on.
Production readiness
Production scoping requires evidence that the bounded workflow meets its pilot acceptance criteria and has a defensible business reason to operate. The workflow, system and approval owners must be named. Required integrations, data constraints, support responsibility, monitoring expectations, recovery needs and acceptable change process must be clear enough to estimate.
A pilot that does not meet those conditions should be changed, extended or stopped rather than presented as production-ready.
Custom scope
Production work may include:
The proposal identifies what is included, excluded, client-owned and dependent on third parties.
Production engineering
Reliability is made specific. For the agreed workflow, the production design defines valid states, timeouts, duplicate-action protection, queue behavior, service dependencies, stop conditions and recovery objectives. The required level depends on consequence and operating volume; high availability is not assumed.
Monitoring should answer whether the workflow is available, advancing through valid states and producing reviewable results. Logs and alerts cover relevant failures and authority changes. Operational evaluation tracks the agreed quality and review measures on a defined cadence. A model response alone is not proof that the workflow completed correctly.
Access follows the minimum authority required for the scoped action. Authentication, roles, tool credentials and approval rights are defined with the client’s existing security and operational requirements. State Method does not present production engineering as a security audit or compliance certification.
The production scope defines who receives an alert, what can retry, how duplicates are prevented, when work stops, how a case moves to manual handling and how service resumes. Recovery procedures are documented and tested to the level agreed for the workflow.
Operational ownership
Before handover, name:
Controlled operation
Changes to models, prompts, tools, permissions, business rules or acceptance thresholds can alter workflow behavior. The production design identifies which changes require review, evaluation, approval and a recovery option. Evidence from one frozen version should not be silently applied to another.
Deliverables may include production code and configuration within the agreed boundary, deployment support, operating documentation, runbooks, evaluation procedures, recovery instructions and an ownership handover. Exact repositories, licenses, infrastructure accounts, support period and acceptance terms belong in the commercial scope.
Qualification boundary
Commercial scoping
Production scope follows an evidence and readiness review. The proposal defines the proven boundary, deliverables, dependencies, client responsibilities, environments, acceptance criteria and handover. No standard duration or price is claimed on this page.
FAQ
Only after a readiness review. Pilot code and evidence may be reusable, but production access, reliability, monitoring, recovery and ownership must be scoped.
Not by default. Availability, recovery and support requirements depend on workflow consequence and volume and must be stated in the proposal.
The commercial scope names the monitoring and support owner. This may be the client or a separately agreed responsibility; it should never remain implicit.
Only if evidence, consequence and authority support a reviewed design change. Time in operation alone does not justify removing approval.
The operating plan should define alert thresholds and a response: narrow authority, route work to review, roll back a change, fall back to manual handling or stop.
Continue with the evidence
Production readiness / evidence review
Bring the pilot evidence, current architecture, operating owners and required production boundary. Do not send confidential architecture through the public form.