Skip to main content

Send an approved job towards production

Status: Planned

The public developer contract does not yet expose the transaction operation that turns a capable route into a live production commitment.

This page documents the canonical boundary so you can design your integration without inventing an API that Gnaww does not currently provide.

Canonical handoff direction​

controlled Specification
  -> SpecMatch-capable route
  -> live route checks
  -> route proposal
  -> buyer approval where applicable
  -> producer acceptance
  -> order and production lifecycle

The first two parts are intelligence and capability work. The later stages belong to the transaction plane.

What crosses the boundary​

A future production handoff must preserve the controlled identities and evidence already established rather than asking a provider adapter to reinterpret the job.

That means retaining, where applicable:

  • the durable Specification reference and canonical GJS evidence;
  • Recipe identity when the physical definition is eligible and exact;
  • the evaluated producer capability reference and version evidence;
  • the SpecMatch result that established capability fit;
  • quantity and fulfilment context;
  • authenticated buyer or workspace context;
  • request and correlation identifiers needed for audit.

This is architectural direction, not a currently callable transaction request schema.

What happens next belongs to a separate plane​

Live transaction orchestration may need to establish facts such as:

  • current quote or price;
  • fulfilment to the actual destination;
  • current availability where the provider exposes it;
  • provider-side order validation;
  • buyer-visible route and commercial terms;
  • buyer approval where required;
  • producer or network acceptance.

Those facts must remain separately attributable from capability fit.

capability plane
  Can this controlled route normally satisfy this controlled requirement?

transaction plane
  Can this specific route fulfil this specific job now on current terms?

Do not submit a provider payload from SpecMatch alone​

A canonical Specification is not a provider-specific order payload.

canonical specification != provider-specific order payload
capability match != current price
capability match != current availability
capability match != producer acceptance
capability match != an order

Provider-specific references and current commercial evidence belong in the transaction connector and orchestration layer. They must not leak back into the canonical GJS as new print meaning.

What to build today​

You can safely build your application through capability validation now:

  1. Understand the requirement.
  2. Retain the Specification.
  3. Find capable production.
  4. Validate one capability.
  5. Retain the controlled references and present the result as capability evidence only.

Do not fabricate a send-to-production call after step 5. The transaction handoff will be documented here when it enters the reviewed public developer contract.

Next​

Read Track production for the planned lifecycle after a route enters transaction orchestration.

Last updated on