TemporalStore | Time-Aware Memory for Better LLM Context

Why TemporalStore is the right tradeoff

LLM context is not just a pile of semantically similar text. It is a stream of events whose usefulness changes with time. A decision from five minutes ago may be critical; the same decision after a policy update may be dangerous. TemporalStore's architecture matches that shape: timestamped events, valid-as-of reads, scope hashes, compact indexes, summary embeddings, decay scoring, compression windows, hot/cold paging, and replayable ContextPacks.

Freshness first

Recent, valid, high-authority context can beat older text even when the old text is semantically similar.

No ANN by default

Layer-by-layer traversal keeps candidates bounded, so TemporalStore can score summaries exactly without a VectorDB.

Better tokens

Exact scoring over bounded candidates helps the prompt budget carry more useful evidence and fewer stale or redundant chunks.

Less overbuild

Most prompt-time context can be served by one temporal engine instead of forcing VectorDB, graph DB, cache, and metadata DB into every path.

Natural decay

Older events can decay, compress into summaries, and move to persistence while staying replayable for audits.

Production fit

The same model runs local, cloud, on-premise, or distributed, with optional sync and Raft modes for strict workflows.

Hooked into agents, or standalone context infrastructure

TemporalStore can power MatrixArk in two product shapes. In hook mode, a Cursor-like agent or vertical AI product calls MatrixArk before the LLM, around tool/resource events, and after the final answer. In standalone mode, MatrixArk becomes a central context API for many applications that need ingestion, retrieval, feedback, audit, and replay.

Hook + cloud

AI harness vendors can call a managed MatrixArk endpoint while keeping their own local context and prompt UI.

Hook + on-premise

Enterprise agents can call MatrixArk inside the customer network for private context, audit, and model-provider control.

Standalone + cloud

Many apps share one managed context service when centralized operations are more important than local deployment.

Standalone + on-premise

Regulated teams run MatrixArk and TemporalStore as internal infrastructure with customer-owned keys and logs.

The same public APIs work in every shape. Deployment changes auth, network boundary, durability, observability, and model-provider configuration, not the customer contract.

Simple customer inputs, strict serving models

TemporalStore is strongest when it gives Cursor-like vertical AI products and enterprise Cursor-style workspaces a simple customer-facing context model and a strict internal serving model. Customers send normal inputs: messages, tool results, final answers, documents, tickets, approvals, costs, policies, corrections, and source references. MatrixArk extracts the time, scope, entities, facts, validity, permissions, and serving fields, then compiles them into scope hashes, declared collections, timestamp sort keys, secondary indexes, freshness windows, and request-time query budgets.

Customer sends

Raw query, lightweight hints, domain events, object refs, and optional app-provided understanding.

MatrixArk extracts

Entities, timestamps, validity windows, commitments, stale markers, permissions, source ids, and prompt relevance.

MatrixArk compiles

Scope hashes, collection keys, equality-prefix indexes, time ranges, retention, limits, and context-pack sections.

TemporalStore serves

Bounded online reads for latest facts, recent sequences, open commitments, stale-memory checks, replay, and prompt-time context.

Design principle: customer-defined JSON is allowed at the edge, but request-time serving must be compiled into declared indexed access. TemporalStore should not become an unbounded JSON filter engine in the prompt path.

Extraction and ingest: easy for customers, strict inside TemporalStore

MatrixArk should make ingestion feel like a simple context API, not a database modeling exercise. The customer or AI harness can send a raw message, a tool result, a final answer, a document reference, or a normal business JSON payload. MatrixArk then uses schema hints, deterministic parsers, and LLM extraction where useful to produce TemporalStore-ready records with bounded indexes and clear freshness rules.

1. Accept

Receive raw query, conversation turn, document, tool output, final answer, correction, approval, cost event, incident update, or policy change.

2. Extract

Identify entities, scope, event time, valid time, source, owner, action, commitments, decisions, numbers, status, and sensitivity labels.

3. Normalize

Map extracted fields to ContextEvent, EntityState, ContextSummary, ContextPack replay metadata, and optional vector/object references.

4. Compile

Choose collection, scope hash, equality-prefix index, timestamp sort key, TTL/retention, freshness rules, and serving threshold.

5. Write

Append events, update latest state, store summaries, attach source refs, and emit replay ids through the TemporalStore serving path.

6. Query

At prompt time, retrieve only bounded, valid, permissioned, fresh context that fits the requested token budget.

// Customer-facing ingest: simple and forgiving.
ingest_context({
  tenant: "company_a",
  source: "cursor",
  scope_hint: { team: "platform", project: "project_1" },
  kind: "tool_result",
  content: "Alice approved another GPU batch up to $80k until June 30.",
  source_ref: "s3://company-a/tools/purchase-approval-913.json",
  observed_at: "2026-06-14T16:20:00Z"
})

// MatrixArk internal extraction result.
ContextEvent {
  collection: "approvals",
  scope_hash: h("company_a|platform|project_1"),
  entity_key: "approval:gpu_batch",
  event_time: "2026-06-14T16:20:00Z",
  valid_from: "2026-06-14T16:20:00Z",
  valid_until: "2026-06-30T23:59:59Z",
  actor: "alice",
  amount_limit_usd: 80000,
  status: "approved",
  source_ref: "s3://company-a/tools/purchase-approval-913.json"
}

The important product choice is where complexity lives. Customers should not define TemporalStore hash keys, index names, or timestamp layouts. MatrixArk can accept hints from the harness, run extraction if needed, validate the result against tenant policy, and only then write the strict TemporalStore model.

Read path: raw query to prompt-ready context pack

The same boundary works for query-time context. A vertical AI product or enterprise workspace can send only a raw user request and lightweight hints, or it can send its own first-pass understanding to avoid another LLM call. MatrixArk converts that into bounded TemporalStore reads and returns the context sections that should enter the prompt.

Option A

The harness sends raw query plus scope hints. MatrixArk extracts intent, time range, filters, permissions, and token budget.

Option B

The harness sends raw query plus a structured plan. MatrixArk validates it and routes to TemporalStore directly when safe.

TemporalStore query

Use scope hash, collection, valid-as-of time, equality-prefix filters, timestamp range, limit, freshness, and deadline.

Context pack

Return current facts, recent timeline, open commitments, stale blockers, citations, replay ids, and token-budgeted summaries.

get_context_pack({
  tenant: "company_a",
  raw_query: "Can we buy another GPU batch this week?",
  hints: { team: "platform", project: "project_1", max_prompt_tokens: 1200 },
  as_of: "2026-06-14T18:00:00Z"
})

// MatrixArk plans internally:
TemporalStoreQuery {
  collection: "approvals",
  scope_hash: h("company_a|platform|project_1"),
  valid_as_of: "2026-06-14T18:00:00Z",
  filters: { status: "approved", entity_key: "approval:gpu_batch" },
  time_range: ["2026-05-01T00:00:00Z", "2026-06-14T18:00:00Z"],
  limit: 20,
  deadline_ms: 30
}

Filesystem-like graph, serving-engine execution

OpenViking-style context filesystems are useful because paths, folders, and resource trees are easy for agents and humans to understand. TemporalStore keeps that graph/tree model, but does not make low-latency context retrieval depend on filesystem metadata walks. It compiles logical paths into a temporal namespace: multi-layer prefix hashes, timestamps, validity windows, permissions, compression pointers, optional embedding references, and source-object references.

Logical path

/company/team/project/approvals/alice-budget.md remains readable for users, agents, debugging, and migration.

Hash chain

Every layer gets a stable prefix hash so browsing, listing, and subtree operations can be supported without POSIX filesystem semantics.

Serving hash

Hot prompt-time queries use compiled 3-5 layer hashes such as tenant/team/project, avoiding deep dynamic tree traversal.

External payloads

TemporalStore can store L0 embeddings for bounded traversal; VectorDB is optional for high-fanout ANN and L2 chunks; S3 keeps raw sources.

ContextNode {
  logical_path: "/company_a/platform/project_1/approvals/alice-budget.md",
  scope_layers: ["company_a", "platform", "project_1", "approvals"],
  scope_hash_chain: [h1, h1_h2, h1_h2_h3, h1_h2_h3_h4],
  serving_scope_hash: h("company_a|platform|project_1"),
  valid_from: "2026-06-10T09:30:00Z",
  lifecycle_state: "active",
  embedding_refs: ["local://l0/node_approval_001", "milvus://matrixark_context/emb_chunk_456"],
  object_ref: "s3://company-a/raw/approvals/alice-budget.md"
}

Deep paths are allowed for exploration, migration, and UI browsing. Low-latency LLM serving uses compiled scope hashes, declared indexes, validity windows, temporal compression, and token budgets. That is the practical difference between a context filesystem and a context serving engine: the interface stays intuitive, while the request path stays bounded.

Why this is faster and simpler than graph or filesystem memory

Zep-style graph memory, Mem0-style memory APIs, and OpenViking/VikingMem-style context hierarchies are strong signals that the market wants structured memory. MatrixArk's bet is that production speed and maintainability come from compiling that structure into a small serving plan before the model call.

System style	Common strength	MatrixArk advantage
Zep / graph memory	Relationships, observations, temporal facts, and global graph context.	MatrixArk starts from tenant, user, session, project, workflow, or object scope, so most requests avoid broad graph expansion and read bounded temporal records first.
Mem0 / simple memory API	Developer-friendly add/search memory with persistent personalization.	MatrixArk keeps the simple product surface, but makes memory operational: source freshness, valid-time reads, native compression, replay ids, and explicit storage boundaries.
OpenViking / VikingMem filesystem-like memory	Hierarchical context that agents can browse and reason about.	MatrixArk keeps the hierarchy, but compiles hot paths into prefix hashes, indexes, compressed state, and ContextPacks instead of walking folders plus separate metadata and vector stores at request time.

Faster

Scope-first reads, prefix hashes, declared filters, and exact scoring on bounded candidates reduce request-time fanout.

Simpler

One TemporalStore path owns events, latest state, summaries, embeddings, compression, replay refs, and prompt packs for the core context workload.

More maintainable

The product API stays high level while storage internals stay typed, indexed, compressed, auditable, and recoverable.

Filesystem-like, but better

Paths remain readable, yet the serving engine can choose hashes, indexes, time windows, and cache layers without exposing that complexity to agents.

Filter-first tree traversal, then vector scoring

TemporalStore can support deep logical paths without turning prompt serving into filesystem traversal. Parent and child nodes are addressed by hash, cheap filters run first, and similarity scoring happens only on the remaining child summaries. Depth should not be the main limit: if each layer is a hash lookup plus bounded sibling scoring, traversal remains cheap. Leaf records then use declared temporal indexes for time windows, validity, permissions, status, actor, entity, and limits.

Parent layers

Use O(1)-style hash lookups, lifecycle filters, permission checks, valid-as-of checks, secondary indexes when fanout is high, and exact similarity over L0 summary sets.

Leaf layer

Run bounded TemporalStore queries on declared indexes, such as approvals by status/time or costs by vendor/category/time.

Optional ANN

Add Milvus or another VectorDB for broad semantic recall, cross-tree discovery, or very large L2 chunk search; large scale alone does not require ANN when layers and leaf reads are bounded.

Prompt evidence

Use L0 for navigation, selected L2 chunks for exact evidence, and optional L1 only for large or ambiguous nodes.

Traversal:
  parent_hash -> indexed child nodes
  filter tenant, scope, permission, lifecycle, valid_as_of
  score query_embedding vs child.summary_l0_embedding
  keep top_k branches

Leaf query:
  serving_scope_hash + leaf_category_id + collection
  + time_range + indexed_filters + limit + deadline

Serving guardrails: traversal is fanout- and deadline-bound, not depth-bound. A normal parent can score thousands of in-memory L0 child embeddings directly. A high-fanout cached parent can score tens of thousands, and approach 100k when vectors are cache-hot and streaming top-K is used. If filters are obvious, ContextIndex narrows the child set before vector scoring. The context request deadline should be separate from LLM extraction: TemporalStore traversal can target hundreds of milliseconds, while MatrixArk end-to-end retrieval should use a more generous budget because it includes query understanding, optional LLM extraction, query embeddings, filtering, and packing.

Why VectorDB is often not required: context trees usually have limited semantic layers, and the expensive work happens at leaf nodes. TemporalStore can first navigate with hashes, metadata filters, and summary embeddings, then fetch only a bounded threshold of leaf timelines with temporal filters such as valid-as-of, updated-after, event type, status, and result limit. Once the candidate set is small, exact/brute-force scoring is more accurate and deterministic than ANN approximation, and the token budget is spent on fresher, more informative context. That keeps large deployments in one serving store unless the product needs open-ended semantic search.

ContextPack is a replayable manifest, not a giant prompt blob

MatrixArk should store every returned ContextPack as a compact manifest: included record ids, blocked record ids, selected category path, source refs, validity decisions, token estimates, retrieval trace, and replay id. The AI harness combines the returned MatrixArk context with local files, current UI state, and its own instructions before the final model call.

Store by default

Plan id, context_pack_id, selected records, blocked stale records, token budget, source versions, and why each item was used.

Return to harness

Prompt-ready context text plus replay metadata, citations, blocked-context reasons, and stable section ids.

Optional full prompt

Store final prompt text only when the customer enables it; otherwise store hashes and MatrixArk-owned context sections.

Post-answer loop

Use context_pack_id with final answer, tool calls, and feedback to extract new memories, commitments, and corrections.

Memory intents become TemporalStore serving functions

Agent-facing memory APIs should stay simple, but MatrixArk does not need to expose a long generic memory-operation list. Internally, TemporalStore maps memory changes to a few serving functions: append evidence, refresh state, consolidate duplicates, expire stale facts, and preserve replay.

Serving function	TemporalStore execution	Why it matters
Append evidence	Append ContextEvent, assign scope, update indexes.	New memory becomes queryable immediately.
Refresh state	Append correction event, update validity interval, refresh EntityState.	Old facts remain replayable but stop entering current prompts.
Consolidate memory	Deduplicate related events and preserve source refs.	Similar memories consolidate without losing provenance.
Expire or forget	Expire, tombstone, or privacy-delete records according to policy.	Governance is enforced by the serving engine, not prompt code.

Production context data models

TemporalStore should not expose arbitrary JSON scans in the hot LLM prompt path. MatrixArk can accept flexible customer events at ingestion, then compile them into a small set of typed, bounded temporal models that are safe to query at serving time.

Model	What it stores	Serving use
ContextNode	Canonical domain node, parent hash, short summary, status, refs.	Fast lookup for project, ticket, approval, incident, matter, or memory node.
ContextEvent	Timestamped event with kind, status, actor, confidence, importance, text, source ref.	Recent facts, open commitments, tool history, user confirmations, stale checks.
ContextIndex	Secondary references by declared field, scope, and time.	Equality-prefix plus time-range retrieval without scanning all event JSON.
ContextDirty	Summary refresh markers with bounded propagation depth.	Async summary updates while event writes stay lightweight.
ContextAudit	Context-pack selections, blocked refs, token budget, query id, session id.	Replay, evals, governance, and why-this-context debugging.

Serving guardrails: time windows are validated and end-time inclusive, query limits cap returned matching records, index names are safe storage keys, confidence and importance are bounded, and summaries update asynchronously outside the event-write path.

Where MatrixArk routes temporal context

MatrixArk routes time-aware LLM context to TemporalStore: session timelines, tool-call history, prompt replay, memory deltas, open commitments, stale-memory detection, freshness counters, temporal windows, latest per-entity KV, and long behavior sequences. That is the opportunity: most LLM stacks still treat time as logs or TTLs, not as a request-time context primitive.

Portfolio routing: if the value is needed for serving, latest context, temporal KV, time ordering, filtering, replay, and prompt-time context assembly, MatrixArk uses TemporalStore first. MatrixDB is added only for database-specific needs such as Redis-compatible online/offline/nearline KV, multi-tenancy, very large profile or summary KV, scans, exports, and tens of millions of QPS; MatrixKV is added only for low-volume permissions, ownership, approvals, leases, and workflow truth that need transactional correctness or strong consistency.

Read the MatrixArk routing guide

Product Advantages

Why TemporalStore for LLM context?

01

Context is temporal

Prompts depend on recent actions, open commitments, superseded memories, tool failures, and state transitions. TemporalStore keeps that timeline queryable so the prompt can say what to use, avoid, refresh, or replay.

02

Replayable agents

Store tool events, retrieved context, memory diffs, prompt packs, and committed actions so teams can debug and evaluate agent behavior later.

03

Extremely performant serving

Serving workers, typed models, durable update streams, and shared-store recovery target low-latency ingestion and request-time context queries.

04

Freshness and counters

Windowed counters, recency features, rejection signals, and safety limits help decide which memories should enter the prompt now.

05

Portfolio routing

MatrixArk can route time-aware memory to TemporalStore, hot and nearline KV to MatrixDB, and canonical facts to MatrixKV behind one product surface.

06

LMCache companion

TemporalStore works beside LMCache-style runtime reuse by separating stable prompt sections from volatile timeline, permission, source-version, and memory sections that must refresh.

Why TemporalStore Is Different

It turns temporal memory into a low-latency serving primitive.

That is why TemporalStore matters: the same system can record what happened, serve fresh context in the request path, replay what the model saw, and decide what memory should be trusted, ignored, reused, or refreshed. Most teams can build a demo with a vector database, prompt template, Redis cache, and logs. Customers feel the pain when the agent must answer with the right memory, at the right time, under the right permission, and then explain exactly why that context entered the prompt.

Better than raw logs

Logs are for inspection after failure. TemporalStore serves ordered timelines, windows, counters, and replay records during the request.

Better than cache-only memory

Cache keys are fast but fragile. TemporalStore gives durable, typed, queryable memory that can recover, replay, enforce freshness rules, and explain why context was used.

Better than vector-only RAG

Semantic similarity is only one signal. TemporalStore adds recency, sequence, open commitments, repeated failures, source freshness, time-valid behavior, and cache eligibility.

Better customer fit

Vertical AI builders, enterprise AI teams, and local evaluators can start with the Rust TemporalStore open-source release planned for July 2026, while MatrixArk keeps broader state-engine choices behind the platform surface.

KV-cache control plane

Feed LMCache-style systems stable prompt sections, reusable source packs, Redis-compatible metadata keys, invalidation signals, and freshness decisions while keeping volatile memories outside the runtime cache.

From sequence features to custom temporal context models

The direction for TemporalStore is to extend sequence feature serving into customizable temporal context serving. Vertical Cursor-like products should be able to define their own hierarchy, typed records, indexes, filters, freshness rules, and serving guardrails, then query fresh context online without forcing normal LLM requests through offline aggregation.

Customer logical model

Company, team, project, matter, ticket, claim, or incident layers with collections such as approvals, costs, policies, tool history, and memory deltas.

Compiled serving model

Deep customer hierarchy is compiled into scope hashes, declared indexes, sort keys, and time shards so serving avoids expensive tree walking.

Bounded online queries

Only declared indexed filters, scoped time windows, limits, query budgets, and collection caps run in the request path.

Offline only when needed

Large scans, many filters, fuzzy matches, joins, group-bys, and multi-year analytics become summaries written back into TemporalStore.

Example: a finance Cursor can model Company A, Platform Infra, Project 1, approvals, and costs. TemporalStore can answer "Can we buy another GPU batch?" by serving the latest active approval, current committed spend, remaining budget, stale approvals, and missing approval warnings directly from bounded online context queries.

Context-first architecture

Context API / SDK Router Serving worker Temporal model Durable event stream Replayable store

TemporalStore keeps namespace, table, key, and model-aware temporal state close to the prompt-serving path. SDK writes append context rows, tool events, memory deltas, counters, and long sequences, while queries read bounded windows with filters for prompt-time assembly.

Serving Workflow

Ingest a session event, tool call, memory diff, counter update, behavior append, or context record.
Resolve namespace, table, key, and model.
Apply updates through the typed model instead of service-side glue.
Answer timeline, sequence, replay, window, filter, risk-signal, and context queries online.

Scenario Architecture

One high-QPS serving path for prompt context, memory updates, and replay.

Ingest

Application events, stream consumers, SDK writes, and repair jobs write the same entity timeline or aggregate object at production serving scale.

Store

Serving workers update typed records, append durable update streams, and keep shared-store state ready for replay.

Serve

LLM systems request timelines, replay records, freshness counters, long behavior sequences, ad hoc filters, and prompt-ready context through one low-latency serving API.

Architecture Comparison

From multi-system context stacks to one TemporalStore-first serving path.

Zep, Mem0, OpenViking, and VikingMem all validate the need for structured memory. MatrixArk keeps the useful ideas, then removes two common sources of production complexity for scoped LLM context: mandatory VectorDB serving and custom ingestion pipelines per application.

Architecture	Typical before	MatrixArk after
Graph memory	Expand graph facts, observations, embeddings, and app metadata before the prompt.	Use tenant, user, session, object, and workflow scope first; read bounded temporal records and only expand when needed.
Memory API	Simple add/search API, but production teams still wire freshness, replay, permissions, and storage separately.	Ingest through one context API; TemporalStore owns typed events, summaries, replay ids, freshness, compression, and prompt packs.
OpenViking-style filesystem	Browse paths, then coordinate filesystem metadata, VectorDB recall, object chunks, and prompt assembly.	Keep readable paths, but serve compiled prefix hashes, declared filters, compressed state, and optional evidence chunks.
VectorDB-first RAG	Chunk and embed broadly, retrieve semantically, then filter stale or unauthorized context late.	No VectorDB is required for the default path: TemporalStore filters by scope, time, validity, status, and permission before local scoring.
Custom ingestion pipelines	Each app builds extract jobs, cache keys, backfills, repair scripts, log joins, and prompt-specific materializations.	No complex ingestion by default: send raw events, hints, sources, and feedback; MatrixArk compiles them into strict TemporalStore records.

No mandatory VectorDB

Scoped LLM context usually knows the tenant, user, session, object, or workflow before retrieval starts.

No complex ingestion

Customers call one context API while MatrixArk handles extraction, schema validation, hashes, indexes, summaries, and replay.

Filesystem-like UX

Agents can still reason over paths and trees, but prompt-time serving uses storage-engine primitives.

Smaller hot path

Events, latest state, summaries, embeddings, compression, and audits stay in one TemporalStore-first boundary.

Architecture Innovation

A purpose-built temporal storage layer, not just RocksDB behind an API.

RocksDB is excellent embedded storage, but TemporalStore is designed around online temporal data models: hot typed state, durable update streams, retained records, multi-layer cache, replica reads, and compute/storage disaggregation. For hot update-heavy temporal data, generic RocksDB-backed serving can create much larger write amplification across encoded blob rewrites, cache mutation, LSM compaction, replay logs, repair jobs, and downstream materializations; TemporalStore's storage path is built to keep typed deltas, retained records, cache refill, and recovery in one model-aware flow.

Generic RocksDB-backed serving

Application logic
feature semantics in services Encode latest value or blob
model state outside storage Write generic KV engine
LSM write path and compaction amplification Cache, replay, repair jobs
extra write paths to operate

TemporalStore storage architecture

Typed SDK command
namespace, table, key, model Hot temporal state
windows, counters, sequences, filters Purpose-built durable state
update streams and retained records Shared store plus replicas
cache, recovery, read fanout

In-memory data models

EntityState
current object view Recent ContextEvents
fresh timeline ContextSummary
prompt-ready memory FreshnessRule
stale blockers

serve / compact / refill

MTCache

Multi-tier cache for hot entity state, recent windows, summary embeddings, compressed segment refs, and replay manifests.

flush / evict / recover

Durable storage

Update streams
append deltas Retained records
typed temporal rows Compressed segments
older same-object events Raw source refs
object store replay

One object/entity over time

old event t1 old event t2 old event t3 compressed + evicted to storage event t9 event t10 latest state

Older events for the same object can be compacted into summaries, validity windows, counters, and replay refs, then evicted to storage. TemporalStore keeps the newest events and current entity state hot for low-latency context serving.

Implementation Direction

C++ core performance, Rust TemporalStore open source in July 2026.

The performance-critical serving and storage implementation is designed around C++ for low-latency data structures, cache control, memory management, and high-QPS execution. The open-source TemporalStore direction is Rust, with the Rust version planned to open source in July 2026, so the community-facing implementation can emphasize safety, maintainability, and a modern systems-programming developer experience.

C++ serving core

Use C++ where low latency, memory layout, cache locality, and storage-engine integration matter most.

Rust open source

Open source the Rust TemporalStore track in July 2026, with safer concurrency and a clean systems API surface.

Shared model

Keep the public concepts consistent: namespaces, tables, typed updates, retained records, windows, and context reads.

LLM Context

Online memory and context features for LLM applications.

TemporalStore is not a transformer KV-cache runtime. It is the persistent online state layer around the model: the place to keep structured context, temporal memory, counters, retrieval metadata, and context signals that decide what should enter the next prompt, tool call, ranking step, or safety policy. It can integrate beside LMCache-style systems and remote cache layers that reuse model prefixes or attention KV state.

Session memory

Persist recent conversation turns, user actions, tool calls, and state transitions with time-aware retention and replay.

Context ranking signals

Serve freshness, frequency, recency, and interaction signals that help choose which memories or documents should enter the model context.

LMCache integration

Work beside LMCache or remote cache services for prefix reuse, model-runtime KV-cache reuse, repeated prompt segments, cache eligibility, and invalidation hints.

Tool-use timelines

Keep ordered tool results, errors, retries, and agent decisions as long context sequences for debugging and next-step planning.

Safety and policy counters

Track rate limits, abuse signals, topic frequency, user risk, and policy state with online windows and distinct counts.

Retrieval metadata

Store document impressions, clicks, feedback, source freshness, and retrieval history beside vector search instead of inside the vector index.

Personalization state

Serve user preference deltas, recent task history, account context, and behavior sequences for personalized agents and copilots.

Read the LLM context guide TemporalStore-first context serving Context ingestion flow Prefix and LMCache policy Recommendation patterns Ads serving patterns

Enterprise Deployment

On-premise-first by design for enterprise security and compliance.

TemporalStore can be deployed inside a customer cloud or data center without requiring raw prompts, vector indexes, or context metadata to leave the perimeter. This lets compliance-heavy teams use local data governance while still gaining enterprise-scale low-latency context serving.

Customer control

Customer identity, policy, and network controls remain local. Cursor-like harnesses call the local MatrixArk gateway, which returns pre-filtered context packs and replay identifiers.

Security controls

Tenant isolation, RBAC/ABAC, SSO/SAML integration, private PKI, and customer-managed encryption keys for data at rest and in transit.

Operational controls

Audit logging for ingest, query planning, and replay, plus role-scoped access for security and finance teams to explain every context decision.

Scale model

Use a local cluster for serving, with optional multi-region replication for DR and backup, or private networking for strict air-gap environments.

Recommended enterprise topology: Cursor/LLM harness -> MatrixArk context gateway -> TemporalStore serving workers -> local object/vector layer -> optional MatrixDB/MatrixKV. This keeps context planning and prompt packs local while allowing optional external retrieval for semantic recall.

Data Models

Built for LLM context engineering first, with typed temporal models underneath.

TemporalCounter

Counts and sums over keyed time buckets for velocity, caps, and online policies.

TemporalAggregate

High-cardinality filtered sum, min, max, count, and model-specific rollups over recent event state and bucketed dimensions.

TemporalDistinct

Unique merchant, device, campaign, IP, or session counts inside time windows.

Sequence

Long user, item, session, and agent action sequences with filters, timestamps, and high-performance online reads.

Hash/Profile

Latest user, account, tenant, document, or session attributes beside temporal context.

Context

LLM and agent context, tool timelines, session memory, retrieval metadata, preference deltas, and safety/rate counters.

Comparison

Alternative	Good at	TemporalStore difference
Redis / Redis Enterprise	Fast cache, strings, hashes, modules, and ephemeral serving patterns	TemporalStore adds typed timelines, filters, temporal windows, replayable prompt context, and durable shared-store recovery; MatrixDB keeps the Redis-compatible hot-state bridge.
Vector database	Semantic retrieval over chunks and embeddings	TemporalStore decides which memories, events, freshness signals, and timelines should enter the prompt now.
Logs plus cache	Trace capture and fast temporary state	Replayable context state, memory deltas, freshness counters, and prompt-ready timelines in one serving path.
Feature store	Feature definitions, lineage, training sets, and online lookups	TemporalStore focuses on LLM context timelines and prompt-time temporal state, with feature-serving patterns available as a secondary workload.
Prompt management	Prompt templates, versions, evals, and test cases	TemporalStore provides the live context substrate: memories, tool history, freshness, permissions, and replayable prompt inputs.
LLM observability	Trace collection, cost tracking, latency, and debugging views	TemporalStore governs context before the model call and stores enough state to replay why that context was selected.

Where TemporalStore fits

TemporalStore is the primary serving engine for time-aware LLM context engineering: timelines, memory deltas, tool events, temporal KV, latest KV, prompt replay, freshness counters, long sequences, persistence, and multi-layer caching. MatrixDB supplies the database layer only when teams need Redis-compatible online/offline/nearline KV, large profile or summary records, scans, exports, cheaper persisted storage, multi-tenancy, tens of millions of QPS, and familiar application APIs. MatrixKV supplies low-volume transactional KV when a permission, version, lease, approval, ownership record, or committed action must be correct.

Talk to MatrixArk

The best tradeoff for LLM context management.