Product Factory: How Work Flows

In most organisations, delivering a change means a ticket in one system, a branch in another, a review in a third, a pipeline in a fourth and a deployment record in a fifth — and a person whose actual job is keeping those five stories consistent with each other.

Apiway runs it as one execution. A programme starts from a ticket and ends with that ticket closed, and every step between is part of the same thread. Nothing needs reconciling afterwards because nothing was ever separate.

A Programme

A programme is a planned sequence of steps executed against your estate. You start one, it runs, and it can suspend — waiting for a pull request to be raised, a gate to report, a human to approve — then resume exactly where it stopped when that event arrives. It waits on events rather than polling for them.

Programme	What it delivers
Producer	Designing and publishing an API product
Consumer	Onboarding an API you consume
Product deploy	Deploying a product and its member APIs
Cross-tenant subscribe	Subscribing to another tenant’s product across the marketplace

How A Change Travels

A programme begins by resolving the ticket the work exists for, dispatches the implementation to your agent or your team, and then waits. When a pull request appears it is bound to that ticket. Verification runs against the contract, review is requested once there is something verified to review, and the deployment follows the merge — after which the change is propagated across the estate and the ticket closes because the work completed.

Every wait is a genuine suspension: the programme resumes when the event arrives rather than polling for it, so a change that sits in review for three days costs nothing while it waits.

Why This Is Not A Pipeline

A CI pipeline runs when code is pushed and finishes when it has deployed. It has no knowledge of why the change exists, whether it was approved, what it was supposed to do, or what depends on it.

A programme starts from the intent — a ticket — and carries that intent through every step. So the pull request references the ticket because the programme bound them, the gate verifies against the contract the ticket was raised from, and the deployment is attributable to an approved change rather than to whoever pushed last. The audit trail is not assembled afterwards from five systems; it is what the programme did.

What This Requires Of You

Two things, and no more. Work must originate from a ticket — which is the discipline the whole thread depends on. And your API must have a contract, because that is what the gate verifies against.

Everything else — binding the pull request, running verification, sequencing the review, deploying on merge, propagating the change, closing the ticket — is the programme’s job.