History & time travel
The graph isn't just a snapshot of now. It remembers. So you can ask what's true today, but also what was true on the tenth of April, and how something changed over the last quarter.
Asking about a point in the past
A normal query reads the graph as it exists right now. An as-of query reads it as it existed at a moment you pick. Same question. You just set the clock.
That makes point-in-time questions ordinary:
- How many centers were out of ratio on the morning of the incident?
- Which services depended on payments before last week's migration?
- What did this account's ownership look like at the start of the quarter?
The engine rebuilds the graph at that time, relationships and all, and runs your query against it. You're not querying a separate audit log. You're querying the graph itself, rewound.
Derived values read the same clock, so "as of last Friday" works for computed answers too. A staffing ratio evaluated as of a past time uses the data that was current then, not today's.
Entity history and trends
Every entity keeps its own version history. You can ask how a single field moved: when a service's owner changed, when a center's enrollment crossed a threshold, how a contract's value trended across renewals.
The graph becomes a record of change, not just a record of state. You see that something changed, when, and what it changed from. You didn't have to wire up a history system per source to get it.
The change feed
Alongside per-entity history, the graph exposes a change feed: what changed across the whole graph in a window of time. It answers the incident question directly. When production broke, what changed in the hour before? The feed shows the entities and relationships that moved, so you can trace from a change to the systems and teams it touched.
The change feed is also what triggers listen to. A rule that fires when a field changes, or when a deleted entity comes back, is reacting to this same stream.
Two clocks, and honest uncertainty
The graph tracks two timelines, which matters whenever accuracy does:
- When a fact was true in the real world.
- When SixDegree recorded it.
Usually they're close. They diverge when a source backdates a correction, or when we learn something after the fact. Keeping them apart means a backdated change lands on the day it was true, not the day we noticed.
The graph also records how it learned each fact. A value seen during a fresh discovery scan carries a tight, confident window. A value filled in later by a tool call carries a wider one. SixDegree won't present a guess as a precise fact. When the timing is uncertain, it keeps the uncertainty instead of rounding it away, and it uses source-provided timestamps wherever a source gives them.
You rarely touch this distinction directly. It works underneath every as-of query and history view to keep them honest. It's why a point-in-time answer reflects what was actually known and true then, not a guess stitched together later.
Using it
In the dashboard and in chat, just ask the time-bounded question: "as of April 10," "before the migration," "over the last quarter." The agent turns that into an as-of query, a history lookup, or a change-feed read.
From the structured query API, pin the reference clock on a query to read the graph as of that time. Per-entity history and the change feed come through the agent's graph tools.
Next steps
- Querying the graph: how the engine plans and executes, and where the reference clock comes from.
- Triggers: react to changes as they enter the change feed.