Clinical trials, with AI under a human gate.
A multi-party platform for a regulated industry: sponsors, research organisations, sites, vendors and patients work from the same records through their own portals. AI drafts and cross-checks long technical documents, every consequential change passes a human approval, and everything lands in a tamper-evident audit trail anchored outside the system.
A real system, described without its names.
What it does.
The platform spans a trial's operations end to end: feasibility, the request-for-proposal and budget negotiation between parties with strict rules about who may see what, site start-up, data capture, monitoring, database lock and submission. Five AI roles sit on specific decisions: audit-readiness scoring, a supervisor that cross-checks other AI output, statistical design review, support triage and output verification. The rule for patients is never auto-exclude; a person decides.
Every consequential action, human or AI, is written by one audit writer into a hash chain and anchored weekly to a public ledger, with the actor recorded as user, agent or system. Forty-six scheduled jobs keep the data moving and repaired: outbox delivery and document generation every minute, a safety-clock scan every fifteen, and repair jobs whose names say what they are for.
Where a request-and-response stack breaks.
- 01A review that outlives a request
A three-pass review of a 245 KB protocol took 403 seconds against a 300-second serverless ceiling. Running two passes concurrently got it under the limit. That is a workaround for the runtime, not a property of the work.
- 02Cron standing in for a queue
Forty-six timers deliver an outbox, generate documents, scan safety clocks, reprocess stuck documents and catch up a mirror. None of them can say retry with backoff, once per document, or dead-letter after three attempts.
- 03One writer for the chain
A hash chain forks if two writers race, so the audit log has one writer under serializable isolation. Correct, and a bottleneck by design.
- 04A corpus the model can lie about
Cohort mining over a 597,000-row mirror where corpus-wide aggregates exceed a fifteen-second database timeout, and where any trial identifier the model invents must be stripped in code before it reaches a person.
The same problems, on two runtimes.
Python is a fine language and a poor runtime for this shape of work. Each point below names the piece of infrastructure a Python stack would add, and the runtime property that makes it unnecessary here.
PythonWhat you would have to build
- A request has a deadline; a review does not
Any request-and-response runtime, Python included, turns a 400-second chain of model calls into a problem to hide with concurrency tricks. On Z8 a review is a durable run: it takes the time it takes, survives a deploy, and replays exactly without calling the model again.
- Cron is not a queue
A Python stack would add Celery, Redis and a beat scheduler to express what forty-six timers cannot. Z8 says it in the job's declaration, retries, backoff, uniqueness, snooze, priorities, schedules, and records every transition in the same log as the domain.
- A gate that outlives its process
In a function or a Python worker, waiting for approval is a row and a poll. On Z8 it is a run parked in the log, resumed from the inbox with the answer, and visible on the dashboard while it waits.
- An audit chain as a primitive
Building a tamper-evident trail by hand means one writer, one isolation level and one place to get it wrong. Z8's chain is part of the runtime: SHA-256 blocks with Merkle proofs and a write-once mirror; anchoring outside becomes an ordinary scheduled job.
- Six kinds of participant on one dataset
Python frameworks scope rows by a column and hope. In Z8 the tenant is an axis of the runtime: provisioning, suspension and decommissioning are single calls, and cost is metered per scope.
Z8What the runtime already does
- Reviews as graph agents
Each pass a node, the adversarial refutation a branch, the join explicit: parallel where the current code had to force it, with no ceiling and an exact replay.
- One queue, named lanes
Outbox, generation, safety and sync as queues with retries, uniqueness and schedules, in place of forty-six timers and their repair jobs.
- Approval as a state
The human gate is a state in a durable agent, parked in the log; the never-auto-exclude rule becomes a transition that only a person can take.
- The chain, built in
The runtime's audit chain replaces the hand-built writer; the weekly external anchor is a scheduled job writing a Merkle root.
- Tenants by participant
Sponsor, research organisation, site, vendor, patient and investor as tenants with their own portals, scopes and budgets.
- The dashboard
Runs, the inbox of parked approvals, jobs, cost per scope and the compliance page: the visibility a regulated pilot spends months building by hand.
One log, everything around it.
Where it stands.
Blueprint
Blueprint. The platform is in pilot on a serverless request stack, with over five thousand commits in six months. This page describes its target architecture on Z8, not a system that runs today.
Counts on this page are taken from the code as it stood in September 2026: modules, workers, event types and tests, not usage or revenue, which we do not publish.
Does your system have this shape?
Many agents on one problem, work that must survive a deploy, a person in the loop, and a trail someone will inspect. Tell us what you are building.
henry@z8.run