TTemporalStore.AI GitHub

Data models

Context is the flagship; the rest make the store broadly useful.

Each data model is a time-indexed primitive the engine understands directly — not a table you assemble by hand. Open a detail page for depth, or build your own when a workload needs one.

The data models

One flagship, composed from a handful of temporal primitives.

Every model stores per-entity state indexed by time, so the same reads — tails, windows, filters, and replay — work across all of them. Context Management is the model most teams reach for; underneath, it composes the supporting primitives, and each of those is useful on its own. All of it is persistent and memory-first: hot state serves from RAM while the engine moves data automatically across memory, SSD, and shared storage — durable by default, without a separate cache tier to keep in sync.

Each node is a first-class object in the engine; Context stitches them into agent memory.

Model detail pages

Open the three supporting data models directly.

These are not side notes. Long Sequence Feature, Aggregated Feature, and Control State are the reusable temporal primitives that make Context Management work, and each has a dedicated page with workload shape, read/write behavior, and examples.

At a glance

What each model stores, and when to reach for it.

ModelWhat it storesExample use
Context ManagementSession memory, tool traces, evidence, summaries, safety countersReplayable memory for an AI agent
Long Sequence FeatureLong, ordered per-entity event historyLast N interactions for a ranker or agent
Aggregated FeatureFiltered sum/min/max/count & grouped rollups over windowsFresh risk or campaign-spend features
Control StateBucketed counters, frequency caps, velocity checksRate limits and ad frequency caps
Distinct SetUnique devices, merchants, IPs, sessions in a windowFraud fan-out and abuse detection
ProfileLatest entity facts colocated with temporal historyStable identity context beside the timeline

Extensibility

Build your own data model for your workload.

TemporalStore data models are engine-aware objects with explicit commands over entity-local state. Adding a new data model is a small, testable recipe — not a fork of the engine. Enterprise backends like MatrixObject Enterprise and MatrixKV Enterprise plug in underneath without changing the model code.

1 · model

Define the object

Describe the per-entity state and its encoding — what lives in memory, dumps into pages, and recovers from WAL.

2 · commands

Declare commands

Add the model-aware write and read commands — append, increment, window, distinct — the engine runs at the shard.

3 · storage

Wire indexes & dumps

Register bucket and page bookkeeping plus any secondary indexes so dirty state persists and reloads correctly.

4 · proof

Add tests & benchmarks

Cover correctness, reload and replay, and a workload benchmark — then it is a first-class model in the store.