A venture platform needs a stated ontology posture

Chapter 6 opens with a point that matters more than it first appears: a foundational ontology is not just a tidy taxonomy at the top of the stack. It is a policy decision.

Hadto 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. If the shared conceptual layer stays implicit, each venture inherits the software but not the reasoning behind it.

What the foundational layer is for

Keet’s framing is straightforward. A foundational ontology should make visible:

• the top-level categories the business relies on,
• the generic relations that connect them,
• the way reusable qualities or attributes are represented.

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 difficult to align or extend once ventures need to interoperate.

For Hadto, reuse only compounds when the shared layer is intentional.

Thin alignment is not the same as a posture

Hadto already has a thin upper-layer alignment. That is useful, but it is not enough.

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

That difference matters because Hadto is building for handoff. Founders, domain experts, apprentices, and operators should be able to inspect the system and see not only which shared concepts exist, but what commitments they carry.

Why attribute modelling belongs in the posture

Chapter 6 also treats attributes as modelling decisions, not mere implementation detail.

Representing status, monetary value, identifiers, or time as literal-valued fields is often practical. The problem starts when the platform has no rule for when that shortcut is acceptable and when a richer reusable model is needed.

Without that rule:

• interoperability gets harder,
• cross-venture reporting is less legible,
• future reasoning options narrow,
• teams cannot tell which choices were deliberate and which were temporary.

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

Say the posture out loud

An upper ontology only creates leverage when the company states its ontology posture openly.

For Hadto, that means the shared layer should answer questions like:

• which top-level categories are relied on across ventures,
• which generic relations belong in the common contract,
• which foundational commitments are intentionally out of scope,
• when a reusable attribute stays a literal and when it becomes a richer conceptual pattern.

Those are operating choices. They shape how well the platform can be reused, audited, taught, and handed to future owner-operators.