# Ontology: entities and relationships

Understand how company knowledge becomes a cited view of people, organizations, decisions and their relationships.

An ontology describes the kinds of things a company knows about and the relationships between them. In Company Brain, this appears as an Entities and relations view derived from the company’s cited memory pages.

For example, a person, a product and a decision are different kinds of things. “Helps with” and “owns” express different relationships. Keeping those distinctions makes a question such as “Who owns this, and why?” more precise.

## Entities and types

An **entity** is a particular thing. Its **type** says what kind of thing it is. A company called Harbor is an organization; its Launch Kit is a product; a named customer workshop is an event.

The current view can represent these kinds:

| Kind | What it represents |
| --- | --- |
| People | Company members and named people outside the company. |
| Organizations | Customers, suppliers, partners and other organizations mentioned in the pages. |
| Products and tools | Products, components and tools the company discusses. |
| Teams | Named teams or working groups. |
| Events | Named occasions such as a workshop, conference or launch. |
| Decisions | An agreement or choice recorded in the company’s memory. |
| Rules | A recorded working norm or rule. |
| Terms | Vocabulary and definitions used by the company. |
| Commitments | A dated record of something someone promised, requested or was waiting for. |
| Questions | A question the memory records as needing an answer. |
| Channels | A conversation channel associated with the cited learning. |

An event here is a named occasion. It is not a promise that every source change becomes a separately queryable event stream. A recorded commitment also does not establish whether the work is still open; check its current task or source record.

## Properties describe a thing

An entry has a name and type, and can include a description, alternate names, a date and supporting sources. These details help a reader distinguish one entry from another.

A decision’s reason, scope or expiry may be explained in the cited page text. Do not assume every detail is a separately filterable field. The current view is generated from the company pages; these docs do not describe a custom schema editor or a way to create arbitrary property types.

## Relationships connect things

A relationship has a direction: “Harbor is a customer of Northstar” says something different from the reverse. Read the relationship together with its evidence and any qualifying note.

| Relationship | How to read it |
| --- | --- |
| Owns; helps with | Accountability for something, or a supporting contribution. Helping does not itself establish ownership. |
| Decided; committed to; asked for | Who made a decision, voiced a commitment or requested something. |
| Waits on; depends on | A dependency that matters to the next step. |
| Supplies; customer of; partner of | How organizations and their offerings relate. |
| Uses; part of | What relies on a tool or belongs within a larger thing. |
| Defines; about | What a term names or a question concerns. |
| Supersedes | A later decision replaces an earlier one. Check the scope of the replacement. |
| Scheduled for | A commitment is associated with a named event. |
| Involves; discussed in | The people involved in a recorded learning and the channel where it was discussed. |

Relationships are descriptions of recorded knowledge. They do not grant permissions, assign a task in another system or execute an action.

## Identity and alternate names

The same organization or product may have several names. The generated view can group names when the evidence supports that they refer to the same thing and retain those alternate spellings.

Ambiguous names should stay distinct. Two people named Alex are not necessarily the same person, and a product nickname may also name a different product. The view can show possible matches that were kept apart for review.

When you see a mistaken match, identify the exact entries and the source that distinguishes them. Correcting the company knowledge is more useful than treating a convenient label as proof of identity.

## Every connection needs evidence

The view is derived from cited lines in company memory. Entries and relationships retain references to the learning and sources behind them. Unsupported or unresolved entries can be omitted rather than turned into a connection.

A citation makes the claim inspectable; it does not guarantee the interpretation is right. Open the page and source to check that they establish the specific relationship, not merely mention both things. If the relationship is uncertain, ask Milo to state that uncertainty.

## Follow a small example

An illustrative company page records: “Jordan committed to prepare the Launch Kit training for Harbor’s workshop. The workshop depends on completion of the training.”

That can support a person, a product, an organization, an event and a commitment, connected by “committed to,” “scheduled for” and “depends on.” It does not establish that Jordan owns the whole product, that the workshop is approved or that the training is already complete.

> Show the people, decisions and dependencies connected to the Harbor workshop. Explain each connection with its source, keep uncertain name matches separate, and check the current task record before calling anything complete.

## Updates and access

The Entities and relations view is generated after company-memory processing. The underlying company pages remain the editable knowledge it is built from. A source change may need to reach those pages and a later generation before it appears in the view.

The view belongs to the company memory it was derived from. A connection between two entries does not widen their audience or open an inaccessible source. Ask your company’s designated steward about a correction or removal; do not assume changing one displayed name changes every source record.

Use [Context graph](https://joinhexagon.com/docs/context-graph.md) to turn these concepts into a dependency question, or [Decisions and memory](https://joinhexagon.com/docs/decisions-and-memory.md) to understand how agreements change over time.

## Related guides

- [Company Brain](https://joinhexagon.com/docs/company-brain.md)
- [Context graph](https://joinhexagon.com/docs/context-graph.md)
- [Connected knowledge](https://joinhexagon.com/docs/connected-knowledge.md)
- [Decisions and memory](https://joinhexagon.com/docs/decisions-and-memory.md)

## References

- [Company Brain](https://joinhexagon.com/company-brain)
- [Context graph](https://joinhexagon.com/context-graph)

Last updated: 2026-10-31
Canonical: https://joinhexagon.com/docs/ontology
Markdown: https://joinhexagon.com/docs/ontology.md