Five surfaces.One governed execution boundary.
Keon separates cognition, ingress, execution, truth, and operator visibility into five platform surfaces with strict responsibilities. Platform surfaces are mapped by responsibility, not by sequential pipeline. AI systems can act only through governed authorization.
Branching cognition, adversarial challenge, and execution candidate generation.
Authorization or execution.
Decisions need temporal branching, multi-agent synthesis, and internal challenge before governed action.
Pre-execution authorization, deterministic policy evaluation, governed execution, and receipt emission.
Cognition, memory preservation, or operator visibility.
Any consequential action must be authorized and receipted before effect.
Canonical memory, receipt preservation, lineage, and replayable reconstruction evidence.
Authorization or execution decisions.
Decisions must be provable, reconstructable, and auditable under governed review.
Operator observation, state and receipt visibility, lineage access, and governed action initiation.
Authorization. Governed actions route through Runtime.
Operators need a governed cockpit for state visibility and action initiation.
Tool ingress governance, tenant and actor identity binding, ingress policy enforcement, and governed envelope preservation.
Authorization. Routes into Runtime, which remains the Decide-before-Execute authority.
MCP-capable agents or external tool calls need governed ingress before reaching the execution boundary.
How responsibilities meet.
Surfaces connect through governed message. No request passes through all surfaces by default.
Adopt by boundary, not by bundle.
The system can enter through execution or governed ingress. The execution boundary remains mandatory for effects. No deployment requires all five surfaces.
Govern effect-bound actions. The execution boundary is the foundation of every deployment.
Explore Runtime →Govern MCP-native agents and external tool calls with low client adoption friction. Routes governed tool calls into Runtime.
Explore MCP Gateway →Preserve causal memory, lineage, and reconstructable evidence. Required for provable, auditable deployments.
Explore Cortex →Add group intelligence, Temporal Echo planning, adversarial challenge, and synthesis before Runtime.
Cortex is optimized for Collective. Its memory model preserves branch lineage and reconstructable history.
Explore Collective →Give operators a governed cockpit for state, receipts, lineage visibility, and governed action initiation.
Explore Control →Built for zero-trust systems.
Keon operates as a federated, tenant-bound system. Requests entering the governed boundary are attributed, inspected, and routed through policy-bound execution.
MCP Gateway brings external tool calls to the governed execution boundary.
MCP Gateway binds tenant and actor identity, enforces ingress policy and scopes, preserves structured governed envelopes, and routes calls into Runtime. Runtime remains the Decide-before-Execute authority.
MCP-capable agents and OpenClaw-style exposed agents enter through the governed ingress boundary.
MCP Gateway is an integration surface into Runtime. Runtime holds the Decide-before-Execute authority. Gateway does not replace it.
Explore MCP Gateway →Mapped to CAES primitives.
Deterministic policy evaluation
Pre-execution authorization receipts
Fail-closed enforcement
Append-only causal records
Offline-verifiable evidence
Reference alignment only. No external certification or blanket conformance claim is implied.
Map only. No layer compression.
Map the five Keon platform surfaces by strict responsibility.
What responsibility does each platform surface own?