Vertical AI products need a production domain context layer.

Local context is not enough

A coding assistant can often answer from local workspace context. A vertical AI product needs live operational memory across systems: what happened across sessions, which facts are still valid, what the team already approved, what the customer was promised, which source version is canonical, and which prior action should not be repeated.

Why this can save tokens and improve answers

Many vertical agents burn tokens because they cannot tell which facts are current, which records were already superseded, which prior action failed, or which source version is safe to cite. A flexible context filesystem model lets MatrixArk send compact context packs: latest valid facts, recent deltas, open commitments, blocked stale memories, and citations instead of broad summaries or raw history dumps.

The vertical context filesystem

TemporalStore lets each customer define the hierarchy and fields that matter to its own domain. The shape feels familiar to AI applications because it is tree-like, but the records are typed, temporal, queryable, and replayable. The leaves are not files; they are customer-defined temporal records with timestamps, lifecycle state, permissions, source references, and declared serving indexes.

Make schemas simple for customers

Customers should not have to design indexes, hashes, query planners, or latency budgets. They should describe their domain in a small model file or through a UI wizard: what objects exist, how they nest, which timestamps matter, and which questions their AI application needs to answer. MatrixArk turns that simple definition into the full TemporalStore serving model behind the scenes.

create_context_model({
  template: "finance_project",
  name: "Company A project memory",
  hierarchy: ["company", "team", "project"],
  collections: ["approvals", "costs", "commitments"],
  common_questions: [
    "what is approved now?",
    "what did we already spend?",
    "what changed since last review?",
    "what should the model avoid saying?"
  ]
})

That is the customer-facing contract. MatrixArk infers timestamps, filterable fields, retention windows, context-pack sections, and indexes. Advanced teams can override them, but the default experience should feel like defining a domain workspace, not designing a database.

The customer contract should be small

The product should feel like a context SDK, not a database project. A vertical AI app should define a few business objects, send normal events, and ask for context packs. MatrixArk should own the internal model generation, index recommendations, online-query safety checks, and fallback routing.

customer-facing API:
  define_model(domain_objects, common_questions)
  ingest(record_or_event)
  get_context_pack(raw_user_query, hints, max_context_tokens)
  write_back(final_answer, tool_results, user_feedback)

MatrixArk-owned internals:
  schema compiler
  scope_hash planner
  secondary-index planner
  temporal query validator
  storage router
  context-pack renderer

Concrete model: Company A

A finance-focused AI assistant for Company A can define team and project context directly in TemporalStore. Normal serving queries should not require offline aggregation; the system ingests and queries bounded indexed records online.

collections:
  approvals:
    customer meaning: who approved what, when, and under which conditions
    examples: cloud budget approval, legal approval, manager exception
  costs:
    customer meaning: what was purchased, when, by whom, and for which project
    examples: GPU batch, vendor invoice, software subscription
  commitments:
    customer meaning: what is still open, promised, blocked, or expired
    examples: budget review due, approval missing, refund promised

How ingestion works

Ingestion is shared between MatrixArk and the calling application. MatrixArk can infer part of the ingestion model from the customer schema, common questions, observed records, and serving requirements: which fields become temporal context, which fields need indexes, which timestamps matter, and which records should be replayable. Other signals come directly from the agent app, workflow engines, webhooks, or customer backends calling MatrixArk APIs with explicit domain events and write-backs.

ingest_context_record({
  workspace: "company_a/platform_infra/project_1",
  collection: "costs",
  happened_at: "2026-06-11T14:15:00Z",
  data: {
    vendor: "aws",
    category: "gpu_compute",
    amount: 18420,
    status: "committed",
    instance_type: "p5.48xlarge",
    region: "us-west-2",
    purpose: "LLM eval batch",
    invoice_ref: "s3://company-a-finance/invoices/aws-2026-06-11.pdf"
  }
})

The customer sends normal domain JSON, while MatrixArk decides how much of the ingestion path can be generated automatically and where the application should call explicit APIs. MatrixArk maps records to the model, extracts timestamps and important fields, writes the base temporal sequence, writes the right HASH indexes, stores large objects by reference, and records enough metadata for replay.

Ingestion happens before and after the final LLM call

A vertical AI app should send MatrixArk context signals before asking for a context pack, then send the final LLM result and user/tool outcomes back afterward. This is how TemporalStore becomes living memory instead of a one-time retrieval system. Some signals can be inferred by MatrixArk from schema and query flow; others are explicit application API calls because the app knows the UI state, user action, selected object, and final answer.

// Before retrieval: capture current working state.
ingest_context_event({
  workspace: "company_a/platform_infra/project_1",
  event_type: "user_query",
  happened_at: "2026-06-12T10:00:00Z",
  data: {
    raw_user_query: "Can we buy another GPU batch?",
    active_page: "project_budget",
    selected_entity: "project_1"
  }
})

// After final LLM output: teach the next request what happened.
ingest_context_event({
  workspace: "company_a/platform_infra/project_1",
  event_type: "assistant_answer_final",
  context_pack_id: "ctx_123",
  happened_at: "2026-06-12T10:00:04Z",
  data: {
    answer_summary: "Another GPU batch is allowed if spend stays under $50,000.",
    accepted_by_user: true,
    new_commitments: ["Use spot instances where possible"],
    memory_updates: ["GPU spend decision should check Alice's June 10 approval"]
  }
})

Simple outside, optimized inside

Customers can think in filesystem-like paths: company, team, project, collection, record. TemporalStore does not serve those paths by walking a tree. MatrixArk compiles the path into a stable HASH scope, chooses the right indexes, and keeps serving keys shallow.

what the customer sees:
  /company_a/platform_infra/project_1/costs/by_category/gpu_compute

what MatrixArk creates inside TemporalStore:
  scope_hash = hash(company_a, platform_infra, project_1)

  customctx:{model}:{scope_hash}:costs:seq
    key = purchased_at | cost_id

  customctx:{model}:{scope_hash}:costs:idx:by_category
    key = gpu_compute | purchased_at | cost_id

  customctx:{model}:{scope_hash}:approvals:idx:by_status_type
    key = approved | cloud_budget | approved_at | approval_id

This is more flexible than filesystem context. The customer gets readable layers and business words. MatrixArk owns the hard parts: HASH layout, index selection, timestamp ordering, scan limits, freshness rules, and prompt rendering.

Serving-time query

When the user asks a domain question, the calling application does not need to construct TemporalStore filters itself. There are two clean integration options. Option 1: the app already understands the user query and sends MatrixArk schema'ed input, such as task type, needed context, domain terms, and UI hints. Option 2: the app sends the raw query directly and MatrixArk performs query understanding, context planning, validation, and store routing.

// Option 1: app sends schema'ed input after query understanding.
get_context_pack({
  workspace: "company_a/platform_infra/project_1",
  raw_user_query: "Can we buy another GPU batch?",
  schema_input: {
    task_type: "purchase_decision",
    needed_context: ["latest_budget_approval", "committed_gpu_spend", "open_commitments"],
    domain_terms: { "GPU batch": { collection: "costs", category: "gpu_compute" } }
  },
  hints: {
    active_page: "project_budget",
    selected_entity: "project_1"
  },
  max_context_tokens: 3000
})

// Option 2: app sends the raw query directly.
get_context_pack({
  workspace: "company_a/platform_infra/project_1",
  raw_user_query: "Can we buy another GPU batch?",
  hints: {
    active_page: "project_budget",
    selected_entity: "project_1",
    local_summary: "User is reviewing GPU spend."
  },
  max_context_tokens: 3000
})

In Option 1, the app owns the first query-understanding step and MatrixArk validates the schema'ed request before serving context. In Option 2, MatrixArk owns query understanding and maps phrases like "GPU batch" and "can we buy" to the customer's model. In both options, MatrixArk chooses stores and sends structured, bounded inputs to TemporalStore. The final model receives the context that matters now, not a raw dump of every record. That is where token savings and quality improvements can come from: less irrelevant history, more valid state, and clearer citations for the answer.

MatrixArk plans; TemporalStore serves

MatrixArk owns the safe serving plan. It can use a small planning LLM to understand the raw user query, or it can accept schema'ed input when the calling app already did that first query-understanding pass. Either way, a deterministic planner validates the plan against the customer's schema, permissions, indexes, and serving thresholds. TemporalStore receives only structured, bounded queries.

MatrixArk context-planning LLM output:
  task_type = purchase_decision
  needed_context = [latest_budget_approval, committed_gpu_spend, open_commitments]

MatrixArk deterministic serving plan:
  approvals.latest_active(type = cloud_budget, as_of = request_time)
  costs.sum(category = gpu_compute, since = approval.valid_from)
  commitments.open(scope = project_1)
  stale_context.blocked(scope = project_1)

If the request is too broad:
requires_offline_aggregation({
  reason: "query exceeds online filter and scan guardrails",
  rejected: ["cross_project_scan", "fuzzy_filter", "group_by"],
  suggestion: "narrow scope, use declared index, or read SummaryFact"
})

Agent apps may send hints because they know the UI and local state. They should not need to send TemporalStore index names, HASH keys, SQL, or storage routing choices. MatrixArk owns those details so the calling application can stay infrastructure-agnostic.

When TemporalStore is not the right engine

TemporalStore protects the prompt-time serving path. Some customer questions are too broad or exploratory for that path: arbitrary JSON filters, fuzzy search, all-team scans, long-range reports, joins, and group-by analytics. MatrixArk still supports those use cases, but routes them to the right layer instead of forcing TemporalStore to behave like an OLAP database.

same customer event:
  approval/cost record arrives once

MatrixArk storage plan:
  TemporalStore:
    latest active approval, recent costs, open commitments
  MatrixDB:
    project current-spend summary, active session, cache metadata
  OLAP / HSAP:
    full JSON event, long-range analysis, dashboards, ad hoc filters

future prompt:
  OLAP result -> SummaryFact -> TemporalStore context pack

This keeps the customer experience simple. The app sends the raw request and optional hints. MatrixArk decides whether the answer should come from TemporalStore, MatrixDB, an OLAP/HSAP layer, or a precomputed summary written back into TemporalStore.

Why this is a flagship use case

Vertical AI products are a natural buyer because their core challenge is not generic chat memory. Their challenge is domain context: custom objects, time validity, team decisions, approvals, source versions, permissions, and replayable prompt inputs.

The product message

MatrixArk gives vertical AI companies the missing backend for domain context: time-aware memory, custom data models, online serving queries, stale-context blocking, runtime reuse signals, and replayable context packs.

The application keeps the interface, workflow, model, and prompt style. TemporalStore provides the context filesystem behind it: what happened, what is valid now, what was approved, what is stale, and what should enter the prompt.