Meet PiTRA™

PiTRA™ is the point-in-time reasoning engine inside Alvia. It’s how Alvia resolves what was true, what changed and what’s true now.

This page explains PiTRA™ (pronounced “PIT-rah”): what it does when your application writes and reads, how Alvia’s six core technologies work together in it and what that means for the code you write.

What PiTRA™ is

Point-in-Time Reasoning for AI is the category Alvia defines: knowing what’s true now, what was true before and how it changed. PiTRA™ is how Alvia delivers it. It is not a separate product or a separate API. Every write through the REST API or the MCP remember tool runs through it, and every search, recall and context read returns what it formed. Every plan, Free included, runs all of it.

PiTRA™ does its main work once, when a fact arrives, not on every read. Before a fact becomes readable, it decides how it relates to what the project already holds. A read then starts from memories whose changes are already resolved.

When your application writes

A write answers 202 at once. PiTRA™ then forms memories in the background, in less than a minute:

Extract. With infer: true, the default, a language model takes each durable fact out of the text. Each fact runs through the next steps on its own.
Screen. The project’s memory policy excludes a fact by keyword or by meaning before it becomes memory.
Normalize. It rewrites the fact in a consistent form, gives it a category and writes the dates that phrases such as “yesterday” name into its text.
Compare. It finds the memories closest in meaning to the fact, in the same project and scope, each at its current version.
Classify. It decides how the fact relates to them: supersession, refinement, duplicate, contradiction, related or novel. It records the outcome and why.
Commit. A supersession or refinement becomes the next version of the memory it changes, under the same ID. A contradiction or a related fact becomes a new memory linked to the other. A duplicate stores nothing new. The memory is now readable.

PiTRA™ also records the entities each memory names, such as a project or a tool. Each step is explained in Memory formation.

When your application reads

Search, recall and context rank memories in two passes. PiTRA™ first finds the memories closest in meaning to the query, within the scope fields you send, then orders them by how well each one answers it. It then adjusts each score with a boost for the memory’s category that fades with age, recent use, favorites and feedback.

Reads return each memory’s current version. Inspect returns every earlier version, with how PiTRA™ classified it and why.

Context goes one step further. It takes the best match with the memories related to it and the memories that contradict it, and a language model writes them as one to three sentences. When the best match has a contradiction, the context reports both sides. See Read memories.

How the core technologies work together

Alvia’s six core technologies are parts of PiTRA™, and each one shows up in the API:

Technology	What PiTRA™ does	Where you see it
As-of Queries	Ask a question that includes a time and get what was true then. Ask about now and get what’s current. Each fact is dated by when it was stated; relative dates are resolved on that day, and a memory’s time only moves forward.	Context, for a question such as “What database was Atlas on in April?” Every memory carries `occurred_at`, and reads can be bounded with `occurred_after` and `occurred_before`.
Supersession	Commits a fact that replaces a memory as that memory’s next version. Reads return the new version.	The same `memory_id` with the new text
Contradiction	Keeps both facts and links them, instead of picking one.	Context that reports both, and the link in inspect
Adaptive Relevance	Adjusts each match’s rank by its category’s boost, which fades with age, and by use, favorites and feedback. Meaning still leads.	`ranked_score` on search and recall
Temporal Graph	Holds each memory’s dated versions and the related and contradiction links between memories.	Inspect’s `relationships`, and Graph in the dashboard
Full Lineage	Keeps every version with the outcome that produced it and the classifier’s explanation.	Inspect’s `versions`, and a memory’s History in the dashboard

They depend on each other. Classification decides between supersession and contradiction. The versions it commits form the lineage. The dates it records drive both the date bounds and the fade in Adaptive Relevance. The links between memories are what context follows to report a disagreement.

One example, step by step

A team sends three facts about the Atlas service, each with the time it was stated. In this example, PiTRA™ classifies them as follows:

Stated	Fact	What PiTRA™ does
March 4	“We’re standardizing on PostgreSQL 16.”	No close memory: novel. A new memory at version 1.
May 12	“Atlas is moving to PostgreSQL 17.”	Supersession of the March memory. The same memory at version 2.
July 8	“Atlas is still running 16 in production.”	Contradiction of version 2. A new memory, linked to it as contradicting.

A context read for “Which database does Atlas use?” then starts from the best match and reports the disagreement. A language model writes the answer, so its wording varies; a typical one reads:

{
  "context": "Atlas is moving to PostgreSQL 17, as stated May 12, 2026. A July 8, 2026 statement says Atlas still runs PostgreSQL 16 in production."
}

Inspect on the first memory returns both versions, newest first: the May text with the outcome supersession and the classifier’s explanation, then the March text with the outcome novel.

Why it matters

One answer, not a pile. Your prompt gets the current version of each fact. Your code does not sort by date or reconcile old and new facts before each model call.
Disagreements surface. A contradiction reaches your application as a contradiction, so your agent can ask, flag or wait instead of acting on a guess.
Every answer is traceable. Inspect shows each version, its outcome and why. When an answer surprises you, you can see how the memory reached its current state.
Old information keeps its age. Send occurred_at with backfills and imports, and PiTRA™ dates and ranks those facts by when they were stated. See Point-in-Time Reasoning and change over time.
Reads stay short. Classification runs once, in the background, after the write returns. Context returns one to three sentences, so the prompt stays within budget as history grows.

Alvia returns context; your application or agent decides what to do with it. See What Alvia handles and what stays with you.