Execution Authority

10-Second overview

Execution Authority governs how Context Layer executions are admitted, validated, and executed within the runtime boundary between applications and LLM providers.

Application
↓
Context Layer
Execution Authority Enforcement
↓
LLM Provider

Execution Authority determines whether execution is allowed.
Execution Authority constructs execution context.
Execution Authority verifies execution results.

Why execution authority exists

Without centralized enforcement, LLM systems face structural problems: execution rules vary across services, workflow ordering can be violated, provider misconfiguration can go undetected, runtime traces can be missing, and context construction can be inconsistent; Execution Authority resolves this by centralizing enforcement inside the Context Layer runtime boundary.

Authority Reports

Context Layer generates Authority Reports when Flow workflows terminate. They are not generated for Pulse mode.

Authority Reports provide traceable execution evidence. Reports are session-scoped and retrieved via the runtime API.

Per-step execution detail is available through Execution Receipts. See Execution Receipts.

Operational guarantees

Execution Authority enforces the following guarantees within the Context Layer runtime boundary.

Execution Mode Enforcement

Execution mode (Flow or Pulse) is bound to the API key at creation and cannot change during execution.

Session Lifecycle Enforcement

Context Layer creates, validates, and terminates sessions according to execution mode rules. Flow enforces one session per workflow run and requires explicit termination.

Context Construction

Given identical inputs and policies, context assembly is consistent and reproducible. Execution behavior remains consistent under identical conditions.

Provider Invocation Boundary Enforcement

Execution requests remain inside the runtime boundary and are subject to boundary enforcement policies.

Invocation Verification

Context Layer validates provider responses against runtime constraints.

Flow mode and Pulse mode

Flow Mode

Flow mode executes structured workflows with sequential step ordering, one session per workflow run, explicit termination, and Authority Report generation on termination.

Pulse Mode

Pulse mode executes conversational requests with session-scoped context and no Authority Report generation.

Provider invocation

Applications do not call providers directly when Context Layer is used as the runtime boundary. Provider invocation is controlled by the Context Layer runtime.

Provider invocation follows runtime boundary enforcement and policy checks. Provider credentials are managed through the BYOK model. See BYOK for credential handling.