Operator guide

NeuralRing operator guide

You run EU inference endpoints. NeuralRing is the neutral, developer-facing front door that verifies your sovereignty posture, routes paying demand to you, meters every request, and settles your revenue share — so your capacity reaches developers you couldn't reach directly, without giving up neutrality or control.

This is the operator counterpart to the white-label tenant runbook. Everything here is human-gated: no operator, endpoint, or catalog change goes live without a person approving it.

The lifecycle at a glance

Apply → (approved) → Submit endpoint → Conformance probe → Human review → Live & earning

1. Apply (/partner). Sign in, then fill the operator application: org name,

legal entity + jurisdiction, contact, and the endpoints you plan to serve. Submitting creates an operator_application in our review queue — not a live operator. A human approves it, which creates your operator and makes you its owner. You can watch the application status on /partner.

1. Submit an endpoint (/partner/submit, once you're an operator). Give us a

public OpenAI-compatible base URL, the model it serves, its region, and (optionally) a bearer token — sealed AES-256-GCM under our platform key, never stored in plaintext.

1. Conformance probe. Our automated probe tests your endpoint's OpenAI

compatibility (chat, streaming, tools, structured output) and samples latency and throughput. You see the probe's output verbatim behind "show technical detail" if it fails, so you can fix and resubmit.

1. Human review. The probe's evidence is reviewed by a person before anything

goes live. You never self-assert your tier — your sovereignty tier and assurance are computed from your verified posture (operating entity, ultimate parent, data-center region, key custody, log residency), not from a form.

1. Live & earning. Once approved, paying demand routes to your endpoint like

any other in the eligible pool — subject to the same per-request sovereignty pin. Your revenue share accrues on every served request.

The cockpit renders this as a five-step stepper per submission (submitted → probing → in review → approved → live), with one plain sentence per state.

Sovereignty is measured, not claimed

• Your tier (0–3) is computed deterministically from facts; your assurance

(self_attested → verified → certified) says how substantiated those facts are. They are separate signals — see `/docs/runtime-sovereignty`.

• Model origin (where the weights came from) is a separate axis from your

runtime tier and never changes it: a US-origin open-weight model served on your verified EU endpoint reads as exactly that.

• Certifications are only shown verified against a live registry reference —

claiming SecNumCloud on your company website does not make your AI endpoint SecNumCloud (cert-scope rule).

The wanted list — demand waiting for supply

/partner shows the models NeuralRing will route demand to if you serve them, each with a deployment recipe and the license restrictions verbatim — so you see exactly what you're agreeing to serve before you pick it up. Serve one on a verified EU/EFTA endpoint and demand flows to you.

Get paid

• Your share of revenue is shown on the cockpit (e.g. "70% of gross usage").
• NeuralRing meters every served request (token counts + routing metadata only —

never your customers' prompts or completions) and generates your settlement statements. They appear read-only in your Get-paid section.

• Statement generation and payout are NeuralRing finance actions in the admin

console. Payout is records-only today — no real bank disbursement moves until a human enables an EU PSP (§3.9 money guardrail).

Neutrality

You only ever see your own data. No operator can see another operator's endpoints, pricing, usage, or settlement — enforced at the data layer, not just the UI.

Questions

Reach us at the contact on your application, or open an issue in the repo.