Enterprise storage backend Enterprise
Transactional metadata for the context control plane.
MatrixKV is MatrixArk's enterprise, strongly-consistent, transactional KV backend for the context platform. It holds the small set of records the context path must trust before it acts — permissions, approvals, leases, ownership, and timestamps — so a prompt is built on facts that cannot be stale, duplicated, or half-committed.
Most of what the context platform serves tolerates eventual consistency: memory timelines, hot session state, cached summaries. A small slice does not. Whether a document is visible to this user, whether an action was already committed, which worker currently owns a lease — get these wrong and the model reasons over unauthorized, duplicated, or superseded context.
Why strong consistency matters here
The context control plane sits at three boundaries. Each one references records that must be read-your-writes correct at the moment of decision, not "correct soon". A stale permission read leaks context; a duplicate ownership record double-commits an agent action; a missed lease lets a paused worker keep writing. MatrixKV is the backend that commits and serves exactly these records.
- Before the prompt — permissions, source versions, tenant policy, and workflow locks the extractor checks before context enters the model.
- Before the action — idempotency keys, leases, approvals, and ownership transfers committed before an agent mutates product state.
- After the action — committed outcome ids and timestamps TemporalStore references later for replay, audit, and stale-action blocking.
MatrixKV is deliberately small and separate from MatrixDB. It is not high-volume memory or a general application database — it is the transactional boundary that keeps the few correctness-critical records the rest of the context path depends on.
# Before the prompt: is this source visible to this user, at this version?
GET perm:company_a:doc_913:user_918 -> "read"
GET source:doc_913:visible_version -> 7
# Before the action: commit ownership + idempotency in one transaction.
TXN
SETNX lease:gpu_batch:owner worker_44 EX 30
SETNX action:appr_913:commit 1
COMMIT
# After the action: record the committed outcome for replay + stale-blocking.
SET outcome:appr_913 '{"status":"approved","ts":"2026-06-14T16:20:00Z"}'Where MatrixKV sits in the context control plane
The transactional boundary the serving path consults at decision time — kept off the hot path.
MatrixKV commits the small strongly consistent records; MatrixDB serves eventually-consistent hot state; MatrixObject holds durable context data. TemporalStore stays the single serving surface.
When to use which backend
TemporalStore serves context everywhere. Reach for MatrixKV only for records that cannot be wrong.
| Backend | Consistency | Use it when |
|---|---|---|
| Local disk | Single node | Dev, edge, and self-hosted context footprints where one node owns its storage. Open source. |
| MatrixRaft | Replicated | Replicated high availability for context state without a shared-storage tier. Open source. |
| MatrixObject Enterprise | Durable shared | Disaggregated, concurrent, elastic capacity for durable context data at five-nines. |
| MatrixDB Enterprise | Eventual | High-throughput hot context state, profile KV, and cache metadata read on every request. |
| MatrixKV Enterprise | Strong / transactional | Small correctness-critical records — permissions, approvals, leases, ownership, timestamps — the context path must trust before and after acting. |