rdfs:domain doesn’t check a subject — it converts it.

Much of this is right, and it stays. Every property should say what it applies to. Tools should be able to read that. And the exception — cross-cutting properties get no domain — is the right instinct. Even §2.6’s opening “critical nuance” is exemplary: it says plainly that domain and range are inferential, not validating, and that the reasoner “does not reject the assertion” — it re-types the subject instead. The dispute is only with the sentence that follows all of that: “declare them on every property” — and with hiding the excepted signatures in free-text comments.

In OWL, rdfs:domain C on property P means: everything that uses P as a subject is a C — so infer that. It never filters, never warns, never rejects. The rule most modelers actually have in mind — “only policies should carry a policy number” — is a rule about what data is allowed. The axiom cannot express that. §2.6’s own “critical nuance” paragraph says exactly this; the decision then mandates the axiom everywhere anyway.

Now put that in this ontology’s real environment. Its stated purpose is integrating messy source systems (the “Definition of Good” companion is entirely about imperfect source schemas). §2.3 declares disjointness between sibling classes across the model, and §4.1 runs OWL consistency checks. Finding F4 traces what happens when those three rules meet one bad triple: a source feed uses a property on the wrong kind of subject → the domain axiom silently re-types that subject → the new type clashes with a disjointness axiom → the whole ontology becomes inconsistent. In OWL, an inconsistent ontology entails everything — every query answer and every inference, model-wide, is now meaningless. One bad record does not fail; the model does.

• What the modeler meant: “flag any non-policy that carries policyNumber.” A per-record check with a clear error message — a SHACL shape.
• What the axiom does: “whatever carries policyNumber is a Policy.” A silent re-typing — until disjointness turns it into a model-wide failure.

§2.6 writes the warning into its own “critical nuance” — then applies the hazard to every property and points it at integration data.

The cross-cutting property §2.6 uses as its own example, both ways. As decided — the signature lives in prose:

Signature as metadata, rule as shape — machine-readable, enforced, and with no inference risk anywhere:

As with the code-list decision, most of this argument comes from the design document itself:

• §2.6’s “critical nuance” already concedes the whole argument: domain/range are “inferential, not validating … the reasoner does not reject the assertion. For validation, use SHACL.” The decision two paragraphs later mandates the non-validating construct on every property.
• §2.6’s own cross-reference points to “§4.2 (SHACL validates domain constraints that OWL only infers)” — naming SHACL as the layer that does the actual job.
• §2.6’s own exception is the rule behaving correctly. Its showcase property, ra:hasRiskObservation, ships without a domain — the best-behaved property in the document is the one that breaks the rule.
• §2.5 already teaches the same lesson for property characteristics: “these are inference rules, not constraints — FunctionalProperty does not reject a second value; it infers the two values are identical.” The identical logic applies to domains; §2.6 forgets it one section later.
• §2.3’s stated goal is “a loud inconsistency report” instead of silent nonsense — but domain + disjointness delivers neither: silent re-typing when there is no clash, a model-wide failure when there is. A SHACL violation is the loud, local report §2.3 actually wants.
• F4 (High) flags the live interaction — domain everywhere (§2.6) + disjointness everywhere (§2.3) + OWL consistency checks over integrated data (§4.1) — and recommends exactly this split: the reasoner checks the schema (T-Box); SHACL checks the data (A-Box).
• F20 (Minor) flags the union rationale as a misreading that teaches authors to fear a sound construct — while the comment-based escape hatch is the least machine-readable option on the table.

This is a correction, not a purge: rdfs:domain/rdfs:range keep a legitimate, narrow role. The test is simple — if the reason for the axiom is “documentation” or “validation,” it should not be an axiom. A domain earns its place only where you want its inference to fire.

The revision keeps everything §2.6 got right — a signature on every property, the cross-cutting exception’s instinct, SHACL as the validation layer — and gives each job to the construct built for it: metadata for tools, shapes for checking, axioms for the inference you actually chose.