Changelog

Durable Platform Foundation (Milestone 1)

Replaced the development-only in-memory persistence layer with a production-grade PostgreSQL layer — new packages/database (Drizzle ORM + node-postgres), with a Postgres*Repository implementation for every repository interface the Runtime Engine depends on, selected at boot via PERSISTENCE_BACKEND=postgres (default in_memory, unchanged behavior). The Runtime Engine itself is unmodified: it still only ever holds a repository interface-typed reference, never anything Postgres/Drizzle/ SQL-specific — see packages/database/README.md for the full schema, migration, and Cloud SQL deployment guide. runtime_events/timeline keep their existing embedded-array shape for read/write parity; the same writes are additionally fanned out into a normalized audit_events table in one transaction, so a durable, queryable audit trail exists without any change to how the ~10 engines that emit RuntimeEvents already work.

Execution Profiles (Initiative 3)

Introduced ExecutionProfile — the canonical execution contract, kept permanently separate from RegisteredAgent (what may execute), ProviderConnection (whose credentials), and the Adapter Registry (how execution happens). A RegisteredAgent now references exactly one ExecutionProfile via execution_profile_id, which in turn carries adapter_id, provider_connection_id, model, and every inference/ timeout/retry parameter. ProviderConnection no longer carries default_model — that responsibility moved entirely to ExecutionProfile. The managed-execution resolution gate grew from 12 to 19 ordered steps to account for the new indirection. Agents registered with the pre-Initiative-3 shape (adapter_id + provider_connection_id, no execution_profile_id) are transparently migrated: the engine auto-creates and activates an ExecutionProfile on their behalf, so no existing integration breaks. See Execution Profiles.

Customer-Owned Model Credentials (Initiative 2)

Introduced ProviderConnection — a tenant-owned connection to an external model provider, kept permanently separate from RegisteredAgent (what may execute) and the Adapter Registry (how execution happens). Managed execution (POST /runtime/agents/{id}/execute) now requires both adapter_id and provider_connection_id, resolved through a strict gate; Giggle AI Innovation's own credentials are usable only for internal development/testing/demonstration and are structurally unreachable by any other tenant. New @giggle-ai/credential-store package (in-memory dev/test backend + Google Secret Manager production backend, using only system-generated opaque identifiers in secret names). See Provider Connections.

Developer Platform v1

Not a runtime control feature — a developer adoption layer around the existing platform:

• OpenAPI 3.1 specification (services/runtime-control-engine/openapi/openapi.yaml)
• Interactive API docs at GET /docs, machine-readable spec at GET /openapi.json
• This Developer Portal
• GET /health, GET /ready, GET /version + matching SDK methods
• Structured JSON request logging with explicit redaction rules
• Correlation IDs (X-Correlation-ID) propagated through requests, logs, and errors
• Lightweight tenant awareness (X-Tenant-ID) — an architectural placeholder, not a security boundary (see Security)
• Centralized configuration module + .env.example
• examples/quickstart-external-agent — a runnable end-to-end quickstart
• examples/reference-integrations — three worked scenarios with distinct outcomes

External Agent Runs (Workstream 4)

Introduced the Agent Run architecture: a Runtime Session can own multiple Agent Runs over its lifetime (one per attempt, one more per retry), each producing its own immutable Decision Context Record. POST /runtime/agent-runs opened the platform to third-party agents — the engine evaluates and governs externally-executed output without ever running the agent itself. Multi-run session replay (GET /runtime/sessions/{id}/replay) merges every run into one chronological view.

Runtime Metrics (Workstream 3)

GET /runtime/metrics — operational metrics computed fresh on every request from existing session/decision/policy state: summary counts, per-agent and per-workflow breakdowns, per-policy hit rates, and a recent intervention feed.

Agent Registry (Workstream 2)

Introduced RegisteredAgent and its lifecycle (draft → active → suspended/deprecated). Every Runtime Session now validates its agent against the registry before running — an unregistered, non-active, or disallowed-task agent is rejected before any clinical context is touched.

Runtime Sessions (v0.2)

Introduced the Runtime Session as a long-lived control-plane object wrapping the original v0.1 request/response pipeline: execution states, the Decision Controller, configurable data-defined policies (replacing v0.1's hard-coded rule functions), and single-run Decision Replay.