28 questions across 6 categories — written for sponsors, executives, inspectors, and new employees. Click any question to expand.
It is an "OS of agents" sitting over commodity clinical trial systems (EDC, eTMF, safety, regulatory). Specialized AI agents draft, review, and propose regulated actions; signed humans approve and promote those actions to live records. Every action is provenance-tracked end to end so an inspector can replay any decision months later.
Studies are seeded through the integrations layer: the L0 connectors pull protocol, sites, and roles from the source system (CTMS or sponsor handoff), an authoring agent drafts the essential-documents checklist, and a human signs off on the study activation packet. Until that signature is captured, the study sits in staging and does not appear on live operational consoles.
Costs are dominated by AI token spend and Supabase compute. The Costs page breaks usage down by agent, study, and model so finance can attribute spend back to a sponsor or program. Each agent has a configurable cost cap that halts further model calls and surfaces a notification when exceeded.
See also: Cost analytics
An agent (or a human) writes a proposed change to a staging table. A reviewer with the required role opens the staging record, reviews the diff against the current live row, re-authenticates with MFA, declares signing intent, and approves. The orchestrator atomically promotes the staging row to live, writes the signature row, and emits a provenance event. Anything that fails at any step is left in staging with the error captured.
See also: Staging
For sponsors and external users, file the issue through the sponsor portal so it lands in the request inbox with the correct study attribution. Internal staff open an issue in the GitHub repository following the team's issue template. Anything that touches a regulated path is triaged through the change-control workflow before any code lands.
See also: Sponsor portal
No. A 21 CFR Part 11 signature is a personal act tied to a real, authenticated human with re-authentication and explicit intent. The platform architecturally rejects any write path that lets an agent insert a signature row. This invariant is enforced in packages/policy and re-checked at the orchestrator boundary.
See also: Compliance dashboard, Signatures
Yes. Every regulated action passes through a Part 11 e-signature gate: the user re-authenticates, declares intent, and an immutable signature row is written. Audit trails are ALCOA+ (Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available). The Compliance dashboard surfaces real-time conformance evidence the FDA expects to see.
See also: Compliance dashboard, Validation evidence
The signing flow has three parts: (1) re-authentication with Supabase Auth plus TOTP MFA so the identity is fresh, (2) an explicit intent declaration where the signer types or selects the meaning of the signature ("I approve", "I reviewed"), and (3) an immutable signature row written to the cro.signature table with a foreign key to the underlying record, the user, and a provenance event. Signature rows are append-only and never modified.
See also: Recent signatures
ALCOA+ is the FDA-recognized standard for data integrity in regulated records: Attributable, Legible, Contemporaneous, Original, Accurate — plus Complete, Consistent, Enduring, and Available. Every regulated row on this platform carries the fields needed to demonstrate each property (created_by, created_at, provenance_id, an immutable audit trail). If you cannot defend ALCOA+, you cannot defend the trial.
See also: Glossary — ALCOA+
Every regulated write generates a provenance event with the actor, timestamp, before/after state, and the agent or human who initiated it. The Provenance section exposes a searchable view; the Inspection page bundles a full evidence binder for any time window. Audit rows are append-only and exported on demand in formats the FDA accepts.
See also: Provenance search, Inspection package
Yes. The Inspection page assembles a date-range evidence binder containing the provenance events, signature rows, system metadata, and validation artifacts an inspector typically asks for. Exports are PDF for human review and JSON for machine review, both with cryptographic checksums so the binder cannot be altered after export.
See also: Inspection package
Serious Adverse Event reporting follows the ICH timelines: 24 hours for life-threatening or fatal events, 7 calendar days for the initial expedited report, and 15 calendar days for follow-up reports. The platform tracks the clock from the moment the SAE enters staging and surfaces a countdown on the Risk register; missed deadlines escalate to the responsible medical monitor.
See also: Risk register
No. The causality assessment for any adverse event is a medical judgment made by a qualified human (typically the investigator or medical monitor). The platform architecturally prevents an agent from writing a causality value — packages/policy rejects any staging row that fills the causality field from an agent-initiated provenance event. Agents may summarize or surface relevant context; humans decide.
See also: Compliance dashboard
An agent is a narrowly scoped Claude-powered worker (for example, the Essential Documents agent or the Audit Trail agent) that proposes work in a specific regulated domain. Each agent has a dossier, a fixed model assignment, a citation grounding requirement, and a registered prompt version. Agents never write directly to systems of record — they write to staging, where a human reviews and signs.
See also: Agents catalog, Model registry
A0 is fully manual: the human does the task end-to-end and the agent is not involved. A2 is "supervised agentic": the agent proposes an action and writes it to staging, and a signed human review (re-auth + intent + Part 11 signature) is required before promotion to live. A2 is the default class for any regulated work on this platform. A4 (fully autonomous regulated action) is prohibited by policy.
See also: Glossary — autonomy classes
Because agents write only to staging, a failure cannot corrupt live data. Failed proposals stay in staging marked as errored, the orchestrator records the exception in the provenance event log, and the on-call human sees it on the Staging review queue. No automatic retry escalates beyond the configured policy; nothing promotes itself.
See also: Staging review queue, Operational health
Authoring agents are required to ground every factual claim in a citation drawn from the source corpus; the shared citations library rejects outputs whose claims do not resolve to a cited span. Ungrounded drafts never reach staging. On top of that, every agent output is reviewed by a human before promotion, and the evaluation harness runs golden-case suites against each agent to catch regressions before deployment.
See also: Validation
Claude Sonnet 4.7 is the default model for routine agents; Opus 4.7 is reserved for high-stakes work where reasoning quality dominates cost. Every agent has a pinned model ID stored in the model registry, and any prompt change requires a registry version bump enforced by CI. The Models page shows the full registry including history.
See also: Model registry
Every agent ships with a credibility dossier (intended use, training data, known limitations) and a promptfoo golden-case suite of at least ten cases that must pass before any other agent references it. Validation evidence is versioned, reproducible, and surfaced on the Validation page. Changes to an agent reset the validation gate and require a fresh run.
See also: Validation
The evaluation suite includes adversarial cases that probe known failure modes — demographic shortcuts, source bias, recency bias, sycophancy — and an agent cannot ship if its scores fall below the registered threshold. Citation grounding is a structural defense too: every claim must resolve to a cited span, which limits the agent's ability to invent. Humans remain in the loop on every regulated promotion.
See also: Validation
The Models page lists every pinned model ID, the agents that use it, and the full version history of the prompts assigned to each agent. Every prompt change requires a new registry row; CI fails any PR that diffs a prompt without bumping the registry. The history is the authoritative record an inspector asks for when they want to know which prompt produced which signed action.
See also: Models
Yes. Supabase Postgres storage is encrypted at rest using AES-256, with TLS 1.2+ in transit. Row-level security is deny-by-default on cro.* tables, and access requires an authenticated session plus role membership. Backups are encrypted with the same key management policy as the primary store.
#patient-data-encrypted-at-rest
Yes. Row-level security policies on every cro.* table scope access to the sponsor, study, and role the user is assigned. A sponsor on Study A cannot read a single row from Study B even if both live in the same Postgres database. Agent service identities are scoped the same way; an agent invoked for Study A cannot reach Study B context.
Only a human with the appropriate role on the study (for example, a Clinical Lead approving an essential-documents promotion, or a Safety Reviewer approving an SAE update) and an active Part 11 session. The role-to-action mapping lives in packages/policy and is validated at the orchestrator boundary. Service accounts and agents are never granted promotion rights.
See also: Staging
Supabase Postgres runs point-in-time recovery with daily encrypted snapshots and a documented restore drill. Regulated artifacts (signature rows, provenance events, validation evidence) are additionally exported to immutable object storage on a recurring schedule so a full Postgres loss would not destroy the audit trail. Restore objectives, owners, and last-tested dates are tracked on the operational Health page.
See also: Operational health
Yes. The sponsor portal at /portal streams the same provenance events that drive internal consoles, scoped to the studies the sponsor is permitted to see. Updates land as soon as the underlying records change, with the same audit lineage exposed downstream. Sponsors can request specific reports or evidence through the inbox and get notified when a human signs the response.
See also: Sponsor portal
Routine sponsor requests have a 2-business-day target for first response; expedited requests (regulatory holds, safety queries) target 4 hours. SLA timers start when the request enters the inbox and pause only when waiting on the sponsor. The portal shows the live timer and the responsible owner on every request.
See also: Sponsor portal
Yes. The L0 integration layer (services/integrations) hosts connectors per system of record — EDC, CTMS, eTMF, safety database, regulatory submissions. Each connector normalizes data into the platform's canonical schema and runs through the same provenance and staging pipeline as any other writer. Adding a new EDC is a connector PR, not a platform change.