Semantic architecture · law, facts and data in one picture
Every Value Has a Reason
Law, terms, rules, facts and data in one grid. Meaning travels down, data travels across. The point is not the layers but the links between them: when a law changes, a system is replaced or an auditor asks why, you follow links instead of searching. The fact model in the middle is the one place that experts can check and generators can build from.
What the links buy you
Each layer on its own is ordinary practice. The value is in connecting them, and in putting one validated fact model where they meet.
Change once, know where
Follow the links down from the changed article or policy to every rule, shape, column and report it touches, and see what it does not touch.
Without the links: a search through code and spreadsheets, a meeting per system, and no proof that nothing was missed.
Agree on sentences, not columns
Experts cannot check last_order DATE, but they can check "C042 placed the last order on 14 March 2019". FCO-IM is the level that experts can verify and generators can use.
Without it: each system decides for itself what "customer" means, and the difference shows up in a report years later.
Map to the facts, not to each other
Five systems mapped pairwise need up to 10 mappings, each re-interpreting meaning. Mapped to one fact model, they need 5, and a sixth system adds 1 mapping, not 5.
Without it: mappings multiply and every column rename breaks someone downstream.
Answer with evidence
An auditor, a customer or an AI agent asks why C042's data will be deleted. The links answer with the facts, rules, terms and articles behind it. Each step can be queried and shown.
Without it: the answer depends on who remembers, and the evidence is put together by hand for every audit.
The grid
Each cell has its definition on top and a concrete example underneath: customer C042 in Utrecht, whose last order was on 14 March 2019. Arrow labels pair the general term with the concrete value. Pick a scenario to see which cells it involves. The grid shows one path per cell for readability; in reality each value rests on several facts and rules, definitions lean on other definitions, and articles overlap. The model keeps that whole network, so any path through it can be walked.
With the links
Without them
The grid is drawn by JavaScript; it appears once the page has loaded.
One model, more than facts
The grid draws the fact model as one row, but a CaseTalk model holds far more than object and fact types. Everything below lives in the same model, under the same identities and versions. That is why it can feed every row of the grid without copies drifting apart. The chips show which rows each part feeds.
Paragraphs
Documentation paragraphs inside the model: law articles, policy clauses, interview notes. They nest, and document roles link them to the types they are about.
§ RP-07 "Customer data is deleted 7 years after the last order." → documents Customer, LastOrder
Concepts and containers
Free concepts outside the FCO-IM realm, grouped in containers and related in concept maps, typed with ELM or ArchiMate.
Customer: ELM Person CRM: ArchiMate Application Component
FCO-IM: expressions, types, populations
Example sentences in the experts' words, the object, fact and label types qualified from them, their names in each model language, and the populations behind them.
Customer C042 lives in Utrecht. Klant / Customer · C042 Utrecht
FCO-IM: constraints, subtypes, derivations
Uniqueness, totality, subset, value and ring constraints with their verbalisation, generalisation and specialisation, and derivable types with documented calculations.
UC: one City per Customer Due date = last order + retention
Rules
Rules as elements of the model, linked to the fact types they read and produce, next to the constraints that FCO-IM already states.
RP-07 retention in: LastOrder · out: Due date
Business transactions
Transactions as model elements with their inputs and outputs, connecting the facts to the processes that create and change them.
Place order out: LastOrder
Levels 0 to 3
Instances, model, classifications and meta-classifications in one repository, linked by classification roles instead of kept in separate tools.
0 C042 1 Customer 2 Party type 3 classification scheme
Custom attributes
Typed, project-defined attributes on any element, alongside system attributes such as ring type and constraint scope.
legal.ref = eli/reg/2016/679/art_5 owner = Privacy Officer
Sensitivity and retention
A confidentiality tier and a retention period on each type, the period stored as an ISO 8601 duration.
Customer: Protected · P7Y
Mappings to physical data
Role paths bound to columns in external catalogs, which gives the source side of lineage.
\Customer\City → crm:srv\crm\This email address is being protected from spambots. You need JavaScript enabled to view it. _name
Every name, in every language
Anything that has a name can carry it in each model language: types, roles, readings, constraints, paragraphs, concepts. The law can stay in Dutch while systems and agents work in English.
nl Klant woont in Plaats en Customer lives in City
Versions and element lineage
Model versions, archives and Git history, and a globally unique identity on every element that records the model and version it came from. Links survive renames, merges and copies into other models.
Customer → Klant: same identity origin: CRM model v14 · merged into DWH v3
Open questions
Todos with bookmarks that point into the model, so doubts stay attached to the element they are about until someone answers them.
Are prospects customers? casetalk://…/otft/Customer
Imports, exports, artifacts
Read in from XSD, Turtle, XMI, FBM and ORM, and data catalogs. Generated out as SKOS, OWL, SHACL, FCO-IM RDF, DDL, Data Vault, XSD, TMDL, RegelSpraak, ArchiMate and more, through templates.
in: XSD · TTL · XMI · FBM · catalogs out: SKOS · OWL · SHACL · DDL · TMDL …
A single source of definition is only single if everything that needs a definition lives in it. Spread the same content over a glossary tool, a rules repository, a data catalog and a spreadsheet of mappings, and each copy drifts on its own schedule. Kept in one model, a rename, a new constraint or a changed retention period reaches the terms, the shapes, the schemas, the catalog and the AI context in the same step.
↓ Vertical: meaning
Law and policy are annotated and identified, their terms defined, their norms written as testable rules, and those rules expressed over fact types. Each row adds precision and keeps a reference to the row above.
→ Horizontal: data
Data moves from the source system through messages and APIs into integration, a knowledge graph and finally reports and agents. Each hop changes the shape, but the facts stay the same.
+ Where they cross
The fact model spans every system. Each logical schema is generated from it or mapped to it, so a mapping between two systems is a mapping between two shapes of the same fact type.
↑ Back up
Traceability runs the other way: from a value to its column, its fact type, and through the rules, terms and articles behind it. Catalog and lineage records make those paths queryable.
The semantic layer for AI
An LLM or agent does not read the grid row by row. It gets a slice of it as context, through MCP, a knowledge graph or a BI semantic model. Whether its answers can be trusted depends on two things: what happens to that slice when something changes, and whether it holds enough to answer without guessing.
When something changes
| Change | Context written by hand | Context generated from the model |
|---|---|---|
| Retention policy goes from 7 to 5 years | Wiki pages, prompts and embedded documents still say 7. The agent answers 7 with confidence, and nothing flags the old text. | The rule, its DMN table and its verbalisation are regenerated. The context carries model version and valid-from date, so the agent answers 5 and can say since when. |
CRM renames city_name | Generated SQL and examples point at a column that no longer exists, or that now means something else. | Only the CRM mapping of the fact type Residence changes. The agent still asks for the fact, and the mapping resolves it. |
| A new term appears in the business | The agent meets an unknown word and fills the gap with general knowledge. | The term has no concept and no fact type yet, so the gap shows up as missing coverage before anyone asks. |
| A source system is replaced | Every prompt, notebook and RAG index that mentions the old system needs to be found and updated. | The new system maps to the same fact types. The context the agent sees does not change at all. |
| A question arrives in Dutch | The context is in English, so the agent translates the terms itself and may pick a word the law does not use. | Every name exists in each model language, so the agent answers with the model's own Dutch terms, the ones the law and the business agreed on. |
| A model is merged into another | Copied definitions lose their origin, and nobody can tell which version an answer came from. | Each element keeps its identity and records the model and version it came from, so answers stay traceable across merges. |
How rich is rich enough
Each step adds something the AI can do and removes a class of wrong answers. A glossary alone is the most common semantic layer, and the least trustworthy.
- TermsRecognises the words.Still guesses how they relate, and which "city" is meant.
- Fact types with readingsKnows what connects to what, in sentences it can quote.Still invents cardinality: "customers and their cities".
- ConstraintsKnows a customer has one city, which values are allowed, what identifies what.Still unsure whether its reading of the model matches reality.
- ExamplesSees "C042 lives in Utrecht": real populations remove ambiguity and anchor answers.Can explain, but cannot fetch current data.
- Mappings and catalogKnows where each fact lives and queries it, instead of guessing at columns.Cannot say why a rule applies or since when.
- Rules, provenance, versionsCites rule, term and article, and knows which version it answers from.This is the level at which an answer can be checked.
Trust is tested, not declared
Keep a fixed set of test questions whose answers follow from the example population. Run them after every model change, the way unit tests run after every code change. Include questions the AI must refuse.
| Question to the agent | Expected answer | What it tests |
|---|---|---|
| Where does C042 live? | Utrecht | examples, mapping |
| Can a customer live in two cities? | No: one City per Customer | constraints |
| Whose data must be deleted before 1 June 2026? | C042, due 2026-03-14 under RP-07 v3, GDPR art. 5(1)(e) | rules, provenance |
| After the policy change: how long do we keep customer data? | 5 years since RP-07 v4; 7 years before that | versions |
| What is C042's credit score? | Not in the model; no answer | boundaries, refusal |
Coverage can be measured before any question is asked: how many terms have a definition and a source, how many fact types have readings and examples, how many columns map to a fact type, and how many rules cite an article. Low coverage predicts guessing. In CaseTalk these figures come from the model itself, and the MCP server serves the same model to the agent.
Built in: the AI works on the model, not beside it
CaseTalk does not only serve context to an AI. The AI can take part in the modeling itself, on the same single source as the human modeler.
A modeling assistant inside the tool
Chat and a modeling coach in CaseTalk, on the provider you choose: OpenAI, Azure OpenAI, Claude, Gemini, or a local Ollama model when data may not leave the building. DeepL for translating names and readings into other model languages.
Full agentic access for any MCP client
Around sixty tools let an agent read and change the model: expressions, types, roles, constraints, populations, paragraphs, transactions, mappings, custom attributes, refactoring, diagrams, todos and quality checks. The Portal serves published models over MCP for read-only use.
add_expressions · add_constraint · population add_paragraph · transactions · add_mapping refactor · model_quality · todos · diagram
An agent edit is a model edit
Changes made by an agent pass through the same verbalisation, constraints, quality rules, undo and versions as a change made by hand. Edits ask for consent first. The context an agent reads is the model it writes to, so nothing has to be synchronised afterwards.
- Readparagraphs, documents, existing schemas
- Proposeexample sentences in the experts' words
- Qualifyinto types, roles and constraints
- Confirmreadings and populations with the experts
- Checkmodel quality and the test questions
- GenerateSKOS, OWL, SHACL, DDL and the AI context
The agent drafts and the expert decides. Every step leaves the model in a state that can be read back as sentences, which is what keeps agentic modeling checkable.
Worth it, or not
The grid costs upkeep, and links maintained by hand go stale. Choose the rows that answer questions you actually get. Two things decide it: how many systems share the data, and how many rules come from outside (law, contracts, audit).
A good schema is enough
One application, its own data, little regulation. Model the facts if it helps the conversation, then build. The upper rows would cost more than they return.
rows 5–7Terms and facts as the integration hub
The pain is mappings and drift between systems. A shared vocabulary and fact model replace pairwise mappings. Legal annotation can wait.
rows 3, 5–7 + catalogTraceability first
The pain is proving compliance and explaining decisions. Link articles, terms and rules to the facts. There is little to integrate yet.
rows 1–7The whole grid
Government, finance, infrastructure. Every rule change and every audit question crosses both rows and columns. This is where the links pay for themselves.
rows 1–7 + catalog + lineageUpkeep stays low only when the lower rows are generated from the fact model rather than maintained beside it. That is the role CaseTalk plays here: SKOS, OWL, SHACL, DDL, XSD and TMDL come from one validated model, so the links come with them.
Download 15.1
Use Online