Order to delivery: complete the promise, not just the task list

A signed scope is not a delivered project. The founder still has to check access, schedule the work, notice missing dependencies, review the output and obtain acceptance. This loop is designed to coordinate those steps and preserve the evidence that the customer received what was promised.

The current prototype models work orders, jobs, dispatches, proof of delivery and service-level states. It can walk a seeded local order through its lifecycle. For a software studio, I would adapt the domain terms: a dispatch becomes an assigned delivery activity, and proof of delivery becomes an accepted release or handover record.

Four records answer four different questions

Combining these into one status field creates ambiguity. A job can be complete while the customer has not accepted the work. A release can be deployed while the agreed handover is missing. An agent should be able to explain those distinctions in ordinary language.

The local lifecycle includes validation, scheduling, dispatch, work, quality review, evidence capture and closure. Its state constraints prevent jumping straight from a draft work order to a closed one.

Run the local demonstration

This example uses the existing pipeline and its fixtures:

from o2d.pipeline import build_o2d_pipeline

pipeline, dispatcher = build_o2d_pipeline()
seed = pipeline.seed("studio-demo")
result = pipeline.deliver(seed, tenant_id="studio-demo")

assert result.allowed
assert "o2d.work_order.delivered" in result.emitted

deliver drives pre-seeded objects through the transitions. It does not perform software development, dispatch a technician or obtain a real customer's signature. Its value is making the order of required records and decisions executable.

What the agent should do for a software pilot

At intake, it can compare the accepted scope with prerequisites: document access, evaluation questions, deployment environment and an owner for acceptance. If credentials are missing, the useful output is a blocked task with the specific dependency and responsible person.

During delivery, it can summarise progress from the project tracker and repository, prepare a handover checklist and surface discrepancies. It can identify that an agreed language is absent from the evaluation set. It should not interpret a developer's “looks fine” message as customer acceptance.

A proposed handover record might look like this:

work_order: pilot-017
release: release-3
checks:
  - agreed evaluation set reviewed
  - deployment guide delivered
  - customer access confirmed
acceptance:
  state: awaiting_customer
  source_ref: null
billing_ready: false

The code and project-management connectors needed to fill this record are planned extensions. The shared action and event contracts already provide the place where their evidence should land.

Missing evidence is a first-class outcome

The proof-of-delivery path demonstrates this well. The local tests exercise a low-completeness record that becomes invalid rather than releasing the delivery event. The prototype uses a completeness threshold around 0.85 in that path. A real acceptance policy should name its required evidence; a single model-generated completeness score is not enough.

For example, an accepted release may require a specific customer acknowledgement plus the agreed validation report. Both must refer to the same deliverable version. A previous acceptance does not automatically cover a changed deployment.

SLA risk and escalation

The prototype can move a service-level record from active to at-risk and breached. One local path uses 80% of the window as an at-risk signal. That is a useful demonstration of a timer-driven escalation, not a universal service policy.

A practical founder notification should state the deadline, current blocking condition and available choices. “Access approval is still missing; the agreed review is tomorrow; request a new date or reduce the initial scope” is useful. Repeated “deadline at risk” alerts without new information create supervision work rather than remove it.

The delivery-to-finance handoff

A confirmed milestone can make an invoice eligible. The same event should not independently create revenue and a second invoice in two consumers. In the current prototype, delivery and proof-of-delivery events can each feed simple financial examples. The integrated version needs one recognition and billing policy keyed to the underlying obligation.

I would measure accepted-on-time delivery, reopened work, missing acceptance evidence and founder intervention time. Task throughput matters only when it leads to a completed customer promise. The first live slice should therefore end with an inspectable handover, not merely a green project board.

Make acceptance evidence version-specific

For a software pilot, a screenshot of a working screen is not enough. The accepted deliverable may require a release, an evaluation report and an acknowledgement from the named customer reviewer. All three should refer to the same release. Otherwise an agent can accidentally assemble a complete-looking handover from incompatible versions.

from company_lab.business import delivery_ready

required = {"evaluation", "handover", "customer_acceptance"}
evidence = {
    "evaluation": {"release": "r3", "ref": "eval-report-3"},
    "handover": {"release": "r3", "ref": "guide-3"},
    "customer_acceptance": {"release": "r2", "ref": "email-12"},
}
assert not delivery_ready(required, evidence, "r3")
evidence["customer_acceptance"] = {"release": "r3", "ref": "email-17"}
assert delivery_ready(required, evidence, "r3")

The model can extract candidate references and summarise a handover. A deterministic gate checks whether the required evidence exists for the current obligation. If the agreement permits an alternative acceptance process, record that exception rather than weakening the gate for every customer.

Build a dependency graph before assigning dates

For the studio example, document access precedes ingestion, ingestion precedes evaluation, and customer review follows a deployed candidate. Independent work, such as drafting the handover guide, can proceed in parallel. The agent should distinguish a task dependency from a preferred sequence.

I would store each task's prerequisites, owner, estimated effort and completion evidence. A missing prerequisite creates a blocked state with the responsible party and next follow-up time. A single founder can then see whether a deadline is threatened by internal work, customer access or provider availability.

An external project tracker remains useful as the working board. The platform maps each task to a stable tracker identity and projects status changes through explicit rules. A tracker ticket marked done can nominate delivery evidence; it does not automatically authorise billing.

Treat repository events as evidence with a scope

A CI result proves that a named check ran against a named commit under a named configuration. It does not prove the customer can access the deployed application. The repository connector should retain commit, check suite, result and artifact references, while the deployment connector reports environment and release identity.

For a handover, the agent can compare the acceptance checklist with those receipts and list what remains missing. It may say “release r3 passed the fixture suite, but customer access is not confirmed.” That is a useful operational summary because the boundary of the evidence is clear.

If the customer reports an issue after acceptance, create a support case linked to the release and agreement. Reopening delivery may be appropriate, but the previous acceptance should remain in history. This makes it possible to distinguish rework, warranty support and a new scope request.

What happens when the worker dies halfway through?

Suppose the project tracker task was created but its acknowledgement was lost. A recovered worker should search by the platform's operation identity or use a provider-supported idempotency mechanism. Creating a fresh ticket every time the worker restarts makes the board look productive while multiplying coordination work.

The expanded kit's receipt-recovery example applies to this connector as well as email. Its safe unresolved state is valuable: if the provider cannot prove whether the task exists, the system asks for reconciliation. The founder should see the uncertain external operation alongside the original work order.

Define a meaningful delivery scorecard

Count accepted milestones, acceptance delays, reopened work, missing evidence and founder coordination time. Separate time spent waiting for the customer from time spent executing tasks, while retaining the overall customer-facing elapsed time. That helps identify the actual bottleneck without hiding it.

For the exercise, complete every development task but leave the handover guide on release r2 while the candidate is r3. The work order must remain unaccepted. Add the corrected guide, then replay the delivery event twice. Acceptance can complete once, and the billing consumer should create one obligation. This tests the connection between engineering evidence and business completion.