One bank, one question, and the architecture it takes to answer it properly.

A bank executive asks how many loans went bad. Three teams answer, three numbers come back, and every single query is correct. You will reproduce the disagreement in SQL, then find the thing that was missing.

You will pin down what Accuracy, Consistency and Explainability each actually require, and watch each one fail at Meridian in a specific way. Then you divide the work: language models handle fuzzy human input, symbolic reasoning hands down verdicts. The lab makes a scorer contradict itself five times in a row.

RDF has one data structure: subject, predicate, object. You will take Priya Raman's mortgage out of a relational row and write it as eleven triples, learn Turtle syntax properly, and see why adding a fact needs no schema migration. Named graphs arrive here quietly and pay off in Modules 7 and 11.

SPARQL does not join tables, it matches shapes. You will learn basic graph patterns, OPTIONAL, aggregates and property paths, then close the loop from Module 1 by writing Meridian's three definitions of default as three queries against one graph and getting 1,847, 4,102 and 1,203 back.

You have triples and you have SPARQL. What you do not have yet is a vocabulary that says what a Loan is, which loans cannot also be something else, and how many borrowers one loan is allowed to have. You will write that vocabulary in RDFS and OWL, starting from six real questions Meridian needs answered.

Tobias Fenn's loan application has no identity document attached. Your OWL ontology, with all its cardinality axioms, reports no problem whatsoever. This module explains why that is correct behaviour, and gives you the second language you need to actually stop the application.

You wrote the axioms in Module 5 and nothing happened. Now you run the software that applies them, and triples appear that nobody entered: L-1042 becomes a Loan, Mei Lin Tan's exposure group closes itself, and Meridian's three warring default definitions turn into three separately named, versioned, traceable classes.

Everything you built in Modules 3 to 7 assumed the triples were sitting in a graph store. Meridian's loans are not. They are 52,400 rows in a Postgres table that the core banking system writes to every night, and nobody is going to let you copy them. You will declare a mapping instead, and let SPARQL compile itself into SQL.

Module 7 closed the Module 1 loop by writing down what a defaulted loan is. This module closes it from the other side, by writing down what average processing time is. A capable language model will produce five defensible formulas for that phrase and five different numbers, which is a consistency failure that no better model fixes.

Meridian never lost its definition of arrears. Somebody wrote it down carefully in the Credit Policy 2026, in prose, on page 34, and then nobody could query it. This module builds the pipeline that turns that page into triples with a citation, and connects it to the ontology class it governs.

Everything you built in Modules 5 to 10 was correct on the day you wrote it. This module is about the day after. You induce an ontology from Meridian's schema, catch the two classes the machine got subtly wrong, and watch a materialized fact about Daniel Okafor's income quietly become a lie.

Nine modules of ontology, mappings, rules, reasoning, metrics and documents get wired into one agent. It answers the Tuesday question with a number, the definition behind it, the rows that support it, the rule that fired and the page of the credit policy where the definition was written down. Then it decides Daniel Okafor's application, and refuses to decide it alone.

The architecture works in a lab. This module is about the version that survives a year in production: what Meridian deliberately did not model, what their showcase-question test suite looks like, the seven anti-patterns that kill these projects, a phased roadmap with team sizes, and the full local-to-AWS migration map.