The ODIN
Design Manifesto

1. The problem with data catalogs today

In 2026, most enterprise data catalogs still work the same way they did in 2014. You crawl your data sources, extract table names and column names, optionally run a profiler, and store the results in a searchable index. Then you ask analysts to write descriptions and they don't, because they're busy and you end up with a catalog that is half-populated at best and actively misleading at worst.

The failure mode is consistent across vendors and tools. The catalog knows that a column named TRADE_AMT exists in a table called TRADE_BLOTTER. It does not know whether that amount is gross or net. It does not know whether it is pre-netting or post-netting. It does not know which currency it is expressed in, or whether currency normalisation has already been applied. It does not know whether the same concept appears in SETTL_AMOUNT in a different system or whether those two columns mean subtly different things.

A catalog that cannot answer those questions has not catalogued your data. It has catalogued the names of your data. That is a meaningfully different and much less useful thing.

The consequence is not theoretical. The 70% of analyst time spent finding and understanding data, rather than using it, is mostly spent resolving ambiguity that a well-designed catalog would have made unnecessary. The lineage incidents that cause regulatory failures are mostly failures to know which upstream systems feed which reports. The scramble before every audit is mostly a scramble to reconstruct meaning that was never captured in the first place.

ODIN is built on the conviction that this is not an inevitable property of data catalogs. It is a design choice; and it is the wrong one.

2. Meaning is not metadata

The word "metadata" has become so broad as to be nearly meaningless. Column names are metadata. Data types are metadata. Row counts are metadata. Business glossary terms are metadata. Lineage edges are metadata. Access control policies are metadata. All of these things are true, but treating them as equivalent obscures the most important distinction in data management: the difference between structural metadata and semantic metadata.

Structural metadata describes the shape of data. Semantic metadata describes its meaning. Most catalogs capture the former thoroughly and the latter not at all.

Semantic metadata is harder to capture because it requires domain knowledge. Knowing that TRADE_AMT corresponds to the financial concept of a monetary amount. Specifically, a pre-netting notional value expressed in settlement currency, as defined by the FIBO Financial Industry Business Ontology, requires someone who understands both the data and the domain to make that connection explicit.

The insight that shapes ODIN's design is that this connection can be encoded in a machine-readable form that is both durable and reusable. A SKOS exactMatch triple linking a data element to a FIBO concept IRI is not just a human-readable annotation. It is a formal assertion that survives system migrations, survives personnel changes, and can be reasoned over by both humans and machines.

This is why ODIN's logical model is built around semantic vocabulary mappings as a first-class concept, not a bolt-on feature. The mapping from a physical column to a controlled vocabulary concept is the most valuable artefact a data team can produce. Everything else (AI discovery, governance decisions, compliance reporting) becomes more reliable when that artefact exists.

3. Standards are load-bearing, not decorative

Open standards appear in data catalog marketing materials as a form of credentialing. "We support DCAT" is often shorthand for "we can export JSON-LD if you ask nicely." This is not what ODIN means by standards support.

In ODIN, the open standards are the metamodel. DCAT 3.0 defines what a dataset and a distribution are. DPROD defines what a data product is and what it means for it to have input and output ports and an owner and a lifecycle stage. CSV-W defines what a physical schema is. OpenLineage defines what a lineage event is. SKOS defines what a vocabulary mapping relationship is.

This matters for two reasons. First, it means the data you put into ODIN is portable by construction. You are not annotating your data assets in a proprietary schema that only ODIN can read. You are annotating them in W3C-standard JSON-LD that any standards-aware tool can consume. If you replace ODIN with a different catalog, or if ODIN is acquired and the business model changes, your metadata is not stranded.

Second, it means that the standards themselves do work in the system. FIBO is not a lookup table of financial terms. It is a formal ontology with defined relationships between concepts; relationships that ODIN can traverse. When you mark a field with fibo-fnd-acc-cur:Currency, ODIN knows that currency is a subclass of a medium of exchange, which is a subclass of a financial instrument, and it can expose that hierarchy in search and in AI context. The ontology is doing real work.

This is why ODIN ships with FIBO FND, FBC, SEC, MD, and BP pre-loaded, not as a marketing claim, but because a blank vocabulary store puts the mapping work back onto the teams least equipped to do it. The hardest part of semantic annotation is choosing the right concept. Making the right concepts available from the first login removes that friction.

4. Lineage is a first-class citizen

Data lineage has been described as a feature of data catalogs for at least fifteen years. In practice, it is almost always an afterthought: a separate system, manually maintained, and perpetually out of date by the time anyone looks at it.

The reason is architectural. Lineage is hard to capture automatically, hard to store efficiently, and hard to query at the traversal depths that make it useful. Most catalogs solve this by not solving it. They accept lineage metadata as an import, display it as a static diagram, and call it done.

ODIN treats lineage as a live graph query problem, not a display problem. The lineage-service stores lineage events in Apache AGE, a graph extension to PostgreSQL, and exposes them via Cypher queries that can traverse the graph in any direction to any depth. When you ask "what upstream systems feed this regulatory report?", ODIN does not retrieve a pre-computed answer. It runs a graph traversal.

The practical consequence is impact analysis that is actually usable. Before changing a source table schema, you can know with confidence every downstream report, model, view, and data product that will be affected. This is the thing that prevents the lineage-related incidents that cost teams weeks and regulators millions.

Column-level lineage is not optional for regulated industries. BCBS 239 and GDPR both require the ability to trace individual data elements from source to report. Row-level lineage tells you which table fed which table. Column-level lineage tells you which specific transformation of which specific field produced which specific value in which specific regulatory output. ODIN captures both.

5. AI needs contracts, not descriptions

Every data platform vendor now claims to have AI features. Most of them have the same feature: a natural language interface over a vector search index of column descriptions. You type a question, the system retrieves the columns whose descriptions are most similar to your question, and returns them as results.

This works tolerably well for simple cases. It breaks down in exactly the cases where it matters most: regulated industries, ambiguous column names, cross-system concept equivalence, agentic workflows.

The failure is not a failure of the AI models. It is a failure of the data layer beneath them. When you ask "which fields contain a monetary amount?" and the system retrieves columns based on the word similarity of their descriptions, you get columns that mention money. When you ask the same question against a catalog where every monetary field is annotated with fibo-fnd-acc-cur:MonetaryAmount via SKOS exactMatch, you get the columns that are monetary amounts. The difference is precision; and in financial data, imprecision is a compliance failure.

The deeper issue is agentic AI. As AI systems move from answering questions to taking actions: writing transformation pipelines, generating reports, triggering data product subscriptions. They need to know exactly what data they are operating on. A description is a suggestion. A vocabulary mapping is a contract.

An agent that knows it is handling a LegalEntityIdentifier can apply the validation rules, normalisation conventions, and regulatory reporting requirements that apply to LEIs without being told. An agent that knows it is handling "some kind of ID" cannot do any of those things reliably. Agents that operate on contracts are auditable. Agents that operate on descriptions are not.

AI as a metadata producer, not just a consumer

ODIN's AI layer does more than answer questions. It is also a tool for accelerating the semantic annotation work that makes the catalog valuable in the first place. For every logical model element, the AI service can suggest a data classification level: Public, Internal, Confidential, or Restricted. Then generate a plain-English business description grounded in vocabulary mappings and surrounding context.

These suggestions are never applied automatically. A data owner reviews each one and accepts or rejects it. This design choice is deliberate. AI-generated metadata that is applied without human review creates a catalog that looks populated but is not trustworthy. Human-reviewed AI suggestions create a catalog that is both efficiently populated and auditably correct.

The schema.org and FIBO IRIs that ODIN uses for vocabulary mappings appear extensively in the training corpora of every major foundation model. Annotating a data element with a FIBO IRI puts it in semantic proximity to everything the model already understands about that concept; zero prompt engineering required.

6. Ownership is accountability made explicit

Data governance fails when accountability is unclear. The most common governance failure is not a technical failure; it is an organisational one. Nobody knows who is responsible for a dataset, so nobody maintains its metadata, nobody is notified when its schema changes, and nobody can be held accountable when it causes a compliance failure.

ODIN treats data ownership as a first-class operational concept. Every dataset must have an owner. A specific, named individual who is accountable for its metadata quality and access governance. Ownership is not a label. It is enforced in the product: the data owner is the only person who can approve AI-generated classification recommendations, accept ownership transfer proposals, and make governance decisions about their datasets.

The role model is deliberately structured. Administrators can assign ownership directly. Data Governance Officers can propose transfers and nominate owners. Data Stewards can curate metadata and propose ownership changes. Data Owners hold the final accountability. These roles map to the ones that appear in actual data governance frameworks and regulatory guidance.

The governance dashboard makes the state of ownership visible at a glance. Outstanding transfer proposals, pending AI recommendation reviews, and a full activity feed for every dataset under a user's ownership. These are operational tools for people who are actually accountable for data quality, and who need to know when something requires their attention.

7. Open source is a governance prerequisite

There is a structural problem with proprietary data catalog vendors that is rarely stated plainly: a tool that you cannot inspect is not a governance tool. It is a governance dependency.

When your metadata, your vocabulary mappings, your lineage graph, and your access policies live in a proprietary system, your governance posture is hostage to that vendor's continued existence, pricing decisions, and strategic direction. When the vendor is acquired, when the pricing model changes, when the product is deprecated. In a market with this much consolidation, all three happen regularly, you are left rebuilding governance infrastructure from scratch.

This is a particular problem for regulated industries. You cannot credibly assert governance over data whose catalog is a black box. You cannot audit a system you cannot inspect. You cannot demonstrate compliance with a lineage record that is stored in a format you do not control.

ODIN is Apache 2.0 licensed. The source code is available. The schemas are documented. The APIs are standardised. You can run it on your own infrastructure, inspect every decision it makes, and migrate away from it at any time with your metadata intact: because your metadata is stored in W3C-standard formats that do not require ODIN to read.

Open source is not a business model choice. It is a governance design choice.

8. The UI is a reference implementation

ODIN ships with two web interfaces: a producer UI for data stewards and governance teams, and a consumer UI for analysts and data product subscribers. Both are built on the same REST API that every external system uses. There are no private APIs, no undocumented endpoints, no capabilities that are only available through the UI.

This is not a developer ergonomics decision. It is a commitment to a particular vision of what a data catalog is. A catalog that hides capabilities behind a UI is a product. A catalog that exposes all capabilities through a documented API is infrastructure.

Infrastructure can be composed. You can build an internal data portal that surfaces only the datasets relevant to a specific business unit, with branding that matches your internal tools, with workflows that match your team's actual processes, and it will use the same ODIN APIs that the reference UI uses. You can build a VS Code extension that surfaces lineage and vocabulary mappings inline when an engineer is writing a query. You can build a Slack bot that lets analysts ask questions in the tools they already use.

The producer and consumer interfaces shipped with ODIN show what is possible. They are starting points, not constraints.

9. The eight principles

These are the commitments that every design decision in ODIN is tested against.

Where this leads

The data governance problem is not going to be solved by better UI design or more aggressive sales motions. It will be solved when the infrastructure underneath governance tooling is semantically rich enough to support the claims that governance frameworks make; that data has documented meaning, documented lineage, documented ownership, and documented access control, in a form that can be verified by machines and audited by regulators.

Every major AI research lab is investing in knowledge graphs and structured data because they have discovered what data governance practitioners have known for two decades: unstructured text retrieval has a ceiling. The organisations that will get the most from AI over the next decade are the ones building semantic structure into their data now; not as a preparation for AI, but because semantic structure is what makes data governable, and governable data is what makes AI trustworthy.

ODIN gives you that structure today, on top of the data you already have. The design choices described in this document are not arbitrary. They are the result of a conviction that the catalog layer is the right place to build the semantic foundation that everything else depends on, and that building it on open standards, with open source code, is the only approach that is credible as governance infrastructure.