Applied Ontology Readiness - Design Sketch

Unit ID: applied-ontology-readiness Status: Design sketch for human review. No implementation is claimed. Trigger: human request, 2026-09-25. Close the gaps an applied (domain) ontology meets when it is built on LATTICE. Baseline: commit 9a12da4. Plan: applied-ontology-readiness.md Status record: applied-ontology-readiness.md

Premise

An applied ontology imports LATTICE layers, declares its own classes, properties, concept schemes and conditions, and expects three things from the substrate: that it can load LATTICE reproducibly, that its declarations mean what the substrate documents, and that the compilers turn its declarations into executable and checkable forms with provenance. Each gap below breaks one of these for any applied ontology, independent of its domain.

Worked examples (non-domain, per ADR-A-C2)

• Clinical trial. Admit adults with a solid tumour, excluding tumours of the central nervous system, with a dose ceiling of 2 mg per kg of body weight and a screening visit within 3 business days of consent. Two trial arms must not admit the same patient.
• Employment. Grant a relocation benefit to every job family except contractor grades. The benefit’s notice period is 20 business days. A revised policy must not silently admit a job family the previous revision excluded.
• Lending. A facility limit is stated as USD 10 million or EUR 9 million, each figure authoritative in its own currency, with no conversion between them.
• SaaS subscription. A service credit is 10% of the monthly fee. A subscription agreement exists in two language versions, both authoritative, each expressing the same uptime obligation.

Gaps

Already closed, and not repeated here: Quantification unresolvedReason domain and Instrument ins:Element disjointness (9a12da4), and Surface and Eligibility honouring voc:SchemeBinding (vocabulary-temporal-binding).

Invariants to protect

1. Every example under ontology/<layer>/examples/ validates against its layer’s shapes with no violation and no unexplained warning.
2. Any LATTICE document loads, with its import closure, from a checkout with no machine-specific configuration.
3. A version IRI identifies exactly one content of its document.
4. Every compiled form of a condition (SPARQL, SHACL, SWRL, OWL) derives from one IR plan, so no two forms can disagree about what the condition means.
5. No backend derives Undetermined from absence of evidence where ADR-A24 forbids it, and every Undetermined carries a diagnostic.
6. Substrate text stays domain-neutral (ADR-A-C1, ADR-A-C2).

Proposed deliverables

Phase C candidates (no ADR yet)

• AO10 derived rates. Declare a rate space as the quotient of two value spaces (qnt:DerivedValueSpace, numerator and denominator spaces), so “2 mg per kg” and “10% of the monthly fee” are typed values rather than dimensionless numbers. A percentage is the case where both spaces coincide. The quotient’s evaluation stays with operation capabilities.
• AO11 calendar binding. Quantification’s open question 2 leans towards binding a calendar through qnt:UnitContract. A business-day unit is then a unit whose conversion to elapsed days needs a calendar context, the same Contextual conversion rule Quantification already has. Calendar content stays deployment-supplied.
• AO12 alternative bounds. A bound set whose members are alternative statements of one limit, one per unit, with an explicit rule for how a candidate in a given unit is compared (only against the member in its own unit, Undetermined if none). No conversion is implied.
• AO13 provision attachment. Remove owl:FunctionalProperty from ins:inProvision. Its inverse, ins:hasObligation, is already unrestricted. Under ADR-A86 this widens a cardinality and is MINOR. It also removes an entailment (two provisions of one obligation are no longer inferred equal), which the ADR must state as a judgement call.

Proposed phases

Details, dependencies and token estimates are in the plan.

Coordination with other units

• eligibility-compiler: Phase B carries that unit’s deferred items (other condition kinds, profile aggregation). Its Part B reasoning harness (ADR-A83) gates AOR-10 and AOR-11.
• temporal-binding-consumer-hardening: its Finding 1 option decides how a resolution instant enters compilation. AOR-6 follows the same option.
• ontology-semantic-versioning: AOR-3 implements the proposed ADR-A86 addendum. That unit’s own slices are unchanged.
• Surface outstanding items §1.3 and §3.1 are resolved by ADR-A92, if accepted.

Deliberate non-coverage

• Serving documents at their IRIs (ADR-A88 item 5).
• Changing ontology IRIs to the …/lattice/ base (ADR-A86 addendum item 4).
• Semantics for elg:DimensionConsistent.
• The ADR-A03 question of whether an admission profile should carry a match strategy and wildcard policy at all (see open questions).
• Repairing tools/literate_extract.py drift across the core layers, already recorded by ontology-semantic-versioning.
• SPC integration.

Open questions

1. Profiles as conditions. ADR-A03 makes elg:AdmissionProfile a condition, so elg:ConditionShape requires a profile to declare a match strategy, compatibility operation and wildcard policy. The interval example gives its profile elg:SetMembership to satisfy the shape. AOR-2 follows that convention. Should ConditionShape exempt profiles instead?
2. Example scope. Should AOR-2 also bind hierarchical-match.ttl to a scheme contract (elg:constrainedByContract), so the example is evaluable under L9? Recommended, at a small cost.
3. Phasing. Should this unit become an epic with one plan per phase, given seventeen slices?