THE PRODUCTION PATH
Give the next AI update something real to show.
Before the project begins, we define a prioritized workflow, the exact day-90 target, and the client decisions required to achieve it. We then lead delivery, validation, governance, adoption, and transfer to reach that goal.
90-day delivery plan · Fixed proposal after scoping
Starting fees are in USD and apply to the agreed assessment scope. Final scope and fees are confirmed before kickoff. Additional business units, systems, jurisdictions, and implementation work are scoped separately. Fees exclude applicable taxes.
The prototype works. The organization still cannot run it.
- Production Data
- Integration
- Ownership
- Security
- Governance
- Human Review
- User Adoption
- Operational Support
The remaining blockers often involve production data, integration, ownership, security, governance, human review, user adoption, and operational support. Expanding the backlog does not resolve these issues. Focusing on a single workflow and a defined finish line does.
Day 90 is defined before Day 1.
Before the engagement begins, the proposal specifies a single Day-90 outcome: either a controlled release to a designated user group, deployment in a defined environment, or a production-ready handover pending approval from a named client. It also documents the owner, acceptance criteria, and any dependencies related to client-controlled access, approval, or procurement.
Client receives
Working system
- The working system at the written day-90 state;
Validation and control
- Architecture and control record;
- Validation and acceptance evidence;
Adoption and value
- Adoption/training plan;
- Value-measurement baseline and cadence;
Ownership and handover
- Operating and ownership model;
- Technical and operational handover;
- Executive evidence pack.
Rhythm
- Days 1–30
Lock the outcome, architecture, controls, backlog, owners, and go/adjust decision.
- Days 31–60
Build and validate the working workflow; review evidence weekly.
- Days 61–90
Harden, release to the agreed state, establish adoption/value tracking, and transfer ownership.
Delivery gates
Four decision points keep the engagement controlled from kickoff through handover. The Day 5 review is the second gate. Later approvals occur when their required evidence is ready, not on a universal calendar date. Completion and commercial terms are defined in the proposal.
- Before counted delivery begins
Access-ready kickoff
Confirm the sponsor, decision owner, scope, agreed inputs, legal and access authorization, stakeholder availability, and acceptance criteria. Record any missing prerequisites before counted delivery begins.
- Fifth project business day after the agreed kickoff
Scope and feasibility gate
Confirm or adjust the boundary, accessible evidence, main constraint, feasible outcome, and remaining risks. Record the decision to proceed, rescope, pause, or stop.
- During delivery, when the required evidence is ready
Service-specific approval gates
Apply any technical, security, regulatory, business acceptance, or release approvals required by the agreed scope. Each approval occurs when its required evidence is ready, not on a universal date.
- At the end of the scoped engagement
Completion and continuation gate
Accept the contracted outcome, record remaining decisions and risks, and decide whether to close, operate, extend, remediate, launch, or scale through a separately agreed next scope.
After release, who owns what
The proposal confirms the exact stabilization window and any ongoing operating support before work begins.
| Responsibility | Coverage | Accountable owner | Boundary |
|---|---|---|---|
| Deployment approval | Client decision | Client | The client authorizes release into its environment. |
| Acceptance | Acceptance evidence and review included | Client | Limitls provides evidence against the acceptance criteria. The client accepts or rejects the outcome. |
| Stabilization | Included for the window stated in the proposal | Limitls during that window; client afterward | Applies to the agreed released scope. |
| In-scope defect correction | Included for the same window | Limitls during that window; client afterward | Covers reproducible defects against the agreed scope and acceptance criteria, not enhancements. |
| Monitoring setup and handover | Included when stated in the agreed scope | Limitls until handover; client afterward | Limitls configures and documents the agreed monitoring, then transfers operation. |
| Access and asset handover | Included | Limitls transfers; client accepts and controls | Covers the agreed accounts, repositories, environments, and documentation. |
| Ongoing monitoring and incident response | Available under a separately agreed operating-support scope | Client unless otherwise agreed | Coverage, hours, escalation, and response targets are defined in that agreement. |
| Model, vendor, and platform changes | Change-controlled or separately scoped | Client after handover; the relevant vendor remains responsible for its service | Changes that require Limitls work follow change control or a new scope. |
| Ongoing enhancements | Change-controlled or separately scoped | Client product owner after acceptance; Limitls only if commissioned | New capabilities beyond the acceptance criteria are new scope. |
- Deployment approval
- CoverageClient decisionAccountable ownerClientBoundaryThe client authorizes release into its environment.
- Acceptance
- CoverageAcceptance evidence and review includedAccountable ownerClientBoundaryLimitls provides evidence against the acceptance criteria. The client accepts or rejects the outcome.
- Stabilization
- CoverageIncluded for the window stated in the proposalAccountable ownerLimitls during that window; client afterwardBoundaryApplies to the agreed released scope.
- In-scope defect correction
- CoverageIncluded for the same windowAccountable ownerLimitls during that window; client afterwardBoundaryCovers reproducible defects against the agreed scope and acceptance criteria, not enhancements.
- Monitoring setup and handover
- CoverageIncluded when stated in the agreed scopeAccountable ownerLimitls until handover; client afterwardBoundaryLimitls configures and documents the agreed monitoring, then transfers operation.
- Access and asset handover
- CoverageIncludedAccountable ownerLimitls transfers; client accepts and controlsBoundaryCovers the agreed accounts, repositories, environments, and documentation.
- Ongoing monitoring and incident response
- CoverageAvailable under a separately agreed operating-support scopeAccountable ownerClient unless otherwise agreedBoundaryCoverage, hours, escalation, and response targets are defined in that agreement.
- Model, vendor, and platform changes
- CoverageChange-controlled or separately scopedAccountable ownerClient after handover; the relevant vendor remains responsible for its serviceBoundaryChanges that require Limitls work follow change control or a new scope.
- Ongoing enhancements
- CoverageChange-controlled or separately scopedAccountable ownerClient product owner after acceptance; Limitls only if commissionedBoundaryNew capabilities beyond the acceptance criteria are new scope.
Fit
Best fit
Organizations that have already prioritized one material AI workflow and can define its exact day-90 state before delivery begins. It is particularly suited to a working prototype or approved use case that still needs coordinated product delivery, integration, governance, validation, adoption, and handover to reach an agreed operational state.
Not a fit
This Sprint does not begin with an unprioritized idea, an unresolved portfolio, or an undefined production promise. If the workflow, sponsor, or finish line is not ready, begin with AI Execution Readiness. It is also not a commitment to place any system into unrestricted production regardless of client-controlled access, approvals, procurement, security, or governance dependencies.
The entry scope assumes
One prioritized workflow, one written day-90 state, explicitly included environments and integrations, an agreed division of client-supplied and Limitls-supplied capacity, defined acceptance and control requirements, and dated client decisions and access. The fixed proposal is built on a tightly bounded workflow supported by substantial client capacity, targeted Limitls or specialist capacity, existing components that materially reduce engineering effort, or an exceptionally bounded integration path. More connected, regulated, or resource-intensive work is scoped and priced accordingly.
Client responsibilities
The client names the sponsor and operating owners; provides the agreed documents, data, environments, integrations, test accounts, and client-supplied delivery capacity; completes required security, governance, procurement, and release approvals; participates in validation and acceptance; and supports adoption and ownership transfer. The proposal states how delays in client-controlled access or decisions affect the schedule and day-90 state.
Exclusions
Only the workflows, environments, integrations, acceptance criteria, and delivery capacity written into the proposal are included. A new system, workflow, environment, integration, deadline, or acceptance criterion is handled through documented change control. Optional or out-of-scope travel, software, infrastructure, cloud consumption, or third-party costs are disclosed separately.