Data relationships

Facts alone do not get a brand recommended. Relationships do.

An AI agent choosing between a brand and its competitors has to reason across several connected data points at once — a product and its ingredients, a store and the zones it serves, a service and the locations that offer it, a price and the conditions attached to it. Publishing those facts as isolated pages leaves the agent to infer the connections. Publishing them as a graph lets the agent traverse them.

Data relationships are the part of the Norg platform that turns scattered facts into a connected, verified graph that agents can actually walk.

Why relationships matter

Why isn't structured data on each page enough?

Page-level schema markup describes one page at a time. It tells an agent what a product is; it does not tell the agent which stores stock it, which ingredients it contains, which zones it can be delivered to, or which policy applies to returning it.

Most commercially useful questions cross those boundaries. An agent answering one has to assemble the connections itself, from separate pages, with no guarantee it assembles them correctly — or it declines to answer, which is the more common outcome.

What is a multi-hop question?

A question that cannot be answered from any single page, because answering it means following several relationships in sequence.

"Gluten-free pizza delivered to postcode 3021 before 10pm under $25" is one. It requires connecting a dietary tag to a product, the product to a store that makes it, the store to a delivery zone covering that postcode, the zone to a cutoff time, and the product to a price. No page exists for that query, and no page reasonably could — the combinations are unbounded.

With a traversable graph, the agent resolves it by walking the relationships. Without one, the brand is simply absent from the answer.

How do relationships affect comparison?

Comparison requires shared attributes. An agent shortlisting options compares entities on the dimensions they have in common, and an entity that does not expose a dimension is not compared on it — it is skipped.

When a brand's entities carry the same typed relationships its competitors expose, the brand enters the shortlist. When they do not, it is omitted without any signal that the omission happened.

Why does verification matter more than volume?

AI systems are cautious about staking a recommendation on unverifiable claims, and most cautious where the stakes are highest — allergens, dietary requirements, safety ratings, compliance. A relationship that traces back to a source gives an agent grounds to recommend and to explain why. An unsourced assertion gives it grounds to stay silent.

This is why the platform scores and verifies relationships rather than simply asserting as many as possible.

How Norg builds the graph

What are the stages?

Four, in order.

1. Extract every entity. Products, ingredients, allergens, nutrition profiles, locations, service areas, opening hours, offers and policies are pulled from the website, point-of-sale systems, supplier data and franchise systems into one typed inventory. Entities are typed at this stage, not merely listed.

2. Discover the relationships. Every entity is scanned against every other entity, and typed connections are proposed — contains, serves, stocks, applies to, is available in. Each proposal carries a confidence score.

3. Verify and prune. Each proposed relationship is checked back against a source. Proposals below the verification threshold — typically 0.75 confidence — are not applied. Weak relationships are dropped, contradictions are flagged for human review rather than silently resolved, and dead links are removed as the underlying business data changes.

4. Publish where agents look. The verified graph is served inline on every page, as a single whole-graph file, and through the MCP endpoint, so an agent can traverse it rather than scrape page by page.

What stops a wrong relationship going live?

The confidence threshold and the source check. Nothing is applied to published data on the strength of a proposal alone — a relationship has to clear the threshold and trace back to a source. Contradictions are surfaced for a human to resolve, on the principle that a conflict between two sources is information, not noise to be averaged away.

The graph is also re-checked as business data changes, because a relationship that was true at extraction can become false without anything on the page appearing to change.

Where the graph is published

In what formats is the graph available?

Four surfaces, all public and read-only:

The same verified graph backs all four. They are different access patterns over one source of truth, not four separately maintained copies.

How this differs from schema markup

Isn't this just schema.org with extra steps?

schema.org is the vocabulary. It is what the relationships are expressed in, and Norg uses it.

The difference is scope and maintenance. Publishing structured data page by page describes each page in isolation. Building a relationship graph connects every entity across the whole site, scores each connection, verifies it against a source, and keeps it current as the business changes. The vocabulary is shared; the exercise is not the same one.

Norg holds a provisional patent covering its data structuring methodology.

What does this require from the business?

Access to the systems where the facts actually live — the website, product data, point-of-sale, supplier feeds, franchise or location systems. The graph is only as good as the sources behind it, and a relationship cannot be verified against a source that was never connected.

It does not require restructuring the existing website. The graph is built alongside it and published to the same domain.

Further reading

The platform overview is at norg.ai/product, published pricing at norg.ai/pricing, and client engagements with named brands, stated metrics and defined measurement windows at norg.ai/case-studies.

Images on This Page