What should a thin ontology production slice prove?

Slice through a decision rather than a technology layer

A fictional team proposes to spend its first month integrating five databases before showing a planner anything. A thinner slice instead supports one work-order decision across only the necessary evidence and services. It still reaches the user and the relevant operating boundary. A partially completed data layer cannot establish whether the intended decision is useful or understood.

State what improvement would matter

Define the expected change in the planner’s work: less reconciliation, fewer invalid candidates, faster correction, or clearer handoff. Record a baseline and a way to observe the outcome. Avoid choosing the measure only after the demonstration succeeds. The slice should also name a stopping condition, such as unresolved identity ambiguity that prevents reliable candidate selection.

Use actual boundaries with limited consequence

Start with authentic identity and appropriately scoped data access, while keeping the first result a proposal where that meets the purpose. Mocking every permission and conflict can hide the hardest part of enterprise delivery. Conversely, giving a first prototype unrestricted authority adds consequences without improving the evidence needed for the initial decision.

Progress through explicit evidence gates

Gate	Evidence that permits the next step
Decision	User, alternative, and desired outcome are clear
Mapping	Relevant source meanings and conflicts are reviewed
Shadow use	Results can be compared without changing production
Limited action	Authorization and target preconditions are enforced
Operation	Failures have detection, response, and recovery owners
Handoff	The receiving team can run and correct the slice

These gates are an author-designed review sequence. Their value comes from evidence, not from completing a checklist as a ceremony.

Compare a wrong answer with a correct refusal

During a shadow trial, include missing evidence, an outdated supplier statement, and a candidate outside the caller’s scope. A correct refusal or request for clarification may be the best available result. Grade these cases separately from successful recommendations so that pressure for a higher completion rate does not reward unjustified confidence or excessive access.

Finish with an operating handoff

Give the receiving team a supported scenario, known limitations, correction process, and a rehearsed response to one realistic failure. Ask it to explain a result without the original FDE present. If only the implementation team can interpret the mapping or repair the pipeline, the slice has not completed its ownership transfer. Expansion should follow demonstrated operating value and supported reuse, rather than a polished demonstration alone.

Evidence and scope

• W3C Data Quality Vocabulary: DQV provides vocabulary for expressing quality measurements and their context.
• OWASP Authorization Cheat Sheet: Authorization must be checked on every request and enforced in a trusted component.

The proposed checks are teaching tools; validate their behavior in the actual environment.