Trust, access, and disclosure. One document.

Proof audits whether software does what was promised. This page exists so that AppSec, counsel, and procurement can clear the engagement in a single pass, without a call. It covers access, data handling, legal posture, continuity, disclosure, and how we use AI. It is maintained as one document on purpose, so your reviewers all work from the same source.

AppSec → access & data · Counsel → legal · Procurement → continuity · Everyone → disclosure

Job: one forwardable URL that lets three reviewer personas (AppSec → #security, counsel → #legal, procurement → #continuity) clear a young firm in a single pass, zero vendor hours consumed. The single-document line is a real ruling: reviewers diff trust pages against contracts, and one page cannot contradict itself. ⚠ TRUTH-GATE governs this entire page: it may publish only what is true on ship day; every bracketed placeholder below must be resolved or the section ships with the placeholder visible. An unbacked claim here is worse than an omission.

§ 2 · Access & data

Access models. The strictest one runs in your CI.

How much access we need depends on the code. There are three models; you pick one on the scoping form.

Public / open-source

No access at all. We work from the public repository, and the evidence corpus is public alongside it.

Private code

We countersign your NDA first. Then read-only access, scoped to the component under audit and nothing wider.

In your CI

Nothing leaves your infrastructure. The audit gate and evidence generation run inside your CI, on your runners. Your code never reaches us.

Whichever model applies, the scope is the same: indexing covers the repository and its history, and, only with your approval, read access to the intent systems the engagement names, typically the issue tracker and the support queue. The audit reads; it does not write.

Data handling

[PLACEHOLDER: named subprocessors + the commercial API terms that govern each]
⚠ TRUTH-GATE: enumerate only the subprocessors actually contracted on the day this ships. If the list is empty, say so; if it is unresolved, this block stays.

On training: your code is never used to train anything, ours or anyone else's. On retention: engagement working data exists only for the engagement.

When an engagement ends, anything we hold is deleted within 30 days of exit, with written confirmation.

[PLACEHOLDER: incident and breach notification commitment: window, channel, and which access models it applies to]
⚠ TRUTH-GATE: every AppSec questionnaire asks this; publish only the commitment actually made.

AppSec's section. "Runs in your CI" is promoted into the h2 because it is a young firm's strongest security answer: the strictest tier asks the client to trust us with nothing. The three cards deliberately mirror the frozen access-model options on the lead form (public / NDA / runs in our CI) so reviewer and form speak the same language. ⚠ TRUTH-GATE: the subprocessor block cannot ship as prose until the list and the API terms are verified true.

§ 3 · Legal

For counsel.

NDA

Yours is fine. We countersign your NDA, same day, and read no private code before it is in force.

IP boundary

The boundary: the evidence corpus is yours, in your repo; the engine that produced it is ours.

One warning: a mature corpus describes your component completely enough that its requirements alone could guide a rebuild. It is more sensitive than the code it describes. It therefore lives only in your repo, under your access controls, is never used as our marketing, and we retain none of it after exit. The public corpora in our ledger are open-source projects, where the code was already public; client corpora never appear there.

SOC 2

[PLACEHOLDER: state plainly whatever is true at ship time. Likely: "We are a young practice and do not hold SOC 2. Here is what we do instead," followed by the runs-in-your-CI model in § 2, under which we hold nothing of yours to certify controls around.]
⚠ TRUTH-GATE: no certification named unless held; no "in progress" claim unless an engagement letter with an auditor exists.

Entity and insurance

[PLACEHOLDER: registered entity name, jurisdiction, and insurance coverage held at ship time]
⚠ TRUTH-GATE: publish the entity and policy that exist on ship day, or leave this block visible. Nothing invented.

Counsel's section: the four questions they actually send (NDA, IP, SOC 2, entity/insurance), each answered in one breath. The SOC 2 placeholder must stay plain-spoken when resolved; the honest "we do not hold it, here is what we do instead" answer beats a roadmap promise, and the runs-in-your-CI model is the substantive half of that answer. ⚠ TRUTH-GATE ×2 in this section.

§ 4 · Continuity

The key-person question, answered head-on.

Every finding is signed by name, and one reviewer can only stand behind so much work, so we take a limited number of engagements each quarter. Proof is a young practice, founder-led, with every finding signed by name, and the deliverable is designed so that neither fact puts what you rely on at risk.

The entire corpus lives in your repo as plain YAML and executable tests. The audit gate runs without us, in your CI, on every release. Nothing you depend on day to day is hosted by us or gated on our availability.

Cancellation costs the ongoing expertise, not the asset.

Procurement's real question is key-person risk on a small firm, and dodging it reads worse than conceding it. Strategy: concede the fact in one sentence, then show the deliverable design removes the dependency. All three continuity facts are verbatim from the inventory (capacity line, corpus-in-repo, cancellation line). No headcount invented, no bus-factor euphemisms. This is also the page's single permitted "X, not Y" contrast.

§ 5 · Disclosure

Findings are private by default.

Everything we find in your engagement belongs to you and stays private. We name a client publicly only with written approval.

Security-relevant findings follow coordinated disclosure, case by case, worked out with the affected maintainers or vendor.

The findings ledger shows the policy in practice: where we have not asked for approval, entries appear anonymized. See the ledger →

Disclosure policy doubles as proof of marketing restraint. The ledger is the receipt: anonymized entries show the policy running before anyone asked, which is stronger than any pledge. Coordinated disclosure stays case-by-case on purpose; no fixed SLA windows invented, no CVE-process claims we have not exercised.

§ 6 · AI use

Expert-signed, machine-verified.

Two kinds of machine involvement: deterministic checks, which pass or fail; and AI drafting assistance, whose output must survive those checks. A named reviewer signs every finding before it reaches you. Which systems see your code is governed by the access model in § 2 and the subprocessor list above; under the in-your-CI model, none of ours do. The fuller disclosure lives on the methodology page.

AI posture in exactly two sentences, disclosed rather than confessed. House line is "expert-signed, machine-verified". Never write "we don't use AI"; the credibility comes from naming what the machine does (deterministic checks, drafting) and what a human signs (every finding). Reviewers who care will forward exactly this paragraph.

§ 7 · Form data

What the scoping form collects, and why.

The form asks for one required thing, your email. Six optional fields add context so our first reply can be a scoping answer instead of a question. Each has one job.

Work email: so we can reply.
Company: so we know who is asking before we answer.
Which component matters most: the seed of scoping; the engagement is one component, chosen with you.
What triggered this: a release, an incident, a compliance ask; it shapes how we scope.
Budget posture: so neither side spends a call discovering there is nothing to scope.
Access model: which of the three models in § 2 applies, and whether an NDA should be ready before the first call.
Anything else: free text, optional.

[PLACEHOLDER: analytics / tracking posture as actually deployed at ship time]
⚠ TRUTH-GATE: no "no tracking" or "no analytics" claim unless verifiably true on ship day. State only what is deployed.

Transparency for the privacy-minded reviewer: the seven frozen field names itemized with purpose, nothing more claimed. ⚠ TRUTH-GATE: the analytics block must describe what is actually deployed. Related honesty trap from index § 9's note: the deployed subscribe function currently persists only email + source, so any "we store all seven fields" statement is false until the richer function ships. Do not resolve this placeholder from memory; check the deploy.

§ 8 · Next

That is the whole page.

If your review clears, the engagement itself is described in one place: the Continuous Correctness Audit →

No form here on purpose: this page's reader is a reviewer, and the conversion event is a "cleared" reply inside the buyer's own thread. A form would misread the audience and undercut the form-data section above. Single exit link keeps the approval chain pointed back at the offer page, where the champion and the form already are.