Technology
AI where language is the input. Deterministic engines everywhere else.
The interesting engineering problem in clinical data is not generating text. It is deciding precisely where a language model is allowed to act, and what happens to its output before that output becomes a clinical number.
Design principles
Four rules the architecture is built around.
AI assists with interpretation
Generative AI is used where language is the input — reading protocols, drafting specifications, structuring ambiguous source material.
Deterministic engines execute
Specifications are executed by deterministic engines. Clinical outputs are produced by defined processing, not by a language model.
Humans approve
Reviewers see drafts, corrections, and QC results, and are the ones who approve a study design or a deliverable.
Everything is traceable
Outputs connect back to the specification and the source record behind them, with an append-only audit log.
Architecture
Two pipelines, one set of rules.
FlashEDC
Protocol → EDC & Data Capture- 01
Protocol
The sponsor protocol and any amendments.
- 02
Document processing
Text, tables, and structure extracted from the source document.
- 03
Routed AI pipeline
Each part of the document routed to a prompt suited to that content.
- 04
Deterministic code generation
Specifications turned into study-builder code by defined processing.
- 05
Second-eye QC
Adversarial review of the generated design.
- 06
Human review
A study builder corrects and approves.
- 07
EDC study design
Exportable design for the EDC environment.
- 08
Data capture
Sites and subjects enter data into the EDC study built from the reviewed design.
FlashAnalysis
Data → Submission- 01
Clinical data
Collected data admitted under a provenance policy.
- 02
Provenance policy
Real and synthetic data governed explicitly, not by convention.
- 03
Deterministic SDTM
Standards transformation executed, not generated.
- 04
ADaM
Analysis-ready datasets with recorded derivations.
- 05
TLFs
Tables, listings, and figures produced from specifications.
- 06
Independent QC
The computation re-implemented and compared.
- 07
Cross-artifact QC
Datasets, specifications, and outputs checked against each other.
- 08
Submission
Define-XML, aCRF, cSDRG, ADRG, and the eCTD-lite package.
- 09
Audit & lineage
Append-only logging; outputs traceable to source.
Technical concepts
How the AI layer is kept on a leash.
Six-pass AI pipeline
Protocol interpretation is decomposed into passes rather than one prompt, so each pass has a bounded job and a reviewable output.
Routed prompting
Different parts of a document are routed to prompts suited to that content instead of being sent through a single generic path.
Human review checkpoints
The pipeline stops at defined points where a person reviews and corrects before downstream work builds on the result.
Editable outputs
Generated artifacts are working documents. Corrections are made in the artifact, not by re-running and hoping for a better answer.
Background jobs
Long analyses run as jobs with progress, cancellation, and resume, because protocol analysis is not an instant operation.
Provider-swappable AI
The model layer is separable from the pipeline, so the provider behind a given pass can change without redesigning the workflow.
Second-eye QC
A separate adversarial pass reviews generated work for defects and escalates what it cannot safely resolve.
Deterministic execution
Everything downstream of a specification is executable, repeatable processing with a recorded result.
What this is not
Automating clinical work means accepting limits on the automation.
A model that can write anything can also invent a value, a visit, or a derivation that no protocol called for. So the model is never the component producing the contents of a clinical dataset.
Everything downstream of a specification is deterministic processing with a recorded result. Specifications are generated, reviewed, corrected, and approved — and only then executed.
The same principle governs the model layer itself: because it is separable from the pipeline, the provider behind a given pass can change without redesigning the workflow. That is a design property, not a claim about any specific vendor.
We do not describe these systems as autonomous, and we do not describe outcomes we have not documented.
Next step
Ask us the hard questions about the architecture.
If you are evaluating the technology rather than the pitch, we would rather have that conversation early.