Review findings on 9bb307e: Calc 1.0 as iXBRL acceptance basis contradicts RTS Ch. 3 art. 5 reading; ix-0514 trigger; INFENT/AUTACK/CONTRL

[MaxSchoon]

What

Three findings from the CodeRabbit CLI review of the doc2ixbrl sync to 9bb307e (ontoslabs/doc2ixbrl#8378), each checked against a primary source before filing. Findings against the vendored tree go upstream rather than being patched downstream, so they are recorded here for the owner to promote or decline.

1. nl-sbr.md presents a Calc 1.0 pass as the KvK deposit-acceptance verdict for an iXBRL package, against the file's own reading of RTS Chapter 3 art. 5 (major)

references/jurisdictions/nl-sbr.md (Calc section, around lines 749-777, and the review workflow around lines 1589 and 1620), references/validation.md § 4 (around lines 179-184 and 274), references/taxonomies.md (around line 299) and references/viewer.md (around line 97) all say: the NT20 Filing Rules list XBRL 2.1 as the normative calculation basis, "so the KvK deposit-acceptance test runs on Calc 1.0 semantics", and label the --calc c10 command "Deposit-acceptance pass" (heading changed in #46 from "Legacy / compatibility pass only if the operative validator profile uses it").

The same file, in the block-tagging section added by #47 (around lines 1015-1020), reads the RTS the other way: all four rule sets "address 'XBRL instance documenten', and the RTS binds them to that route alone: Chapter 3 art. 5 ... while the Chapter 2 iXBRL articles name none of them." The cheatsheet row (line 233) gives Calc 1.1 as the FY2025 and FY2026 basis for KvK iXBRL Report Packages under RTS Annex III.

Those two readings cannot both hold. If the Filing Rules bind the Chapter 3 route alone, their XBRL 2.1 calculation basis is not the acceptance basis of a Chapter 2 iXBRL package, and the "Deposit-acceptance pass" label is wrong for the file this section is about. Suggested resolution: keep the Calc 1.0 pass, but scope it to the Chapter 3 classic route or relabel it an optional compatibility diagnostic for iXBRL packages, and align the four other references. Downstream, doc2ixbrl already validates KvK iXBRL packages under Calculations 1.1 by taxonomy arcrole and filing profile, never by a --calc flag (its AGENTS.md § XBRL Validation Standard), so this is the product's operative reading.

2. sec-edgar.md states the wrong trigger for EFM 5.2.5.14 / ix-0514 (major)

references/jurisdictions/sec-edgar.md around lines 197-202: "EFM 5.2.5.14 (EDGAR message ix-0514) requires that any ix:hidden fact whose value also appears as visible text be referenced via the -sec-ix-hidden CSS style on the visible element".

The SEC's EDGAR XBRL Validation Warnings page (https://www.sec.gov/data-research/xbrl-validation-rendering/edgar-xbrl-validation-warnings, read 2026-09-04) lists three 5.2.5.14 warnings, none conditioned on visible duplication:

• ix-0514-Hidden-Fact-Not-Referenced: "{countUnreferenced} fact(s) appearing in ix:hidden were not referenced by any -sec-ix-hidden style property"
• ix-0514-Hidden-Fact-Eligible-For-Transform: "{countEligible} fact(s) appearing in ix:hidden were eligible for transformation"
• ix-0514-Hidden-Fact-Multiple-References: "{element} is referenced by {countReferences} -sec-ix-hidden style properties"

So the trigger is any hidden fact without a -sec-ix-hidden reference (a warning, not a rejection), with a separate warning for hidden facts that a transform could have displayed. The cover-page case (dq-0545, EFM v68 § 6.5.45) stays a distinct rule: a cover-page fact must be visible or referenced. The sentence "A duplicate fact must have at least one occurrence outside ix:hidden" is the EDGAR XBRL Guide's visibility convention and is correct, but it reads as the same rule when placed here. Suggested resolution: state the three ix-0514 warnings and their triggers, keep dq-0545 separate, and say "warns" rather than "requires".

3. fr-amf.md folds AUTACK and CONTRL into "the INFENT message family" (minor)

references/jurisdictions/fr-amf.md around line 276: "the INFENT message family (INFENT DF for the declaration/liasse, AUTACK for securisation, CONTRL for the syntactic ack) of directory D00B".

DGFiP's cahier des charges EDI-TDFC 2026, Volume IV § 4.1.1 "Les messages EDIFACT" (https://www.impots.gouv.fr/sites/default/files/media/1_metier/3_partenaire/edi/cdc_edi_tdfc/2026/volume_iv_tdfc_2026.pdf): "Trois messages EDIFACT ont été retenus": INFENT "Informations des Entreprises" of directory D00B (declaration, technical acknowledgement, readability and security error reports, processing report, via the GUMs INFENT DF, INFENT RCS, INFENT CR); AUTACK "Authentification et accusé de réception sécurisé", part 6 of EDIFACT version 4, for electronic security; CONTRL "Compte rendu syntaxique et de service", part 4 of EDIFACT version 4, for the syntactic rejection. AUTACK and CONTRL are separate UN/EDIFACT messages, not INFENT variants, and only INFENT is from D00B. Suggested resolution: name the three messages as the source does.

Done when

Each of the three is either applied upstream (with the citation the source provides) or declined with a reason on this record; doc2ixbrl resyncs at the next upstream tag.