PQA030 — Multiple access-model roots inferred¶
The access model infers more than one person-owned root.
Ownership is read from the reference graph. An entity that nothing else references is an allocator root and is taken as person-owned; entities reachable from it are shared. A well-formed model has one such root — the record the panel allocates per person, with everything else hanging off it by reference.
Two roots means some entity lost its way into the graph.
Why this is reported¶
The usual cause is a flattened reference. A shared table referenced by an integer instead of by an entity type (see RULE-040) is invisible to the graph. Nothing appears to reference it, so it is inferred to be a second person-owned root — and from then on it is synchronized per person instead of once per installation.
The consequence is duplication on the panel. A time-zone table written once per cardholder exhausts a table sized for the installation, and the overflow surfaces as rejected writes late in a large sync.
How to fix it¶
Look for an integer that should be a reference.
If both roots are genuinely intended, say so. Declaring owner: person on each intended root states the intent explicitly and silences the inference.
What is not reported¶
A single inferred root. The ordinary shape.
Explicitly declared roots. Once owner: is declared, ownership is no longer being guessed.
If you disagree with a report¶
Do not suppress it. A wrong report is a bug in the check — report it with the YAML that triggered it.