Governed LLM, API, and MCP control plane
Governed model calls with receipts your product can act on.
ΛXIØM Lens sits between your app, your models, and your MCP tools. Issue keys, route calls, preserve axiom_governance, and inspect every decision in ΛXIØM Lens Console.
OpenAI-compatible
Anthropic-compatible
MCP-ready
HTTPS-only
Decision receipt
POST api.axiomlens.com/v1/chat/completions → govern → record
decision
stop_loop
hidden axis
motion_without_progress
next action
return_to_human
01 — Start Here
Three ways into the same governed boundary.
Start with the surface your team already uses. Backend systems use API keys. Agent and IDE workflows use MCP. Operators use the dashboard to see decisions and receipts.
API Keys: backend HTTP integration
Create a team key, point your server at the OpenAI or Anthropic-compatible endpoint, and preserve the returned governance metadata.
MCP Access: IDE/agent/tool integration
Connect AXIØM Lens to agent clients and tool surfaces so governed decisions travel with the work, not just the chat output.
Dashboard: see governed decisions and receipts
Inspect what came in, what AXIØM saw, what it decided, and which receipt should guide the next product action.
Example Decision Receipt
Plain English proof that governance ran.
Input came in → AXIØM saw this → AXIØM decided this → app should do this next.
01 / Input came in
Draft a customer-facing claim from weak evidence.
02 / AXIØM saw this
The request crosses a proof boundary and needs evidence before publication.
03 / AXIØM decided this
require_verification
04 / App should do this next
Hold the claim, ask for supporting evidence, and record the receipt.
02 — What Lens does
A control plane, not a chat wrapper.
ΛXIØM Kernel owns governed execution. ΛXIØM Lens Console owns keys, route policy, billing, usage, and the decision ledger. The value is the boundary between the two staying visible.
Keys
Issue live and test API keys under one AXIØM Lens team boundary.
Routes
Choose BYOK, AXIØM-managed frontier, or consensus-style routes.
Governance
Return decisions the host can branch on instead of hiding model behavior.
Ledger
Record verdicts, route, model, latency, tokens, cost, trace IDs, and outcome.
03 — Decisions you can inspect
AXIØM returns a branch, not just a blob of text.
The host app can decide what happens next because the kernel returns system effects: continue, call model, call tools, return to human, and persist the contract.
allow
Pass
Inside contract, authority, budget, and evidence boundaries.
warn
Continue tightly
Budget or confidence pressure is visible before the next call.
rewrite
Repair first
Unsupported certainty or brittle output needs a safer prompt.
require_verification
Verify
Evidence or coherence is not strong enough to continue as-is.
stop_loop
Stop
The loop is exhausted, degrading, or producing no new evidence.
escalate
Human boundary
The next action crosses authority, spend, publish, or production lines.
04 — How it fits
Keep your client. Change the boundary.
Backend services use HTTP API keys. Agent and IDE tools use MCP. Both are governed under the same AXIØM Lens account model.
API Keys
Server and backend HTTP integration for /v1/chat/completions, /v1/messages, evidence checks, workers, and product routes.
MCP Access
Agent, IDE, and tool integration for Claude Desktop, Cursor, Codex-compatible clients, Gemini, and other MCP clients.
Both
Available under the same AXIØM Lens team/account boundary, so usage, governance, and revocation stay centralized.
05 — Workflow boundary
The loop is explicit.
AXIØM is most useful when the workflow has to know whether a model call should continue, pause, verify, rewrite, stop, or return to a person.
01
Classify the work
AXIØM reads the task shape before choosing chat, prompt, tool, agent loop, or human-required mode.
02
Contract the intent
The vague request becomes objective, artifact, authority, budgets, stop conditions, and verification requirements.
03
Govern the next action
The kernel returns a branchable decision: allow, warn, rewrite, block, escalate, require_verification, require_contract, or stop_loop.
04
Persist the receipt
The portal stores what happened so teams can inspect patterns instead of guessing whether governance ran.
06 — Dashboard visibility
See what the API is doing.
The instrument panel is the plain-English view: what came in, what AXIØM did, what evidence was visible, and which claims are safe to make now.
shape
decision
reason
receipt
07 — Domain map
One product surface, clear entrances.
The public site, API, docs, help, bridge, and console each get a clear home under axiomlens.com.
Public site
axiomlens.comΛXIØM Lens home, positioning, and pricing
Kernel API
api.axiomlens.comOpenAI and Anthropic-compatible governed request path
Documentation
docs.axiomlens.comIntegration reference, routing, limits, and examples
AXIOM Bridge
bridge.axiomlens.comGoverned model choice and substrate gateway policy
Help Desk
help.axiomlens.comSupport intake, implementation triage, and incident handoff
Console
console.axiomlens.comΛXIØM Lens Console keys, billing, and decisions ledger
08 — Commercial access
Start with a key. Scale with policy.
Use BYOK when teams want their own provider accounts. Use managed frontier routing when AXIØM supplies provider access under an agreed allowance, with usage visible in the portal.