Runtime Lane Proof

Mirror exposes runtime lanes as execution choices behind Gateway. They are not separate customer gateways.

The proof target is one service credential, one hosted /mapi surface, one Gateway registry, and the runtime lanes enabled for your tenant.

Required lanes

Lane	Purpose	Proof
`provider-plain`	Provider-backed model access through Gateway	health, model list, chat completion, usage telemetry
`protected`	Encrypted/end-to-end encrypted runtime through Gateway	health, release-enabled model list, chat/messages validation, evidence summary
`plain`	Plain baseline runtime through Gateway	health, model list, chat completion parity
`confidential`	Confidential-compute protected deployment when enabled	attestation or evidence summary, model list, chat completion
`fhe-local`	Customer-controlled local FHE flow when enabled	local key proof, encrypted payload proof, local decrypt proof

Implementation sources

Lane	Implementation source	Customer entry point
Provider lane	Mirror-managed provider adapter	Gateway `/mapi`, SDK, Portal, MCP, or CodePrism local agent
End-to-end encrypted lane	Mirror-managed encrypted runtime	Gateway `/mapi`, SDK, Portal, MCP
Plain lane	Mirror-managed baseline runtime	Gateway `/mapi`, SDK, Portal, MCP
Local/FHE lane	Customer-controlled SDK/runtime	SDK and customer environment

Do not expose any implementation source as a second customer gateway. Evidence is owned by the Gateway lane and correlated into Observability and Governance.

Gateway registry checks

Use these hosted checks first:

GET /mapi/v1/gateway/registry/runtime-lanes
GET /mapi/v1/gateway/registry/runtime-models
GET /mapi/v1/gateway/registry/guardrails
GET /mapi/v1/gateway/mcp/summary/evidence?serviceCredentialId=<id>

The registry should show:

lane id from the platform registry
protection mode
deployment target
release-enabled model list
guardrail model mapping
evidence availability

Customer-Facing Proof

Use hosted SDK calls for customer-facing proof. Direct runtime URLs are for operations only.

Expected proof:

service credential is valid and scoped
registry returns release-enabled models for the selected lane
SDK call returns a model response
Observability shows the trace under the same service credential
Governance evidence can be ingested when the workflow requires a release record

import { Mirror } from '@mirror/sdk';
 
// new Mirror() reads MIRROR_SERVICE_CREDENTIAL_FILE from env; the service credential
// binds every hosted call to the tenant + entitlements minted in the portal.
const client = new Mirror();
 
const catalog = await client.routing.catalog({
  surface: 'gateway',
  includeLiveModels: false,
});
 
const reply = await client.chat.completions.create({
  model: 'gemma-4-e2b-it',
  runtime: 'protected',
  messages: [{ role: 'user', content: 'Return exactly: MIRROR_OK' }],
});

Instruction-tuned chat models must be validated through the chat/messages path. Raw completion prompts are not a valid release gate for chat checkpoints.

Governance handoff

After lane proof, ingest evidence:

POST /mapi/v1/governance/evidence/ingest

Use source=runtime-lane and include:

lane id
model id
health result
model-list result
chat smoke result
attestation or evidence summary when available
deployment reference, but not private keys, host credentials, bearer tokens, or raw secrets

Non-goals

Do not create a second customer-facing Gateway for runtime lanes.
Do not route production users directly to runtime host ports.
Do not validate instruction/chat models with raw completion prompts.
Do not expose internal deployment topology in customer docs, SDK output, or Portal copy.