The person who ran the result cannot be the person who releases it.
Each state carries a recorded signature with a meaning, and each transition is a check inside the database function rather than a rule the interface politely observes. A client that calls the function directly meets the same refusal.
- Enteredsignature meaning
authorshipThe result is recorded against its sample, its method, and the reagent lots consumed to produce it. The instrument it ran on is usable only while its calibration stands.
- Verifiedsignature meaning
reviewA second person reviews it. If the verifier is the person who performed the result, the function raises sod_violation and writes nothing. The interface is not what is holding that line.
- Approvedsignature meaning
approvalA director-level approver signs off, and may be neither the performer nor the verifier. Three sets of eyes, checked inside the function rather than by hiding a button.
- Releasedsignature meaning
releaseRelease is bound to a signature. From that moment the certificate is immutable: a correction issues a new version and voids the prior one, so what reached the requester stays retrievable exactly as it was sent.
This is a diagram of the checks, not a screenshot. The state names come from the review-state module and the gates from the review-queue migration, both of which you can open: src/lib/lims/reviewState.ts supabase/migrations/20260709000000_lims_wave1c_review_queue.sql
Every mechanism, with the file you can open to check it.
Every entry below was verified by opening the migration or module named beside it. A capability with no file behind it is absent from this list rather than softened into it.
Hash-chained audit trail
supabase/migrations/20260707000000_lims_wave1a_audit_trail.sqlAn append-only ledger written by a database trigger, where each row hashes the previous row hash together with its own payload under SHA-256. A later edit, deletion or reordering breaks the chain, and verify_lims_audit_chain reports the first sequence number that fails.
Electronic signatures
supabase/migrations/20260708000000_lims_wave1b_esignatures.sqlEach signature stores the signer, the timestamp, the authentication method, the record hash and the meaning (authorship, review, approval, release, rejection, amendment), plus a rendered signature statement: the manifestation 21 CFR Part 11 section 11.50 asks for. Release is bound to a signature.
Separation of duties on review and release
supabase/migrations/20260709000000_lims_wave1c_review_queue.sqlEnforced in the database, not in the interface. The person who performed a result cannot verify it, and neither the performer nor the verifier can approve it: the RPC raises sod_violation instead. Results move entered, verified, approved, released.
Westgard multi-rule QC
src/lib/lims/qc/westgard.tsSix rules over the z-scores of a control history (1-2s, 1-3s, 2-2s, R-4s, 4-1s, 10x), evaluated in the database on every QC measurement and mirrored by a pure module that drives the live preview and is the tested specification.
Reagent lot and instrument calibration traceability
supabase/migrations/20260714000000_lims_wave4_reagents_instruments.sqlA result carries the reagent lots consumed to produce it, and an instrument is usable only while its calibration stands. Lot status and calibration records are first-class tables, not free text in a comment field.
Certificate of Analysis versioning
supabase/migrations/20260713000000_lims_wave5_coa_versioning.sqlA certificate is an immutable record. Correcting one issues a new version and voids the prior, so a released certificate that reached a customer stays retrievable exactly as it was sent.
Nonconformance, CAPA and out-of-specification investigation
supabase/migrations/20260722000000_lims_wave5b_quality_events.sqlQuality events open, link to the orders, samples and results they concern, move through a recorded disposition, and close. CAPA actions are opened, completed, verified and approved as separate tracked steps, and an out-of-specification investigation is recorded against the result it questions.
Coding and interoperability
src/lib/lims/interopLOINC coding of results, UCUM units with conversion in the database, HL7 v2.5.1 ORU^R01 result messages, FHIR R4 DiagnosticReport bundles, and X12 837P claim and 835 remittance handling on the billing side. Every builder is deterministic: the same inputs yield byte-identical output.
Turnaround time and SLA clocks
supabase/migrations/20260718000000_lims_wave7a_sla.sqlTurnaround clocks that run on a business calendar with holidays, and that pause and resume rather than counting time a sample spent legitimately on hold.
A control point past two standard deviations raises a warning. A control point past three rejects the run. Olto keeps those in separate lists, because a warning rule is not a rejection rule and a QC log that flattens the two is a QC log you cannot act on. All 6 of the rules are evaluated in the database on every QC measurement, and mirrored by a pure module that drives the live preview and is the tested specification.
One record, and nobody retypes it into the next system.
The ladder above is not an abstraction: it is who may do what, and the database is the thing that knows.
At the bench
- Enter results against the method, the reagent lots consumed, and the instrument that ran them
- See the Westgard evaluation of the control history before a run is accepted
- Watch a turnaround clock that runs on a business calendar and pauses for a legitimate hold
- Cannot verify your own work, because the function will not let you
Technical supervisor and lab director
- Work a review queue rather than a spreadsheet of pending results
- Verify and approve under separate signatures, each recording signer, time, method and meaning
- Release, and the certificate carries the release signature and a version
- Read the audit chain and get back the first sequence number that fails, if any does
Quality
- Open a nonconformance or an out-of-specification investigation against the result that raised it
- Track CAPA through opened, completed, verified and approved as separate recorded steps
- Trace a released result back through lot, calibration, method and signature
- Export results and certificates without filing a ticket
One route of 72 calls a model. The other 71 compute.
A flag against a reference interval, a Westgard evaluation, a turnaround clock, a unit conversion, a claim line: all return values from functions with fixed inputs. None of them is a model output, and none of them is a judgement call made by prose.
The one route that does call a model is a plain-language read of results that have already been released. It writes nothing, it computes nothing, and it cannot move a result along the ladder. We publish the ratio as one of 72 rather than rounding it to none, because the honest number is the one you can check, and a vendor who claims zero here is a vendor you should go and count.
The same property is watchable rather than described on the Engine Registry, which re-runs every sealed engine when you load it and prints whether each one still reproduces its recorded hash.
The size of it, rounded down.
Each figure below is rounded down from a measured value, and the command that produced it is recorded in the repository beside the constant these render from. A number on this page can go stale and low. It cannot quietly go high.
Distinct lims_ tables across the migrations, holding samples, results, signatures, lots, instruments, quality events and the audit ledger.
Postgres functions a client can call. Counted apart from the column guards and trigger writers, because those are a different claim.
Every function whose name carries lims, guards and triggers included. This is the layer the rules actually live in.
Schema changes, in order, each one readable in the repository. The regulated mechanisms arrived as numbered waves.
Assertions over the pure lab modules: QC evaluation, review state, signatures, reference intervals, reflex rules, interop builders.
Here is what Olto does not clear.
These are not a disclaimer at the bottom of a page. For a regulated buyer they decide whether an evaluation can begin at all, and you would find every one of them on the first call. We would rather you find them now and spend the call on something else.
No completed SOC 2 audit
No independent SOC 2 audit has been completed. If your procurement process requires a Type II report before evaluation can begin, Olto does not clear that gate today.
No SSO, and MFA cannot be enforced org-wide
There is no SAML or SSO, and no SCIM provisioning. Every user can turn on TOTP multi-factor authentication and it is fail-closed once enabled, but an administrator cannot require it across an organization.
No Business Associate Agreement by default
Olto is not offered as a HIPAA platform by default and a BAA is not available as standard. Treat protected health information accordingly.
No public API
There is no public or programmatic API yet. Instrument and LIS integration today means the HL7, FHIR and X12 message surfaces plus file export, not a REST API you can build against.
Not end-to-end encrypted
Olto is not end-to-end encrypted. Content sent to an AI-assisted action reaches the model provider, so the result-interpretation route is the one place in this workspace where lab data leaves for a model.
Software can be 21 CFR Part 11 capable. Only your configured, validated and operated system is compliant, and it is your laboratory that gets certified, not our code. So this page describes what the software does and stops there. Nowhere on it is Olto called compliant or certified, and that rule is written into the constant this section renders from rather than left to whoever writes the copy.
The same list, kept for the platform as a whole, is on the trust centre and the security page.
The lab plan is $499 / month for 10 seats, published, with a checkout button instead of a quote form. The honest edge of that: the seat after the 10th is a conversation, so a lab growing past 10 people lands in the procurement cycle this page is trying to spare you. Every price is on the pricing page, including that one.