Add reusable certificate and file validation helpers

Fix process-name ownership and module lookup outputs, add explicit SPKI hashing and bounded chain access, and improve WDM integration. Deprecate superseded entry points with migration guidance and align branch code and tests with the library style.

Add CI validation helpers with explicit signature selection and owned results

Document runtime-confirmed CI signer selection and crypto reuse

Expand CI compatibility matrix to twenty verified samples

Extend CI export matrix with Windows 11 x64 and ARM64 samples

Document CI API availability and historical mincrypt layouts

Add explicit Authenticode workflows and correct CI helper contracts

Document CI validation flag 0x20 and add kernel probe

Harden CI digest parsing and failure cleanup

NOTES.md

@@ -1,16 +1,76 @@
-# CI APIs
+# CI API availability observations
 
-## Available starting with 1511
+See the [CI API compatibility matrix](docs/ci-api-compatibility.md) for the
+per-API tables covering 20 VM, ISO and modern x64/ARM64 samples, with exact
+versions, file hashes and machine-readable results. The six-sample notes below
+describe the original VM corpus and its subsequent ISO follow-up.
 
-- CiCheckSignedFile
-- CiFindPageHashesInCatalog
-- CiFindPageHashesInSignedFile
-- CiFreePolicyInfo
-- CiGetPEInformation
-- CiInitialize
-- CiValidateFileObject
-- CiVerifyHashInCatalog
+These are export-table observations from six extracted x64 `ci.dll` files, not
+claims about every servicing revision or a proof of the original introduction
+build. The companion CodeIntegrity-RE `corpus-index.json` records identities,
+extraction aliases, manifest checks, and metadata. VM directory names are labels;
+versions below come from the PE version resources. No target was executed.
 
-## Added in 1709
+## Named exports common to all six samples
 
-- CiSetTrustedOriginClaimId
+- `CiCheckSignedFile`
+- `CiFindPageHashesInCatalog`
+- `CiFindPageHashesInSignedFile`
+- `CiFreePolicyInfo`
+- `CiGetPEInformation`
+- `CiInitialize`
+- `CiValidateFileObject`
+- `CiVerifyHashInCatalog`
+
+`CiValidateFileObject` is already present in sampled Windows 10 **1507**
+`10.0.10240.16463`. The old “starting with 1511” list was therefore too narrow.
+Export presence does not establish a complete compatible parameter/structure
+contract; consult the per-build static analysis before using it.
+
+## Additional names and absent names
+
+`CiSetTrustedOriginClaimId` is present in sampled `10.0.15063.0` (**1703**) and
+in the sampled 1709/1803 files. It is absent from the sampled 1507,1511,1607
+export tables. This corrects the old “added in 1709” note, without claiming the
+first Windows build on which the API ever existed.
+
+`CiGetCertPublisherName` is absent from **all six** sampled 1507–1803 export
+tables. The ISO follow-up also finds it absent in x64 `10.0.19041.1`, present
+in x64 `10.0.19041.1865` and `10.0.22000.318`, and the original investigation
+finds it present in `10.0.26100.8328`. This brackets Windows 10 servicing
+observations without identifying the first update adding the export. The
+CodeIntegrity-RE `iso-corpus-index.json` records the exact files and hashes.
+The Windows 10 ARM64 21H2 sample additionally exports it in CI
+`10.0.19041.1566`; this does not establish x64 availability at that revision.
+The matrix keeps architecture-specific observations separate.
+A header declaration,
+import-library symbol, or `NTDDI_VERSION >= NTDDI_WIN10` alone does not make an
+unconditional static import loadable on the older samples. Callers supporting
+those samples must avoid that import or use optional resolution with an
+explicit unavailable/fallback path. `CiSetTrustedOriginClaimId` likewise cannot
+be assumed available on every Windows 10 build; it is a CI-global setter.
+
+The original modern x64 sample has display `FileVersion` **26100.8328**, but
+its numeric fixed version is **26100.9444**. The matrix records both under the
+same SHA-256 identity and uses numeric fixed versions in its tables.
+
+## Exact sampled files
+
+- Windows 10 1507: `10.0.10240.16463` x64, SHA-256
+  `e83d900f4675c6e6ffc3fb7dcd3074610876a1398e495796769988df810fd3bc`.
+- Windows 10 1511: `10.0.10586.0` x64, SHA-256
+  `f949bfa614addea6174b28c3818c56b327c9290fd41bd91dfc545414b3df6783`.
+- Windows 10 1607: `10.0.14393.2189` x64, SHA-256
+  `ef0c02ecbd0818e84be9f61421f919825f96a3c59199460cab08548eee2881df`.
+- Windows 10 1703: `10.0.15063.0` x64, SHA-256
+  `3705aaf408f05326e028621380aa5c96a1f3583a2de8a139b188da4b82577863`.
+- Windows 10 1709: `10.0.16299.125` x64, SHA-256
+  `1db7ae5a08bd2361fc7fcdd373fb980e8d680035e67b02e5967095db0443effd`.
+- Windows 10 1803: `10.0.17134.1130` x64, SHA-256
+  `8ce3b8fe38c23b699f30b045383640019a429d3a9d513285c655bffe03a796d9`.
+
+Matching Microsoft public PDB GUIDs/ages were verified in
+`historical/ci-<build>-symbols.json` in CodeIntegrity-RE. Public names help map
+functions; they are not a full typed SDK. The default Domito declarations remain
+conservative. See [current contracts and limits](docs/mincrypt-contracts.md) and
+[implementation status](docs/implementation-status.md) for ABI and runtime work.