ΛXIØM Lens Documentation

ΛXIØM Lens Console can be wired into products through HTTP API keys, MCP access, or both. They share the same team/account boundary, but they are different integration methods.

Sign up at console.axiomlens.com/sign-up. We create a live key. Use it as a Bearer token and choose the compatibility shape your client already speaks.

OpenAI Chat Completions shape

curl https://api.axiomlens.com
/v1/chat/completions \
  -H "Authorization: Bearer axm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 256,
    "messages": [
      {
        "role": "user",
        "content": "Summarize: ..."
      }
    ]
  }'

Anthropic Messages shape

curl https://api.axiomlens.com
/v1/messages \
  -H "Authorization: Bearer axm_live_..." \
  -H "Content-Type: application/json" \
  -H "X-Axiom-Operator: oracle" \
  -H "X-Axiom-Tier: throughput" \
  -d '{
    "model": "claude-sonnet-4-6",
    "max_tokens": 256,
    "messages": [
      {
        "role": "user",
        "content": "Summarize: ..."
      }
    ]
  }'

Portable evidence shape

curl https://api.axiomlens.com
/process \
  -H "Authorization: Bearer axm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "signal": "Use ΛXIØM to check whether this support queue policy is stable, recurrent, and auditable.",
    "context": "New signup onboarding: prove the evidence contract before the first live workflow call.",
    "assumption_witnesses": {
      "noether": {
        "transition": "app.step",
        "quantity": "governance_mass",
        "quantity_trace": [
          1,
          1,
          1
        ]
      },
      "lyapunov": {
        "potential_trace": [
          84,
          70,
          63.5,
          51
        ]
      },
      "poincare": {
        "bounded": true,
        "reaches_boundary": true,
        "cycle_trace": [
          0,
          0.5,
          1,
          0
        ]
      },
      "fixed_point": {
        "regime": "banach",
        "fixed_point_residual": 0,
        "lipschitz_bound": 0.42
      },
      "information_loss": {
        "states": [
          "appeal_pending",
          "sarcastic_quote",
          "policy_violation"
        ],
        "observer_outputs": [
          "allow",
          "allow",
          "block"
        ],
        "closed_under_transition": true,
        "observer_invariant": true
      },
      "empirical": {
        "dataset_uri": "s3://axiom/studies/diminishing_returns.csv",
        "schema_uri": "git:replication/v1/schema/diminishing_returns_v1_schema.json",
        "protocol_uri": "git:replication/v1/PROTOCOL.md",
        "result_uri": "git:replication/v1/results/run_2026_05_06.json",
        "run_hash": "sha256:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
      }
    }
  }'

TypeScript helper

type Operator = "oracle" | "validator" | "lens" | "governor" | "codex";
type Tier = "throughput" | "judgment";

export async function axiomMessage(input: string, operator: Operator, tier: Tier) {
  const r = await fetch("https://api.axiomlens.com
/v1/messages", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.AXIOM_API_KEY}`,
      "Content-Type": "application/json",
      "X-Axiom-Operator": operator,
      "X-Axiom-Tier": tier,
    },
    body: JSON.stringify({
      // Required by /v1/messages; X-Axiom-* overrides it when the pair is mapped.
      model: "claude-sonnet-4-6",
      max_tokens: 256,
      messages: [{ role: "user", content: input }],
    }),
  });
  if (!r.ok) throw new Error(`ΛXIØM ${r.status}: ${await r.text()}`);
  const data = await r.json();
  return {
    text: data.content?.[0]?.text ?? "",
    modelUsed: data.model,
    governance: data.axiom_governance,
  };
}

Python

import os, requests

r = requests.post(
    "https://api.axiomlens.com
/v1/chat/completions",
    headers={
        "Authorization": f"Bearer {os.environ['AXIOM_API_KEY']}",
        "Content-Type": "application/json",
    },
    json={
        "model": "claude-sonnet-4-6",
        "max_tokens": 256,
        "messages": [{"role": "user", "content": "Summarize: ..."}],
    },
    timeout=120,
)
r.raise_for_status()
data = r.json()
print(data["choices"][0]["message"]["content"])
print(data["axiom_governance"])

Use these as starting points when wiring ΛXIØM into a product. The key implementation habit is to keep governance metadata next to the generated text, tool action, workflow decision, or business object that used it.

If you are building an AI feature, prefer the full sandwich: validate the prompt, call a model or the ΛXIØM API, govern the answer, store the governance object, and attach the request id to the user-visible action.

Send a ΛXIØM Lens Console API key in Authorization: Bearer. The kernel also accepts x-api-key for Anthropic SDK clients that use that header.

Treat keys as infrastructure credentials. A browser UI may show a prefix for recognition, but raw values should live in server environment variables, encrypted secret stores, backend workers, or trusted MCP server processes. CMNDCNTR Advisor follows the same rule: it uses a scoped server credential rather than copying a user key into the client.

• axm_live_... — production traffic, billed against your team plan
• axm_test_... — development traffic; same governance, separate key namespace

Keys validate through the console HTTP contract when the kernel is configured for white-label mode. Revoked keys can remain cached by a kernel instance for roughly 60 seconds.

/v1/chat/completions is the OpenAI-compatible entry point. Set your client base URL to https://api.axiomlens.com /v1 and keep the usual chat request fields. /v1/messages accepts model, max_tokens, messages, optional system, temperature, top_p, and stop_sequences.

You can name a concrete model in the request body or ask the kernel to route by X-Axiom-Operator and X-Axiom-Tier. Header routing overrides the body model only when the pair is mapped.

The console also stores weekly model-route selections. The refresh job pulls provider catalogs, scores candidates against Signal Jumping's 8D route lanes, and exposes the active policy at /api/internal/model-routes for kernel consumption. The consensus lane is ΛXIØM's preferred margin-aware route: cheap, high-alignment models that let the product price competitively against frontier defaults. Route signatures are stored as first-class Signal Jumper rows, and a refresh only promotes a new active route when it clears the material-improvement threshold.

Default operator map

In full mode, the kernel decomposes the last user message, injects structural context, calls the upstream model, and governs the output. The governor pipeline reports action, repairs, warnings, blocking governors, and optional quality scores.

A user message beginning with /lens or another operator command activates the kernel's explicit Lens mode. The command is stripped before the prompt is sent upstream.

For product integrations, preserve axiom_governance exactly where the generated text is stored or displayed. The metadata is the audit handle: it tells support, compliance, and operators whether the call was allowed, repaired, warned, or refused and which structural read shaped that decision.

The MCP server exposes the ΛXIØM Kernel as callable tools for agent clients. Use it when an agent needs structural decomposition, governed prompt/response checks, operator selection, coherence reads, canon lookup, world-model memory, or gap analysis without importing kernel source code.

Keep the boundary clear: MCP is the kernel tool surface. ΛXIØM Lens Console owns account identity, API keys, governance records, usage, and the decision ledger. Do not expose raw user API keys to browser code or copy them into client-side MCP configuration.

Copy-paste starter config

Replace the paths and provider key, then restart the MCP client. Use this for local agent/IDE setup; do not treat it as a hosted public MCP URL.

{
  "mcpServers": {
    "axiom-kernel": {
      "command": "python",
      "args": [
        "/path/to/axiom-kernel-core/mcp-servers/axiom-kernel-mcp/server.py"
      ],
      "env": {
        "AXIOM_LLM_PROVIDER": "openai",
        "AXIOM_LLM_API_KEY": "sk-...",
        "AXIOM_LLM_MODEL": "gpt-4o-mini",
        "AXIOM_WORLD_MODEL_PATH": "/tmp/axiom_world_model.json"
      }
    }
  }
}

Local STDIO configuration

For Claude Desktop, Cursor, Gemini, Codex-compatible clients, or any MCP client that launches local commands, point the client at the kernel MCP server file from the kernel checkout:

{
  "mcpServers": {
    "axiom-kernel": {
      "command": "python",
      "args": [
        "/path/to/axiom-kernel-core/mcp-servers/axiom-kernel-mcp/server.py"
      ],
      "env": {
        "AXIOM_LLM_PROVIDER": "stub",
        "AXIOM_LLM_MODEL": "",
        "AXIOM_WORLD_MODEL_PATH": "/tmp/axiom_world_model.json"
      }
    }
  }
}

Remote or multi-project SSE

For remote access, run the same server in SSE mode and put normal network controls around it. The server process owns provider credentials through environment variables; clients call tools through MCP.

cd /path/to/axiom-kernel-core
python mcp-servers/axiom-kernel-mcp/server.py --sse --host 0.0.0.0 --port 8420

# SSE-capable MCP clients connect to:
# http://localhost:8420/sse

Environment variables

Tool groups

Governed app pattern

1. Call kernel_govern_input on the user prompt before sending it to a model.
2. Call your model or the ΛXIØM HTTP API using the server-side credential boundary.
3. Call kernel_govern on the draft answer and preserve the returned governance metadata.
4. Use kernel_laws, kernel_atoms, kernel_patterns, kernel_coherence, or gap_analyze when the agent needs a diagnostic read instead of free-form advice.

These examples are intentionally fictional. They show the product pattern without implying an existing customer deployment. The repeatable shape is always the same: define the operating object, run the governed API or MCP tool, preserve governance metadata, and write the outcome back to the relevant ledger or business object.

In each case, a missing mechanism, missing evidence source, or missing return metric should produce a gap report. The Advisor and MCP tools should not turn absent business evidence into a confident recommendation.

The portable /process and /chain surfaces accept assumption_witnesses. The kernel returns an evidence object that reports pattern matches, theorem backing, assumptions satisfied, assumptions missing, witness discharge results, empirical provenance, confidence, and limitations.

Pattern detection is not treated as proof. A pattern upgrades to assumption_discharged only when the witness data satisfies the discharge checks for that theorem family.

Evidence response shape

{
  "expression": "...",
  "confidence": 0.71,
  "evidence": {
    "proof_registry_version": "2026-05-06.bridge-1",
    "pattern_matches": [
      {
        "id": "pattern.stability.lyapunov",
        "status": "assumption_discharged",
        "theorem_family": "Lyapunov stability",
        "assumptions_satisfied": [
          "Potential values live in a preorder",
          "The potential is nonincreasing after one transition"
        ],
        "assumptions_missing": []
      }
    ],
    "theorem_backing": [
      {
        "id": "bridge.lyapunov.lyapunov_nonincreasing_iterate",
        "proof_status": "lean_verified",
        "source_file": "AxiomTheorems/Bridge/LyapunovBridge.lean"
      }
    ],
    "assumption_discharge": {
      "results": [{ "id": "discharge.lyapunov", "status": "discharged" }]
    },
    "confidence": 0.82,
    "confidence_level": "high",
    "limitations": [
      "Formal bridge theorems certify theorem-shape under stated assumptions, not every empirical claim."
    ]
  }
}

Signed-in users can run this flow in the Evidence Contract console.

The proof registry is the machine-readable bridge between ΛXIØM language and known theorem families. Each entry names the theorem ID, Lean symbol, source file, domain, assumptions, external theorem family, proof status, and confidence.

• GET /proof-registry returns Lean-backed theorem records.
• GET /empirical-provenance returns empirical records and their limitations.
• Dashboard decisions store evidence summaries so production traffic can be audited without storing the whole response body.

OpenAI-compatible responses preserve choices, message, finish_reason, and integer usage fields. Both compatibility shapes append a non-standard axiom_governance field, so clients that ignore unknown fields keep working.

Anthropic Messages response

{
  "id": "msg_4d470ffa1a8f42d69f02aebb",
  "type": "message",
  "role": "assistant",
  "model": "claude-sonnet-4-6",
  "content": [{ "type": "text", "text": "..." }],
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": { "input_tokens": 142, "output_tokens": 87 },
  "axiom_governance": {
    "action": "allow",
    "passed_all": true,
    "total_repairs": 0,
    "total_warnings": 0,
    "blocked_by": [],
    "mode": "full",
    "lens_active": false,
    "duration_seconds": 1.4,
    "structural_perception": {
      "operator": "oracle",
      "dominant_axis": "functional_coherence",
      "signal_type": "analysis"
    }
  }
}

OpenAI Chat Completions response

{
  "id": "axiom-2f8c9a0b4d2e",
  "object": "chat.completion",
  "created": 1777560000,
  "model": "claude-sonnet-4-6",
  "choices": [{
    "index": 0,
    "message": { "role": "assistant", "content": "..." },
    "finish_reason": "stop"
  }],
  "usage": {
    "prompt_tokens": 142,
    "completion_tokens": 87,
    "total_tokens": 229
  },
  "axiom_governance": { "action": "allow", "mode": "full" }
}

• Plan quota is checked before keyed calls when the kernel is wired to the console HTTP API. Confirmed over-quota requests return 429.
• /v1/messages compatibility is text-first today. Image, tool_use, and tool_result blocks are represented as text placeholders.
• /v1/chat/completions can return governed SSE when stream: true; the kernel sends the governed answer as a complete chunk.
• Bare model names fall back to the deployment's default upstream model. For predictable production routing, use claude-*, hf/..., or <org>/<model>.

• 401 — missing, invalid, or revoked console key
• 400 — malformed request body
• 429 — confirmed plan quota exceeded for this billing period
• 502 — upstream provider error, timeout, or no upstream choices
• 500 — internal kernel error; inspect the corresponding request in /dashboard/decisions