A Federated Semantic Layer — Govern Data in Place, Without the Centralization Tax

The instinct when an enterprise "gets serious" about AI is to centralize: pull Oracle, SQL Server, and Databricks into one lake, then build semantics on top. For most banks that is the wrong move. Centralization incurs a migration tax — multi-year projects, egress costs, and data-sovereignty risk — and it stalls the AI program behind a platform rewrite.

The alternative: build a virtualized semantic + knowledge layer in place. Federate, govern, and semantically map the estate where it already lives.

The reference architecture

Six planes, bottom to top, none of which require moving your systems of record:

Plane	What it does	Primary tooling
Federated source estate	Systems of record stay in place	Oracle on-prem, SQL Server, Databricks Delta, S3
Federation runtime	Query remote sources with no ETL	Databricks Lakehouse Federation, foreign catalogs
Selective replication	Hydrate only AI-critical products	Delta + Lakeflow AUTO CDC
Streaming spine	Real-time events, governed	Event Hubs / Kafka → Structured Streaming
Semantic + knowledge layer	Business meaning + relationships	FIBO ontology (RDF/OWL), metric views, CDEs
Active context + serving	One governed contract for agents	Unity Catalog + Purview + MCP server

The governance plane — Purview Unified Catalog + Unity Catalog — is the runtime trust boundary spanning all of it. Row/column policies, PII masking, and Do-Not-Train tags are enforced at the query engine, not bolted on afterward.

Virtualize vs. replicate — the placement decision

Not everything should be federated, and not everything should be copied. Choose placement by business value, control thresholds, and freshness SLOs:

Pattern	Best for	Trade-off
Virtualization-first	Inventory, semantic prototyping, ad-hoc joins	Weaker fit for repeated AI training workloads
Consolidation-first	RAG grounding, training datasets	Strongest governance; replication overhead
Hybrid	Model-critical, regulated workloads	Virtualize broadly, replicate selectively

The default is hybrid: virtualize broadly for discovery, replicate the hot, latency-sensitive entities into Delta via CDC.

The five accelerators that make it real

Each readiness dimension is closed by an accelerator that produces or consumes governed metadata:

1. Lakehouse Federation (Coverage) — register credentials in Databricks secrets; CREATE CONNECTION external read-only sources; foreign catalogs mirror Oracle and SQL Server schema so federated queries join on-prem tables with Delta in real time — no copies.
2. Schema-Miner Pro (Context) — an agentic pipeline that maps physical columns to FIBO classes at scale (covered in depth in the FIBO article).
3. CDE Discovery / Manager (Clarity + Capacity) — ingests policy manuals, catalogs Critical Data Elements, and propagates validation rules to every physical instance.
4. Entity Resolution + CDC (Credibility) — probabilistic ER fingerprints client and counterparty records across silos and publishes a single golden entity ID.
5. Consent & PII Guardrails (Capacity) — live policy tags for every asset; Do-Not-Train records auto-excluded from RAG indexes and fine-tuning sets.

Worked example — the ABC Corp exposure query

An RM copilot asks one question; the MCP server fans out across the federated estate, transport-agnostic:

# 1. Agent → MCP server (one contract, no transport awareness)
result = mcp.resolve(
    intent="exposure_summary",
    entity={"LegalEntity.lei": "5493001ABC...XYZ"},
    domains=["deposits", "credit", "news"],
    policy={"PII": "masked", "DoNotTrain": False},
)

The MCP server plans the fan-out from the FIBO-mapped intent and resolves each branch in parallel:

-- 3a. STRUCTURED → Lakehouse Federation (Oracle + SQL Server + Delta)
SELECT SUM(a.balance)     AS deposits,
       SUM(l.outstanding) AS credit
FROM   oracle_fed.acct a
JOIN   sqlsrv_fed.loan l USING (lei)
WHERE  a.lei = '5493001ABC...XYZ';
-- governed via Unity Catalog row policy  → deposits $48.2M · credit $112.6M

# 3b. UNSTRUCTURED → FAISS + Schema-Miner embeddings
faiss.search(query="ABC Corp risk news",
             index="contracts_calls_email",
             filter={"entity": "ABC", "dnt_tag": False})
# → covenant-breach memo, Q1 earnings transcript, KYC refresh, complaint letter

# 3c. REAL-TIME → Structured Streaming + AUTO CDC
#     Reuters: rating downgrade 14:02 · payment delay flagged 14:08

The agent returns a grounded, cited, policy-checked payload:

{
  "exposure_usd": 160800000,
  "deposits": 48200000, "credit": 112600000,
  "risk_signals": ["Moody's downgrade", "payment_delay"],
  "sources": ["oracle.acct#117", "sqlsrv.loan#42",
              "faiss://covenant_memo", "reuters://14:02"]
}

The accelerators keep the context layer fresh continuously: federation refreshes foreign catalogs every ~5 minutes, Schema-Miner re-embeds new docs hourly, entity resolution updates golden LEIs on CDC, and consent/PII tags propagate to agents in under 100 ms.

Latency budget

An in-place architecture is only viable if it is fast. The read-path budget is ≤ 200 ms p95 end-to-end:

Agent → MCP resolve   ≤   5 ms
MCP  → context lookup  ≤  25 ms
context → fan-out query ≤ 120 ms
assemble + policy check ≤  50 ms
─────────────────────────────────
total (read)            ≤ 200 ms p95
write-path freshness: docs ≤ 1 hr · CDE ≤ 24 hr · entity ≤ 1 s · consent/PII ≤ 100 ms

The path to implement

1. Stand up Lakehouse Federation over your top two source systems — no data moves.
2. Map the highest-value domain to FIBO with Schema-Miner Pro; publish metric views and CDEs.
3. Wire the governance plane (Unity Catalog + Purview) so policies enforce at query time.
4. Expose the estate through an MCP server so agents and BI share one governed contract.
5. Replicate selectively into Delta only where latency or training workloads demand it.

The result is production-grade AI on a federated, governed estate — heterogeneous data made queryable in real time, without centralization. Explore the building blocks in the Lab.

Talk to us about a federated semantic layer →