Skip to Content
Product Boundary

Product Boundary

This page defines the boundary of the public Keel product: which surfaces are documented, what Keel owns on those surfaces, and which claims are intentionally route-specific.

For the faster product mental model and route chooser, start with Overview. For the problem Keel solves and when to adopt it, read Why Keel.

What Keel owns

  • returns an AI Permit decision record when you use POST /v1/permits
  • executes governed requests when you use /v1/execute, /v1/executions, or /v1/proxy/*
  • enforces supported policy, budget, routing, and retry controls on the documented public routes
  • records AI Permits, executions, usage, jobs, and related evidence on documented readback surfaces
  • uses project-scoped provider credentials on Keel-managed execution routes

What Keel is not

  • not a model host
  • not an autonomous routing system
  • not just a proxy, wrapper, or logging layer

Active public surface

Keel’s documented public surface falls into four groups:

  • decision and audit routes such as POST /v1/permits and AI Permit readback
  • governed execution routes: primary POST /v1/execute, provider-neutral POST /v1/executions, and provider-native POST /v1/proxy/*
  • async lifecycle routes such as POST /v1/jobs and GET /v1/jobs/{job_id}
  • project-scoped readback routes such as request timeline, governance events, and compliance exports

Use Public API Surface for the current endpoint index and exposure labels.

Scope of these docs

Keel public docs cover:

  • what Keel checks and records on the public runtime routes
  • which request shapes each public route family supports
  • what buyers and developers can rely on across the current beta surface
  • the important limits, non-claims, and plan gates that shape the current product boundary

Non-claims

  • fully autonomous provider choice across all routes and providers
  • universal Prompt Firewall coverage across every payload type and every provider
  • exact pre-dispatch pricing for every multimodal request shape
  • uniform replay or execution-binding guarantees across every public surface
  • cryptographic or externally verifiable guarantees for every record on every public surface
  • public support for undocumented, dashboard-only, or internal routes

Where to go next

Last updated on Edit this page on GitHub