ADR-0055: The Query Intent endpoint is not built until the Study Area's Corpus exists

Status: Accepted — amends ADR-0033, which stands Date: 2026-09-11

Decisions

D-126 The server's Query Intent endpoint is built when the Study Area's Corpus exists, and not before

The client half of the Query Intent tier is built and stays. The server endpoint ADR-0033 specifies — provider, spend cap, per-address limit — is written when there is a Corpus for it to help route over, with its price, cap and limit taken from that day's facts rather than today's.

What each amendment touches

• ADR-0033 — D-75 to D-78 stand as the specification of the endpoint: the provider tier, the narrower retention requirement, the server-side spend cap that disables the tier, and the per-address limit with the key kept on the server. What moves is when the endpoint is built. The prices ADR-0033 records are dated 2026-09-08, and are to be re-read when it is.

Context

The Routing Floor runs first on every question, and its first rule is the Corpus sentinel: "No verified Corpus is Corpus Unavailable, whatever the question said" (RoutingFloor.ts). There is no Study Area Corpus yet, so every question is answered Corpus Unavailable before Query Intent is consulted. A live endpoint today would spend against the cap, send each Handler's question to the provider — Query Intent is the one thing that crosses the network (D-69) — and have its answer discarded every time.

Ticket 19 is the endpoint's ticket. Its three open blockers — the per-address bucket size, the spend cap, the provider SDK's shape — are all guesses today and all answerable later. The bucket is sized from the Study Area's device count, which ADR-0054 now determines. The cap is set from prices re-read at build time; one of ADR-0033's rates doubles on 2027-01-01. And the SDK is checked against live documentation the day the code is written, rather than against a pricing page read past the building model's knowledge cutoff — which is how a package came to be asserted three times as installed while absent from the manifest (ADR-0045).

Nothing waits on the endpoint meanwhile. Seam 5 runs on recorded intent with no provider, and ADR-0043 already makes intent advisory: a dead tier yields the same outcome as no tier.

Decision

Keep the client half; build the endpoint when the Corpus exists; re-read prices and the SDK then.

Rejected options

• Build it now and switch it on — rejected. Cost, and each question sent to a provider, for an answer that is always discarded.
• Build it now, switched off — rejected. It goes stale against a provider before it is ever used, and would be switched on later on the strength of code nobody re-checked.

This ruling may not be re-decided

If a change contradicts this ADR: stop and raise it. Do not implement over it.

Specifically: do not build the endpoint against today's prices and SDK "to have it ready".

Consequences

What becomes easy. Ticket 19's blockers are answered with facts rather than estimates, and no question leaves a device for a Corpus that is not there.

What this costs. When the Corpus arrives, the conversational surface routes on the Floor alone until the endpoint is written — a slower path to a name, never a wrong answer, because intent is advisory.

Coverage

No upstream finding lands here. The ruling came from reading the Routing Floor's order of evaluation (D-104).