Platform
Clinoria is not a single model. It is a pipeline of narrow, inspectable stages where interpretation is separated from generation, and where the last word belongs to a validator and then to a clinician.
Working prototype · English ultrasound and focused dictation · pre-clinical
Design position
Decision 01
The system decides what the conversation means clinically and records that decision in a structured graph. Prose is produced afterwards, from the graph. This makes interpretation reviewable independently of writing quality.
Decision 02
A deterministic renderer turns validated facts into sections under a department template. The same graph always produces the same note, so a difference between two drafts is a difference in evidence — never in sampling.
Decision 03
Before a draft becomes reviewable, a validator checks that each claim is supported by the fact graph. If it finds an unsupported phrase, the draft is marked invalid and withheld from review rather than shown with a warning.
Decision 04
Editing a draft moves it to reviewed. Approval is a separate credentialed action, and export is refused unless the note is approved. These are server rules, not disabled buttons in a browser.
Pipeline
Each stage has one job and a defined failure behaviour. Nothing downstream can silently repair a decision made upstream.
Audio is captured for a specific consultation, with the transcription route disclosed to the user before recording. Speech recognition runs locally on CPU. Speaker separation is applied where the source supports it.
Limitation There is no automated de-identification of audio anywhere in the system. Audio retention is time-bounded, not content-filtered.
The transcript is parsed into clinical concepts. Each concept is given a status from a closed vocabulary, a subject, laterality where relevant, a temporal marker, any exact measurement, and the transcript span that supports it.
Limitation Negation rules are applied by the normalisation layer that runs on speech-recognition output. Text submitted through the typed path does not receive them, which is the direct cause of the polarity defect documented on the research page.
The validated graph is rendered into a note template for the department: fourteen sections covering the standard documentation headings. Sections without supporting facts are rendered as not documented rather than filled.
Limitation Templated prose is linguistically plainer than a generated note. Some sentences read awkwardly, and we prefer that to sentences that read well and are unsupported.
A validator compares each rendered claim against the graph. The draft, its facts and any validation findings are shown to a credentialed clinician, who edits, reviews and approves. Approval is what starts the retention clock.
Verified Export is refused for drafts that have not been approved. The gate is enforced server-side and has been tested end to end.
The fact graph
This is the unit the rest of the system reasons about. It is deliberately verbose: every field exists because omitting it caused a documentation error somewhere in clinical practice.
| Field | Value | Why it exists |
|---|---|---|
| concept | hydronephrosis | Normalised clinical concept, not a matched string. |
| status | ABSENT | Distinguishes a denial from an omission. |
| laterality | left | Anchored to the structure described, not to reading order. |
| subject | patient | Keeps family history from becoming the patient's history. |
| temporality | current | Allows historical and present states to coexist. |
| measurement | — | Preserved verbatim and attached when present. |
| uncertainty | null | Defined in the schema; not yet populated reliably (§known gaps). |
| source_span | turn 4, chars 12–38 | Lets a reviewer check the claim against the words. |
Known gap
uncertainty is the field we are least satisfied with. Hedged clinical language is common and currently arrives as null.
Operational envelope
Why there is no public demo
A public free-text box would expose the defects documented on the research page to anyone, at any hour, with nobody present to explain them. It would also invite real patient data into a system with a heuristic content filter that does not recognise Indian phone numbers or Malayalam names.
Demonstrations are therefore run live, by a person, on synthetic inputs. That is a deliberate product decision, not a missing feature.
What this architecture does not solve
Next
A demonstration runs the real engine on synthetic cases and stops at each stage so you can inspect what it decided and why.