02 — The library
Summary
Everything the tool knows lives in one versioned JSON file, served same-origin, readable raw, and rendered by its own explorer page. The code computes; the library claims — so an argument with the tool is an argument with a library row, reviewable in a pull request. The basis rule keeps named products from becoming a vendor scorecard: every tree is derived from what a surface architecturally is, so the product picks the surface and the surface carries the tree. Facts are questions with a fixed vocabulary and requires-chains; controls are already-true containment with four structural effect fields; nodes carry tier, evidence class and quotable detail prose; escalations carry their why in plain language; and every surface names a public re-run method, because the library never asks to be believed.
Key concepts
- Architecture, not audit — a CLI agent reaching what your account reaches is a fact about CLI programs, not a claim about a vendor
- Four evidence classes — derived, third-party, measured, tested — and the weakest on the path labels the answer
- Benign nodes are mandatory — a tree that only lists frightening capabilities measures its own framing
Key ideas
- Fact-set identity is load-bearing: renaming a fact id breaks every stored assessment and share link, and gets a change-control entry.
- The library is dated as a whole at v2, and that is a recorded defect (MC3) — per-node dates are phase 1.
- A control's effect is never its description — it is a before/after diff against this visitor's case.