01
Intake
A request arrives as text, audio, or a media prompt. Nothing is sent to a model yet. The fabric’s only job at this step is to hold a value.
Fabric
One intake. A lane for each kind of work.
The fabric is Separator’s decision plane. It is the path a request takes before a model spends time on it. We measure the decision, the contract, and the split. We do not measure a pile of accelerators and call that routing.
Decision plane
4.2 ms
explanationreason-1
Orange sparks are requests. A fork means the request contained two types and left on two lanes. The field is drawn in the browser. It does not call a model.
02
Type
Separator assigns a type, or several types when the request is more than one job. Explanation, patch, prose, lookup, media, speech, workflow.
03
Contract
A single type that fits an allowed lane must satisfy Route<In, Out>. Several types become Fanout<Request, Part[]>. A fit that the allow-list removes stays pending.
04
Lane
Each part goes to the model that is good at that type, if the allow-list permits it. The decision latency is the time spent getting here, not the time the model then spends.
Live path
The same intake, a different contract each time.
The curve that is lit is the request in front of the fabric right now. A single lane is a Route. A label with a plus is a Fanout. The milliseconds are the design target for that decision.
Decision
Why is the sky blue?
- type
- explanation
- contract
- Route<Question, Answer>
- lane
- reason-1
- decision
- 4.2 ms
Catalog
Which lanes take the current request.
Seven lanes sit on the fabric. A request lights the ones it actually needs. The others stay dark. Darkness is not a failure. It means that type was not in the ask.
Why is the sky blue?
Route<Question, Answer>
reason-1
Judgment, explanation, comparison.
code-1
Patches and reviews.
write-1
Prose meant to be read as a document.
search-1
Lookup and the citations that support a later hop.
vision-1
Stills and video.
speech-1
Audio in, transcript out.
ops-1
A workflow step a system can run.
Two clocks
The decision has a budget. Generation does not borrow it.
Separator is designed so the routing choice lands in under 10 ms. That number ends when the lane is chosen. Everything after that belongs to the model and is metered on its own.
Decision
4.2 ms
A design target for the choice of lane. The consoles on this site illustrate it. They do not measure production.
Target under 10 ms
Generation
Separate
The model’s answer takes as long as the model takes. That time is metered on its own and is not added into the decision figure.
Not this clock
Record
Every handoff leaves a line.
The log on the right is an illustration of the lines a decision writes. A refused lane is still a line. Pending is still a line. The absence of a model call is the thing you wanted to see.
- Type
- The kind of work, named before a model is chosen.
- Contract
- Route or Fanout, so the caller can switch without parsing prose.
- Model
- The lane id that received the part, or the refusal if none did.
- Latency
- Milliseconds for the decision. Generation is a different meter.
- Parts
- Present when the request split. Each part can be read alone.
- Prompt
- Omitted from the record unless the customer enables that logging.
Hop log
- 000 intake Why is the sky blue?
- 001 type explanation
- 002 contract Route<Question, Answer>
- 003 allow reason-1
- 004 lane reason-1 4.2 ms
- 005 intake Close the month and write the summary.
Shape
The response the caller switches on.
This is the contract, written out. It is not a trace from production. model is null on a fan-out because the models live on the parts.
{
"id": "rte_01",
"latency_ms": 4.6,
"type": "fan-out",
"contract": "Fanout<Request, Part[]>",
"model": null,
"parts": [
{ "type": "workflow", "model": "ops-1" },
{ "type": "prose", "model": "write-1" },
{ "type": "explanation", "model": "reason-1" }
]
}Install
VeloxitySI puts this plane in the stack you already run.
Veloxity is an Xythera company. The fabric is the engagement: one intake in front of the models a customer already calls, with a type on every hop.
- 01
Listen to the requests you already have
A week of real asks is enough to see which ones are one type and which ones are hiding a second job.
- 02
Write the allow-lists
Per team, per environment. A lane that is not on the list cannot be selected, including a lane added later.
- 03
Point one client at /v1/route
OpenAI-compatible callers set the model to separator. Callers that already know the type send a lane id and accept a refusal when the type does not fit.
- 04
Read the hop log
Look for types you did not expect. Tighten the list. The fabric is doing its job when a blended answer becomes a list of parts.
- 05
Keep the clocks apart
Put the decision latency on one graph and the model latency on another. Mixing them makes the routing target meaningless.
Separator
Put a typed route in front of the models you already call.
Decision
explanation
reason-1
4.2 ms