Route Guarantees

For each public surface, this page states exactly what Keel guarantees. If a guarantee is not listed here for a route, Keel does not claim it.

For stability commitments (GA / Beta / Internal), see Surface Maturity.

Runtime API vs Management API

Keel’s public HTTP surface is split into two tiers with different stability commitments:

Runtime API — project-API-key authenticated, SDK-covered, stable contract. Execution, permits, lifecycle, governance reads, compliance exports, and the public status summary. All client-api-key rows below are Runtime API.
Management API — user-JWT authenticated, dashboard-driven. Policy authoring, project CRUD, provider-key CRUD, billing. All user-jwt rows below are Management API. The per-route guarantees (auth, RLS, chain events, signed export coverage) hold for these routes, but the request and response shapes may change alongside dashboard UI evolution. Scripting against them is possible, but carries more change risk than the Runtime API — and management routes are not wrapped by the SDKs.

Label	Meaning
Auth	Required credential type. `client-api-key` = tenant project API key (some routes require admin scope); `user-jwt` = authenticated dashboard user JWT; `public` = unauthenticated
Policy evaluated	The route runs policy evaluation over the resolved policy document and decides allow / deny / constrain / throttle
Permit required	The route produces a `Permit` row that is hash-chained, replayable, and covered by signed exports
Constraint clamp	Permit-declared constraints (e.g. `max_output_tokens`) are enforced on the outbound provider payload before dispatch
Chain event	Emits a governance event that is appended to the per-project hash chain
RLS	Database reads/writes enforce tenant isolation at the database layer for this route
Signed export	Data read or produced by this route is covered by Ed25519-signed compliance exports

Route	Auth	Policy evaluated	Permit required	Constraint clamp	Chain event	RLS	Signed export
`POST /v1/executions`	client-api-key	✅	✅	✅	✅	✅	✅
`POST /v1/execute`	client-api-key	✅	✅	✅	✅	✅	✅
`POST /v1/proxy/openai/*`	client-api-key	✅	✅	✅	✅	✅	✅
`POST /v1/proxy/anthropic/*`	client-api-key	✅	✅	✅	✅	✅	✅
`POST /v1/proxy/google/*`	client-api-key	✅	✅	✅	✅	✅	✅
`POST /v1/proxy/meta/*`	client-api-key	✅	✅	✅	✅	✅	✅
`POST /v1/proxy/xai/*`	client-api-key	✅	✅	✅	✅	✅	✅
`POST /v1/permits`	client-api-key	✅	✅	n/a (no dispatch)	✅	✅	✅
`POST /v1/permits/dry-run`	client-api-key	✅	❌ (no persistence)	n/a	❌	✅	n/a
`POST /v1/permits/{id}/usage`	client-api-key (admin scope)	❌	n/a (permit already issued)	n/a	✅ (usage.reported)	✅	✅
`POST /v1/jobs`	client-api-key	✅	✅	✅	✅	✅	✅

Notes:

Every execution surface enforces constraint clamping before provider dispatch.
Every execution surface persists a Permit whose hash chains into the per-project governance chain. Chain snapshots are periodically published to external storage (Business+).
dry-run evaluates policy without persisting. It produces no permit, no chain event, and is not replayable.

Route	Auth	Policy evaluated	Permit required	Constraint clamp	Chain event	RLS	Signed export
`GET /v1/permits`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/permits/{id}`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/permits/{id}/bundle`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/permits/{id}/lineage`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/permits/{id}/usage`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/permits/export`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/jobs/{id}`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/requests/{id}/timeline`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/governance/events`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/governance/events/{id}`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/governance/events/stream`	client-api-key	❌	n/a	n/a	❌	✅	n/a (live feed)

Route	Auth	Policy evaluated	Permit required	Constraint clamp	Chain event	RLS	Signed export
`POST /v1/compliance/exports`	client-api-key	❌	n/a	n/a	✅ (export.created)	✅	✅ (this IS a signed export)
`GET /v1/compliance/exports`	client-api-key	❌	n/a	n/a	❌	✅	✅
`GET /v1/compliance/exports/{id}`	client-api-key	❌	n/a	n/a	❌	✅	✅

Signed exports carry an Ed25519 signature and manifest covering the export’s content hash. See Signed Exports for verification steps.

Route	Auth	Policy evaluated	Permit required	Constraint clamp	Chain event	RLS	Signed export
`POST /v1/policies`	user-jwt	❌	n/a	n/a	✅ (policy.created)	✅	✅
`GET /v1/policies`	user-jwt	❌	n/a	n/a	❌	✅	✅
`PATCH /v1/policies/{id}`	user-jwt	❌	n/a	n/a	✅ (policy.updated)	✅	✅
`DELETE /v1/policies/{id}`	user-jwt	❌	n/a	n/a	✅ (policy.deleted)	✅	✅
`PATCH /v1/projects/{id}/policy`	user-jwt	❌	n/a	n/a	✅ (policy.overrides_updated)	✅	✅
`GET /v1/policy-templates`	public	❌	n/a	n/a	❌	n/a	n/a
`GET /v1/policy-templates/{id}`	public	❌	n/a	n/a	❌	n/a	n/a

Policy mutations emit hash-chained events so replay can reconstruct what policy was in effect at any decision time.

Route	Auth	Notes
`GET /v1/public/status/summary`	public	Readiness and coarse provider-status for the documented subset; no tenant data. Safe for uptime integrations.

Output content. Keel governs the decision to call a provider and the request envelope. Once the provider responds, Keel records and reconciles; it does not filter, rewrite, or attest provider output beyond usage accounting.
Provider availability. Keel’s health signals inform routing but Keel does not guarantee third-party provider uptime.
Real-time replay. Replay is a historical reconstruction tool. Live streams (/v1/governance/events/stream) are best-effort feeds, not a replay substitute.
Sub-project isolation. Tenant isolation is enforced at the project boundary. Per-user or per-team isolation inside a project is a customer concern, addressable through context-based policy conditions.

Surface Maturity — which routes are GA, Beta, or Internal
Trust & Integrity — the four-layer integrity stack behind the chain events and signed exports
Signed Exports — how to verify a delivered export
Permits — the permit-first governance model