Architecture · July 21, 2026 · 7 min read
Why dataset metadata belongs in the control plane—and dataset bytes do not
A dataset used to evaluate an AI system needs a durable identity, immutable content, and a reviewable lineage. Those requirements are best met by a registry and an artifact store working together—not by asking one database to impersonate both.
It is tempting to think of a dataset registry as a file upload screen with a table behind it. That framing misses the important architectural split. A dataset has two very different parts: the facts needed to govern it, and the bytes needed to reproduce it.
The facts are small, relational, and highly connected. Name, version, checksum, record count, schema version, owner, lifecycle state, and the experiments or evaluations that reference the artifact belong in a control plane. The bytes are potentially large, streamed, immutable, and best served by object storage. Treating either side as incidental makes the other side harder to trust.
Metadata is the governance surface
When an operator asks which dataset produced an evaluation result, they rarely need a raw download first. They need to know the exact version, whether it is still the active baseline, how many records it contains, what schema it claims, where the immutable artifact lives, and which work depends on it.
That is registry metadata. It supports references, lineage, audit history, lifecycle controls, and precise comparisons. A checksum is especially important because a human-friendly name such as support-evaluation-v1 is not enough to prove that two runs used identical bytes.
A dataset version is a governed claim about a specific immutable artifact—not merely a filename with a timestamp.
Bytes need an artifact store
Dataset files want different operational behavior. They should be streamed rather than loaded into a web process, addressed by deterministic keys rather than user-provided filenames, and protected against accidental overwrite. Object storage is designed for that job. A relational database is not made more governed by forcing large artifacts into a blob column.
Kavach writes dataset bytes through an S3-compatible contract. SeaweedFS provides the local development implementation and an inspectable Filer UI; AWS S3 or another compatible service can take the production role. The registry keeps an s3:// URI and artifact metadata, while the storage layer keeps the content.
Two systems means failure handling matters
Separating the systems introduces an honest distributed-systems problem: an object write and a registry write cannot share a normal database transaction. Pretending otherwise leaves confusing orphaned files or registry records that point nowhere.
The useful response is explicit behavior. Kavach validates the stream before registration, uses deterministic tenant-scoped object keys, rejects duplicate content according to registry rules, guards writes conditionally, and deletes a newly written object if registry creation fails. A future reconciliation job can strengthen the safety net further, but the primary path should already state what happens when only one side succeeds.
Immutability is practical
Immutable artifacts are sometimes described as a compliance feature. They are also a debugging feature. If an evaluation regresses after a model change, a stable dataset checksum removes one source of ambiguity. If a replay produces a different outcome, the operator can distinguish a changed runtime from a changed test set. If a decision is challenged months later, the organization can retrieve the artifact that its record actually describes.
This does not require turning Kavach into a data-engineering platform. The registry accepts a deliberately narrow set of evaluation-oriented file formats, records the artifact plane’s essential metadata, and stops there. Transformations, labeling, ETL, and warehouse governance remain separate concerns.
Replaceable storage is a feature
The S3-compatible boundary is more than deployment convenience. It lets local development use a lightweight object store while production adopts the controls, lifecycle policies, and regions appropriate to the organization. The governed dataset record remains the same because the control-plane contract is not coupled to the storage implementation.
That is the durable design: relational truth for the identity and relationships, immutable object storage for the artifact, and a graph projection that makes the dataset’s downstream consequences inspectable.