Enterprise Context Layer: Overlay Pattern

An overlay pattern that introduces enterprise semantics without modifying two decades of pipelines. Worked through single-family mortgage delivery.

Prakash Jaganathan · September 2, 2026 · 28 min read

The 5-minute version

Full article: 28 min · Nutshell: 5 min

There have been many discussions amongst practitioners around enterprise context layers — ontology, semantic layer, context graph. The concepts converge quickly. The practical questions are the harder ones, and much of the writing in this space skips right over them:

How would you practically build one over a 20-year data estate?
What does a quick win look like?
Who would do what?
How would you get stakeholder buy-in?

This article works those questions through as a design pattern I call the Overlay Pattern, steel-threaded across the single-family mortgage loan lifecycle. Three ideas from it seem to matter most to practitioners:

A non-intrusive design pattern. An overlay that adds semantics without touching the estate you already run. If the context layer is down, every existing job still succeeds and every dashboard still refreshes. That is the sentence that makes it survivable inside a large organization.

The economic argument. Central bindings scale with the number of source systems. Point-to-point reconciliation scales with the pairs between them. Ten systems produce 45 pairings; twenty produce 190. Once more than a handful of systems need to agree on the same term, central context becomes economically compelling, and the gap widens with every source added after that.

The operating model. Centralize the mechanism, federate the meaning. The team that owns the integrated data model owns the runtime and release pipeline. Domain owners sign off on what a term means. Source-system owners maintain the bindings for what they emit. Governance holds the tiebreakers.

Continue below for the full walkthrough — ontology and binding catalogue, decision traces, identity spine, federated resolution, and the RACI that makes it operate.

This is my perspective on how an enterprise context layer can be built in large organizations that have two decades of data foundations already in place. I have written it for the practitioner who has to propose this pattern inside their own organization: the architect who then sits across from the tech leader whose warehouse is being ringfenced, the platform engineer whose pipelines are being asked to stay untouched, and the business owner whose team owns the definitions.

The technical argument is the easy half; the rest of what follows is about how to get the pattern past the meeting where it might otherwise be killed, respectfully and with the grain of the room. I have picked an example from the secondary mortgage business (specifically the single-family loan lifecycle followed by GSEs such as Fannie Mae and Freddie Mac) because it is a domain I have been close to across my career, and one where the public data standards (MISMO, ULDD, UAD, the GSE Selling Guide) let me anchor the walkthrough in published detail rather than in anything proprietary.

Note: The standards, systems and regulatory dates referenced here are public. Every loan-level value in the worked example is invented for the walkthrough. Nothing here describes the internal architecture of any employer, past, present, or prospective, and nothing draws on proprietary or non-public information.

1The problem, stated honestly

Why the obvious answer is unaffordable, and what remains once you accept that.

Every large regulated enterprise has arrived at roughly the same analytics architecture, and it took about two decades to get there. Source-aligned ingestion into a data lake on a near real time cadence. An integrated data model beneath it that conforms and integrates across sources. Then consumption in two shapes: wide snapshots for analytics, dimensional marts for reporting. Thousands of pipelines run against that stack every day. Hundreds of downstream consumers depend on its output. The people who built the earliest parts of it have retired.

Into that estate arrives a new requirement. Agents need grounding. Regulators want to know why a decision was made. Executives want one definition of a term rather than four. The vendor answer is a semantic layer, and the vendor diagram always shows it sitting in the middle of the architecture, which means re-plumbing the middle of the architecture.

The constraint that kills the obvious answer: There is no cost-effective path to introducing a semantic layer that requires material change to the existing pipelines, the integrated model, or the marts. Not because the engineering is hard, but because the change management is impossible. You cannot ask four hundred pipeline owners to accept a new dependency, and you cannot remodel a twenty-year-old integrated model without a multi-year program that will be cancelled in year two when leadership changes.

So the design problem is not what is the ideal semantic architecture. It is what is the most semantics you can add while touching nothing.

What the estate already gives you, and what it does not

The instinct many partners will have is that conformed ETL already solved this. It did not, and being precise about why is the difference between a credible proposal and a rejected one.

The estate provides	Which means	But it does not provide
Conformed structure	Consistent grain, consistent types, consistent keys within the warehouse	Conformed meaning. A dimensional model can be immaculate and still carry four definitions of delinquency, because nothing in the model forces a business term to resolve to one thing.
Local keys	Joins work inside the warehouse	Stable global identity for the same real world thing across systems, and no place to record the aliases it carries elsewhere.
Foreign keys	Relationships you can join if you already know they exist	Relationships as first class objects you can traverse without knowing the path in advance.
Facts and dimensions	What was true, as of a load	Decision traces. What was asserted, by which system, under which rule version, at which moment. Dimensional ETL drops these because they are not facts in the dimensional sense.

Structure and semantics are separate problems. Solving the first does not solve the second, and two decades of excellent work on the first is exactly why the second is now the binding constraint.

2Design principles

Five rules. Every decision in the architecture falls out of them.

The invariant

Nothing in the overlay reads from a source system directly. It reads from the estate.
Nothing in the overlay writes to the estate. Ever.
Nothing in the overlay sits in the critical path of an existing pipeline.
If the context layer is down, every existing job still succeeds and every existing dashboard still refreshes.

That last line is what makes the proposal survivable inside a large organization. It is what lets an operational executive commit to the pattern without commissioning a separate risk assessment first.

Principle 1 · Bind to the integrated model, not to the lake or the marts

Not the lake. Source-shaped, volatile, no conformance work done. Binding an ontology there means re-doing the integration the estate already did, and re-doing it badly.
Not the marts. Grain and aggregation are baked in. The semantics are lossy by the time data lands there, and a mart is designed around a reporting question rather than around the business entity.
The integrated model. Already conformed, business-facing, slow to change, and owned by people who can sign off on a definition. It changes on the order of quarters, which is the same cadence as an ontology release.
The one exception is decision traces, which the integrated model has usually discarded. Those come from the lake, and that is the only second read path in the design.

Principle 2 · The ontology binds to the estate; the estate does not bend to the ontology

No new columns. No new tables. No remodeling.
If a term cannot be bound to something that already exists, that is a finding to record, not a change request to raise.
Unbound terms are useful information. They tell you what the enterprise cannot currently answer.

Principle 3 · Separate design time from run time

Authoring the ontology and authoring the physical bindings are design-time activities. They produce files, they are reviewed, they are versioned, and they are released on a cadence.
Deploying the model, building the identity spine and loading decision traces are run-time activities.
Conflating these is the most common failure. It produces a mapping that lives inside a transformation job, which means changing a definition requires a code deploy, which means definitions stop changing.

Principle 4 · The graph holds relationships; the estate holds values

Canonical nodes, aliases, edges and decision traces go into the graph.
The attribute payload stays exactly where it is and is reached at query time.
This is what keeps the graph small enough to be operable and cheap enough to be approved.

Principle 5 · The binding catalogue is the deliverable, not the graph

The graph is replaceable. If Neo4j is the wrong choice in three years, you rebuild it from the ontology and the bindings in a sprint.
The bindings are the accumulated institutional knowledge: which physical column carries which business meaning, at which lifecycle state, with what null semantics.
That knowledge currently lives in the heads of about nine people and in the comments of about four hundred ETL jobs.

Why this design becomes economically rational as the estate grows.

Suppose 10 source systems each hold a value for the term "delinquency," and all 10 need to agree on what it means.

Option A: reconcile every pair. Each pair of systems builds and maintains its own bilateral agreement. Ten systems have 45 possible pairs (10 × 9 ÷ 2). Twenty systems have 190. Each new system does not add one more reconciliation; it adds one for every system already in the estate.

Option B: bind each system to one central definition. Every system maps its value to the same shared meaning. Ten systems means 10 sets of bindings. Twenty means 20. Each new system adds exactly one set, whatever the size of the estate.

Bindings scale with the number of systems. Pairwise reconciliation scales with the number of pairs between them. Central context costs more to set up than any single bilateral agreement. But once more than a handful of systems need to agree on the same term, central context is already cheaper. And it wins more decisively with every source added after that.

3System context

Thirteen numbered boxes in four bands. Boxes 1 to 4 already exist and are not modified. Boxes 5 to 13 are the entire proposal.

Enterprise Context Layer system diagram: four bands (design time, existing estate, run time overlay, consumers) with thirteen numbered boxes and their read-only relationships

Click the diagram to view at full size. Read order: 5 to 8 is the build. 1 to 4 is what already exists. 9 through 12 are the run-time overlay. Box 3 is the only place the two worlds touch, and that contact is read-only in one direction and a query pushdown in the other.

4The boxes

What each one is, what it does, what it deliberately does not do, and what breaks if it is wrong.

1 Source systems Existing

Desktop Underwriter and Desktop Originator, the collateral portal and Collateral Underwriter, the closing dataset collection solution, Loan Delivery, and the servicing stack.
Emit MISMO XML, change data capture streams and files on the cadence they already emit them.
What changes: nothing. No schema change, no additional emission, no new endpoint, no awareness that a context layer exists.
This matters more than it sounds. The moment a source system owner has to do work, the proposal enters their roadmap negotiation and dies there.

2 Source-aligned data lake Existing

Near real time ingestion, source-shaped, minimal transformation, long retention.
Its value to this design is what it kept. Findings payloads, edit results with their warning and fatal codes, appraisal score rationale, rule versions in force, and the raw MISMO XML.
The integrated model discarded most of that, correctly, because none of it is a fact in the dimensional sense.
Read by box 10 only, and only for decision traces. Nothing else in the overlay touches it.
If it is wrong: you have a knowledge graph rather than a context graph. Still useful, considerably less defensible under examination.

3 Integrated data model Binding anchor

The conformed, integrated, business-facing layer. The enterprise's existing agreement about structure.
Two roles in this design. It is the source the identity spine is built from, and it is the physical target that attribute queries resolve against.
Chosen as the anchor because it is stable, already conformed, owned by people with authority to sign off on a definition, and it moves on a quarterly rhythm rather than a daily one.
What changes: nothing. Not remodeled, not extended, no new columns. The ontology binds to it as it stands.
Where its model is genuinely the best representation in the enterprise, the ontology adopts it and credits it rather than inventing a rival.

4 Analytics and reporting consumption Existing

Wide snapshots for analytics, dimensional marts for reporting, and every dashboard, extract and downstream consumer built on them.
Continues to serve everyone it serves today, unchanged.
The context layer does not replace these and does not compete for their workload. It answers the questions they were never shaped to answer.
Over time the definition service in box 13 can become the place a mart's business definitions are sourced from, but that is an opt-in migration per mart, not a precondition.

5 Ontology authoring Design time

OWL 2, authored in Protégé, serialised as Turtle, held in a repository.
FIBO supplies the upper model. The LOAN domain covers loan contracts across commercial, small business, automobile, education and mortgage categories, published in RDF and OWL on a quarterly release cadence.
MISMO supplies vocabulary, not structure. Both v3.0 as used by loan delivery and v3.6 as used by the redesigned appraisal dataset are mapped in as vocabularies. Neither is treated as the model. This is the mechanism that absorbs a version fracture rather than propagating it.
Core classes for this slice: Loan, Property, Party, Appraisal, and DecisionTrace. Deliberately small. The temptation to model the whole of MISMO is the thing that has killed most attempts at this.
Authored by architects. Signed off by the domain owner for each term. The signature is the political product; the file is just the artifact.
Output is files in a repository. Not a database. Nothing is running yet at the end of this box.

6 Physical binding catalogue Design time

Declares, for each ontology term, exactly where that meaning lives physically: schema.table.column, or a file path plus a JSON path, or an XPath into a stored message.
Expressed as R2RML or RML where the runtime is RDF, or as a mapping configuration where the runtime is a property graph. The pattern matters; the standard is optional.
Each binding carries more than a location: grain, null semantics, the lifecycle state at which that source is authoritative, and the lineage that produced the column.
Authored once per term and source. Maintained, not re-authored. What triggers maintenance: source schema drift, a standards version change, ontology evolution, or a new source system.
The catalogue is partitioned by the physical thing each binding points at, and owned by whoever owns that thing. Bindings that point at the integrated model are owned by the team that operates the integrated model. Bindings that point at source-anchored artifacts, such as XML emitted by an operational system, are owned by that source system's owners. Ownership follows the physical dependency, not the semantic one. This is the operating-model split section 8 will draw on.
Bindings scale with sources; point-to-point reconciliation does not. Each new source adds one set of bindings. Point-to-point reconciliation, by contrast, has to link the new source to every existing one. Ten sources produce forty-five pairwise reconciliations; twenty produce one hundred and ninety. This is the economic case for the whole design.
If it is wrong: queries return the wrong column with total confidence. This is worse than returning nothing, and it is why binding resolvability is a build-breaking check in box 7.

7 Version control and release Design time

Ontology and bindings live in the same repository and are tagged together as one release artifact. A release is a pair, never a file.
Continuous integration checks three things: OWL consistency, binding resolvability against the live catalogue of the integrated model, and breaking-change detection against the previous tag.
Binding resolvability is the check that earns its keep. It fails the build when someone renames a column in the integrated model, which turns a silent production defect into a red pipeline.
Semantic versioning, with release notes written for consumers rather than for architects.
This is the box that makes the economics work. When the appraisal dataset moves from one MISMO version to another, the change is an edit to a mapping file, reviewed and released. It is not a program with a steering committee.

8 Model deployment Design time to run time

Takes a tagged release and loads it into the runtime graph. In Neo4j that is neosemantics, usually invoked as n10s.rdf.import.fetch. In an RDF store it is a native Turtle load.
Ontology and reference data only. No loan data passes through this box. If someone proposes using neosemantics to load the instances, they have confused the model with the data.
Idempotent. Roll back by redeploying a prior tag.
Kilobytes to megabytes. Minutes, not hours. Runs on the same continuous integration infrastructure as any application deploy.
Critically, it does not run on the orchestrator that runs the estate. The overlay has its own deployment path so that a failure here will not page the team that owns the nightly load.

9 Identity spine builder Run time

A read-only reader of the integrated data model. It produces canonical Loan, Property and Party nodes and the edges between them.
Every source identifier is retained as an alias, never discarded. The casefile identifier, the lender's own loan number, the enterprise loan number, the MERS registration number, the pool number. A loan carries several identities before it is even purchased.
Deterministic matching where a shared key exists. Probabilistic matching for property, where address plus parcel number is the practical key because no universal property identifier exists, and for party across borrower and co-borrower.
Every match carries its confidence and its basis. A probabilistic match presented as a fact is a defect waiting to be found by an examiner.
Emits nodes and edges. No attribute payload. Volume is orders of magnitude below the estate.
Runs on the integrated model's own cadence, reading after that layer settles.
If it is wrong: everything above it is confidently wrong. This is the box that actually decides whether the program succeeds, and it is the least interesting one to talk about, which is why it gets underfunded.

10 Decision trace loader Run time

Reads the source-aligned lake rather than the integrated model, because this is the content the integrated model discarded.
Loads underwriting findings, appraisal score rationale, delivery edit results including warning and fatal codes, certification events and quality control determinations.
Each trace is an append-only event attached to the canonical loan node, carrying: the timestamp, the emitting system, the rule or model version in force, the outcome, the identifier it was keyed on, and the values as asserted at that moment.
Values on a trace are the one exception to principle 4. A trace is a record of what was asserted at a point in time. Reaching into the estate for the current value would defeat the purpose, because the current value is precisely what may have changed.
Immutable. Never updated in place. A correction is a new event, not an edit.
This is the box that makes it a context graph rather than a catalogue, and it is the box that answers an examiner asking what ran, on what, under which version.

11 Runtime context graph Run time

A property graph such as Neo4j, or an RDF store such as GraphDB or Stardog. The choice follows the query pattern, never the other way around.
Holds: the deployed ontology, canonical nodes, aliases, edges, and decision traces.
Does not hold: the attribute payload. Loading tens of millions of loans with hundreds of attributes each is how these implementations fall over, and it is the first thing a sceptical engineer will probe.
Answers three kinds of question: which things relate, how far apart they are, and what happened when.
Sized by relationships rather than by rows, which is what makes the infrastructure request modest enough to approve.
Read-only, outside the ETL directed acyclic graph, independently deployable, and restorable by rerunning boxes 8, 9 and 10 from scratch.

Choosing the store

If the workload is	Then	Because
Bounded depth, known path, aggregation	Relational or lakehouse	It is a join. Cheaper, mature, and you already have the staff. Worth naming early in the design conversation rather than defending after the fact.
Variable depth, unknown hop count, relationship discovery	Property graph	Recursive common table expressions degrade and you cannot index your way out.
Formal inference, classification against axioms, standards interchange	RDF triplestore	You need a reasoner and global identifiers, which a property graph does not give you.

12 Federated attribute resolution Run time

When a question needs values rather than relationships, this component turns a canonical key plus an ontology term into a physical read against the integrated model, using the bindings from box 6.
Implemented either as ontology-based data access, where a tool such as Ontop rewrites SPARQL into SQL, or as a query service that performs the same resolution explicitly.
Nothing is materialized twice. There is no second copy of the payload to keep in sync, and no reconciliation between the graph and the warehouse, because there is nothing to reconcile.
The pushdown is the only traffic the overlay sends toward the estate, and it is a read on the same interface any other consumer uses.
Honest limitation: this is slower than a materialized join. It is fine for conformance checks, agent grounding and investigative work. It is not how you back a dashboard that refreshes every thirty seconds. Name that boundary in the proposal, because it is a much cheaper way for the audience to learn it than discovery in production.

13 Consumers Run time

Agent grounding. Retrieval resolves against the model rather than against raw tables, which is the difference between an agent that answers and an agent that guesses plausibly.
Delivery conformance. Did we buy the loan we underwrote. Worked end to end in section 5.
Quality control targeting. Sample on relationship risk rather than at random.
Definition service. One definition behind every dashboard, with the marts themselves unchanged.
Audit evidence. What ran, on what, under which rule version, produced from the traces rather than assembled by hand ahead of an examination.

5Steel thread: one loan, end to end

Every value below is invented for this walkthrough. The mechanics are real; the loan is not.

The question this thread answers is the narrow, high stakes one at delivery. Is the loan being delivered the same loan that underwriting approved? The selling guide is explicit that the final underwriting submission must match the terms of the closed loan and must carry an eligible recommendation, and that representation and warranty relief is tied to those findings. So the question is not academic.

The loan

Attribute	Value	Where it lives
Enterprise loan number	9001234567	Assigned at delivery. Chosen as the canonical key.
Underwriting casefile	1451220987	Alias. Deterministic.
Lender loan number	LN-88213	Alias. Seller's own key.
MERS registration number	100012300000088213	Alias. Survives servicing transfer.
Pool number	AL7742	Alias. Present only for pool deliveries.
Property	4412 Old Mill Road, Ashburn VA 20147 · parcel 058-27-1140	Probabilistic match. No universal property identifier exists.
Note amount	480,000	Integrated model. Reached at query time.
Appraised value	600,000	Integrated model.
Loan to value	80.0	Integrated model.
Debt to income	41.2 at underwriting, 43.8 at closing	The discrepancy this thread finds.

The story behind those two numbers: borrower income was restated between the final underwriting submission and closing. The note reflects the corrected figure. The findings on file reflect the earlier one. Today this surfaces either in the delivery application's own comparison, if that field happens to be in scope for it, or months later in post-purchase quality control sampling, when the remedy is a repurchase conversation rather than a correction.

Step 1 · Box 5: the ontology fragment

Small on purpose. Two properties and three relationships carry the entire thread.

@prefix sf:  <https://example.org/ont/sf#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix fibo: <https://spec.edmcouncil.org/fibo/ontology/LOAN/LoansGeneral/Loans/> .

sf:Loan a owl:Class ;
  rdfs:subClassOf fibo:Loan ;
  rdfs:label    "Single-family loan"@en .

sf:hasCanonicalId a owl:DatatypeProperty ;
  rdfs:domain    sf:Loan ;
  rdfs:range     xsd:string ;
  rdfs:label     "canonical loan identifier"@en .

sf:LifecycleState a owl:Class .
sf:Underwriting  a sf:LifecycleState ; sf:authoritativeSystem "Desktop Underwriter" .
sf:Closing    a sf:LifecycleState ; sf:authoritativeSystem "UCD collection" .
sf:Delivery    a sf:LifecycleState ; sf:authoritativeSystem "Loan Delivery" .

sf:debtToIncomeRatio a owl:DatatypeProperty ;
  rdfs:domain  sf:Loan ;
  rdfs:range  xsd:decimal ;
  rdfs:label  "debt to income ratio"@en ;
  rdfs:comment "Total monthly obligations over qualifying monthly income, in percentage points." ;

  # The two lines that carry the whole political argument:
  sf:authoritativeAt sf:Closing ;
  sf:assertedAt    sf:Underwriting, sf:Closing, sf:Delivery .

sf:securedBy a owl:ObjectProperty ; rdfs:domain sf:Loan ; rdfs:range sf:Property .
sf:hasTrace a owl:ObjectProperty ; rdfs:domain sf:Loan ; rdfs:range sf:DecisionTrace .

Note what authoritativeAt and assertedAt do: One lifecycle state is authoritative for a term; several states may assert it. Each state carries the system that owns it: underwriting sits with Desktop Underwriter, closing with the UCD collection, delivery with Loan Delivery. For debt-to-income, closing is the authoritative state, which means the UCD collection value is the trusted one. Underwriting and delivery both assert the term too, and their assertions are recorded but not the source of truth. That two-step, from term to authoritative state to authoritative system, is the whole answer to our system is the source of truth, expressed as machine-readable metadata rather than as a position in a meeting. Authority becomes explicit and queryable instead of tribal.

Step 2 · Box 6: the physical binding

The catalogue entry carries far more than a location. The last four fields are the ones that stop this from becoming a data dictionary nobody trusts.

- term: sf:debtToIncomeRatio
 binds_to:
  layer:      integrated_data_model
  object:      IDM.LOAN_CORE
  column:      DTI_RATIO_PCT
 grain:       one row per loan, current state
 precision:     decimal(5,2), percentage points, not a fraction
 authoritative_at:  Closing
 null_semantics:   "NULL means not yet closed. NULL is not zero."
 upstream_lineage:  UCD collection -> STG_UCD_CLOSING -> IDM.LOAN_CORE (job UCD_LOAD v14)
 domain_owner:    Single-Family Origination Data
 signed_off:     2026-07-14
 introduced_in:   release 2026.3

Where the runtime is RDF, the same declaration is expressed as a standards-based mapping:

<#LoanCoreMap> a rr:TriplesMap ;
 rr:logicalTable [ rr:tableName "IDM.LOAN_CORE" ] ;
 rr:subjectMap  [ rr:template "https://example.org/loan/{ENTERPRISE_LOAN_NBR}" ;
          rr:class   sf:Loan ] ;
 rr:predicateObjectMap [
  rr:predicate sf:debtToIncomeRatio ;
  rr:objectMap [ rr:column "DTI_RATIO_PCT" ; rr:datatype xsd:decimal ] ] .

This is a declaration, not a transformation. It is authored once and then evaluated continuously, either at materialization time or at query time. It is closer to a view definition than to an ETL job, and that distinction is why it does not add load to the estate.

Step 3 · Boxes 7 and 8: release and deploy

Ontology and bindings are tagged together as release 2026.3.
Continuous integration checks OWL consistency, then resolves every binding against the live catalogue of the integrated model. If IDM.LOAN_CORE.DTI_RATIO_PCT has been renamed, the build fails here rather than the query returning nothing in production three weeks later.
Deployment loads the ontology and reference data into the graph. Kilobytes. Minutes. No loan data moves.

Step 4 · Box 9: build the identity spine

Read-only against the integrated model. Note what is absent: no note amount, no rate, no debt to income. Identity and edges only.

// One canonical loan, every source identifier kept as an alias.
MERGE (l:Loan {canonicalId: $enterpriseLoanNbr})
 ON CREATE SET l.createdAt = datetime(),
        l.uri    = 'https://example.org/loan/' + $enterpriseLoanNbr

WITH l
UNWIND $aliases AS a
 MERGE (x:Alias {scheme: a.scheme, value: a.value})
 MERGE (l)-[r:IDENTIFIED_BY]->(x)
  SET r.confidence = a.confidence, r.basis = a.basis, r.observedIn = a.system;

// $aliases for this loan:
//  {scheme:'DU_CASEFILE', value:'1451220987',     confidence:1.00, basis:'deterministic'}
//  {scheme:'LENDER_LOAN', value:'LN-88213',      confidence:1.00, basis:'deterministic'}
//  {scheme:'MERS_MIN',  value:'100012300000088213', confidence:1.00, basis:'deterministic'}
//  {scheme:'POOL',    value:'AL7742',       confidence:1.00, basis:'deterministic'}

// Property resolution is probabilistic, and the confidence travels with the edge.
MERGE (p:Property {canonicalId: $propertyKey})
MERGE (l)-[s:SECURED_BY]->(p)
 SET s.confidence = 0.94,
   s.basis   = 'address normalised + parcel match; fuzzy on unit designator';

Step 5 · Box 10: load the decision traces

Read from the lake, because the integrated model kept the outcome and discarded the rationale. Append-only, immutable, each carrying the rule version in force.

MATCH (l:Loan {canonicalId: '9001234567'})

MERGE (uw:DecisionTrace {eventId: 'DU-1451220987-FINAL'})
 SET uw.type    = 'UNDERWRITING_FINAL',
   uw.system   = 'Desktop Underwriter',
   uw.occurredAt = datetime('2026-03-12T14:22:07Z'),
   uw.ruleVersion = 'DU 11.1',
   uw.outcome   = 'Approve/Eligible',
   uw.keyedOn   = 'DU_CASEFILE:1451220987',
   uw.asserted  = {debtToIncomeRatio: 41.2, loanToValueRatio: 80.0, noteAmount: 480000}
MERGE (l)-[:HAS_TRACE]->(uw);

MERGE (cl:DecisionTrace {eventId: 'UCD-LN88213-CLOSING'})
 SET cl.type    = 'CLOSING',
   cl.system   = 'UCD collection',
   cl.occurredAt = datetime('2026-03-20T00:00:00Z'),
   cl.keyedOn   = 'LENDER_LOAN:LN-88213',
   cl.asserted  = {debtToIncomeRatio: 43.8, noteAmount: 480000}
MERGE (l)-[:HAS_TRACE]->(cl);

MERGE (dl:DecisionTrace {eventId: 'ULDD-9001234567-SUB1'})
 SET dl.type    = 'DELIVERY_SUBMISSION',
   dl.system   = 'Loan Delivery',
   dl.occurredAt = datetime('2026-04-02T09:41:00Z'),
   dl.ruleVersion = 'ULDD Phase 5 (5.2.0)',
   dl.outcome   = 'No fatal edits',
   dl.keyedOn   = 'ENTERPRISE_LOAN:9001234567',
   dl.asserted  = {debtToIncomeRatio: 43.8, loanToValueRatio: 80.0, noteAmount: 480000}
MERGE (l)-[:HAS_TRACE]->(dl);

Values appear on a trace because a trace is a record of what was asserted at a moment. Reaching into the estate for the current value would defeat the purpose, since the current value is precisely what may have moved. This is the deliberate exception to the rule that the graph holds no payload.

Step 6 · Box 13: ask the question

MATCH (l:Loan)-[:HAS_TRACE]->(uw:DecisionTrace {type: 'UNDERWRITING_FINAL'})
MATCH (l)-[:HAS_TRACE]->(dl:DecisionTrace {type: 'DELIVERY_SUBMISSION'})
WHERE dl.occurredAt > uw.occurredAt
 AND abs(dl.asserted.debtToIncomeRatio - uw.asserted.debtToIncomeRatio) > $tolerance
RETURN l.canonicalId          AS loan,
    uw.asserted.debtToIncomeRatio  AS dtiAtUnderwriting,
    dl.asserted.debtToIncomeRatio  AS dtiAtDelivery,
    uw.ruleVersion          AS underwritingVersion,
    uw.outcome            AS underwritingOutcome,
    duration.between(uw.occurredAt, dl.occurredAt).days AS daysElapsed
ORDER BY abs(dl.asserted.debtToIncomeRatio - uw.asserted.debtToIncomeRatio) DESC;

loan	dtiAtUnderwriting	dtiAtDelivery	underwritingVersion	underwritingOutcome	daysElapsed
9001234567	41.2	43.8	DU 11.1	Approve/Eligible	21

Step 7 · Box 12: reach for a value the graph does not hold

The finding raises a follow-up: what does the enterprise currently hold as authoritative for this loan? The graph has no idea, and should not. It resolves the identity and hands off to box 12, which uses the binding from box 6 to rewrite the query and execute it against the estate.

# Asked against the model
SELECT ?dti WHERE {
 ?loan a sf:Loan ;
    sf:hasCanonicalId   "9001234567" ;
    sf:debtToIncomeRatio ?dti .
}

# Executed on the estate
SELECT DTI_RATIO_PCT
FROM  IDM.LOAN_CORE
WHERE ENTERPRISE_LOAN_NBR = '9001234567';

What just happened, and what did not

No new data was created. Every value in that result already existed inside the enterprise. It existed in three places that had never been asked to agree.
Nothing was written to the estate. Two read-only jobs and one query pushdown. No pipeline was modified, no table was added, no schema was changed.
The check is expressed once, in business terms. Not implemented separately in each application that needs it.
Extending it is cheap. Loan to value, occupancy, note amount and property type follow the same shape. Each is one ontology term plus one binding, not a new reconciliation job.
The timing changes. This finding is available before certification, which makes it a correction. The same finding from post-purchase sampling months later is a repurchase conversation.

The honest limit, worth naming up front in any proposal of this pattern: Whether a 2.6 point move in debt to income is a defect is a policy question, not a data question. Income can legitimately be restated between underwriting and closing, and the resubmission rules exist precisely because that happens. The context layer surfaces that three systems assert different values and shows exactly what each asserted and when. It does not adjudicate, and a design that claims to adjudicate will be correctly distrusted by the people who own the policy.

6Objections, and what to concede

Every practitioner proposing this pattern will meet an executive who has sat through three vendor pitches and will test the limits. Concede first and you take the weapon away.

Why not just extend the integrated model?

Because extending it is a schema change to an object that several hundred pipelines read, which is a multi-quarter change program before a single question gets answered.
And because the thing you would be adding is not structural. Meaning does not have a natural home in a relational schema; it ends up in column comments and a spreadsheet.

Conformed dimensions already solved this

They solved conformed structure, and they solved it well. That is why the estate works.
They did not give you global identity across systems, relationships as traversable objects, or decision traces. A conformed dimension tells you what was true as of a load. It does not tell you what was asserted, by whom, under which rule version.

How is this different from the catalogue we already bought?

A catalogue documents. A context layer executes. The test is whether anything resolves against it at run time.
Most catalogues are populated by stewards after the fact, which is why they go stale. The bindings here are validated by continuous integration against the live catalogue of the integrated model, so a stale binding breaks a build.
If the existing catalogue holds good lineage, harvest it. It is a head start on box 6, and saying so buys goodwill from whoever owns it.

Who owns the ontology when two business units disagree on a definition?

Nobody arbitrates a single winner. The model records both, scoped, with the lifecycle state at which each is authoritative.
Where two units genuinely mean different things by the same word, they get two terms and the word gets deprecated. Forcing a single definition is how these efforts acquire enemies.
The escalation path is only for the case where two units mean the same thing and disagree about the number, which is a data quality issue rather than a semantic one.

What does it cost?

Boxes 5 through 8 are authoring and release work. A small architecture group plus one platform squad.
Boxes 9 through 12 are three read-only jobs and a graph. Sized by relationships rather than by rows, which keeps the infrastructure request modest.
The number to be honest about is not infrastructure, it is the binding catalogue. That is patient, unglamorous, domain-by-domain work, and underfunding it is the standard way this fails.

Will the graph drift from the warehouse?

Identity and traces are rebuilt from the estate, so drift is bounded by load cadence rather than accumulating.
Attributes cannot drift at all, because they are never copied.
The graph is disposable. Losing it means rerunning boxes 8, 9 and 10, which is a recovery procedure rather than an incident.

Is this not just another metadata project that dies in year two?

Most of them die because they ask the estate to change, and the estate does not change.
The ones that survive deliver a named question in the first quarter and let the result recruit the next domain. Start with one lifecycle segment and one product type.
Say out loud where centralization is wrong. If two systems need to agree, point to point is cheaper. Centralization earns its cost when many systems must agree on the same thing.

7Sequencing, and what this does not do

The failure mode is scope, not technology.

Sequence

First. One product type, one lifecycle segment, one question. Underwriting to delivery conformance is a good first choice because the question is narrow, the stakes are visible, and every input already exists.
Second. Prove the model absorbs a standards version change. If the enterprise is running one version of a reference model for delivery and a newer one for appraisal at the same time, that is a real, dated, unavoidable problem and it is the cheapest possible demonstration that the ontology earns its keep.
Third. Extend by domain, not by layer. Resist the pull toward completeness.

What this deliberately does not do

It is not a replacement for the warehouse or the marts. Anyone who hears that will kill it, correctly.
It does not adjudicate disputes between systems. It records who asserted what, and when.
It does not back high-concurrency dashboards. Federated resolution is slower than a materialized join, and pretending otherwise sets up a failure everyone will remember.
It does not model the whole standard. Modelling the entirety of a mortgage reference model is the single most reliable way to spend two years and ship nothing.
It does not fix data quality. It makes disagreement visible, which is the necessary precondition and is frequently mistaken for the cure.

8The people equation

Centralize the mechanism. Federate the meaning.

The pattern above works when the roles behind it work. A design that funnels every domain through a central data team fails on the same schedule as a design that leaves every domain to invent its own semantics. The organizing rule is short: centralize the mechanism, federate the meaning.

The failure mode at both extremes is easy to name. A central council that approves every definition dies of throughput. A pure federation dies of divergence. This pattern deliberately lives between them.

A follow-up piece in this series will work through the operating model in detail: who signs off on what, how the roles line up against a typical enterprise data organization, what a RACI looks like across a full lifecycle, and where the pattern breaks when any of those roles goes missing.

Who owns what, at a glance:

The team that owns the integrated data model. Two mandates: stand up the platform for the context layer (runtime, release pipeline, continuous integration, deploy path), and own the binding files that point at the model they already run.
Domain owners. Term definitions in their area, and the authoritative lifecycle state for each term.
Source-system owners. The binding files that point at the emission each source produces. When a schema shifts on their side, the PR against the binding catalogue comes from them.
Governance. The tiebreaker rules for when two domains disagree on the same word. Record both, scope them, escalate only when the disagreement is about the number rather than the meaning.

What this pattern earns:

Definitions change like code, not like programs. A term's meaning shifts with a pull request against a tagged release, not with a multi-quarter change effort that touches transformation code.
One governed model, three different questions. Audit evidence, agent grounding, and delivery conformance all resolve against the same context, not against three copies of the payload that will disagree by Wednesday.
New sources have a bounded cost. Adding a system costs one set of bindings, not a reconciliation between the new system and every existing one.

In closing: Enterprise AI does not succeed on the strength of its models. It succeeds on the strength of the context it acts against. The estate already holds almost everything an autonomous agent, an examiner, or a definition-hungry mart needs. What it lacks is a shared, executable, versioned agreement about what that data means, held somewhere the machines can reach and the humans can govern. Without it, Enterprise AI keeps producing plausible answers to questions no one can defend afterwards. With it, the same data foundation that has run the business for two decades runs the next generation of it too. That agreement is cheap to build and expensive to keep, and the keeping is the job.

Acronyms and abbreviations

Term	Meaning
IDM	Integrated data model. The conformed, business-facing warehouse layer that sits between the source-aligned lake and the analytics and reporting marts. In this piece, the binding anchor.
MISMO	Mortgage Industry Standards Maintenance Organization. The U.S. mortgage industry's data-standards body.
FIBO	Financial Industry Business Ontology. Published by the EDM Council in RDF and OWL. Used here as the upper model for the loan domain.
ULDD	Uniform Loan Delivery Dataset. Fannie Mae's data standard for loan delivery, built on MISMO with GSE extensions.
UAD	Uniform Appraisal Dataset. Fannie Mae's data standard for appraisals.
UCD	Uniform Closing Dataset. Fannie Mae's data standard for closing.
UCDP	Uniform Collateral Data Portal. Where lenders submit appraisal reports.
CU	Collateral Underwriter. Fannie Mae's appraisal analytics engine, which scores UAD-formatted appraisals.
DU / DO	Desktop Underwriter (lender-facing) and Desktop Originator (broker-facing). Fannie Mae's automated underwriting engine.
MERS	Mortgage Electronic Registration Systems. Registry that survives servicing transfer.
DRS	Default Reporting System. Fannie Mae's servicer-facing system for reporting on delinquent and defaulted loans.
GSE	Government-Sponsored Enterprise. In this piece, Fannie Mae and Freddie Mac.
DTI	Debt-to-income ratio.
LTV	Loan-to-value ratio.
QC	Quality control. Post-purchase sampling and review of delivered loans.
OWL	Web Ontology Language. W3C standard for expressing ontologies.
RDF	Resource Description Framework. W3C standard for representing information as subject-predicate-object triples.
SPARQL	SPARQL Protocol and RDF Query Language. W3C query language for RDF.
LPG	Labeled property graph. The data model used by Neo4j and similar property graph databases.
OBDA	Ontology-based data access. Query pattern where a SPARQL query is rewritten at runtime to a native store query, usually SQL.
R2RML	RDB-to-RDF Mapping Language. W3C standard for expressing relational-to-RDF mappings.
RML	RDF Mapping Language. Generalization of R2RML to non-relational sources.
n10s	neosemantics. Neo4j plugin that loads RDF and interoperates with RDF tooling.
TTL	Turtle. RDF serialization format.
CDC	Change data capture.
ETL	Extract, transform, load.
CI	Continuous integration.
RACI	Responsible, Accountable, Consulted, Informed. Role-assignment matrix used in operating models.
PR	Pull request.

References

Standards, tools, and domain publications cited or used to build this piece.

Ontology and semantic web standards

FIBO (EDM Council). Financial Industry Business Ontology, published in RDF and OWL on a quarterly cadence.
W3C OWL 2 Overview.
W3C RDF 1.1 Primer.
W3C SPARQL 1.1 Overview.
Protégé. Stanford's ontology-authoring environment.

Binding, mapping, and query rewriting

W3C R2RML. Relational-database-to-RDF mapping language.
RML. RDF Mapping Language, generalization of R2RML.
Ontop. Virtual knowledge graph / SPARQL-to-SQL rewriter.
Neo4j neosemantics (n10s). RDF interop plugin for Neo4j.

Mortgage industry data standards

MISMO Residential Standards. Reference model, dataset specifications, and implementation guides for U.S. residential mortgage. Versions cited in the walkthrough: MISMO v3.0 (the basis for ULDD) and MISMO v3.6 (the basis for UAD).
Fannie Mae Uniform Mortgage Data Program. Landing page for ULDD, UAD, and UCD. Specific citations in the walkthrough: Uniform Loan Delivery Dataset, Phase 5 release 5.2.0 (26 May 2026); Uniform Appraisal Dataset 3.6 (broad production 26 January 2026, mandatory 2 November 2026).
Fannie Mae Selling Guide. Section cited: B3-2-01 on Desktop Underwriter casefile handling, resubmission, and final submission requirements.
Fannie Mae Servicing Guide.

Operational systems referenced

Desktop Underwriter (DU) and Desktop Originator (DO).
Collateral Underwriter (CU).
Uniform Collateral Data Portal (UCDP).
Loan Delivery. Fannie Mae's loan delivery application. Documentation cited in the walkthrough: business rule edits and the underwriting-to-delivery data comparison.
MERS. Mortgage Electronic Registration Systems.