A venture platform needs a stated ontology posture

Chapter 6 starts with a useful correction. A foundational ontology is not just a tidy taxonomy at the top of the stack. It is a policy decision.

This company is not building one-off software for a single team with shared assumptions. It is building business infrastructure that has to survive reuse across ventures and handoff to people closer to the domain than the codebase. When the shared conceptual layer stays implicit, each venture inherits the software but not the reasoning behind it.

The shared layer needs a stated job

Keet’s framing is straightforward. A foundational ontology should make the top-level categories, generic relations, and reusable attribute patterns visible. Without that, teams can claim to share an ontology while quietly reinventing basic assumptions about events, roles, organizations, participation, identifiers, status, dependencies, or time.

The stack may look unified from a distance and still be hard to align or extend once ventures need to interoperate. Reuse compounds only when the shared layer is intentional.

Thin alignment is not enough

Hadto already has a thin upper-layer alignment. That helps, but it is not the same thing as a posture.

A thin alignment gives teams common classes like person, organization, event, task, or document. A stated posture goes further. It explains which distinctions the company intends to preserve across ventures and which generic relations belong in the shared contract instead of being improvised downstream.

That likely means making a few top-level commitments explicit. Roles should stay distinct from the people who occupy them. Participation in an event should be visible instead of buried in local status fields. Time should be treated as part of the contract so ventures can tell when something happened, how long it lasted, and what changed after. Identifiers should travel cleanly across systems so a record can be handed off without losing its identity. That is the level a future founder, domain expert, apprentice, or operator needs to see.

Attribute choices belong in the policy

Chapter 6 also treats attributes as modelling decisions rather than mere implementation detail.

Representing status, monetary value, identifiers, or time as literal-valued fields is often practical. Trouble starts when the platform has no rule for when that shortcut is acceptable and when a richer reusable model is needed. Then interoperability gets harder, cross-venture reporting becomes less legible, future reasoning options narrow, and teams stop knowing which choices were deliberate and which were temporary.

The issue is not whether every quality needs heavyweight formal treatment. It is whether the business can explain the choice it made.

A simple example makes the risk concrete. If one venture treats a technician visit as the event, another treats the completed work order as the event, and a third hides both inside a status change on an account record, the platform can still function locally. What it loses is clean comparison, trustworthy handoff, and any reusable view of who participated in what and when.

Say the posture out loud

The posture should be stated plainly. Across ventures, the shared layer should preserve stable identifiers, explicit event and time boundaries, and clear models for roles and participation. The common contract does not need to settle every metaphysical question. It does need to make those operating commitments visible, teachable, and hard to erode through local convenience.

That is the standard. A shared ontology is only doing its job when a new venture can inherit the same basic account of people, organizations, events, and records without reopening the argument from scratch.