Deliver

We commit to a first production release by week twelve of the build phase. That date is set in the fixed-price proposal from Perceive, not renegotiated every month. Deliver is the final segment of that build: typically weeks eleven and twelve, sometimes overlapping late Engineer work — hardening, operational readiness, cutover, hypercare. The definition of done is explicit in the contract: named integrations live, named user groups onboarded, observability in place, documentation delivered.

Production, not pilot

A pilot proves a idea to a small group with forgiving SLAs. Production serves the audience discovery scoped, under the same expectations as any business system. That distinction matters for architecture choices, support model, and governance. We do not call something production if it runs on someone's laptop, lacks audit logging, or falls over when more than ten people use it.

Production also means ownership clarity. Who approves model or prompt changes? Who responds to incidents? Who pays inference costs? These questions are answered before cutover, captured in the runbook, and agreed with your sponsor. Ambiguity here is how AI systems become orphans.

The deliverables checklist

1. Production deployment in the agreed environment with residency controls verified.
2. Monitoring dashboards: latency, error rates, cost, evaluation scores, guardrail triggers.
3. Alerting and incident runbook with escalation paths.
4. User documentation and training sessions for operators and end users.
5. Technical documentation: architecture, data flows, integration contracts, model and prompt versions.
6. Security sign-off recorded where your process requires it.
7. Hypercare period with defined coverage hours after go-live.

Hypercare is typically two to four weeks depending on complexity. During hypercare we staff for faster response, daily check-ins on evaluation metrics, and minor fixes that do not change contracted scope. Structural changes go through change control.

Cutover planning

Cutover is planned, not improvised. We define rollback criteria before launch. Data migrations, if any, are rehearsed. Feature flags or phased rollout by user group reduce blast radius. For agents that act in workflows, we often start with human approval on every action, then relax as confidence and logging prove out — always within what governance allows.

Training and adoption

Software that nobody uses is failed delivery. Training is role-based: end users learn the task flow; operators learn monitoring and escalation; administrators learn configuration within agreed boundaries. We capture the top ten failure modes users encounter in the first week and address them in office hours or quick-reference guides.

The runbook

The runbook is written for the team that will operate the system — yours or ours under Run. It covers normal operation, common incidents, model upgrade procedure, cost review cadence, and evaluation regression workflow. It references where logs live, who has access, and which changes require change advisory board approval in your organisation.

Fixed scope in practice

Fixed scope does not mean fixed quality. It means the boundary of the first release was agreed in Perceive and priced honestly. If production readiness reveals a gap that was in scope, we close it. If new requests appear, we document them for a subsequent increment rather than slipping the week-twelve date silently. Clients choose us because the date means something.

Week twelve is the first production release, not the end of the roadmap. Discovery often surfaces a portfolio; Deliver completes the first item. Subsequent increments can follow the same Perceive-light scoping or extend directly into Engineer under a new fixed price.

Acceptance before cutover

Production promotion requires signed acceptance against criteria defined in the proposal: evaluation scores on agreed sets, successful completion of integration test scenarios, security findings closed or accepted by your security team, training delivered, runbook reviewed. We do not declare victory because the demo looked good in staging. Your product owner signs; their signature means something because the evidence was visible throughout the build.

Load and resilience testing runs where the use case demands it — peak contact volume, batch document windows, concurrent plant-floor queries — with results shared in steering before go-live date is confirmed.

Transition to Run

At handover you choose: operate in-house with the runbook we delivered, or engage us for Run — managed evaluation, cost control, agent supervision, model upgrades, quarterly roadmap reviews. Everything we built is yours: code, infrastructure definitions, evaluation sets, documentation. No lock-in, no hostage data.