Certification

Being able to serve a model and being allowed to serve it are two different facts, established by two different parties. Your node asserts the first. Only Shardio can assert the second.

That split is the whole trust model. Your node advertises that it has an engine warm for a build — that is a capability, and it is easy to claim. Certification is written by us into the dispatch plane, where your node cannot write it. A node that labelled itself certified would still receive nothing, because the routing rule reads our record, not yours.

Certification is per (node, build) pair, not per node and not per model. The same machine can be certified for one model and not another, and re-electing a model under a new build starts the process again — different engine, different quantisation, different numbers.

The de-serving half of this is not switched on yet

The mechanism below is built and it runs: checks execute, are graded, and are recorded against your pair. What is off is every step that would change what the mesh routes. Today, concretely:

a breaker window that would open is logged, and the pair keeps serving;
an admission exam that would refuse is recorded as a refusal, and the pair is certified anyway;
no canary result removes any pair from service.

The grading thresholds are unmeasured guesses, and two have already been found to mis-fire. Collecting real fleet data against them is what this shadow period is for. Enforcement gets turned on deliberately, by a human, once they are calibrated. Read the rest of this page as the mechanism you will be judged by, not as what is judging you today.

Getting certified

A newly elected build starts in certifying. It serves no customer traffic, and the exam is not triggered by your election: we run it. While onboarding is invited rather than self-serve, that is a conversation, not a queue.

To certify it, we run the build's admission set — a fixed pool of prompts belonging to that model — against your node specifically, and compare each answer to a reference completion we captured ourselves. References are never taken from a serving node; a node that supplied its own reference would be grading its own homework.

Your results become your envelope: how closely this node reproduces the reference, and how much that varies. It is measured per node because two honest machines running the same build genuinely differ a little — kernels, driver versions, batching. The envelope is what "normal for you" means from then on.

Pass, and the pair is marked certified and starts receiving traffic.

Staying certified

After that, checks continue at unpredictable intervals, drawing from a separate pool of prompts your node never saw during admission. Each answer is graded against your own envelope.

Three properties of these checks are worth knowing, because they are what make the system work:

They are blind. A canary arrives through the same public path as customer traffic, in the same shape, with the same fields. There is nothing in the request that identifies it, and the routing pin that sends it to you specifically is applied server-side where your node cannot see it.
They are paid. A canary is a real request that you serve and are paid for, at the ordinary rate. Verification is our cost of doing business, not a tax on yours.
They exercise the real build. No special model, no debug mode, no separate code path. The check measures exactly what a customer would get.

The measure is agreement with the reference completion: how much of the expected answer your node reproduces before diverging. Thresholds are being calibrated against real fleet data and will move; the mechanism will not. Until that calibration is done, the grading runs and records without de-serving anyone — see the note at the top.

When checks fail

This section describes the enforcement mechanism. With enforcement off it all happens except the last step: the window is computed and the verdict recorded, and the de-serving is logged rather than done.

A single failed check does not de-serve you. Honest nodes fail occasionally — a sampling tail, a moment of contention — and a system that reacts to one bad answer would throw away good capacity constantly.

Failure is judged over a window: enough failures within a recent run of checks, and the pair's breaker opens. It is a rate, not a streak, so a node cannot pass one check to reset a bad record.

When a breaker opens, the pair is de-served: we revoke certification in the dispatch plane first, so traffic stops immediately, and only then mark the pair recertifying. It stops earning on that model. Your other models are unaffected — the breaker is per pair.

Getting back is deliberately slower than falling out. The window has to fill with passes before the failures age out of it, which takes substantially more good checks than the failures that opened it. There is no appeal queue and no reset button; the fix is a node that answers correctly.

Reading your own state

shardio status

reports each elected build with its state, whether it is currently serving, and its breaker. certifying means not yet admitted, certified means live, recertifying means de-served and working its way back.

Quarantine

Separately from certification, a node can be quarantined — a hard stop for abuse or compromise. A quarantined node cannot resume and cannot mint new credentials, and re-registering does not clear it. It is not something a node reaches by serving badly; that is what the breaker is for.