The right tool for a code list is the one built for code lists.

Half of this decision is right, and it stays. Code-list entries are values, not subclasses. §2.4’s quick test (“is this a category of things with its own structure, or a value in a controlled vocabulary?”) is exactly right, and nothing here reopens it. The disagreement is only about how to represent those values: as a closed owl:oneOf list inside the schema the reasoner works on (the T-Box), or as a SKOS concept scheme that sits next to the schema. And about the blanket rule that SKOS may only be used for annotation.

owl:oneOf is a schema construct. It defines a class by listing its complete membership, and the reasoner treats that list as a logical fact. A code list — perils, lines of business, statuses, NAICS codes — is reference data: a governed list of values that changes whenever the business needs it to. What a code list needs is labels, business codes, hierarchy, and mappings to other systems. What it does not need is logic. §2.2 ties the fastest-changing content in the model to the layer that is hardest and riskiest to change.

Make it concrete. Mid-quarter, underwriting adds Cyber to the peril list:

• Under §2.2: adding the value means editing the published owl:oneOf axiom. That is a schema change — a new ontology version under §5.5’s own rules, which every consumer re-imports and the reasoner reprocesses. All for one new value.
• As a concept scheme: add one skos:Concept and one IRI to a SHACL sh:in list. The schema does not change; the vocabulary has its own version number and release cycle.

The cost also grows with the size of the list. Individuals enumerated inside class definitions (“nominals” in OWL terms) are one of the known things that make reasoning slow. A three-value status list is harmless. NAICS has over 1,000 codes — a closed oneOf at that size gives the reasoner heavy work to support an inference nobody needs. SKOS concepts are ordinary instance data; the reasoner never touches them.

The project already imports SKOS (§1.1’s standard stack). Using it for the job it was designed for is the “reuse first” principle the design says it follows. It is the ban that needs a justification.

Party status per §2.2 — including the owl:AllDifferent the pattern needs but leaves out:

The same list as a governed scheme, with validation where it belongs:

Most of this argument comes from the design document itself:

• Appendix A’s table already points away from oneOf for the common case. Its own rows say “validation-only allowed-value check → SHACL sh:in” and “open set that will grow → no owl:oneOf.” Perils, LOB codes, and NAICS are open, growing sets that need exactly that check — yet the “in this ontology” paragraph prescribes closed oneOf anyway.
• §5.4 already requires SKOS on every term — trilingual prefLabel, definition, example, altLabel. The documentation the design demands is exactly what a skos:Concept carries natively. The “annotation only” rule imports SKOS and then forbids its data model.
• §5.5’s deprecation pattern already uses skos:exactMatch to point a retired term at its replacement — SKOS mapping doing governance work inside the schema layer.
• §1.2’s identity guidance already prefers identifiers with skos:notation over owl:sameAs, to avoid merging properties. Mapping code values with skos:*Match is the same safe-alignment idea, applied to vocabularies.
• §2.4’s promote-to-class test already covers the rare value with real structure — which removes the only case where Claim 2 would matter.
• Finding F7 in the companion review flags this same choice (reasoner cost, volatility, drift between projects) — and notes that the sibling Chubb ontology already publishes perils, statuses, and LOB codes as SKOS schemes. Keeping §2.2 as-is creates two Chubb vocabularies that need a translation layer to work together.

This is a correction, not a purge: owl:oneOf keeps a legitimate, narrow role. The test is simple — if SHACL sh:in can meet the requirement, owl:oneOf was not needed.

The revision keeps everything the original decision got right — values are not subclasses, closure is still available, ACORD alignment stays first-class — and puts reference data where it belongs: next to the schema, in the standard the project already imports.