Bounded Implementation

Implement the smallest system that can pass the agreed test.

Implementation follows an Assessment decision. Scope, controls, acceptance and handover are written before delivery expands.
Implementation boundarychange-controlled
Starts with
Approved decision record
Release
Named human owner
Acceptance
Evidence before release
Change
Material scope returns to decision
What this cannot conclude
That adjacent workflows, unsupported data or future conditions are included.

Delivery record

The build is governed by the same fields used to approve it.

This keeps ambition, implementation and acceptance tied to one inspectable boundary.
Build record / scopelocked at start
In
Named workflow, users, sources, actions and environment.
Out
Adjacent workflows, unsupported data and unapproved providers.
Change rule
Re-estimate, re-assess or refuse material expansion.
What this cannot conclude
That the scope will expand without a new written decision.
Build record / controlrelease-owned
Human decision
Named points that automation cannot cross.
Failure
Unsupported or ambiguous states route visibly.
Acceptance
Named owner signs against the evidence.
What this cannot conclude
That an automated output authorises a consequential release.

What is delivered

A working capability and the means to own it.

Implementation is complete only when the accepted system and its operating knowledge can be transferred together.

System

The bounded workflow capability in the agreed environment.

Evidence

Acceptance results, unresolved issues and known operating limits.

Control

Human review, access, failure and escalation routes.

Handover

Access transfer, runbook, walkthrough and explicit support boundary.

Acceptance

Useful in the tested workflow is not the same as universally reliable.

Acceptance is scoped to agreed data, environment, users and conditions. That boundary remains visible after delivery.
Acceptance recordworkflow-specific
Test set
Representative cases approved for the workflow.
Behaviour
Expected output, refusal and escalation states.
Owner
Named person authorised to accept release.
Comparison
Observed result compared with the agreed baseline.
What this cannot conclude
Performance outside the tested boundary, a guarantee of future outcomes or regulatory conformity.

Handover

The route out is designed before release.

Client-controlled accounts are preferred where practical. Access, dependencies, documentation, unresolved issues and any separately scoped support are made explicit.
Access

Account ownership, credentials and provider relationships are transferred or documented.

Runbook

Operating steps, review points, limits, escalation and recovery are written for the named owners.

Evidence

The baseline, acceptance result and known gaps remain with the operating record.

Support

Post-handover support exists only when separately written and agreed.

Implementation begins only after a defensible build decision.

Discuss one workflow