Architecture

This page describes Keel’s architecture at the public product boundary. It is about runtime responsibilities, execution ownership, and evidence flow, not internal stage names or service wiring.

For the quick route chooser, use Overview. For public claims and non-claims, use Product Boundary.

An AI Permit is the pre-execution decision record Keel makes for a request submitted through a supported Keel decision surface. It may allow, deny, throttle or require review. Only allow authorizes execution.

Keel has one standard execution model: it evaluates authorization and enforces the resulting decision before consequential downstream execution or dispatch. Different route families provide different request shapes and evidence, not alternative standard models.

Execution and integration details

How Keel Executes Authorized Actions is the authoritative explanation of authorization, dispatch, API request formats, and caller responsibilities. It covers the standard execution model, decision-only requests, supported operations, and what Keel can observe.

Evidence path

AI Permit issuance and supported execution routes start with an AI Permit. Dry-run evaluation does not issue or persist one. Downstream records differ by route:

• advanced external-enforcement integrations can attach usage closeout and verification material after the caller-owned provider request completes
• synchronous Keel execution routes attach routing, provider response metadata, usage, timing, and terminal status to the request record
• async jobs persist job state separately while reusing the same governance and execution evidence path
• request timeline replay reconstructs the lifecycle from persisted records rather than from transient logs

For the event-level lifecycle, use Request Lifecycle and Execution Lifecycle.

Trust boundaries

The public runtime model has a few important boundaries:

• project is the primary tenancy boundary for public runtime requests
• Keel execution routes use project-scoped provider credentials held server-side
• advanced external-enforcement integrations keep provider credentials and provider transport in the caller’s application
• routing is explicit and recorded; it is not a claim of autonomous provider selection across every provider and route
• replay, content inspection, and integrity guarantees are route-specific

For exact commitments, use API Guarantees, Route Guarantees, and Scope and Limits.

Next reading

• Quickstart
• How Keel Executes Authorized Actions
• Permits
• Executions
• Execute
• API Reference
• Security
• Observability