A governed asset plane for AI systems: registry first, MLOps later

AI tooling has made the word registry unusually slippery. It can mean a model-serving catalog, a prompt editor, a dataset-labeling workspace, a feature store, or a dashboard that tries to summarize all of the above. Those systems can be valuable. They are not the control-plane problem Kavach is trying to solve.

For governance, an asset is an input to a claim. A prompt version, model revision, dataset artifact, and evaluation provider can all change what an experiment measures, what a replay reproduces, or why a policy allows a decision. The useful capability is therefore not an ever-larger authoring surface. It is a durable answer to: what exactly was used, how did Kavach learn about it, and what downstream work depends on it?

A registry, not another workbench

The new Kavach OSS asset plane is deliberately registry-centric. Studio provides four consistent surfaces: Prompt Catalog, Model Catalog, Dataset Registry, and Evaluation Providers. Each version has Overview, Versions, References, Lineage, and Audit History. Operators do not need to learn a different mental model for each kind of input.

The restraint is intentional. There are no prompt-quality leaderboards, model-cost dashboards, approval queues, drift heat maps, automatic recommendations, or dataset certification workflows in this layer. Those are operational-intelligence products. They may belong in a broader enterprise offering, but they should not obscure the underlying evidence model in OSS.

Ownership is not a label

One of the easiest ways for a governance system to overclaim is to present every prompt and model as if it created them. In practice, teams often use LangChain, custom services, provider SDKs, evaluation harnesses, or internal runtime platforms. Kavach sees the configuration because it is reported as evidence; it does not necessarily own the authoring lifecycle.

That is why asset provenance is persisted on each version. Managed means Kavach owns the asset record or artifact lifecycle. Observed means a runtime or evaluation producer reported what it used. Imported is reserved for future external-registry synchronization. The distinction is small in the UI and large in the architecture: it tells operators whether they are looking at a source of truth, a record of evidence, or a synchronized reference.

Prompts and models are commonly observed. Datasets are naturally managed when Kavach accepts and stores an immutable evaluation artifact. Evaluation providers are managed adapters: Kavach owns the contract that describes their metrics and capabilities even when a provider runs elsewhere.

Protect content without losing identity

Prompt governance has a practical privacy problem. The content that is most useful for evaluation can also contain customer policy, internal operating instructions, or application-specific intellectual property. Requiring every producer to export full prompt text would turn a governance integration into a data-exfiltration decision.

Kavach therefore accepts observed prompt metadata with an optional SHA-256 content hash. If a producer submits content, the catalog can display it. If it submits only the hash, Studio states that content is unavailable while preserving the version, source system, variables, references, audit history, and ontology lineage. A missing body is explicit evidence of a boundary, not a reason to invent a summary.

Datasets are artifacts, not rows in a web form

The dataset registry completes a different loop. An operator can upload UTF-8 CSV, JSONL, or NDJSON from Studio. Kavach validates the stream, calculates a checksum and record count, writes immutable content to an S3-compatible object store, and registers the resulting version. The relational registry keeps the URI, checksum, schema, owner, and lifecycle state; it does not pretend that dataset bytes belong in a control-plane database.

For local development, the Compose stack includes SeaweedFS. Its Filer UI makes seeded and uploaded artifacts inspectable without changing the application contract. In production, the same abstraction can target AWS S3 or another compatible implementation. The point is not the storage brand. It is that object identity is deterministic, content is immutable, and a failed cross-system registration does not silently leave a misleading asset record behind.

Lineage is the product

A CRUD registry can tell you that a prompt called support-assistant has seven versions. A governed asset plane should tell you which version an experiment candidate used, which evaluation runs measured it, which replay jobs reproduced it, and which governance decisions were informed by the resulting evidence.

Kavach projects those relationships into its ontology. Asset detail pages offer a bounded lineage view for orientation and an exact Graph Explorer link for deeper inspection. This is not an analytics claim: the graph is a projection of backend-owned facts, and its job is to make relationships reviewable rather than visually impressive.

A useful OSS boundary

The first integration surface is intentionally generic: producers submit observed prompt and model evidence over REST. There are no mandatory LangSmith, MLflow, SageMaker, Azure AI Foundry, or PromptLayer connectors in the OSS core. That keeps the data model useful for any runtime and avoids turning connector maintenance into the definition of governance.

More importantly, it preserves a clean upgrade path. External registry synchronization can later create Imported records without changing what an asset is, how its versions are shown, or how its lineage is queried. The registry stays a knowledge plane, not a collection of vendor-shaped tabs.

Good governance infrastructure should make boundaries visible. The asset plane does that for ownership, storage, content access, and downstream impact—before the organization is forced to reconstruct them during a review.