The four documents test
- Update/release record: a real project has dated release notes with versioned content, not a “latest fixes” blob. Frequency matters less than structure: every release should list changes ref-by-name.
- Privacy & support policy written in behavior language: “we don't collect telemetry” should enumerate the SDKs not included. Vague claims hide integrations.
- Threat model or security-basics doc: even two pages of text stating scope, mutable state and restore semantics show the culture — desireable even if you never open it again.
- CVE/incident posture: absence “no incidents” is not a document; an empty-but-extant section with a reporting address demonstrates intent.
Behavioral probes
- Email the security address once with a humdrum question (manifest scope, supported OS versions): response content tells you whether audit culture is real.
- Locate a support forum/issue tracker whose public age spans the product's claimed history.
- Compare version numbers across assets — site says 2.3.1, twitter says 2.4, no note on the difference, walk.
The preview repo carries THREAT-MODEL.md, ADRs, release notes and M-gates in public view — that principle is the standard, not a flex: the same auditability you’ll exercise on us, we exercise on our own pipeline.
ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.