Architecture

The object model

Clinical Case
  |
  Runtime Session
    |
    +-- Agent Run #1
    |       |
    |       +-- Decision Context Record #1
    |
    +-- Agent Run #2 (retry)
    |       |
    |       +-- Decision Context Record #2
    |
    Decision Replay (reconstructs the whole session from every run)

• A Runtime Session represents one controlled clinical workflow (e.g. "draft a discharge summary for this patient"). It is long-lived and is the object you poll and act on (pause, approve, reject, retry) while work is happening.
• A Runtime Session owns one or more Agent Runs over its lifetime. The first attempt is Agent Run #1. A retry creates a new Agent Run — #2, #3, and so on. A retry never mutates a prior run.
• Each Agent Run produces exactly one immutable Decision Context Record — the input hash, retrieved sources, agent output, evidence/ policy/risk results, and the human review outcome if any. The previous run's record is never edited.
• Decision Replay reconstructs the entire session by merging every run's events and Decision Context Record into one chronological timeline, clearly labeling which step belongs to which run.

This separation is what makes replay trustworthy: because a retry can never touch a prior run's record, replaying an old run always shows exactly what that run actually produced — never data from a later attempt.

Runtime Control Engine modules

Module	Responsibility
Agent Registry	Which agents exist, what they're allowed to do, and whether they're currently trusted to run
Runtime Session Engine	The v0.2+ control-plane state machine — session lifecycle, pause/resume/cancel/approve/reject/retry
Agent Run Engine	Validates and records internal and external Agent Run submissions
Runtime Engine	The evidence → policy → risk → disposition pipeline every Agent Run goes through
Evidence Engine	Deterministically checks whether every claim cites a real retrieved source
Policy Engine	Evaluates configurable, data-defined deterministic rules
Risk Engine	Computes a runtime risk score from evidence + policy results
Decision Controller	Selects the control action (allow / pause / require review / block / retry / finalize) from policy + risk output
Decision Record Repository	Stores immutable Decision Context Records
Runtime Metrics Service	Computes operational metrics fresh on every request — nothing is cached or separately persisted

Where the SDK, Console, and Developer Portal fit

                      ┌─────────────────────────┐
                      │  Runtime Control Engine  │  ← the only source of truth
                      │  (this API)              │
                      └───────────┬─────────────┘
                                  │ HTTP
          ┌───────────────────────┼───────────────────────┐
          │                       │                        │
 ┌────────▼────────┐   ┌──────────▼─────────┐   ┌──────────▼─────────┐
 │ Runtime SDK      │   │ Web Control Console │   │ Developer Portal    │
 │ (typed client)   │   │ (operations UI)     │   │ (this site — docs)  │
 └──────────────────┘   └─────────────────────┘   └─────────────────────┘

None of the SDK, Control Console, or this Developer Portal contain any runtime control logic — they are all thin clients of the same HTTP API. The Control Console is for operating the platform (reviewing sessions, approving/rejecting, watching metrics); this portal is for integrating with and evaluating the platform. See Integration Patterns.

Next

• Core Concepts — the same objects explained one at a time, in depth
• Quickstart — see the whole lifecycle run end to end