Skip to main content

Track production

Status: Planned

The reviewed public developer contract does not yet expose transaction status, producer acceptance, production, dispatch or webhook operations.

This page documents the canonical lifecycle direction so integrations can distinguish future transaction state from the capability results available today.

Planned normal lifecycle​

draft_requirement
  -> requirement_resolved
  -> capability_matched
  -> live_checks_pending
  -> route_proposed
  -> buyer_approval_pending
  -> buyer_approved
  -> producer_acceptance_pending
  -> producer_accepted
  -> in_production
  -> dispatched
  -> completed

The transaction architecture also defines explicit cancelled, recovery_required, recovered and failed states for non-happy-path outcomes.

These state names are canonical architecture, but they are not currently public developer API operations.

The important boundary is capability_matched​

capability_matched means SpecMatch has established one or more technically eligible production routes against controlled capability evidence.

It does not mean:

  • current price has been confirmed;
  • current availability has been checked;
  • buyer terms have been approved;
  • a producer has accepted the work;
  • an order exists.

The transaction plane moves beyond that capability state only after it obtains the evidence required for each later transition.

Producer acceptance is explicit​

buyer_approved and producer_accepted are different states. Buyer approval does not mean the producer or production network has accepted the production commitment.

A producer decline or timeout before producer_accepted is also not a SpecMatch failure. Another already-capable route may still be evaluated through the transaction orchestration policy.

Production and dispatch are operational evidence​

in_production and dispatched require transaction or controlled operational evidence. They cannot be inferred from the existence of a Specification, Recipe or capability match.

A dispatch event is distinct from actual delivery or completion.

Future status and event consumption​

The platform architecture expects transaction status and event/webhook projection to become part of the public product boundary. The exact reviewed public contract is still Planned.

Until that contract exists:

  • do not poll an undocumented internal route;
  • do not scrape first-party interfaces for status;
  • do not infer state from capability results;
  • do not invent webhook event names or payloads;
  • do not describe architectural states as live developer operations.

When transaction operations enter the reviewed developer contract, this guide will add the supported status and event examples and the API reference will remain the schema authority.

What you can track today​

For current intelligence operations, retain X-Request-Id and X-Correlation-Id as technical trace identifiers. They help troubleshoot interpretation and capability calls, but they are not order or production identifiers.

For the supported path up to capability fit, start with Build with Gnaww.

Last updated on