Data Describes Entities. The Business Lives in Its Relationships

A record tells you what a thing is. The business is not in the things:
it is in what connects them. And that network of connections — ownership, contracts,
dependencies, supply — is exactly where an agent needs
to reason.

Introduction

Yesterday we solved identity: we now know that “ACME”, “ACME LTD” and
“Customer #49281” can be the same entity. Good. But an isolated
entity is not a business. A customer without contracts, a product without
components, a supplier without a supply chain — those are data, not
operation.

The business lives in relationships: who owns what, which contract covers
which product, which component depends on which, who supplies whom. And that
network of relationships is where the decisions that matter happen: risk,
impact, dependency.

The problem

A logistics operator manages fleets, warehouses, transport contracts
and a network of subcontractors. Its order system has all the data:
orders, routes, vehicles, drivers, invoices. And yet, when an
important customer asks for a review of their service, the team needs a
week to answer a question that sounds simple:

“What happens with this customer if subcontractor X stops operating?”

Because the answer is not in any record. It is in a chain of
relationships that nobody has ever represented:

CUSTOMER → owns → CONTRACT
CONTRACT → covers → PRODUCT (transport service)
PRODUCT → depends_on → COMPONENT (route, vehicle, subcontractor)
COMPONENT → supplied_by → SUPPLIER (subcontractor X)

Until the team reconstructs that chain by hand — consulting the
contract, the service catalog, the route assignments, the subcontracting
contracts — it does not know: how many of the customer’s products depend on X, whether
there are alternative subcontractors covering the same routes, which contracts
would be triggered, and how much time there is before the customer
notices.

The data describe each piece separately. The business is the network. And the
network is not in any system: it is in the heads of three people and in
forty Excel sheets.

The concept

A relationship is a link with explicit meaning between two entities:
customer → owns → contract, contract → covers → product,
product → depends_on → component, component → supplied_by →
supplier. It is not a reference field; it is a statement about how
the business works.

The relationships that matter in a company are, for the most part, from five
families:

• Ownership. Who owns or controls what: company → subsidiary,
  customer → contract, contract → policy, project → asset.
• Coverage / scope. Which document or agreement covers what: contract →
  product, policy → risk, SLA → service.
• Dependency. What needs what: product → component, service →
  route, process → resource.
• Supply / flow. Who provides to whom: supplier → component,
  warehouse → center, manufacturer → distributor.
• Responsibility. Who is responsible for what: asset → technician,
  contract → buyer, incident → team.

When these relationships are represented explicitly — entities as
points, relationships as directed, meaningful lines — you obtain a
structure with a name you already know: a knowledge graph. We will develop it
in depth tomorrow; today it only matters to see that the business, by its nature, is a graph: entities
connected by relationships with direction and meaning.

And the consequence for agents is direct: many of the questions that
an enterprise agent has to answer are not lookups (“where is
X’s contract?”), but traversals (“what depends on X?”). A lookup
finds a document; a traversal follows a chain of relationships. And
risk decisions — the impact of a supplier failing, the scope of a
regulatory change, the exposure of a customer group — are traversals,
not lookups.

Architecture

In the series diagram, relationships are the content of knowledge,
and their natural representation is the graph:

                KNOWLEDGE
                     ↑
          ┌──────────┴──────────┐
          ↓                     ↓
      ONTOLOGY          ENTITY RESOLUTION
   (relationship types)    (canonical entities)
          ↓                     ↓
          └──────────┬──────────┘
                     ↓
        RELATIONSHIPS  →  (next: KNOWLEDGE GRAPH)
                     ↓
                SEMANTICS
                     ↓
                   DATA

The ontology (day 4) defines the types of relationship allowed (owns,
covers, depends_on, supplied_by). The entity resolution (yesterday) provides
the canonical entities between which those relationships are established. And
the company’s concrete relationships — this contract covers this product — are
the facts that will populate the graph.

Use case

The logistics operator, with its subcontractor question. We break it down:

1. Problem. The important customer asks for a service review and the
   team does not know what impact the exit of subcontractor X would have. The
   answer takes a week because the dependency chain is not
   represented.
2. Decision. Decide whether to renew, replace or diversify the
   dependency on X before the meeting with the customer.
3. Knowledge needed. Which of the customer’s products depend on X; which
   routes X covers; which alternative subcontractors exist; which contracts
   would be affected; how much margin there is.
4. Data. Orders, routes, vehicles, subcontracting contracts, service
   catalog — each in its own system, without the chain connected.
5. Relationships. The complete chain: CUSTOMER → owns → CONTRACT → covers →
   PRODUCT → depends_on → COMPONENT (route) → supplied_by → SUPPLIER (X). And
   the alternatives: other routes → supplied_by → other subcontractors.
6. Context. The meeting with the customer is in two weeks; there is
   a contract with X that expires next quarter; two routes are
   saturated.
7. Memory. Last year, the exit of another subcontractor forced
   reassigning 30 routes in five days; the lesson is in the
   post-incident report.
8. Reasoning. Traverse the chain: how many of the customer’s products
   touch X; which have an alternative; which do not; the cost and the time
   to reassign each one.
9. Action. Present to the customer a diversification plan (partial
   renewal of X + reassignment of critical routes to subcontractors B and C)
   with the impact on price and time.
10. Infrastructure. The relationship graph (customer→contract→
    product→route→subcontractor chain) + the alternatives as a
    secondary path + the memory of the previous incident + the
    traversal reasoning. The technology (a graph) appears as a consequence of the
    need (to traverse the chain), not as a starting point.

Trade-offs

• Cost. Representing relationships explicitly costs: you have to decide
  which relationships to model (not all of them), where they come from (which system is the
  source of each relationship) and how they are maintained.
• Complexity. Not all of a company’s knowledge deserves to be in a
  graph. Modeling the relationships of every email is over-engineering; modeling
  the relationships of contracts, products and suppliers is what decides
  decisions.
• Quality of the relationships. A wrongly established relationship (a contract
  that “covers” a product it does not cover) is more dangerous than its absence,
  because the agent will reason about it with confidence. Relationships
  need a source and validation.
• Maintenance. Relationships change: the contract is renewed, the
  route is reassigned, the supplier changes. A graph that is not updated is a
  map of the business from a year ago.
• Scalability. Traversing long chains in a large graph has a
  computational cost. In practice, the chains that matter are limited and can
  be precomputed; the problem appears with arbitrary traversals over
  enormous graphs, which is the topic of the knowledge graphs day.
• Honest limitation: the graph captures the relationships that are declared or
  inferable from the data. The informal relationship “in practice, if X
  fails, we call B” is not in any system until someone writes
  it down. The graph improves the explicit; it does not replace tacit knowledge.

Implication for the company

For the CDO, relationships are the asset almost nobody has inventoried:
the data are cataloged, the dashboards exist, but how the things connect
lives in people’s heads. And that is exactly what an agent
needs in order to reason about risk and impact.

For operations, the implication is concrete: impact questions
(“what happens if X fails?”) are the most expensive to answer today, and the most
valuable for an agent. Representing the relationships is what turns
a week of manual investigation into a query.

For top management, the message is one of resilience: the relationships of
dependency are where operational risk hides. Seeing them is the first
step to managing them.

Conclusion

The entities (yesterday) are the points. The relationships are the lines that make
of the whole a business. And when the points and the lines are represented
together, with meaning and direction, we obtain the structure that
enterprise knowledge needs in order to be traversed: a graph.

But a graph is not just a pretty way to draw relationships. It has
properties — multi-hop reasoning, inference, directed retrieval — that make
it different from a table, from a vector and from a document. Tomorrow
we develop that structure in depth.

Next article

Tomorrow: Knowledge Graphs: How to Represent a Company’s Knowledge. We will see exactly what a knowledge graph is, when it adds value
(and when it does not), and how it compares with SQL, a vector database and a
document.

Sources

• Working definition of the ICE: see series, Day 1.
• Knowledge representation in graphs and multi-hop reasoning
  are standard concepts of knowledge representation; they are presented in
  operational terms.