Foundry Ontology Design for Beneficial-Ownership Networks: Person, Entity, Officer, and Jurisdiction Modeling at Bank-Group Scale

What you’ll be able to do after reading this. Recognize the ontology pattern as the difference between a structured relationship database and a flat customer-data table. Read a Person / Entity / Jurisdiction object-type specification and understand what queries it supports. Apply temporal patterns (effective-from / effective-to date pairs) to “who controlled this counterparty as of date Y” investigations. Handle the regulatory-currency caveats around FinCEN BOI (the 2024-2025 rule revisions matter; the institution’s CDD framework under 31 CFR §1010.230 applies regardless). Document beneficial-ownership reviews in workpapers that survive FinCEN, FFIEC BSA/AML, and bank-group examination cycles.

Terms anchored before the article walks them.

• Ontology — a structured relationship database. Think: not a list of tables but a network of typed business objects (Person, Entity, Jurisdiction) connected by typed relationships (OWNS, OFFICER_OF, REGISTERED_IN). A practitioner who has constructed a beneficial-ownership tree manually has used a flat-file approximation of an ontology; the platform-level ontology pattern scales the same logic across thousands of counterparties.
• Object type — a class of business entities (Person, Entity). Each object type has defined properties (fields) and supported relationships.
• Link type — a category of relationship between object types (OWNS, OFFICER_OF, REGISTERED_IN). Each link type carries its own properties (ownership_percentage on OWNS, role on OFFICER_OF, etc.).
• Temporal pattern — the discipline of attaching effective-from / effective-to date pairs to every link, so historical state is queryable rather than overwritten. “Who owned counterparty X as of 2024-06-15” becomes a filter on the OWNS links.
• Entity resolution — the process of recognizing that “Mikhail Volkov” in one filing and “Михаил Волков” in another and “M. Volkov” in a third all refer to the same Person. The discipline carries a legal_name_canonical field for the canonical form and legal_name_variants for observed transliterations.
• FinCEN BOI (Financial Crimes Enforcement Network Beneficial Ownership Information Reporting) — the U.S. federal beneficial-ownership disclosure framework under the Corporate Transparency Act, 31 USC §5336, implemented via 31 CFR §1010.380. Rule status was materially revised through 2024-2025 interim final rules; verify current rule status before relying on any operational claim.
• CDD (Customer Due Diligence) — the institution-side identification expectation under 31 CFR §1010.230, effective 2018, applicable independently of the customer’s FinCEN BOI filing status.
• PSC (Persons with Significant Control) register — the United Kingdom’s beneficial-ownership disclosure framework under Companies Act 2006 §790A-790ZG.
• UBO (Ultimate Beneficial Owner) — the natural person at the end of an ownership chain. EU directives (AMLD5, AMLD6) require UBO identification for legal-entity customers.

Beneficial-ownership modeling for a single counterparty is straightforward. The entity has one or two ultimate beneficial owners. The ownership chain is two or three hops. The disclosure is current. The institution captures the structure, attaches it to the counterparty record, and moves on. For most practitioners, this is the picture beneficial-ownership data evokes — a manageable diagram on a single screen.

Beneficial-ownership modeling at bank-group scale is something else entirely. Tens of thousands of counterparties. Ownership chains routinely four to eight hops deep. Multiple intermediate entities incorporated in jurisdictions whose disclosure regimes differ in nature — some real-time public registries, some annual public filings, some on-request-only access, some functionally opaque. The same person appearing across three filings under three transliterations of their name. Ownership changes that took effect on March 12, 2026, that the institution does not learn about until the next annual filing in March 2027. The data substrate that solves this problem is not a database table. It is an ontology with explicit attention to jurisdictional disclosure heterogeneity, temporal ownership change, and entity-resolution discipline.

This article walks the Foundry ontology pattern for bank-group-scale beneficial-ownership networks. The object-type taxonomy (Person, Entity, Officer, Jurisdiction). The link-type design that distinguishes “owns 25%” from “is officer of” from “is signatory for.” The temporal pattern that captures ownership changes over time without losing historical context. The FinCEN BOI integration that brings U.S.-side disclosure data into the ontology cleanly — with the regulatory-currency caveats this topic requires in 2026. And the cross-jurisdictional harmonization that reconciles UK Persons with Significant Control register, EU Ultimate Beneficial Owner directives, and Cayman / BVI disclosure-on-request regimes into a single queryable model.

Two framings the reader should hold throughout: (1) the ontology pattern is durable across regulatory revisions; the specific compliance implications of any particular filing rule are not. (2) The ontology gives the institution the substrate for beneficial-ownership analytics; the compliance discipline that turns the substrate into examiner-defensible work is institution-side and rule-status-dependent.

The scale problem

The order-of-magnitude difference between single-counterparty modeling and bank-group modeling is what makes the architectural choice between a database table and an ontology consequential. A Tier-1 bank’s commercial-banking portfolio typically holds tens of thousands of legal-entity customers, each with its own ownership chain. The ownership chains in international corporate structures routinely run four to eight hops — a U.S.-based operating company owned by a U.S. holding company owned by a U.S. LLC owned by a Cayman fund owned by a Luxembourg entity owned by a Swiss family trust whose beneficiaries include one named person and an entity that itself has further ownership structure.

The combinatorics matter. Across forty thousand counterparties with average ownership-chain depth of five, the institution’s beneficial-ownership graph contains roughly two hundred thousand entity nodes, several hundred thousand ownership edges, and tens of thousands of distinct natural persons appearing somewhere in the structure. Each person appears in multiple chains. Each entity may sit in multiple jurisdictions over its lifetime. Ownership changes — sales, restructurings, deaths, divorces, inheritances — move through the graph daily.

The query patterns that matter for the institution are also distinct. “Who controlled counterparty X as of the date of this transaction” requires a temporal traversal: as of a specific historical date, walk the ownership chain to ultimate beneficial owners. “Does this counterparty share a beneficial owner with any active sanctions hit” requires a multi-hop graph traversal terminating at SanctionsHit objects. “Which counterparties in our portfolio are controlled by persons resident in a FATF-blacklisted jurisdiction” requires combining the ownership graph with the Jurisdiction object’s risk classification. None of these queries are tractable against a flat database table; all are natural against an ontology with the right object-type and link-type design.

Person versus Entity: why the split matters

The single most consequential schema decision is whether to model Person and Entity as distinct object types or as a unified “Party” type with a discriminator field. The unified-Party approach is initially appealing because both Persons and Entities can own, can be owned, can be officers, can be located in jurisdictions. The unification looks clean.

The unified-Party model fails in practice because Person and Entity have fundamentally different identity-resolution characteristics. A Person has a date of birth, a nationality, and (typically) a relatively stable canonical name. The entity-resolution problem for a Person is name-transliteration variants: “Mikhail Volkov” appearing as “Михаил Волков” in the source-country filing, as “Mihail Volkow” in a German subsidiary’s filing, as “M. Volkov” in a sanctions-screening database. The resolution discipline is to maintain a legal_name_canonical field for the canonical form and a legal_name_variants array for all observed transliterations, with a fuzzy-match index running over both.

An Entity has none of those properties. An Entity has a jurisdiction of incorporation, an entity type (corporation, LLC, partnership, trust, foundation), an incorporation date, and a dissolution date. The entity-resolution problem for an Entity is name-collision: ten different companies named “Acme Holdings Ltd” exist across ten jurisdictions, each with different ownership and operating characteristics. The resolution discipline is to use the (jurisdiction, registration_number) tuple as the structural identifier and to treat legal_name as a non-unique attribute.

The unified-Party model collapses these two very different resolution disciplines into one, with predictable failure modes. The Person’s date-of-birth field is null on every Entity row. The Entity’s jurisdiction-of-incorporation field is null on every Person row. The compromise schema accumulates nullable fields, and the application code branches on the discriminator field on every operation. The Foundry pattern this article recommends is to keep Person and Entity distinct, accepting the modest cost of additional object types in exchange for clearer schema, simpler queries, and resolution disciplines specific to each type.

The companion bundle’s ontology_schema/beneficial_ownership_ontology.yaml ships the full schema with both object types defined separately. The reader who prefers the unified approach can collapse them — but should expect the failure modes the schema design avoids.

Link-type taxonomy

The links between objects are where the modeling work concentrates. Five link types cover most of what bank-group beneficial-ownership modeling requires.

OWNS links a Person or Entity (the source) to an Entity (the target) with a fractional ownership percentage. The link carries ownership_percentage (decimal), ownership_type (direct voting, direct economic, or indirect calculated through ownership of intermediate entities), effective_from and effective_to date pair, and disclosure_source capturing the regulatory regime or filing source from which the institution learned of the ownership.

OFFICER_OF links a Person (source) to an Entity (target) with a role (director, officer, signatory, registered agent) and effective-date pair. Officer-of relationships matter for substantial-control analysis even when the officer’s ownership percentage is below thresholds — a director with significant decision-making authority is a control relationship the institution must consider separately from the ownership percentage.

REGISTERED_IN links an Entity to a Jurisdiction with a registration date and a registration number. This is the structural identity link the entity-resolution depends on. An Entity may have multiple REGISTERED_IN links over its lifetime — a re-domiciliation from Delaware to Cayman moves the entity across jurisdictions without dissolving it.

CONTROLLED_BY is a derived link the institution computes through indirect ownership and substantial-control analysis. It is not a primary disclosure link; it captures the conclusion of the institution’s analysis that a specific Person or Entity exercises control over a specific Entity through the combination of ownership, officer relationships, contractual rights, voting trusts, and other factors. The institution may have one CONTROLLED_BY link per controller per Entity; for entities with diffuse control structures, there may be no CONTROLLED_BY link at all.

BENEFICIARY_OF links a Person to a trust or foundation Entity, capturing the beneficiary relationship that some disclosure regimes treat as equivalent to ownership for control purposes. The link carries a beneficiary type (e.g., named beneficiary, class beneficiary, discretionary beneficiary) and the relevant effective-date pair.

The link taxonomy is intentionally finite. Bank-group modeling does not need every possible relationship type; it needs the small set that captures the disclosed relationships and the derived control conclusions. Additional link types — pledgor-of, custodian-of, attorney-in-fact-for — are useful in narrower domains (private banking, trust services, fiduciary administration) but typically remain niche additions rather than core.

Temporal ownership modeling

Ownership relationships change over time. A counterparty that was 100% owned by Person A in 2023 may be 60% owned by Person A and 40% owned by Person B in 2025. The transaction the institution is reviewing may have occurred in 2024, at which point the ownership state was something else entirely — say, 80% Person A and 20% Person B. The institution’s audit question “who controlled counterparty X as of the date of this transaction” requires the ontology to capture the full temporal history, not just the current state.

The temporal pattern is the effective-from / effective-to date pair on every OWNS link. The link is “active” between its effective_from and effective_to dates; effective_to=null means still active. When a new ownership disclosure replaces a prior state, the prior link’s effective_to is set to the date of the new state, and a new link is created with the new percentages and effective_from set to the same date. No information is lost. The historical state remains queryable.

The query pattern “who owned this counterparty as of date Y” becomes a filter on the OWNS links: WHERE effective_from ≤ Y AND (effective_to IS NULL OR effective_to > Y). The pattern extends naturally to multi-hop traversal — for each hop in the ownership chain, apply the same temporal filter. The result is the ownership snapshot as of date Y, even if Y is two years in the past.

The reader interested in graph traversal techniques for the temporal pattern should also consult the DD Tech Lab Neo4j-and-Knowledge-Graphs sub-series, particularly Quiver for Ad-Hoc Counterparty Queries‘s treatment of temporal patterns in Cypher. The Foundry ontology stores the data; the graph algorithms that compute reachability, betweenness, and component analysis are the same patterns the Neo4j articles cover in detail.

Jurisdictional disclosure-regime modeling

The Jurisdiction object carries the institution’s structural representation of disclosure-regime heterogeneity. The disclosure_regime field — enum of realtime_public, annual_public, on_request, opaque — captures the operational character of the regime. The fincen_boi_equivalent boolean captures whether the regime parallels U.S. FinCEN BOI in structure. The risk_classification field carries the institution’s regulatory-risk weighting on the jurisdiction (low through FATF-blacklist).

The heterogeneity matters because it determines the temporal reliability of the ownership data the institution holds. An Entity registered in a realtime_public jurisdiction (the UK’s PSC register being the canonical example among major economies as of 2026) is one whose ownership changes the institution can learn about with a lag measured in days. An Entity in an annual_public jurisdiction has up to a year of lag between an ownership change and the institution’s awareness. An Entity in an on_request jurisdiction (Cayman, BVI for most beneficial-ownership categories as of 2026) requires the institution to specifically request the information — typically only available through court process or specific regulatory request, not routinely. An Entity in an opaque jurisdiction has no usable disclosure regime; the institution’s beneficial-ownership picture for that entity rests entirely on what the customer voluntarily discloses and what the institution independently verifies through other means.

The institution’s risk-rating models — see Time Series in Foundry‘s composite-scoring framework — should incorporate the disclosure-regime heterogeneity. A counterparty whose ownership chain passes through three opaque or on-request jurisdictions is, all else equal, a higher-risk-rating candidate than a counterparty whose chain is entirely within realtime-public jurisdictions. The ontology supports this analysis natively because the Jurisdiction object carries the regime classification on every traversal.

FinCEN BOI integration (with regulatory-currency caveats)

The Corporate Transparency Act (31 USC §5336), enacted in 2021 and implemented through FinCEN’s Beneficial Ownership Information Reporting Rule (31 CFR §1010.380), established a federal beneficial-ownership disclosure framework for U.S.-incorporated reporting companies. The CTA’s statutory framework defines the concepts the U.S. uses for beneficial ownership: the 25%-ownership threshold, the substantial-control test as an alternate path to reporting obligation, and the categories of exempt entities.

As of this article’s publication date (2026), readers must verify the current state of FinCEN BOI reporting obligations. The rule status has been materially revised through 2024 and 2025 — most notably through an interim final rule that narrowed reporting obligations for U.S. companies and U.S. persons compared with the initial regulation. The institution operating in this space must work from current regulatory text and current FinCEN guidance, not from any prior commentary including this article’s. Every operational claim about who must report, what fields, and on what timeline is rule-status-dependent.

What is durable across the rule revisions is the statutory concept. The 25% ownership threshold remains the percentage-based test. The substantial-control alternate path — a person below the 25% threshold who exercises substantial control through senior officer status, board authority, or other significant decision-making authority — remains a separate path to control-relevance independent of ownership percentage. The institution’s CDD obligations under 31 CFR §1010.230 apply regardless of any reporting-company’s specific BOI-filing status; the bank-side beneficial-ownership identification expectation is independent of whether the entity itself is required to file with FinCEN. This separation matters: an institution that conflates BOI-filing status with CDD-identification expectation may underweight its own customer-side documentation in ways that produce CDD findings even when the BOI rule itself is in flux.

The ontology integration pattern for FinCEN BOI data captures three things. First, the disclosure_source field on every ownership link records when the data came from FinCEN BOI versus other sources. This provenance matters for regulatory traceability — examiners ask not just what the institution knows but how the institution knows it. Second, the substantial-control analysis is captured through the CONTROLLED_BY derived link, separately from the OWNS ownership-percentage links. The two analyses run in parallel; conclusions from each may diverge for the same entity, and the institution’s documentation must show both. Third, the temporal pattern applies to FinCEN BOI data exactly as it applies to other disclosure sources — effective-date pairs on the OWNS and OFFICER_OF links, with new states superseding old states via the effective-to/effective-from chain rather than overwriting in place.

The CDD framework under 31 CFR §1010.230 has been stable since its 2018 effective date and is the institution-side regulatory anchor that does not depend on the FinCEN BOI filing-rule status. The institution must, regardless of FinCEN BOI status, identify and verify the beneficial owners of legal-entity customers, develop a customer risk profile, and conduct ongoing monitoring per §1010.230(b). The ontology’s structure — Person and Entity object types, the OWNS/OFFICER_OF/CONTROLLED_BY link taxonomy, the temporal pattern — directly supports each of these expectations. The institution that builds the ontology well also builds the substrate that satisfies the CDD-rule expectations regardless of the BOI rule’s evolving state.

Cross-jurisdictional harmonization

The same beneficial-ownership relationship often surfaces in multiple disclosure regimes simultaneously. A UK-incorporated entity owned by a U.S. person triggers both the UK PSC register and the U.S. CDD-rule identification expectation; the underlying ownership relationship is the same, but the data comes through different sources, on different timelines, with different field structures.

The harmonization problem is to recognize when two disclosed relationships are the same relationship — even when the source data formats differ, the dates of disclosure differ, and the spellings or identifiers differ — and to maintain a single canonical OWNS link rather than two parallel links. The companion bundle’s harmonization_rules.yaml documents the institutional rule set for this work.

The canonical resolution pattern is to use the (source-Entity, target-Entity, effective-from-date-range) tuple as the dedup key. Two disclosed relationships are candidates for the same canonical link if they connect the same resolved Entity (by jurisdiction+registration_number) to the same resolved Person or Entity, with overlapping effective-from-date ranges. The institution’s harmonization rule resolves the candidates: if the ownership percentages match (within rounding tolerance), the relationships are merged into a single canonical link with both disclosure_source values recorded in an array. If the percentages disagree, the institution must investigate — the discrepancy may be a stale disclosure, a translation error, or an actual ownership change between the two disclosure dates.

The investigation pattern itself is part of the institution’s CDD discipline. A discrepancy between disclosure sources is a signal worth analyst attention, not a data-quality artifact to silently smooth over. The harmonization rule set defaults to surfacing discrepancies, not hiding them.

Conflict resolution for fundamentally inconsistent data — the UK PSC says 60% ownership; the U.S. filing says 80%; the entity’s own voluntary disclosure says 70% — is a CDD-judgment question, not a rule-engine question. The institution’s rules document the default escalation path: discrepancies between regulatory disclosures of the same period trigger an analyst review; the analyst documents the resolution decision in the AuditEntry chain per Foundry Actions Framework; the resolution becomes the canonical record while preserving all source citations.

Worked example

The companion bundle ships a synthetic 200-counterparty bank-group ontology covering three jurisdictions — a U.S. operating subsidiary group, a UK-incorporated holding tier, and a Cayman-based fund layer — with ten ownership hops at depth, two temporal ownership changes, and roughly four hundred linked Persons. The synthetic_data/ directory contains entities.csv (200 rows), persons.csv (400+ rows), officer_links.csv, ownership_links.csv, ubo_entities.csv (ultimate beneficial owners resolved), ubo_links.csv, jurisdictions.csv, and registration_links.csv. The data is fully synthetic; any resemblance to real organizations is coincidental.

The traversal pattern that resolves “who controlled counterparty CP-SYN-0042 as of date 2025-09-15” walks the OWNS links recursively. From CP-SYN-0042, find OWNS links where effective_from ≤ 2025-09-15 AND (effective_to IS NULL OR effective_to > 2025-09-15). For each owner Entity found, recurse — find that Entity’s OWNS links with the same temporal filter. Continue until reaching Persons (the recursion terminates when the source of an OWNS link is a Person rather than an Entity) or until reaching Entities with no further outbound OWNS links (the chain ends at an unresolved structural top).

The expected result for the worked example: a six-hop chain from CP-SYN-0042 through three intermediate Entities (a Delaware LLC, a UK Ltd, a Cayman fund) to two named Persons resolving as ultimate beneficial owners with 60% and 40% indirect economic ownership respectively. Both Persons have CONTROLLED_BY derived links to CP-SYN-0042 — the 60% owner through ownership-percentage majority, the 40% owner through substantial-control analysis as documented director of the UK Ltd. The Cypher-style query pattern (forward-referencing the Knowledge Graphs sub-series for the graph-algorithm details) runs in under a second against the synthetic dataset.

The temporal pattern shows in CP-SYN-0042’s history: prior to 2024-11-01, the ownership chain terminated at a single Person at 100%. On 2024-11-01, the Person sold 40% to a new Person, creating the current two-owner structure. The query “as of 2024-06-15” returns the prior structure with one ultimate beneficial owner; the query “as of 2025-09-15” returns the current structure with two. The same query template produces both answers; the temporal filter is the only difference. The audit-trail discipline (Foundry Actions Framework) attaches to the queries themselves: the institution that runs the query as part of a CDD review generates the appropriate Quiver activity log (per Quiver for Ad-Hoc Counterparty Queries), and any state-change action that follows runs through the Actions framework.

The worked example demonstrates the architectural payoff. Without the ontology, the same question requires the analyst to assemble the data from three filing systems, reconcile the disclosure formats, apply temporal filtering manually in spreadsheets, and produce the analytical conclusion through manual graph-walking. The total elapsed time for a complete chain resolution on this kind of structure typically runs four to eight hours. With the ontology, the query runs in under a second and produces both the resolved chain and the supporting provenance the institution can cite to any subsequent examiner.

The four-to-eight-hour saved time per counterparty review, across a bank-group portfolio of forty thousand counterparties on annual or semi-annual CDD cadences, is the operational case for building the ontology rather than continuing with the spreadsheet workflow. The regulatory-defensibility case is independent: even institutions for whom the time savings do not justify the build will find that the documented temporal-ownership trail produces materially better audit-trail performance under FFIEC, OCC, and FinCEN examination than the spreadsheet alternative.

A grounding case: beneficial-ownership opacity as the enforcement-action pattern

Beneficial-ownership concealment is the recurrent failure mode in major international AML enforcement. The Panama Papers prosecutions (multi-jurisdictional, beginning 2016) produced cases across dozens of jurisdictions where the underlying conduct depended on multi-hop opaque ownership chains designed to obscure ultimate beneficial owners. The Pandora Papers prosecutions (2021 onward) extended the same pattern across additional offshore jurisdictions. Institutions with structured beneficial-ownership ontologies could scan their counterparty portfolios against the leaked entity lists the day each leak became public; institutions without those ontologies waited months for manual reviews to assemble the same exposure picture, by which point counterparties had restructured.

The Danske Bank Estonia branch matter (2018 onward) involved correspondent-banking relationships where the institution’s beneficial-ownership analytics did not surface the network exposure to opaque-jurisdiction entities until well after the underlying volume had accumulated. The ontology pattern this article walks — Person and Entity distinct, temporal effective-date pairs on OWNS, disclosure_source provenance on every link, jurisdictional disclosure-regime modeling — directly supports the analytical work that the Danske matter required and that the institution did not have the tooling to perform.

What the practitioner does with these references. When designing or evaluating a beneficial-ownership analytics program, ground the design in the regulator’s documentation expectations under FinCEN CDD (§1010.230) and the FFIEC BSA/AML Examination Manual’s CDD/EDD sections. The ontology gives the institution the substrate for the analysis; the institutional discipline that turns the substrate into examination-credible work is consistent entity-resolution review, disclosure-source provenance maintenance, and the harmonization rule set that handles cross-jurisdictional overlaps (companion bundle harmonization_rules.yaml). Workpaper documentation should include the resolved ownership chain as of the date of the relevant decision, the supporting disclosure sources, and the institution’s interpretation of any discrepancies between sources.

Authority

• Corporate Transparency Act, 31 USC §5336 (statutory basis for FinCEN BOI; framework remains in force as of 2026 publication date, though specific reporting obligations have been revised through interim final rules during 2024-2025 — verify current rule status before relying on any operational claim).
• Financial Crimes Enforcement Network, Beneficial Ownership Information Reporting Rule (31 CFR §1010.380), as currently in effect.
• Financial Crimes Enforcement Network, Customer Due Diligence Requirements for Financial Institutions (31 CFR §1010.230), effective May 11, 2018 — institution-side identification expectation independent of any reporting-company’s BOI-filing status.
• United Kingdom Companies Act 2006, §790A-790ZG (Persons with Significant Control register framework).
• European Union, Anti-Money Laundering Directive 5 (AMLD5, Directive 2018/843) and Anti-Money Laundering Directive 6 (AMLD6, Directive 2018/1673), for the EU Ultimate Beneficial Owner directive framework.
• Financial Action Task Force, Recommendation 24 — Transparency and Beneficial Ownership of Legal Persons (March 2022 revision).
• Basel Committee on Banking Supervision, Customer Due Diligence for Banks (2014).
• Christen, P. (2012). Data Matching: Concepts and Techniques for Record Linkage, Entity Resolution, and Duplicate Detection. Springer. Entity-resolution methodology reference.
• Palantir Foundry Documentation — Ontology object types, link types, properties, temporal patterns.

Companion repository

Beneficial-Ownership Networks‘s full companion bundle lives at github.com/noahrgreen/dd-tech-lab-companion/articles/009_beneficial_ownership_networks/. It ships the bank-group BOI ontology schema (ontology_schema/beneficial_ownership_ontology.yaml), the Cypher-style traversal patterns (queries/beneficial_ownership_path_queries.cypher), the cross-jurisdictional harmonization rule set (harmonization_rules.yaml), and the synthetic 200-counterparty worked-example dataset across synthetic_data/. Foundry vs Snowflake + DBT vs Databricks closes the Foundry sub-series with the platform-architecture comparison framework that places Foundry’s ontology-layer value relative to Snowflake + DBT + custom-build and Databricks + Unity Catalog alternatives.