Security pages often become misleading not because they lie outright, but because they blur very different kinds of review into one reassuring word: audit. A whitepaper edit pass is not the same as a code audit. A docs build verification run is not the same as a wallet threat review. A future external assessment of one subsystem does not automatically cover every external service that might later be built around the protocol.
This page exists to make those distinctions explicit. The right question is not “Was there an audit?” The right question is “Which surface was reviewed, by whom, against what evidence, with what residual risk left open?”
What Counts As Meaningful Review Evidence
Use this table when reading future review claims:
| Evidence type | What it can support honestly | What it cannot support by itself |
|---|---|---|
| Whitepaper review or architecture review | Conceptual coherence, terminology, boundary discipline, and threat framing | A claim that every implementation lane is already secure |
| Repo-local verification run | That the current docs and site build, lint, and search checks passed | A claim of full runtime or service security |
| Focused code or design review | A narrower statement about one component or one class of risk | A blanket “everything is audited” conclusion |
| Incident report or postmortem | What happened, what was learned, and what changed | Proof that the same class of issue cannot recur |
| External audit report | Bounded third-party evidence for the audited scope | Coverage of unaudited overlays, future upgrades, or unrelated operator surfaces |
The whitepapers themselves encourage this narrower interpretation. Strong privacy language requires narrower evidence, not broader adjectives.
What The Current Repository Can Show
This repo can already show some review evidence, but it should be described correctly:
| Current evidence in this repo | Safe interpretation |
|---|---|
npm run verify and its underlying scripts |
The docs product and site workflow were validated against the current repo checks |
Review logs under .planning/phases/001-Docs/ |
Large documentation rewrites were iteratively reviewed and corrected |
| The security and support pages you are reading now | Public claim surfaces can be inspected directly for drift or overstatement |
content/whitepapers/ corpus |
The intended architecture and threat-language baseline are published and reviewable |
None of those items is a substitute for a future subsystem-specific external audit. They are still valuable because they let readers separate what is locally verifiable now from what remains target or pending work.
How Future Audit Entries Should Be Read
When a future audit or review is referenced, readers should expect at least:
- the date;
- the exact scope;
- the reviewer identity or organization;
- the evidence set used;
- whether the finding is architectural, implementation, operational, or documentation-level;
- any unresolved residual risk.
Without those fields, “audited” is too vague to be useful. A good review page should make it easier to ask hard follow-up questions, not harder.
Why Residual Risk Must Stay Visible
The legal and privacy corpus repeatedly warns against absolute language. Review evidence follows the same rule. A real audit can increase confidence, tighten boundaries, and expose important defects. It does not magically erase endpoint compromise, external-issuer risk, future upgrade risk, or user mistakes. Readers should become more precise after reading review evidence, not more complacent.
That is especially important for privacy systems. A component can be secure in its own lane while still depending on narrower user behavior, operator posture, or service-layer disclosure rules.
What This Page Intentionally Refuses To Do
This page does not give out security badges, quality scores, or implied endorsements. It also does not backfill missing evidence by restating the same claim more loudly. If the current repo or published corpus cannot prove a statement, the correct action is to narrow the statement or mark the gap, not to decorate it.
That discipline is more valuable than cosmetic confidence because it keeps later audit work interpretable instead of theatrical.
Audit Evidence Table
| Evidence item | Required fields | Review question |
|---|---|---|
| Architecture review | Date, scope, reviewer, source corpus, unresolved questions | Did the review check authority boundaries or only readability? |
| Code review | Commit range, files, tests, threat class, residual risk | Which code path was reviewed and which paths were out of scope? |
| Privacy review | Adversary model, metric, workload, telemetry boundary | Did it measure a privacy property or only assert one? |
| Supply-chain review | Dependency, asset, lockfile, provenance, build result | Does the change add hidden trust or only update known inputs? |
| Incident postmortem | Timeline, affected layer, evidence, fix, follow-up | What changed after the incident and what remains open? |
| External audit | Auditor, version, artifact hash or report link, exclusions | Does the report cover the page’s claim? |
The table is intentionally demanding because audit language is easy to launder. A page that says “reviewed” without scope, date, evidence, and residual risk gives readers confidence without giving them a way to verify anything.
Missing Evidence Is Still Evidence
Missing audit evidence should be visible. If a wallet path has no external review, say so. If a privacy metric is defined but not measured under real network conditions, say so. If the docs pass npm run verify, do not transform that into a runtime audit. If an external service is outside this repository, do not imply that a site review covered it. Honest gaps are safer than silent assumptions because they tell readers where caution still belongs.
Current Review Status Language
Use “reviewed” only with a scope. “Docs reviewed for claim hygiene” is different from “wallet cryptography audited” and different again from “external service penetration tested.” This repository can honestly cite planning review logs, doublecheck reports, npm run verify, and scoped content checks. It should not convert those artifacts into a protocol-wide security audit.
Future audit entries should be appended with dates, links, affected versions, exclusions, and follow-up status. If an issue remains open, the audit page should say so. If a fix lands later, the page should say which command, test, or review evidence supports the fix. This keeps the audit surface useful instead of becoming a badge wall.
Review Notes
Audit pages should make confidence more precise, not broader. When a review exists, record the exact artifact, version, and remaining gap. When a review does not exist, say so without apology. A missing audit is not a scandal by itself; hiding the missing audit behind vague wording is the problem.
The page should also separate review evidence from marketing evidence. A public testimonial, roadmap statement, or partner conversation is not an audit. A passing build is not an audit. A planning review is not an implementation audit. Each can be useful, but only when described by its real scope.
Final Boundary
The audit page should never become a confidence shortcut. Its job is to help readers ask better questions about scope, artifact, reviewer, date, exclusions, and residual risk before trusting a strong claim in public.
Read Next
Read Verification Orchestrator for evidence layers, Privacy Metrics for measurement claims, and Incident Response when a review item becomes an active event.
Evidence and Further Reading
- Privacy Threat Model And Metrics section 10 and sections 3, 4, 5, and 9 explain why privacy and security claims must remain scoped to concrete adversaries, measurements, disclosure surfaces, and telemetry boundaries.
- Main Whitepaper sections 9, 10, 12, Appendix B, Appendix C, and Appendix D distinguish live boundaries from operator, cryptographic, benchmark, or disclosure work that remains less mature.
- Legal Architecture Whitepaper section 17 and sections 4, Appendix A, and Appendix B provide the safe-claim matrix and warn against statements that imply universal control, endorsement, or stronger maturity than the evidence supports.
README.md,package.json, andscripts/verify.shdefine the current repo-local verification surface that can be cited honestly today..planning/phases/001-Docs/001-review-log.mdis current repo evidence that large docs changes are reviewed iteratively rather than published after one unchecked pass..planning/phases/001-Docs/001-doublecheck-report.mdis current repo evidence for prior workspace-first verification of documentation claims.