For your reviewers
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.
02 / Access & data
Two access models.
How much access we need depends on the code. There are two models; you pick one at scoping.
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.
The engagement itself runs on our systems; what we hand back, the evidence corpus (requirements, findings, and tests, in plain YAML and code) and the audit gate that re-runs them, runs in your CI without 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 systems where intent lives, typically the issue tracker and the support queue. The audit reads; it does not write.
Access is minimal by construction: source code is all the audit needs. We do not ask for secrets, credentials, or production access; the rare exception is whatever the component itself requires to run, a license key for a build, named at scoping. Engagement data is encrypted in transit and at rest, and access to it is limited to the people named on the engagement.
Data handling
Three subprocessors handle engagement code and model work: Anthropic, OpenAI, and xAI. Client code reaches them only through their commercial APIs, under terms that exclude training on customer data, and each maintains a SOC 2 program with attestations available through its trust portal — the three names above link to those portals. If your policy excludes a given provider, say so at scoping: the engagement runs only on the providers you allow. And we will walk your AppSec team through each provider’s current retention posture at scoping, in writing. There are no other subprocessors in engagement work on your code: no offshore review, no data brokers.
Separately, on analytics: this website and the hosted cloud portal both run PostHog (EU cloud) for product and usage analytics — for you as a visitor that means we can see which pages and views get opened and used, on EU servers, and nothing about your code. In the portal, client data is redacted from what it collects. For teams whose policies do not allow that, a self-hosted installation is available: the portal runs on your own infrastructure. The portal is optional either way, and engagements that skip it get the same views as generated static reports instead. If this list ever changes, this page changes first, and standing clients hear it from us before they read it here.
Commitments
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.
on exit
when an engagement ends, anything we hold is deleted within 30 days of exit, with written confirmation.
on incidents
if we become aware of an incident affecting the confidentiality or integrity of your code or engagement data, we notify your designated contact by email within 72 hours of becoming aware, with what we know, what it touches, and what we are doing about it, followed by updates until it is resolved. This applies to both access models and to the hosted portal.
The training commitment cuts one way only: the public, open-source corpora we author and publish are our own work and may inform our own tooling. Client corpora never are.
03 / Legal
For counsel.
NDA
Yours is fine. We countersign your NDA, same day, and read no private code before it is in force. A signed data-processing agreement is available at scoping.
IP boundary
The boundary: the evidence corpus is yours, in your repo; the engine that produced it is ours.
ip boundary · the corpuswarning
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.
Said without the policy voice: a client’s requirements corpus describes their product in enough detail that publishing it would publish the product, and no permission fixes that. We hold our own corpus to the same rule — the engine’s full requirements tree describes the engine, so it stays private too.
SOC 2
We do not currently hold a SOC 2 report, and we do not present ourselves as a SOC 2–certified vendor.
For private engagements, your code is handled under NDA as described in section 02 (access models and subprocessors). The evidence corpus and audit gate we deliver live in your repository and run in your CI; the hosted portal is optional and not required for the engagement to work.
We complete security questionnaires as part of scoping. If your procurement process requires a current SOC 2 report before work can start, we will tell you plainly on the first call that we cannot clear that bar yet, rather than stretch what we have.
Entity
Proof is operated by Replay Technologies LTD, registered in Armenia at 36 Manushyan, Yerevan 0012. Engagement contracts name this entity. And your paper is fine here too: we typically contract on your template, under your governing law, so your counsel reviews terms they already know.
04 / Continuity
The key-person question, answered head-on.
Machines check everything, every time. One person validates each finding before it reaches you. People sign the bar and the promises that require a person’s judgment, and decide that a miss gets published. The published postmortem carries no personal signature, and we say so where we publish it.
Findings derive their authority from runnable reproducers — and a named signer can only stand behind so much work, so we take a limited number of engagements each quarter. Proof is a young practice; the deliverable is designed so that limited concurrent capacity does not put 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. The gate runs offline if your environment demands it: release artifacts are checksummed and can be mirrored into internal distribution, and tagged releases are immutable.
And if you stop: you keep everything that runs. The gate keeps checking yesterday’s promises; nobody keeps writing tomorrow’s.
Cancellation ends the ongoing expertise; the asset stays.
05 / 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.
When you need a certified penetration test, for SOC 2, PCI, or a customer security review, engage an accredited security firm; our audit does not substitute for that report, and we say so at scoping. The same holds for black-box red-teaming, infrastructure testing, and social engineering. Security promises inside the audited component’s scope are ours to prove; those artifacts are theirs.
The public register shows the policy in practice: where we have not asked for approval, entries appear anonymized, and say so on their face — one live entry reads that the client is not named because we had not asked permission when it shipped, and that it will be updated if permission is granted.
06 / 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. Machines check everything, every time; a person validates every finding before it reaches you. Which systems see your code is governed by the access model in section 02 and the subprocessor list above. The fuller disclosure lives on the methodology page.
07 / Form data
What the demo form collects, and why.
The form is deliberately short. One field is required. Anything more we need, we ask in the first reply.
Work email, required: so we can reply. Everything else on the demo form is optional and only shapes the first reply — your name, your company, the component you would start with, the timing, and whether your code is public or private. You can leave all of it blank.
Every request gets a reply. Scoping is confidential, and private early access is deliberately small: we take on a limited number of engagements at a time.
The fields are submitted to us over the site form and go nowhere else. Site analytics (PostHog, EU cloud) counts page usage; its session replay masks every form field, so what you type here is never in the recording.
08 / Next
That is the whole page.
If your review clears, the engagement itself is described in one place: the Continuous Correctness Audit.