Question-led guide · how-to
How should ontology discovery start with a business decision?
A discovery workshop that turns a vague enterprise AI request into a bounded decision, evidence requirements, accountable owners, and meaningful exceptions.
Direct answer
Begin with a recent decision that changed work, then reconstruct its inputs, alternatives, authority, and outcome. Identify the minimum shared meanings needed to repeat that decision reliably. Collect nouns only when they clarify those commitments. A useful discovery packet explains what the system may conclude, what remains uncertain, and when a person must resolve a conflict.
Replace the technology request with a moment of work
A fictional service company asks for an ontology and an agent to coordinate replacement parts. Begin by asking a planner to reconstruct one recent reservation that needed correction. Which order was involved? What did the planner believe was available? What changed the decision? This produces a bounded operational question before the team commits to a large inventory of business terminology.
Reconstruct alternatives as well as the chosen answer
A final reservation record hides rejected options and informal checks. Ask which alternative was considered, why it failed, and what evidence would have reversed the choice. A supplier promise, warehouse observation, and internal allocation may all describe “availability” while supporting different actions. Preserve the disagreement instead of settling it by choosing one convenient field name.
Identify the owner of each claim
Separate the person who made the decision from the source that supplied a fact and the service authorized to make the change. Those roles may belong to different systems. Record how old the evidence may be, who can correct it, and how the decision handles missing or conflicting observations. Provenance becomes useful when someone can follow it to a correction path.
Write a decision card before a concept catalog
| Card field | Question to answer |
|---|---|
| User and moment | Who makes which decision at what point in work? |
| Candidate set | Which options may be considered? |
| Evidence | What supports each option, and when was it valid? |
| Constraints | What can disqualify a seemingly useful option? |
| Authority | Who may recommend, approve, and execute? |
| Outcome | What observable state would establish success? |
The card is an original facilitation tool. It is deliberately small enough to challenge with one successful and one failed decision during the same review.
Let exceptions reveal the missing meaning
Test an expired supplier commitment, a reused identifier, and two warehouses reporting the same physical part. Ask whether the proposed model can express the disagreement without overwriting history. The goal is not to enumerate every enterprise exception. It is to discover the distinctions that change this decision and therefore deserve an explicit contract.
End discovery with a testable boundary
A useful first agreement might allow a system to propose candidate reservations with evidence while leaving execution to an existing service. Record what the slice will exclude and what would stop it. Discovery is complete enough to proceed when the team can explain a permitted result, a rejected result, and an unresolved result using the same terms. More nouns are helpful only if they improve that explanation.
Evidence and scope
- W3C PROV-O: PROV-O represents entities, activities, agents, and derivation relationships.
- W3C Data Quality Vocabulary: DQV provides vocabulary for expressing quality measurements and their context.
The proposed checks are teaching tools; validate their behavior in the actual environment.
Evidence
PROV-O represents entities, activities, agents, and derivation relationships.
PROV-O represents entities, activities, agents, and derivation relationships.
Primary source · standard · checked Sep 11, 2026
Limit: This source supports the named mechanism, not the outcome or thresholds of the illustrative workflow.
DQV provides vocabulary for expressing quality measurements and their context.
DQV provides vocabulary for expressing quality measurements and their context.
Primary source · official-doc · checked Sep 11, 2026
Limit: This source supports the named mechanism, not the outcome or thresholds of the illustrative workflow.
Limitations
The scenarios and decision worksheets are original teaching examples. They are not measured deployments or guarantees; adapt the checks to the actual system and its documented behavior.
FAQ
- Do we need an enterprise-wide ontology before the first slice?
- No. Start with the shared meanings needed for a bounded decision and extend them when additional use is justified.
- What should a discovery workshop produce?
- A decision record with evidence, alternatives, ownership, exceptions, and a verifiable outcome is more useful than a noun list alone.
Related guides
Continue within Ontology-driven enterprise delivery, or use one of these adjacent diagnostics:
Editorial QA: automated native-English, structure, source-presence, and link checks completed . This record is not an independent expert endorsement. Review boundary.