NEWTON’SExact ID
The client chooses an ID returned by the live catalog. Unpublished names are rejected.
Routing & receipts
Trust the route.
Read the receipt.
A model name should not be a vague preference. Newton’s reports what you requested, what resolved, whether an explicit fallback ran, what the call cost, and what balance remains.
Pinned by default
No silent substitution.
Automatic model routing is not part of the current public API. You select a published model ID, and Newton’s requires the upstream-reported identity to match.
Identity check
The returned identity must match the pinned route. Unconfirmed identity fails closed.
Visible result
The response records requested and resolved IDs plus explicit fallback status.
Fallback is opt-in. A client may provide up to three documented, published fallback IDs. Newton’s tries them in order and reports when one is used.
Request evidence
Every accepted call accounts for itself.
Receipts are operational and accounting metadata. They improve observability, but they are not cryptographic attestations.
| Receipt field | Question it answers | Where it appears |
|---|---|---|
| Request ID | Which call should support investigate? | Response header and receipt |
| Requested / resolved model | Did the route match the client’s intent? | Response headers and receipt |
| Fallback used | Did an explicitly configured fallback run? | Response header and receipt |
| Request cost | What did this accepted call consume? | Response header and receipt |
| Remaining balance | How much funded service credit remains? | Response header and account view |
| Usage and duration | How large and how slow was the call? | Response body and request log |
Infrastructure should explain itself.
Use the documented headers and settled receipt to reconcile every request.