The long version
How Orinis actually works
The landing page states the mechanism. This one shows it — the stored rows behind each claim, example questions for each reader, and the measurement behind the limit.
- Two clocksevent_time, recorded_time, and the chain a correction leaves
- Why everyone has thisthe gap is not a compliance feature
- Two readers, one mechanisma site file and a shoulder, same query
- What it doesremember, recall, reflect, resolve
- Where it stopsthe abstention, and the number that bounds it
- Connecting itMCP, and what is not open yet
Two clocks
Every record carries two dates, and they move independently.
event_time is when the thing happened. recorded_time is when the record was written: the moment you type it, or for an imported chat export the original message time. Because the two are stored apart, you can pin Orinis to a date. It answers with what had been recorded by then, and leaves out every correction that arrived after.
As of a date
Pin the archive to any past point. Later corrections are excluded, not hidden.
What changed
Compare two points and get what was added, resolved or revised between them.
Honest precision
A fact known only to the month is never rendered as a false-exact day.
event_time 2025-05-15 (day)
recorded 2025-05-15
event_time 2026-06-06 (day)
recorded 2026-06-06
Example modelled on Orinis's demo corpus: the site is renamed and the wording edited; the event ids, dates and values are as stored. Both panels are the same query at two recorded_time horizons. The left one is not stale; it is what the archive held on that date.
A correction never rewrites the old record. Orinis inserts a new event and sets superseded_by on the previous one. The rows marked was: are still stored, still queryable, and still cite their own source messages — superseded is a position in the order, not a verdict on the row.
This is not a compliance feature
Every fact anyone holds has two dates.
When the thing happened, and when it entered the record of it. The gap between those two is where being wrong lives — and a single timestamp cannot express a gap at all. It has nowhere to put the second date.
The result was true in the sample before the certificate reported it.
The illness was already there before the diagnosis gave it a name.
The role was filled a week before the email said so.
Orinis stores that second date as the moment the record was written — for what you type, when you typed it, not a guess at when you knew; for an imported chat export, the original message time, with the import time kept separately. That is the honest version of the second clock, and it is the one that makes a past state reconstructable.
One substrate, two lives
Designed for the record you have to defend, and the one you just want back.
“What did the file say before the March filing?” and “what did I think before the scan?” are one question wearing two vocabularies — what did this record hold on that date. The same two dates answer both, out of the same store.
Choose a reader — the evidence changes, the mechanism does not
Showing — regulated & professional practice
A lab number was wrong for more than a year. The file has to show what it said then, not only what it says now.
Example data. On the hosted database every table that holds your records is covered by per-account row-level security.
You stopped because it seemed to have settled. The scan says it never did — and what you cannot get back is what you were looking at on the day you decided. Unless it was recorded.
superseded_by on the earlier one; it does not delete it.Illustrative example, not demo-corpus data. On the hosted database every table that holds your records is covered by per-account row-level security.
Illustrative example, not demo-corpus data.
What Orinis does
Four verbs, one store.
Remember, recall, reflect, resolve. The same four whether you are defending a site file or trying to remember what you decided last spring — because the store underneath does not know the difference.
Putting things in
Remember
Text, notes, chat exports and PDF reports become dated events with the source message kept behind each one (very long messages may be stored truncated).
Documents, including scans
Tables and dated text become events. A scanned page is read by OCR; a value that does not read clearly enough is left out rather than guessed at.
Forget, properly
Deleting a source message deletes every event derived from it. There is no undo. The few things that stay are listed on /privacy.
Getting things out
Recall
Time, status and scope filter first; ranking happens inside that set. Time is the coordinate system, not a similarity score.
Reflect
Diffs, open loops and what has gone quiet are computed from stored rows. Briefs are generated and cite event ids that are checked to exist.
Resolve
Close a loop, confirm a correction, or review low-confidence extractions in a queue; they stay in your archive until you reject them.
When there is no record
An empty result is an answer.
When nothing in your archive satisfies the query, Orinis returns one sentence, at most with a short note on what your archive covers. The generator is never handed the opportunity to fill the gap from its weights.
Scope, stated plainly. This is structural — a property of the query returning nothing — where the answer is composed from stored fields. Where an answer is generated, the refusal rests on a retrieval boundary instead, and that boundary is weaker than it sounds.
Times Orinis declined when it held the subject but not the attribute
95% CI 0.0–7.4%. A retrieval-only run on an authored 31-event test archive, 2026-08-09: in none of the 48 did retrieval come back empty, so the no-record answer never fired. No model was called and answers were not graded; no re-run is recorded. Closing that without destroying recall is unsolved work — not a roadmap item with a date on it.
“What did the dentist recommend for the crown?”
I have no record of that.
Example data from Orinis's demo corpus, against a subject the archive does not contain. Every content word in that question — dentist, recommend, crown — is absent from the corpus.
Connect it
Your assistant asks. Orinis answers with ids.
Orinis has an MCP server you run locally, so an assistant that can launch local servers can read and write your timeline. Change assistants and your records stay put — same tools, same event ids, same archive — because the engine holds the logic and a client is only a surface onto it.
Point it at your archive
Today that means running the Orinis engine on the same machine and building the server from source — developer setup, not a config line.
Ask in plain language
The tools carry the temporal vocabulary so you don't have to.
Get ids back
Each event a tool returns carries its stored event id, which you can open.
There is no install command today. The server is not published to any package registry: it runs from a source build, against a Orinis engine you run yourself, on your own machine. A hosted endpoint your assistant can reach over the internet — the thing that would make this one line of config — is not open, and will not be until its authorization model is finished.
// you, in the assistant: // "what did I know about Halloran Yard on June 1?" → timeline_as_of timestamp = 2025-06-01 // every event the archive held on that date, one line each (one shown): ← **Time Machine** — known as of 2025-06-01 (… events) - **[evt:94]** PFAS at Halloran Yard MW-3 revised to 12 ppt — _<when> (day, open, concern)_
The boundary — what the integrity chain catches and what it does not — is on the overview.