# Data and state

> Databases, object storage, vector indexes, and session state for AI workloads: provisioned on demand, owned, and backed up.

Source: https://brocs.fyi/run/data-and-state/
Part of the surface: R · Run. Give the work somewhere to live.
Framework: BROCS (Build, Run, Observe, Control, Secure), brocs.fyi. CC BY 4.0, attribute to brocs.fyi.

---

## The Run surface

- Runtime: where apps and agents actually execute
- Data and state: provisioned, owned, backed up
- Secrets: injected at runtime, never in code or chat
- Provisioning: self-service, provision-build-deploy as one motion
- Portability: the runtime goes where the data goes


Every AI application accumulates state faster than its builders expect. Conversation
history, uploaded documents, generated artifacts, vector indexes, evaluation results,
and the prompt log. Most of it appears without a provisioning request, because it started
as a file on a laptop.

## The stores you will end up with

**A primary database.** Ordinary application data, and the one people remember to ask for.

**Object storage.** Uploads and generated files. Usually the first store to be created
by hand, and often the one with the most permissive access policy in the estate, because
a builder needed a URL that worked.

**A vector index.** A copy of your documents, chunked, with the original text usually
stored alongside the embeddings. This is the store most likely to be missing from your
data catalogue while containing the most sensitive material. See
[data access](/build/data-access/).

**Session and conversation state.** Often in whatever cache was nearest. Frequently
contains full prompt and response history, including whatever a user pasted in.

**The prompt log.** Discussed in [Build](/build/data-access/); repeated here because
teams reliably forget it is a data store with a retention obligation.

Each needs the same four properties as any other production store: an owner, a
classification, a backup, and a retention period. The failure mode is not that these are
hard. It is that they were created outside the process that would have asked.

## Provisioned, not hand-built

A store created by a person in a console has no template, no tags, no backup policy
unless they remembered, and no reproducibility. A store created by the platform has all
four because they were decided once.

This is the strongest argument for self-service [provisioning](/run/provisioning/): not
speed, though it is faster, but that the defaults come along for free. The team asking
for a database should not have to know your backup standard in order to comply with it.

## Backups you have actually restored

The uncomfortable question is not whether backups run. It is whether anyone has restored
one.

For AI workloads there are two specific traps. The first is that the vector index is
often treated as a derived artifact that can be rebuilt, right up until you discover
rebuilding takes eleven hours and costs real money in embedding calls. The second is that
conversation history is frequently the only record of what a system told a user, which
makes it evidence as well as data.

Schedule a restore drill. Put it in the calendar with a name attached. An untested backup
is a belief, not a control.

{{< aside title="How data engineering thinks about this" >}}
A data engineer will ask about lineage first: where did this index come from, what
produced it, and what happens when the source changes. That framing is the right one. A
vector index is a materialised view over governed data, and the questions that apply to
any materialised view apply here: freshness, invalidation, permission inheritance, and
deletion propagation.
{{< /aside >}}

## Deletion has to propagate

When a customer asks to be deleted, or a document is withdrawn, the record has to leave
every copy: primary database, object storage, vector index, conversation history, prompt
log, and any backup you keep long enough for it to matter.

Most AI stacks fail this test on at least two of those, usually the index and the log.
Working out the answer before someone asks is considerably cheaper than working it out
during a regulator's timeline.

{{< checklist >}}
- List every store your AI applications write to. Does the list include the vector index
  and the prompt log?
- Which of those stores has a named owner and a classification?
- When did you last restore one of them, on purpose, as a drill?
- If a document is deleted from the source system, what removes it from the index, and
  how long does that take?
- How much would it cost, in time and money, to rebuild the vector index from scratch?
- Who can read the conversation history table today?
{{< /checklist >}}