An audit is meaningful only when its reviewed surface and residual risk are named. A whitepaper edit pass is not a code audit, a docs build check is not a wallet threat review, and an external review of one subsystem does not cover every future service.
A reader must be able to name the tested scope, method, date, and remaining uncertainty.
Scope must be readable without relying on reassuring labels.
The right question is not “Was there an audit?” It 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 |
| Scoped content reviews and verification summaries | 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.
Review Limits
Review evidence does not create security badges, quality scores, or implied endorsements. Missing evidence cannot be repaired by restating the claim more loudly. If the repository or corpus cannot prove a statement, narrow it or mark the gap.
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 scoped content reviews, source-audit notes, npm run verify, and 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.
Audit Interpretation
Audit records make confidence more precise, not broader. When a review exists, record the exact artifact, version, and remaining gap. When a review does not exist, state that directly. A missing audit is not a scandal; hiding it behind vague wording is the problem.
Review evidence is distinct from marketing evidence. A public testimonial, roadmap statement, or partner conversation is not an audit. A passing build is not an audit. A documentation review is not an implementation audit. Each can be useful only when described by its real scope.
A review record includes when the review ran, the artifact or revision covered, the reviewer, the methods used, and the exclusions that remain. Without those fields, readers cannot distinguish a scoped assessment from a broad security claim or identify its residual risk clearly. Dates and exclusions remain visible beside every cited audit artifact.
Final Boundary
An audit record must never become a confidence shortcut. It must identify scope, artifact, reviewer, date, exclusions, and residual risk before supporting a strong public claim.
Read Next
Read Formal Verification 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 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.