On this page
A message mentions a person. A calendar event includes the same address. A document discusses a project using a short name. The records are related, but a search index does not necessarily know how.
Zortex's approach is to keep source records and the decisions about their meaning separate. The source is evidence; the model is an interpretation of that evidence. That difference matters when names collide, identities change, or an earlier inference turns out to be wrong.
The components described here are implemented in ZortexHQ/try-indra. They include the event log, identity resolver, derived claims, index and graph-serving façade. Each inferred relationship retains a trail of evidence and a path for correction.
The original observation comes first
The event-log implementation describes append-only event segments as the authoritative record, accompanied by a rebuildable SQLite representation and a blob store. Connectors send typed source events to this boundary. The event log is deliberately mechanical; it does not need a language model to decide whether an upstream observation should be preserved.
Suppose two emails refer to the same meeting and a file contains the agenda. One tempting design is to write a single polished summary, then retain only that summary. The problem appears when the meeting changes or the summary is challenged: without the original identities and revisions, the system cannot explain which observation supported which sentence.
An event record, and a derivation that cites it, allow the system to revisit the decision.
This is also why source timestamps and system observations are not interchangeable. A late-arriving event can describe something that happened earlier. Ingestion order tells us when the system encountered evidence; it does not always tell us when the real-world fact became true.
Resolving names is a decision, not a string join
The Resolver takes event views with mentions, sources and evidence identifiers. Its stages include normalization, candidate generation, scoring and identity decision events.
For an email address, normalization can make an exact handle match meaningful. For a common display name, it cannot. A name by itself is weak evidence: two people can share it, and one person can use multiple handles. The resolver therefore has a distinction between an observed mention and an entity cluster formed from several observations.
The code also maintains negative identity evidence: records asserting that two references are distinct. User-established distinctness is a boundary that automated resolution is not permitted to overwrite casually. Ambiguous cases have a review path rather than a mandatory speculative merge.
These constraints are as important as the happy path. A mistaken merge can make later retrieval more confidently wrong because unrelated evidence is collected under one label.
How the layers connect
Source records and revisions
|
v
Append-only event log
|
v
Mentions and evidence
|
v
Identity resolution decisions
|
+-----+------+
| |
v v
Entity cards Evidence-linked claims
| |
+------+-----+
|
v
Index / graph projections
|
v
Bounded graph view
Diagram: event records, identity decisions, claims and graph projections.
The graph projection code folds identity decisions into entities and renders cards describing those entities. Its tests check that replaying the same decision log produces identical projections, and that an entity card's knowledge statements carry citations.
That rebuildability is deliberate. A graph is a way to inspect a set of resolved relationships; it should not become an independent source of truth whose provenance has been forgotten.
Claims need their own lifecycle
An identity can be correct while an assertion about it is not. Someone may indeed be a colleague, but a note saying they own a project may have become outdated.
The claims layer checks for evidence identifiers before accepting a derived knowledge claim. It implements addition, invalidation and replacement rather than editing an old assertion in place. It also keeps contradictory claims visible with their provenance rather than making one silently erase the other.
One explicit guard concerns incomplete coverage: low-coverage claims must carry a caveat. This is a rule in code, not an assertion that the system can always measure whether it has read every meaningful source.
A second guard protects user-stated claims from automated invalidation. An automated conclusion can disagree with the user's statement, but disagreement is not sufficient authority to delete it. That conflict remains available for inspection and correction.
This is the difference between a system that stores plausible sentences and one that preserves an accountable chain of evidence.
The graph must be able to say it is stale
Graph views are also an engineering budget problem. The GraphFacade enforces upper bounds on nodes and edges in a viewport response. It reads committed layout positions rather than treating half-written layout state as valid. If a layout is unavailable, it can report unpositioned nodes with a staleness indication instead of inventing coordinates.
The adjacent index tests check that bounded graph exports report truncation, and that an index with no documents produces a checked empty state. A disabled subsystem or absent projection should not be indistinguishable from a person having no history.
These tested serving rules bound response size and distinguish missing projections from empty results.
Documents, people, and project context
In everyday language, a world model connects people, projects and documents. Technically, these are not all the same kind of object.
Source documents have stable upstream references and revisions. People may need identity resolution across several addresses and handles. A project may appear as a phrase, a claim, a folder, or a collection of documents; the reviewed resolver code does not justify claiming that every project is automatically created as a first-class entity with flawless boundaries.
Zortex implements the path from observed records to cited entity and claim projections, served alongside its indexed records.
Correcting relationships
Aliases, shared accounts, forwarded messages, missing sources and contradictory statements are common, not exceptional. The most damaging failure is often a confident merge made from incomplete evidence.
Every relationship needs three answers: Where did it come from? What evidence could change it? Can the projection be rebuilt after a correction? Zortex retains source events, resolution decisions and claim revisions separately, so a person can trace the relationship to evidence and revisit it after a correction.
Visual source: code-generated cover study.
