Mission Control Kernel

Target architecture — not the current operating contract

This page preserves product direction. For available behavior and procedures, see the current release.

The current kernel separates bounded human Organization/Team roles from catalog ∩ Team allowance ∩ virtual-key inference policy, canonical per-attempt accounting and Team-scoped observability. It does not expose a Mission Control Run resource; W3C Trace context correlates requests and optional namespace-scoped Session IDs group Team activity.

The Control Kernel is the mandatory control and evidence foundation for every enabled module, registered runtime, and governed execution. It owns durable control metadata and exposes versioned contracts; it does not own application-specific business logic or runtime execution.

Ownership

Kernel component	Owned responsibility
Identity and Access	Customer SSO mapping, human roles, workload identities, service credentials, environment scopes, and least-privilege capability grants
Resource Registry	Canonical inventory of agents, agent teams, deployments, model resources, MCP servers and tools, workflows, applications, retrieval resources, policies, routes, and evaluations
Lifecycle and Provenance	Drafting, review, promotion, production activation, suspension, retirement, immutable versions, artifacts, attestations, attribution, and rollback events
Policy and Authority	Contextual policy evaluation across principal, resource, operation, environment, risk, history, data classification, and connector classification
Approvals and Decisions	Durable approval requests, task routing, delegation, escalation, expiry, rationale, separation of duties, re-evaluation, and idempotent resumption
Evidence and Audit	Append-only links among identities, versions, configuration, policy, approval, execution, trace, evaluation, incident, correction, and outcome records
Observability and Evaluation	Health, latency, failures, token and cost attribution, evaluation results, business outcomes, cohorts, and portfolio reporting
Platform Configuration	Environments, retention, redaction, gateway settings, enabled modules, customer operating controls, and reference configuration

The shared resource and evidence model is the data contract across these components. A module may add typed fields for its domain, but it may not redefine resource identity, lifecycle, authority, lineage, or retention semantics.

Standard control questions

Every governed operation must make six answers reconstructable:

1. Who is acting: which human or workload principal, customer, environment, and delegated authority?
2. What is involved: which registered resource and immutable version?
3. What is requested: which typed capability, target, arguments, and business-context references?
4. What governs it: which access grant, policy bundle, decision, reason, and approval?
5. What executed: which runtime, model deployment or connector version, timing, status, usage, and cost?
6. What remains: which evidence, evaluation, correction, incident, and business outcome references?

An operation that cannot answer the applicable questions is blocked or explicitly treated as ungoverned; absence of evidence is not interpreted as permission.

Lifecycle

Definitions use the shared states draft, in_review, approved, active, suspended, and retired.

stateDiagram-v2
    [*] --> draft
    draft --> in_review: submit
    in_review --> draft: request changes
    in_review --> approved: approve
    approved --> active: promote
    active --> suspended: suspend
    suspended --> active: reactivate approved version
    active --> retired: retire
    suspended --> retired: retire

• draft can change and cannot serve production traffic.
• in_review is frozen for the submitted review; revisions return to draft.
• approved is an immutable version authorized for a stated scope but not necessarily active.
• active is the approved version selected for an environment.
• suspended cannot begin new work; in-flight handling follows the resource's declared safe-cancellation policy.
• retired is retained for history and cannot be reactivated without publishing a new approved version.

A rollback activates an earlier approved immutable version and appends an attributed lifecycle event. It does not mutate the failed version or erase the deployment and execution history around it.

Kernel interfaces

The kernel provides versioned interfaces for:

• Resource registration, lookup, version publication, ownership, environment scope, and lifecycle transitions.
• Human and workload identity resolution plus short-lived, least-privilege grants.
• Capability authorization and contextual policy evaluation returning exactly allow, deny, or approval_required.
• Durable approval creation, decision recording, current-policy re-evaluation, and idempotent resumption authorization.
• Target shared Run, Trace, event, evidence, evaluation, incident, cost, and outcome correlation. The current release implements Trace/request evidence and optional Session grouping only.
• Environment, retention, redaction, enabled-module, and gateway configuration.

Gateways and runtimes consume these interfaces. The kernel does not proxy business payloads simply to observe them; the gateways enforce execution and emit the minimum evidence needed by the kernel-owned contracts.

Explicit boundaries

The kernel does not:

• Execute agent reasoning loops or own reasoning-session state.
• Schedule or own durable Workflow state.
• Perform model inference or resolve provider credentials in a client runtime.
• Establish MCP transport or invoke a connector.
• Index enterprise content or become its authoritative catalog.
• Render or host arbitrary application logic.
• Replace customer SSO, secret management, CI/CD, business systems, or provider control planes.

These boundaries keep the kernel mandatory without making it a monolith. Modules remain composable, while identity, authority, lifecycle, and evidence remain singular.

Current governance mapping

The current source release uses Organizations, Teams, real user/service-account virtual keys and separate human management roles. Agent is managed application content; deployments own secretless execution access and publisher funding. Observe uses Requests, Traces, Sessions and Usage with separate metadata/content/export permissions. Historical identity terms in this target proposal are not the operating contract. See Current release.