Routing use cases

The gateway router observes incoming traffic continuously, produces embeddings, and groups requests into discovered use cases. This set of use cases and their rankings keeps changing as traffic arrives, and it is called the working set.

The router reports which use cases are stable and which are still moving. Once every use case above the relevance threshold carries a label, you take a snapshot of the working set and give each use case a backend name.

That snapshot is a use case manifest. It is immutable, versioned, and provenance-verifiable. The backend names an operator supplies correspond to the gateway proxy configuration, so the manifest is a route table keyed on the meaning of a request.

Only one manifest enforces routing at a time.

To list every manifest and whether it is able to enforce:

To read one as it was frozen:

A manifest is fixed and the working set is not, so the two separate over time. To see how far apart they have moved:

A large difference means traffic has changed shape since the manifest was frozen, and that some current traffic is being routed by a table that no longer describes it.

Deploying a manifest makes it the routing policy and displaces the one before it:

To withdraw a manifest from use:

Getting from traffic to a routing policy covers the steps that produce a manifest, and Shifting traffic gradually covers moving a use case onto a new backend without replacing the manifest.