owl:cardinality doesn’t count your data — it declares a truth.

The goals are right, and they stay. Constraints should be explicit and machine-readable, not tribal knowledge. “A party must have exactly one party number” should be written down where tools can check it. The dispute is only about the layer: §2.7 writes the rule as an OWL axiom — a statement the reasoner treats as a fact about the world — when what the rule wants to do is count values in records and complain. Counting and complaining is SHACL’s job, and the design’s own §4.2 says so.

OWL reasons under the open-world assumption: missing information is treated as unknown, not as absent. That single fact breaks both halves of the cardinality-as-restriction plan:

• The “mandatory” half never fires. owl:minCardinality 1 on partyNumber means “every party has at least one party number — somewhere, stated or not.” A party record with no party number is not an error to the reasoner; it assumes the number exists and simply wasn’t written down. The completeness check the modeler wanted silently does nothing.
• The “at most one” half fires the wrong way. Give a party two party numbers and owl:cardinality 1 does not reject either. For object values the reasoner concludes the two values are the same thing. For literals like "P-1" and "P-2", which cannot be equal, it concludes the ontology is inconsistent — and an inconsistent ontology poisons every inference, model-wide (finding F3, rated Critical).

So the restriction either stays silent or takes the whole model down. Neither behaviour is what “a well-formed party has exactly one party number” meant. SHACL, which counts under a closed-world reading and reports per record, is the construct that means it.

§2.7 wants a gate. It installed a fact. Facts don’t stop bad data — they absorb it.

The default case: cardinality as a shape, with the constraint stated once, checked closed-world, and free to evolve:

The exception — the logical-axiom viewpoint. Here the restriction states a truth of the domain, and the reasoner uses it to classify. This is inference creating knowledge, not counting values:

As elsewhere in this series, most of the argument comes from the design document itself:

• §2.7’s own preamble says it: restrictions “are OWL axioms (inference), not SHACL shapes (validation).” The rationale then calls them “reasoner-enforceable” and reads them as the definition of a well-formed instance — validation words for an inference construct.
• §2.5 already teaches the exact semantics: “FunctionalProperty does not reject a second value; it infers the two values are identical.” §2.7 quotes the same property as “double-enforcement” one section later.
• §4.1/§4.2 draw the line correctly — OWL owns ontological truth, SHACL owns data quality, “a cardinality restriction in OWL and a sh:minCount in SHACL do different jobs.” §2.7 uses the OWL one to do the SHACL job.
• §4.2’s mirror requirement creates the drift finding: every cardinality is hand-copied between OWL and SHACL with no generation or sync check — F14’s “two sources of truth, guaranteed drift.”
• F3 (Critical) flags the concrete failure: Functional + cardinality 1 on identifiers means the first party arriving with two source keys collapses consistency checking for the whole graph, instead of producing one violation report.
• The review’s own synthesis names the root cause: “the design reaches for an OWL axiom where it wants a data constraint.” §2.7 is the clearest instance of it.

This is a correction, not a purge: OWL restrictions keep a legitimate, narrow role. The test is simple — if failing the constraint should produce a violation report, it is a shape. If satisfying it should let the reasoner conclude something new, it is an axiom.

The revision keeps everything §2.7 wanted — explicit, machine-readable constraints declared early — and gets both behaviours right: bad data produces named, fixable violation reports, and the reasoner spends its effort on classification the team actually asked for.