Your AI forgets. Orinis doesn't.
One continuous memory that lives outside your AI — what happened, when it happened, what changed, and where the record came from.
And when nothing in your records answers the question, Orinis says so.
It happened in March.
It was recorded in June.
Orinis knows the difference.
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.
Two readers, one mechanism
Designed for the record you have to defend, and the one you just want back.
Illustrative questions.
“What did we know about this site before the March filing?”
Pinned to the filing date — later corrections excluded, so the answer is the one you had, not the one you have now.
timeline_as_of · [evt:94]
“What did my record say about the shoulder on the day I stopped?”
Pinned to 2025-11-18. The scan is eleven weeks in the future and is excluded — so the answer is what the record held then, not what you know now.
timeline_as_of · horizon 2025-11-18
Both readers’ full questions, with the stored rows behind 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.
The boundary
A citation proves the telling, not the truth.
Orinis answers about your history cite stored records, and where there is no record it says so.
That guarantee is about the link between a claim and a record. It is not a claim that the record is correct. Orinis records what it was told — a citation proves the telling, not the truth.
Every event, correction and supersession is appended to a hash-linked chain when it is written; the chain is hash-linking, not a signature, and the database refuses ordinary updates to it. The sealed export that let you check the chain yourself was withdrawn on 2026-08-20 and has not been rebuilt, so today the chain is something Orinis can check, not something you can. Here is what it is built to catch and what it does not.
| Threat | Chain exposes it |
|---|---|
| An old event row is edited in the database without updating the chain | Yes |
| A correction is deleted but the chain is left in place | Yes |
| A malicious database owner rebuilds the whole chain from tampered data | No |
| A stolen key or compromised exporter | No |
| Hiding events that were never logged in the first place | No |
| A record that faithfully captures a false statement from its source | No |
The last row is the one worth sitting with. If a report you upload asserts something its own results table contradicts, Orinis will record the assertion, cite it correctly, and repeat it back to you. The citation was never a claim about the document's truthfulness — only about where the sentence came from.
What you are signing up to
You will find this out anyway. Better here.
Capture is immediate. Turning a document into events runs in the background and can take minutes when the model is busy — you are told which state a document is in. The engine is further along than the product, and the correction path above is tested but has not yet run against a long-lived archive in production.
You are allowed to have been wrong.
Orinis supersedes; it never rewrites what it recorded. What your record said in March is still there in June — beside the message it came from and the date Orinis recorded it. A correction sits above the old belief instead of replacing it, so you can go back and read what you actually had at the time.
Two dates, kept apart, and nothing overwritten.
Paid plans, cancel anytime. If you ever stop, your archive stays readable and exportable.