One comment on “Members Used Across Incompatible Dimension Classes”

1. Avinash Saraswat says:

   Friday, September 25, 2026 at 8:37 PM

   The Conditions section and the Technical Details section on this page describe two different predicates, and the whole difference between them is a false positive question.

   Conditions lists two things. The first is that a member appears in the taxonomy across dimensions belonging to different classes. The second reads “The filing uses that member on dimensions from incompatible classes.” DQC_0245, DQC_0248 and DQC_0249 each say the assertion “fires when all of the following are true.” This page says only “Assertion 10962 fires when:”, so the conjunction is never stated. Technical Details then drops the second condition entirely: “The rule operates at the taxonomy level (examining all defined members, not just those used in the filing) to catch potential conflicts that could arise from improper member usage. This approach ensures that even if a member is not currently used in a filing, the conflict is identified at the taxonomy validation stage.”

   Two further statements on the page point the other way. The Report errors step inside that same section says the rule reports “which incompatible classes the member is used across”, and the example message opens “The filer has reported a member UnitedStatesMember that is used across different incompatible dimensions.” Three statements describe a rule about what the filer did. The first analysis step and the paragraph quoted above describe a walk of the taxonomy instead.

   The published v31 source settles which one runs. Assertion 10962 builds its member list by navigating dimension-member relationships down from each axis, then reports every member found under axes of more than one class. Nothing in it tests a reported fact. Its header comment still says it will “check if members in a filing are not used across different dimensions without the same class.” So the code matches Technical Details. Condition 2 and the example message describe a test on reported facts that the code does not contain.

   A usage scoped rule and a taxonomy scoped rule are not the same rule. The one in the v31 code can fire on a member that no reported fact carries on those axes, and its message then tells the filer they “reported” that member. If defining the member that way is not itself the error, that firing is a false positive, and the Rules Development Process says why every rule is researched for them: “the risk is too high that a filer will be led astray and waste time attempting to correct something that was right in the first place, and potentially introduce a new error into their filing.”

   Suggested revision. Make the page, the message and the code describe one rule. If the usage check is intended, add the fact test that Condition 2 describes. If the taxonomy check is intended, rewrite Condition 2 and the message to match it. Then publish its firing rate from the historical filing run the process document already describes. Report that rate separately for members with reported facts on incompatible axes and for members only defined. Consider whether the defined but unused population belongs in a separate assertion, so a filer can tell the two cases apart from the message alone.

   Second point, smaller and quickly fixed. The class names are filer facing, since the example message names them: “The incompatible dimensions this member is used on are Geography, FinancialInstrument.” Five of the twenty-seven published class names will not survive that. FairValueHierachy is missing an r, Scenerios should read Scenarios, and entityIndividualPlanName, statisticalMeasurement and foreignDomesticDistribution are camelCase where the other twenty-four are TitleCase. Step 3 of the Rules Development Process asks each rule to provide “simple instructions that issuers can easily follow to correct their filing.” Misspellings in a name the filer reads back from an error message do not meet that bar. Note also that entityIndividualPlanName is the class holding dei:LegalEntityAxis, which DQC_0245 and DQC_0248 both steer filers toward in this same exposure. A filer following that guidance should be able to tell whether it puts them at risk under this rule, and the page as written does not say.

   Why the scope wording matters more than it looks, and my basis for saying so. I maintain a public tool that checks generated financial narrative against XBRL company facts. An earlier version of its narrative grounding check matched numbers against all pairs arithmetic over the fact base. Twenty-four facts expanded to roughly 460,000 candidate values, dense enough that 100% of random numbers passed. The description of the check was accurate. The check accepted everything anyway, and nothing in the description would have told you that. I rebuilt it around roughly 200 semantically typed derivations and published the residual false acceptance rates it still carries rather than leaving them out. That failure and those rates are in docs/DESIGN.md under D7 at github.com/avinashsaraswat/fsi-eval-harness.

   The transferable finding is that the scope of the set a rule evaluates against decides its error profile, and prose about that scope will not reveal it. A published firing rate will. My error ran the other way from the risk here. Too large a set made my check accept everything; too large a set here lets this rule fire on members no reported fact carries. The direction differs. The lesson does not. On DQC_0250 the page describes both rules and the code runs one of them, so a filer reading the page cannot tell in advance which one will judge their filing.

   Avinash Saraswat
   Submitted in a personal capacity.

   Log in to Reply

Comment

You must be logged in to post a comment.