Do not let the summary become the contract

A useful mismatch showed up in Hadto’s newest ontology research reporting. The cycle history says research discovery added new competency questions. The current ORSD view still shows zero discovery-backed questions in the same areas.

This kind of mismatch needs the artifact categories named before anyone argues about the numbers. The canonical contract is the governed source of shared meaning. A projection is a workflow surface derived from it. A summary is a time-bound account of recent change.

Each category can help an operator. Only one can govern the memory of the business.

The issue is not only that evidence needs to stay attached. Hadto already made that point earlier this week. The deeper problem is what happens when a projection or summary starts getting treated as if it were the canonical model. Reports, schema summaries, generated application models, and ORSD views all do real work. None of them should quietly become the contract.

Why this matters beyond one reporting mismatch

Most companies do not lose the plot in one dramatic step. They lose it by trusting the most convenient surface.

A founder usually remembers that the report is only a report. They know which field is lagging, which summary is partial, which model was generated for one application, and which artifact is the real contract underneath. The next operator does not inherit that private map. They inherit whatever the system makes easiest to trust.

When the easiest surface is a dashboard, the dashboard becomes the remembered business. When it is a schema summary or a generated ORM model, those take the same role. The company then runs on the nearest representation of its knowledge instead of the governed source underneath.

Keet’s boundary is the business point

The closing lesson from Chapter 11.3.2 is not academic hair-splitting. It is a plain operating rule. An ontology is meant to express shared subject-domain knowledge across applications. A conceptual model usually serves the information needs of one application or implementation setting.

Those artifacts are related, but they do not do the same job. A transformation from ontology into a conceptual model, schema, report, or summary can therefore be useful without being lossless, complete, or safely reversible.

Meaning can be narrowed. Application-specific structure can be added. Context can be omitted because the target surface only needs to support one workflow. None of that is automatically a problem. Trouble starts when the derivative artifact is allowed to stand in for the canonical commitment without saying what changed on the way over.

What the current mismatch is actually warning about

The newest report says discovery additions happened. The current ORSD evidence for those areas still shows zero discovery-backed questions. The report may be right while the ORSD view is stale. The ORSD view may be right while the report overstates the current state. Both may be partly right because they describe different moments or transformation stages. The evidence chain may also be incomplete enough that neither surface should be treated as final.

This kind of uncertainty is exactly why derivative surfaces need explicit status. Operators should not have to guess whether they are looking at the governed source of truth, a lagging summary, a workflow-specific projection, or a generated artifact that intentionally dropped detail. When those categories are hidden, people start making decisions against the wrong layer.

The operational failure mode

Once a derivative surface becomes the trusted memory, people start editing the application model, schema summary, or reporting layer because it is faster than going back through ontology review. The local fix may help one workflow while quietly changing the meaning another workflow depends on.

Then disagreement turns into archaeology. Instead of asking which contract governs, the team compares screenshots, generated files, and half-remembered interpretations of what the system “really” means. The stack still looks documented, but the operative distinction lives in the head of the person who knows which artifact is only a convenience layer. Owner-making infrastructure cannot work that way.

What Hadto should insist on

If Hadto wants businesses to become teachable and owner-making, the rule should be visible in the product:

every important derivative surface must say what it is derived from, what it leaves out, and whether edits are allowed to flow back.

Five requirements make that rule usable.

1. Name the canonical contract

Do not make operators infer it. For a given question, there should be a visible answer to which artifact actually governs shared meaning.

2. Mark derivative surfaces as derivative

Do not let summaries present themselves as if they were the full model. A report, ORSD view, or generated schema should say plainly when it is a projection.

3. Record the boundary loss or additions

When a derivative surface narrows semantics, adds application-only fields, collapses distinctions, or omits evidence context, those changes should be visible.

4. Declare the round-trip posture

Can edits made in this surface ever flow back? If yes, through what review path? If no, say no. Silence is how accidental governance gets created.

5. Keep the evidence chain inspectable

A derivative surface can help an operator move quickly. It should not force them to stop at the summary layer when they need to inspect the proof underneath.

A visible labeling scheme can stay simple. The ontology record can be labeled Canonical contract. The ORSD handoff screen can be labeled Projection, followed by Derived from ontology review, Drops evidence detail for operator speed, and Round-trip: proposed edits return through ontology review.

The weekly update can be labeled Summary, followed by Generated from cycle history and Round-trip: none. Those labels are enough to keep a fast operator from mistaking the nearest surface for the governing one.

Why this is a business lesson, not a modeling lesson

Hadto is not trying to make ontology work look sophisticated. It is trying to help businesses survive transfer.

A future owner should be able to step in and tell whether they are looking at the core business contract, a view generated for one operating context, a report meant to summarize change, or an application-facing model that serves local implementation needs. If that is ambiguous, the company still depends on insider judgment to know what is real.

The right outcome is not fewer summaries. Summaries are useful. The goal is business memory that stays explicit, keeps evidence reachable, labels projections and summaries clearly, and never lets a convenient surface quietly become the company.

This mismatch points toward a tighter standard: better boundaries, not only better reporting. A business another owner can inherit needs a visible contract, clearly labeled derivative surfaces, and an explicit round-trip rule. That is the minimum standard for business memory that survives transfer.

---

Source evidence used in this note: reviewed current internal ontology research reporting and the completed Keet Chapter 11.3.2 lesson on ontology versus conceptual-model boundaries (reviewed 2026-04-18), along with existing Hadto blog posts checked to avoid duplicating earlier notes on evidence attachment, validation versus publication, semantic lifting, and live-data architecture.