Execution Lifecycle

This page describes the high-level lifecycle shared by Keel-managed execution routes. It is about behavior and trust boundaries, not internal file layout, stage names, or service wiring.

The lifecycle is shared in intent, not identical in every transport detail. For the route matrix, see Platform Surfaces.

Shared lifecycle

Across Keel-managed execution routes, the public lifecycle has three customer-visible phases:

Evaluate — the project-scoped request is authenticated, normalized into a governed execution intent, and evaluated against supported controls (policy, budget, and route-bound checks).
Execute — when governance allows the request, Keel resolves the execution target (including any permitted fallback behavior) and dispatches. Denied requests do not reach the provider.
Record — Keel persists the route-appropriate accounting and governance evidence, normalizes the output, and returns the route-specific response or completes stream closeout.

That sequence is the right public mental model. It should not be read as a claim that every route uses the same internal implementation or identical transport behavior.

Governance before dispatch

On Keel-managed execution routes, governance happens before the provider call. That includes the documented decision boundary plus any supported budget, routing, and route-bound checks.

Important boundary:

if a request is denied on a Keel-managed execution route, it does not reach the provider
if a request is allowed, the later execution and accounting records stay tied to that governed decision

Supported constraints can also narrow outbound request behavior before dispatch. Public docs should treat that as a governance outcome, not as a promise about internal field-level mechanics.

Routing and execution handoff

Keel resolves the selected provider-model target for the execution route being used. Where fallback is supported and allowed, the later execution path stays bound to the governed routing decision for that request.

What remains route-specific:

the request and response shape
whether the route is provider-neutral, provider-shaped, or provider-native
replay and idempotency semantics
streaming transport behavior
async job wrapping and callback behavior

Dispatch and reconcile

After an allowed dispatch, Keel normalizes the result into the route’s public contract. That includes output, usage, and final routing/result metadata where the route documents them.

The shared public guarantee is not that every route returns the same payload. The guarantee is that governed execution routes apply the documented checks before dispatch and then persist route-appropriate execution and accounting records afterward.

Ledger and terminal accounting

Terminal accounting is the durable boundary for usage and cost closeout. Keel aims to persist terminal execution and accounting state even when later closeout work is interrupted.

That is a durability goal, not a claim of perfect precision on every path. If the provider does not emit final usage, or a request is interrupted after partial output, some records can remain estimated-final rather than exact.

Lifecycle persistence and replay

Governed execution surfaces persist route-appropriate lifecycle and governance records for later readback, audit, and timeline views.

Public takeaway:

timeline and audit views are assembled from persisted records
those records are part of the public trust boundary
they should not be read as proof that every route shares identical internals

Streaming caveats

Streaming should be read more narrowly than sync execution.

public streaming coverage is narrower than total sync coverage
stream transport and closeout behavior can vary by route family
the shared guarantee is governed dispatch plus route-appropriate persistence, not one universal streaming implementation

What this page does not claim

This page does not claim:

that all public routes use identical internals
that streaming behavior is unified across every route
that every provider and operation has the same coverage
that every terminal accounting record is exact under interruption paths