ORACIS
Start a project

Work

Sheet
A-400
Set
Practice
Status
Issued

Real systems, built by the founding team. Status stated on every one.

These systems were built or led by the founding team of Oracis Engineering, some before Oracis existed and for other companies the founders own. We describe them only as far as we can share publicly. Production means live and in use. Built means working, but not yet in paid use.

A-400PracticeIssued

Two engineers discussing system diagrams pinned to a wall.

Clients

Who these systems were built for.

  • TrueEval Medical Group

    Production

    Affiliated company · TrueEHR

    A custom, AI-native EHR for virtual-first medical practices: intake, scheduling, virtual visits, charting, e-prescribing, lab interpretation and billing, multi-tenant from the first table.

    • 2,500+ database migrations
    • 370+ server functions
    • 18,800+ automated tests
    • 116 end-to-end suites
    • Tenant isolation enforced in Postgres, not only in the app
    • AI drafts clinical notes; a licensed provider attests every section
    trueehr.health →

  • TrueLaw

    Built, not in paid use

    Affiliated company

    A multi-tenant platform for the criminal defense bar: discovery synthesis, transcription with privilege screening, contradiction detection grounded in sources, deadline computation with quoted statutes, and drafting behind an attorney-attestation gate.

    • 18 shared packages behind three applications
    • Per-firm isolation, app-layer encryption and an audit trail
    • A citation firewall that fails closed
    • Bilingual interface, English and Spanish
    • Its own README states what does not exist yet

  • ProofInjury

    Built, not in paid use

    Affiliated company

    A medicolegal assessment platform for personal injury firms, with separate interfaces for the firm, the patient, the provider and the administrator, and forensic report generation reviewed before it leaves the system.

    • Four role-specific interfaces on one platform
    • Multi-model consensus rather than a single model's judgment
    • Started on an AI app builder, then engineered for production

Every client here is a company the founders own or are affiliated with, and each card says so. We do not publish a client we cannot name, and we state what is in production and what is not.

W-01 to W-03 · one platform

A production telehealth platform, built and run by the founding team.

18,800+
automated tests
16,700+
CI runs
9,800+
commits
870+
merged pull requests
2,500+
database migrations
370+
server functions

This platform alone, counted from its repository and CI history, 22 Sep 2026. Totals across all three codebases are on the home page.

W-01

Production

Multi‑tenant telehealth platform

TrueEval Medical Group · TrueEHR

Tenant isolation in the database A request from a session in tenant A reaches tenant A's rows. The same session's attempt to read tenant B's rows is denied by a row‑level security policy inside the database. App session Tenant A user Shared Postgres · RLS enforced policy Tenant A rows Tenant B rows Tenant C rows allowed denied inside the database not just hidden by the app Tenant isolation in the database A request from a session in tenant A reaches tenant A's rows. The same session's attempt to read tenant B's rows is denied by a row‑level security policy inside the database. App session Tenant A user Shared Postgres · RLS enforced policy Tenant A rows Tenant B rows Tenant C rows allowed denied inside the database not just hidden by the app
Fig. W-01Isolation lives in the database, verified by tests
Constraint
One platform serves many independent clinical organizations, each with its own patients, staff and records, on shared infrastructure. No organization may ever see another's data.
Decision
Isolation is enforced in the database with row‑level security, not only in application code, and verified by automated tests rather than trusted on inspection.
Trade-off
Database-level isolation takes longer to build than an application check, and every new table has to be designed for it from the start.
Outcome
A production platform covering intake, scheduling, virtual visits, clinical documentation, e-prescribing and lab interpretation, in operation today.

W-02

Production

AI‑drafted clinical notes, human-gated

TrueEval Medical Group · TrueEHR

Section-by-section attestation AI drafts four sections of a clinical note. A provider attests each one. Three are attested and one is not, so signing stays locked at three of four. AI draft History Assessment Plan Orders Sign note locked · 3 / 4 Provider attests each section · the server enforces the lock Section-by-section attestation AI drafts four sections of a clinical note. A provider attests each one. Three are attested and one is not, so signing stays locked at three of four. AI draft History Assessment Plan Orders Sign note locked · 3 / 4 Provider attests each section · the server enforces the lock
Fig. W-02No blanket approval; each section is attested
Constraint
AI can draft a clinical note quickly. A wrong note, or one nobody reviewed, is a patient-safety problem, not a productivity win.
Decision
AI drafts each section. The system won't let the note be signed until a licensed provider has reviewed and attested every section individually. There is no single blanket approval.
Trade-off
Attesting section by section is slower for the provider than one-click approval. We chose accountability at the one point where speed matters least.
Outcome
AI‑assisted documentation in clinical use, with a review step that can't be silently skipped.

W-03

Production

Multi‑model clinical review with a deterministic backstop

TrueEval Medical Group · TrueEHR

Multi‑model review with a deterministic backstop A lab result goes to three independent models in different roles. If they disagree it escalates to a clinician. If they agree, a deterministic rules engine decides whether anything is released to the patient, and can block it. Lab result Interpret Challenge Cross-check agree? disagree → clinician Rules engine deterministic release block Multi‑model review with a deterministic backstop A lab result goes to three independent models in different roles. If they disagree it escalates to a clinician. If they agree, a deterministic rules engine decides whether anything is released to the patient, and can block it. Lab result Interpret Challenge Cross-check agree? disagree agree Clinician human review Rules engine deterministic block release
Fig. W-03No single model output reaches a patient unchecked
Constraint
A single model's judgment on a clinical result is a single point of failure. It can be confidently wrong in ways that are hard to catch later.
Decision
Independent models review the result in different roles, and disagreement escalates to a clinician. A deterministic rules engine, not AI, makes the final call on what reaches a patient.
Trade-off
Several models in several roles cost more per result than one pass. The extra cost is the safety margin.
Outcome
AI‑assisted interpretation in which no single model's output reaches a patient unchecked.

W-04

Built

AI‑assisted casework for criminal defense

TrueLaw

Attorney-gated casework Discovery material goes through AI‑assisted synthesis, is checked against its sources, and reaches an attorney review gate before anything is relied on or filed. Rejected output goes back for rework. rejected → rework Discovery files, audio AI synthesis transcripts, drafts Source check cited back Attorney review required Relied on or filed Attorney-gated casework Discovery material goes through AI‑assisted synthesis, is checked against its sources, and reaches an attorney review gate before anything is relied on or filed. Rejected output goes back for rework. ↑ rejected → rework Discovery files, audio AI synthesis transcripts, drafts Source check cited back Attorney review required Relied on or filed
Fig. W-04The tool files nothing; a lawyer does
Constraint
Discovery review, transcription and deadline tracking consume huge amounts of defense time. But privilege, accuracy and attorney supervision of AI tools (ABA Formal Opinion 512, Model Rule 5.3) aren't optional.
Decision
AI helps with discovery synthesis, transcription and drafts. Every output is gated behind attorney review before anyone relies on it. The tool files nothing; a lawyer does.
Trade-off
Gating every output behind review limits what the tool can do unsupervised. That is the point, not a limitation to route around.
Outcome
Built and working, not yet in paid production use.

W-06

Built

A medicolegal assessment platform, taken off an AI builder

ProofInjury

Four audiences, one reviewed assessment A law firm, a patient, a provider and an administrator feed one assessment, which several models review independently. A clinician signs off, and the forensic report goes to opposing counsel. Law firm Patient Provider Administrator Assessment several models, independently Clinician sign-off a person is accountable Forensic report goes to opposing counsel Four audiences, one reviewed assessment A law firm, a patient, a provider and an administrator feed one assessment, which several models review independently. A clinician signs off, and the forensic report goes to opposing counsel. Law firm Patient Provider Administrator Assessment several models, independently Clinician sign-off a person is accountable Forensic report goes to opposing counsel
Fig. W-06Four audiences, one reviewed assessment, a person accountable for the report
Constraint
An assessment platform for personal injury firms serves four different audiences — the firm, the patient, the examining provider and the administrator — and its reports end up in front of opposing counsel.
Decision
One platform with four role-specific interfaces, and assessments reviewed by several independent models rather than accepted from one, with a person responsible for what the report says.
Trade-off
It began on an AI app builder, which got it working quickly and left production concerns — access control, review, auditability — to be engineered afterwards. That work is the difference between a demo and a system.
Outcome
Built and working, not yet in paid use.

W-05

Built · in daily use

Our own AI engineering infrastructure

Reviewed AI engineering task A scoped brief goes to an AI engineer working in an isolated worktree under a hard spending cap, then to an independent reviewer, then to a human who reads the diff and decides whether to merge. Findings go back for repair. finding → repair Scoped brief write scope Isolated run hard budget AI engineer tests in sandbox Reviewer second seat Human merge reads the diff Reviewed AI engineering task A scoped brief goes to an AI engineer working in an isolated worktree under a hard spending cap, then to an independent reviewer, then to a human who reads the diff and decides whether to merge. Findings go back for repair. ↑ finding → repair Scoped brief write scope Isolated run hard budget AI engineer tests in sandbox Reviewer second seat Human merge reads the diff
Fig. W-05Isolated, budget-capped, reviewed, then a human merges
Constraint
Directing AI models to do real engineering safely means limiting what they can spend, where they can write, and who checks their work. Off-the-shelf coding tools don't do this by default.
Decision
Every task runs in an isolated environment with a spending ceiling the provider enforces, not one checked after the fact. A second, independent model reviews the work before it counts as done.
Trade-off
Isolation and review add latency and cost to every task. We use the system every day, including on this website.
Outcome
The system behind our engineering, research and review work, used every day, including to build this website. Field note N-104 shows one real run: seven lanes, 19.5 cents, and the two defects only a person caught.
Product
The same runtime is becoming a product, Fleet by Oracis, in an invitation-only private preview.

Want the version that fits your system?

Tell us what you're building. We'll tell you honestly which of these is comparable.

Start a project
Next sheet · A‑500 How We Work