A graph of the people, products, and organizations the brand can accurately claim as connected, with a source and a time range behind every line. The attractive connections don't get a free pass.

Records the brand controls provide the candidate relationships. We keep an edge only when an exact source supports it, and legal or privacy reviews anything sensitive before publication. Data governance and content leads who need the parent, product, and founder connections agreed once so every page works from the same answer.

Your public entity graph shows only connections backed by a source document. Legal and privacy owners review sensitive edges before they ship.

Figure stringing cords between entity nodes on a constellation board to map verified relationships

Some of the 500+ brands we've worked with

See all references
  • Decathlon
  • Marks & Spencer
  • Edenred
  • Abdi İbrahim
  • Shiftdelete
  • Albaraka Türk
  • Marble Systems

Raw records first produce candidate edges. Identity, source, privacy, and ownership checks then determine which ones named people approve for the public graph.

How we hold ourselves to it

  • Source behind every edge
  • Direction and time range
  • Private stays private
  • Draft until approved
  1. Set entity and privacy boundaries

    Before proposing relationships, we agree which entity types belong in scope and which fields are off-limits.

    An approved entity scope with sensitive-data exclusions named up front.

    AI assist
    Candidate entities and relationships are extracted from approved records, with private or out-of-scope material flagged as it appears.
    Human gate
    Domain, privacy, and legal owners approve the scope and the excluded data before work continues.
  2. Normalize names and identifiers

    One reconciled name and identifier is agreed for each organization, product, and person before any relationship is attached.

    A canonical entity inventory with every alias and collision flagged.

    AI assist
    Names, aliases, and identifiers are reconciled across source systems without silently combining conflicting records.
    Human gate
    Accountable fact owners select the canonical value or mark a field disputed with a review date.
  3. Map only evidence-backed relationships

    Documents, contracts, or public records must support both entities before the relationship receives a direction and time range.

    A relationship graph where every edge traces to an exact source.

    AI assist
    A directed, time-bounded edge is proposed only when an exact source supports both nodes and the relationship.
    Human gate
    Domain, privacy, and legal owners approve every material relationship. Any edge based on inference stays unresolved.
  4. Attach provenance and an accountable owner

    A named owner becomes responsible for updates when a relationship changes, an acquisition closes, or a product is discontinued.

    Every node and edge tagged with source, confidence, and a named owner.

    AI assist
    Source, confidence, and a review trigger are attached to every fact and relationship in the draft graph.
    Human gate
    Data governance and content owners confirm the accountability and update duties before sign-off.
  5. Approve the graph and the change process

    Named owners approve the graph and its update process together. Completing the model still leaves the publication gate intact.

    A versioned public entity model, plus the rule for how it changes next time.

    AI assist
    Ownership gaps, missing provenance, and unsupported edges are checked before the draft reaches sign-off.
    Human gate
    Graph, privacy, legal, and publishing owners approve the version and the governed process for future changes.

The CMS handoff includes an implementable graph and a provenance rate showing how many public connections have adequate source support.

  • Approved public entity model

    A versioned set of entity types, nodes, attributes, and explicit exclusions signed off by the domain owners.

    Accepted when

    What the organization is willing and able to represent publicly, before a single line of markup is written.

    Cadence: Owners signed off

  • Knowledge graph map

    Shows which connections are ready to implement, which remain uncertain, and which have to stay private.

    Accepted when

    A readable and machine-ready map of every relationship, with its evidence and time bounds attached.

    Cadence: Evidence attached

  • Fact governance spec

    Canonical identifiers, fact ownership, freshness triggers, and a conflict-resolution process that keeps the graph useful after the first snapshot.

    Accepted when

    The operating rules that keep the graph accurate after this project ends.

    Cadence: Ownership assigned

  • Relationship provenance rate

    A sparse graph with sourced edges is stronger than a dense one full of guesses. This metric rewards the sourced graph.

    Accepted when

    The share of public relationships backed by adequate, inspectable source evidence. Raw graph density is excluded.

    Cadence: Provenance checked

  • Relationship refresh schedule

    A relationship that was true last year doesn't get assumed true this year without a refresh, and each edge already carries the owner who runs it.

    Accepted when

    A written schedule naming the acquisition, rebrand, and product changes that force a recheck, plus the volatile facts reviewed quarterly.

    Cadence: Quarterly refresh

The parent company, acquired product line, and founder's other venture may each be documented somewhere. The missing piece is a public, sourced account of how they relate.

A good fit when

  • The facts live in separate systems — The CRM holds the parent-subsidiary structure, the CMS holds the product line, and the press page names the founder.
  • A relationship is obvious inside, invisible outside — The team knows Product X belongs to Brand Y, and no public page says so.
  • Teams disagree on what's canonical — Marketing calls it a subsidiary, legal calls it a wholly owned entity, and the website names none of it.
  • You already have a clean canonical identity — This method assumes settled namesakes and aliases, so unresolved ones go to Entity Inventory & Disambiguation.
  • Privacy boundaries come before any modeling — Business boundaries and records that should never become public knowledge get flagged before modeling starts.
  • Each edge needs its own evidence — A "founded by", "subsidiary of", or "formerly known as" edge carries its direction, time range, and source.
  • Draft relationships wait for approval — A candidate stays a draft until an accountable owner signs off, however plausible it looks.

Better handled as other work when

  • A knowledge-panel guarantee is the goal — The graph documents what is true and public, and it forces no panel, sitelink, or "people also ask" entry.
  • Unsupported edges stay out — Only sourced connections belong in the public graph. Speculative edges create liability and carry no evidentiary value.
  • You want a private relationship shown — Confidential partnerships, unannounced acquisitions, and personal relationships stay out, whatever discoverability they add.
  • Schema App

    builds the sourced relationship edges themselves, as structured connections

  • Google Knowledge Graph Search API

    a quick diagnostic check on what relationships Google's index currently shows

  • Airtable

    tracks each proposed edge's source and legal or privacy review status before publication

The records already held across the business are enough to begin. Candidate edges are traced to evidence, sensitive connections go through privacy or legal review, and only approved relationships enter the graph.
Map your entity relationships

A sourced relationship graph controls the organization's own public account of each connection. That is the boundary. External systems remain independent. They decide whether to render a panel, a sitelink, or any special display.