Document CI API availability and historical mincrypt layouts

docs/ci-validate-file-object.md

@@ -49,6 +49,52 @@ fixed SHA-1/SHA-256 selector. Also distinguish this **input flag** from the
 unrelated `MINCRYPT_POLICY_INFO.PolicyBits` output bit `0x20`, associated with
 the built-in DMD root category in this build.
 
+## Historical generation differences
+
+The same numeric flag does not imply the same internal root mask across Windows
+versions. Static analysis of the extracted x64 corpus adds these bounded facts:
+
+- On sampled `10.0.10240.16463` (1507), `10.0.10586.0` (1511),
+  `10.0.14393.2189` (1607) and `10.0.15063.0` (1703), the recovered
+  `CipGetAcceptedRootKeys` bodies have no direct `flag & 0x20` broadening branch.
+  They still test larger masks containing that bit, so this is not evidence that
+  the flag has no effect anywhere in those verifiers.
+- On sampled `10.0.16299.125` (1709) and `10.0.17134.1130` (1803), when the
+  helper's main global mode is zero,
+  `flag & 0x20` selects mask `0x224FF` (assignment), rather than the modern
+  `mask |= 0xA4FF` operation. A signing-level predicate can select the same mask.
+  Other global additions occur afterward. The other global mode returns
+  `0x204FF` directly.
+
+The observed helper masks include branch-specific diagnostics/categories and
+must not be interpreted as an official stable root enum. The descriptive Domito
+constant names the intended broadening use without promising a single mask or
+identical behavior on every build.
+
+The ISO-derived **10.0.19041.1 x64** helper provides direct static evidence for
+the reported build family: in its main global mode it uses `mask |= 0x24FF`
+when flag `0x20` or the signing-level predicate applies; the alternate mode
+returns `0x24FF`. With requested level zero and optional global additions
+disabled, `0xAA` becomes `0x24FF` (added bits `0x2455`). This is an arithmetic
+witness, not a measurement of initialized OS policy. The exact CI SHA-256 is
+`2955710d34db26e352e62b20861ba338f0216cc36b378d128057be955e184282`.
+CodeIntegrity-RE retains matched-PDB pseudocode and assembly in
+`historical/ci-19041.1-contracts.json` and `historical/ci-19041.1-assembly.json`,
+with batch evidence ID
+`ev_13f89502777ee38ea98410f7a07f078bb934e78d792b662ab242f7b11d27e747`.
+Other 19041/19045 servicing revisions and the TESTSIGNING-off runtime workaround
+still require their own evidence.
+
+Historical records in CodeIntegrity-RE:
+`historical/ci-14393-contracts.json`
+`ev_e63a4c4b7613e231795051b784b9571605b9bf81258b5dcd04d32ddc681abb41`,
+`historical/ci-15063-contracts.json`
+`ev_338658fb82559fa6daa8ae5487b90fe84b8e408ea7578feed6d8dff5d590e114`,
+`historical/ci-16299-contracts.json`
+`ev_fe5731175f0726f0d46af2f78ca615d284f8598939296815e26b5589db3001cf`,
+and `historical/ci-17134-contracts.json`
+`ev_0c3e3359b8b7486318006afa6b95eb2257a18abeec9041a86a32db487bcbe996`.
+
 ## Evidence and compatibility limits
 
 The [upstream report](https://github.com/Ido-Moshe-Github/CiDllDemo/issues/5#issuecomment-2725851295)