Building a Brand Knowledge Graph for AI Discoverability

The graph already exists — whether you manage it or not

Every established brand leaves behind a graph. Its home page points to products, the team page points to people, documentation points to features, profiles point back to the domain, and customers create additional references. The problem is usually not an absence of relationships. It is that the relationships are implicit, stale, or contradictory.

A brand knowledge graph makes those relationships explicit enough to govern. It is a model, not a single schema block. The internal model can power content templates, structured data, search, analytics, and editorial review. The public web expresses only the portions that are useful and safe to publish.

Design the minimum viable graph

Do not begin by modeling every noun in your CRM. Begin with questions that influence revenue, trust, or support load. If prospects ask who owns the company, which products integrate, where a service is available, or whether a feature is included, model the entities and edges required to answer those questions.

• Organization: canonical name, legal name, domain, logo, locations, owners, and official profiles.
• Person: name, role, organization, profile URL, expertise, and publication history.
• Product or service: name, category, audience, status, version, capabilities, and parent brand.
• Place: address, service area, office type, and relation to the organization.
• Source: URL, publisher, publication date, update date, evidence type, and owner.
• Edge: relationship label, start or end date, confidence, and supporting source.

The source field matters. “Product X integrates with Product Y” is a relationship; its documentation page or release note is the evidence. A graph that stores edges without provenance becomes a new place for assumptions to harden.

Identifiers prevent accidental merging

Names change and repeat. Stable identifiers help systems and humans know when two records refer to the same thing. Use canonical URLs, durable database IDs, SKUs, registry IDs, or other identifiers appropriate to the entity. Keep a redirect or alias map for renamed products and people whose names change.

{
  "id": "https://example.com/products/atlas",
  "type": "SoftwareApplication",
  "name": "Atlas",
  "brand": "https://example.com/#organization",
  "status": "active",
  "sameAs": [
    "https://github.com/northstar/atlas"
  ],
  "evidence": [
    "https://example.com/docs/atlas/integrations"
  ]
}

The identifier does not magically register the product with every search engine. Its value is operational: templates can reference it consistently, editors can find the authoritative record, and public pages can connect the same node rather than creating a new spelling on each page.

Publish the graph through useful pages

A graph is only as useful as the evidence available to retrieve. Publish focused pages that answer distinct questions: an organization overview, product documentation, integration pages, team biographies, location pages, and methodology or research pages. Each page should name its subject and explain the relevant relationships in ordinary prose.

Then connect the pages with descriptive links. “Atlas GitHub integration documentation” carries more meaning than “learn more.” Use breadcrumbs, related-content links, and consistent canonical URLs. JSON-LD can reinforce the graph, but it should not be the only place a relationship exists.

Governance is the hard part

A graph ages quickly. People change roles, products are renamed, integrations are deprecated, and pricing moves. Assign each node and high-impact edge an owner. Require evidence for changes, record effective dates, and define what happens to old URLs. A quarterly review is a baseline; volatile product data may need release-based review.

• Propose: an owner submits a new node or relationship with a source.
• Review: a domain owner checks naming, scope, legal constraints, and visible evidence.
• Publish: the CMS, documentation, and structured data receive the approved value.
• Monitor: answer evaluations and crawl checks identify stale or conflicting expressions.
• Retire: deprecated nodes remain redirectable and clearly marked rather than silently disappearing.

Store uncertainty. A proposed partnership, unverified third-party claim, or inferred relationship should not be presented as a confirmed fact. Confidence and review state are useful internal fields even when they never appear publicly.

Query the graph like a customer

Testing should resemble the questions an assistant receives. Ask identity questions, comparison questions, relationship questions, and temporal questions. “What is Atlas?” tests category and identity. “Does Atlas integrate with Slack?” tests an edge. “Who founded Northstar Labs?” tests a person relationship. “Is Atlas still supported?” tests status and freshness.

• Entity precision: is the intended entity selected rather than a similarly named one?
• Attribute accuracy: are category, location, ownership, status, and capabilities correct?
• Relationship accuracy: are products, people, parents, and integrations connected correctly?
• Provenance: does the answer cite the canonical source or a stale secondary page?
• Temporal behavior: does the system distinguish current facts from archived facts?

When a test fails, trace the edge. Find the page or source that introduced the wrong relationship, check whether your own pages contradict each other, and fix the record at its owner. A graph project succeeds when it shortens that diagnosis loop, not when it produces the largest JSON file.

Choose a source of truth for each fact

Organizations often have several plausible systems of record. The CRM knows account ownership, the product database knows plan names, the documentation repository knows capabilities, and the legal system knows the registered company name. Do not force one system to own every fact. Instead, assign authority by domain and define how approved values flow into public pages.

For example, a product catalog can own a product’s canonical name and lifecycle status, while documentation owns its supported integrations. A people directory can own a current job title, while an author profile owns a person’s editorial biography. The graph layer should preserve those source relationships rather than flattening every field into an untraceable manual export.

• One canonical owner for each important field.
• A documented precedence rule when systems disagree.
• A source URL or record ID for every public claim.
• A review queue for unresolved conflicts instead of silent overwrites.
• A publication process that makes corrections visible in downstream templates.

Model time and status

Relationships are not always permanent. A person may lead a team for two years; a product may support an integration until a deprecation date; an office may close while historical articles still mention it. If the graph only stores “has relationship,” an answer system may repeat a once-true fact as current.

Add effective dates, status, and replacement links where they matter. Keep archived pages available when they explain history, but label them clearly and link to the current record. In prose, prefer “Atlas supported the legacy connector until June 2026” over silently leaving a historical statement next to a current integration list. Temporal precision is especially important for pricing, compliance, people, and software compatibility.

A knowledge graph is valuable partly because it lets a team ask temporal questions: what changed, when did it change, which pages still express the old fact, and which customer questions are affected? Those questions turn an abstract “AI discoverability” project into normal information architecture and content operations.

Start small enough to operate. Ten well-owned entities with reliable evidence are more useful than ten thousand records nobody reviews. Expand the graph when a repeated customer question exposes a missing node or edge, and let observed retrieval failures determine the next modeling investment.

Primary references: Google documentation on Knowledge Graph and structured data; Schema.org’s linked vocabulary; W3C RDF 1.1 Concepts; and the W3C Data on the Web Best Practices.