ΛXIØM Lens Documentation

ΛXIØM Lens Console supports hosted HTTP API keys, while the kernel repository provides a separate local or self-hosted MCP process. They can both be used by one organization, but they do not automatically share authentication, usage, or ledger state.

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

Branchable decision shape

curl https://api.axiomlens.com
/v1/govern \
  -H "Authorization: Bearer axm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "current_state": {
      "release": "candidate",
      "evidence": "incomplete"
    },
    "proposed_next_action": {
      "type": "promote",
      "target": "production"
    }
  }'

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.

POST /v1/govern is the branchable decision entry point. /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.

The hosted kernel (version 1.3.8) exposes a five-step work loop before and after model calls. The contract lives in axiom-kernel-core docs/GOVERNANCE_DECISION_CONTRACT.md and docs/AXIOM_POWERED_CONTRACT.md. This portal documents the join. It does not import kernel Python and does not reimplement these routes.

Chat axiom_governance.action is allow | warn | repair | refuse. Those four values are not the branchable govern names. Branch on the AxiomGovernanceDecision object from POST /v1/govern or axiom.govern in @axiom/client.

cURL

curl https://api.axiomlens.com
/v1/govern \
  -H "Authorization: Bearer axm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "current_state": {
      "release": "candidate",
      "evidence": "incomplete"
    },
    "proposed_next_action": {
      "type": "promote",
      "target": "production"
    }
  }'

TypeScript (@axiom/client)

import { Axiom } from '@axiom/client';

const axiom = new Axiom({
  apiKey: process.env.AXIOM_API_KEY,
  baseUrl: 'https://api.axiomlens.com
',
});

const decision = await axiom.govern({
  "current_state": {
    "release": "candidate",
    "evidence": "incomplete"
  },
  "proposed_next_action": {
    "type": "promote",
    "target": "production"
  }
});

AxiomGovernanceDecision

{
  "decision": "require_verification",
  "reason": "The proposed production promotion crosses a proof boundary without rollback evidence.",
  "hidden_axis": "motion_without_progress",
  "required_next_action": "hold_and_request_evidence",
  "system_effect": {
    "should_continue": false,
    "should_call_model": false,
    "should_call_tools": false,
    "should_return_to_human": true
  }
}

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.

Use X-Axiom-Route-Mode with axiom-consensus or frontier-managed. If the header is absent, the portal selects the plan default. Route policy, plan quota, and Managed Frontier spend controls are checked before the provider call. byok is currently refused because secure provider-credential retrieval is not connected.

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. Chat action is allow | warn | repair | refuse. Branchable names live on POST /v1/govern as AxiomGovernanceDecision.

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 a local or self-hosted kernel tool surface. ΛXIØM Lens Console owns hosted API identity, keys, usage, and the decision ledger. MCP uses its own process configuration and local ledgers unless an operator explicitly integrates it with the hosted service.

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."
    ]
  }
}

After calling /process or /chain, inspect retained receipt summaries in Instruments.

Theorem-family and empirical provenance records are returned inside /process and /chain evidence objects. The live kernel does not expose GET /proof-registry or GET /empirical-provenance.

• Each evidence entry can name a theorem ID, Lean symbol, source file, domain, assumptions, proof status, and confidence.
• 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 whose action is allow | warn | repair | refuse. Clients that ignore unknown fields keep working. Do not expect those chat actions on POST /v1/govern.

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 SSE when stream: true. Model deltas arrive before output governance and are advisory until the terminal governance event. For enforcement, buffer the output and read the final governance action before displaying it or acting on it. Output is not enforceably governed before that terminal event.
• 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