[[Fact-Based Modeling]] Meets [[Metadata-as-Code]] — Can [[FCO-IM]] Be the Semantic Backbone of [[Modern Data Architecture]]
💡 How the principles of Fact-Based Modeling could strengthen the next generation of metadata-driven and AI-assisted data platforms.
1️⃣ From Structured Models to Living Metadata
Over the past months, much of the discussion around data modeling has focused on tools — how legacy suites compare to Git-native environments, and how AI is reshaping the way we create and maintain models.
But a comment from Marco Wobben (author and long-time advocate of Fact-Based Modeling and FCO-IM) reminded me that, before any tool or automation, there must be semantic clarity. As he put it:
🔹“Every time something new arrives in the IT-scene, I realise how powerful this fact-based approach really is. Everything is an add-on, never a rewrite.”
That observation points to something essential: while technology stacks evolve, the meaning of the information we manage should not.
2️⃣ What Makes Fact-Based Modeling Different
Fact-Based Modeling (FBM) and its formal method FCO-IM were developed to express information as facts about the world, captured in natural language and grounded in mathematics.
Instead of starting with tables, attributes, or diagrams, FBM begins with statements such as:
“A customer places an order,” or “An order has an order date.”
Each fact is validated with business users and forms the building block of a conceptual schema. From this foundation, logical and physical structures can be derived automatically.
This inversion — meaning first, structure second — makes FBM unusually robust. It aligns naturally with today’s push toward ==metadata-driven architectures, where structure and code are outputs of well-defined semantics rather than starting points.==
3️⃣ The Common Ground with Metadata-as-Code
Metadata-as-code aims to describe models, mappings, and rules in open formats such as YAML or JSON, stored and versioned in Git, validated through CI/CD pipelines, and consumed by automation engines.
At its best, this approach enables:
- Traceability from concept to implementation
- Reuse across modeling, data pipelines, and documentation
- Continuous validation and deployment of metadata
However, many metadata-as-code frameworks lack a semantic model underneath. They describe structure well but not meaning.
That’s where fact-based modeling could fill a gap: its formal foundation ensures that each element in the metadata has a clear, validated definition — potentially expressed in machine-readable form and linked directly to the technical artefacts generated downstream.
4️⃣ How the Two Could Connect
Imagine a workflow where:
- Business users capture facts in natural language using a fact-based tool such as CaseTalk.
- Those facts are exported as structured metadata (JSON/YAML) following the FCO-IM grammar.
- A metadata pipeline translates the semantics into logical entities, dbt models, or physical schemas.
- AI assistants help enrich, document, and validate these models — but always anchored in the formally defined facts.
In this setup, FCO-IM provides the semantic engine, and metadata-as-code provides the operational infrastructure. One defines meaning; the other ensures scalability and automation.
5️⃣ Benefits of Bringing Them Together
- Semantic integrity — Every automated step remains traceable to validated business facts.
- Change resilience — When new requirements appear, existing semantics remain stable; only new facts are added.
- Human-AI collaboration — AI can safely generate or review models because the semantic rules are explicit.
- Unified lineage — Conceptual, logical, and physical artefacts share a single source of truth.
It’s not difficult to imagine FCO-IM constructs represented in a YAML schema and managed alongside dbt and transformation metadata — effectively turning fact-based modeling into an executable part of the data-engineering toolchain.
6️⃣ Challenges and Open Questions
Several practical questions remain:
- How can the richness of FCO-IM’s semantics be represented in a compact, machine-friendly format?
- What is the right balance between formal precision and accessibility for business stakeholders?
- Could an open standard emerge to describe “facts” as portable metadata objects, similar to how dbt models or JSON Schemas work today?
- How can AI be trained to understand and apply these fact structures correctly?
These are not trivial challenges, but the direction feels promising. Combining the clarity of fact-based modeling with the flexibility of metadata-as-code could help us move from static documentation to living, self-validating information systems.
7️⃣ Looking Ahead
Fact-based modeling reminds us that modeling is first about understanding, not drawing. Metadata-as-code brings the ability to operationalise that understanding across pipelines, tools, and AI systems.
If the two can be integrated, we may finally achieve what data architecture has been aiming for all along:
a shared language between business, engineers, and machines — precise enough for automation, clear enough for people.
It’s an area worth exploring further, and one I plan to study in the coming months.