Changelog

Consequential Agent Runtime Control and domain packs (breaking)

CARC is now the Consequential Agent Runtime Control platform. The core is domain-neutral, and healthcare is one domain pack among several. This is a deliberate breaking change to the API, SDK, and database schema; there are no deprecated aliases.

API and SDK

• Agents: clinical_domain is replaced by domain (a registered domain pack) and an optional subdomain. allowed_tasks must belong to the domain. SDK: clinicalDomain becomes domain and subdomain.
• Agent output: medication_recommendations is replaced by recommendations (each with a category, item, and optional value/unit), and discharge_instructions_present by required_sections (e.g. { discharge_instructions: true }). ClinicalClaim is now Claim, with an open claim_type. A malformed agent_output now returns a 400 listing every problem.
• Agent runs and managed execution: clinical_context is replaced by subject_context, plus an optional subject_type. SDK: clinicalContext becomes subjectContext.
• Cases: GET /runtime/cases returns generic cases (domain, subject_type, subject, summary) instead of patient and encounter_summary. Cases are now documented in the OpenAPI spec.
• New GET /runtime/domains (SDK: listDomains()), and SDK listCases().
• Roles and task types are open strings registered by domain packs. Core roles are requester, human_reviewer, and system. A request's role must be in the task type's allowed_roles.
• Policies gain condition_params, domain, and risk_weight. Condition types are now parameterized: recommendation_category_present, recommendation_value_above, claim_type_unsupported, required_section_missing, plus the unchanged unsupported_claim_present, risk_level_high, and critical_unsafe_recommendation. Every PolicyResult snapshots its condition_type and condition_params.
• Risk factors are named unsupported_claims, recommendation:<category>, and policy:<policy_id>.
• Metrics: medication_interventions is replaced by interventions_by_category; the intervention type medication_intervention by recommendation_intervention with a recommendation_category; workflows report their domain.
• Replay: clinical_context_snapshot is now subject_context_snapshot and includes the domain.
• Integration types clinical-agent, hospital-application, and medical-device-platform are now ai-agent, business-application, and device-platform.

Lending domain pack: a second installed domain with the loan_application_review task, four synthetic applicants, the loan-review-agent, and three policies (decline_requires_review, credit_limit_above_threshold_escalates, adverse_action_reasons_required). See Domain Packs.

Database: migration 0013_domain_packs applies the schema change. It refuses to run on a database that already holds runtime history, because Decision Context Records are immutable and are not rewritten. Policies and pack agents are now seeded by the engine at boot.

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.