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.
AppSec → access & data · Counsel → legal · Procurement → continuity · Everyone → disclosure
Two access models.
How much access we need depends on the code. There are two 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.
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. 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, marketing and product analytics vendors receive traffic and usage signals only — never your engagement source code: PostHog (EU cloud) on this site and the optional hosted portal, and Google Analytics on this site. Portal data sent to PostHog is redacted as described below. Skip the portal and those vendors still see only marketing-site traffic from visitors who load reqproof.com. If this list ever changes, this page changes first, and standing clients hear it from us before they read it here.
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.
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.
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.
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
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 § 2 (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.
The key-person question, answered head-on.
Every finding is signed by name, and a named reviewer 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.
Cancellation ends the ongoing expertise; the asset stays.
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 findings ledger shows the policy in practice: where we have not asked for approval, entries appear anonymized. See the ledger →
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. The fuller disclosure lives on the methodology page.
What the scoping form collects, and why.
The form is deliberately short. One required field, one optional note. Anything more we need, we ask in the first reply.
- Work email, required: so we can reply.
- Optional note: free text. A placeholder suggests what helps (component, trigger, public vs private code, timing) if you already know it. You can leave it blank.
This site uses PostHog (EU region, same project as the hosted portal) and Google Analytics (measurement ID G-ELLL5G7YW0) for basic web analytics: page views, page leaves, limited interaction capture, and session replay on this public site (form inputs masked). They may set analytics cookies / local storage so return visits can be counted. The form fields above are submitted to us over the site form; they are not sent to analytics vendors as free-text form dumps. The hosted portal uses the same PostHog project for product analytics, with client data redacted from what it collects; the portal is optional, and engagements that skip it get the same views as generated static reports instead.
That is the whole page.
If your review clears, the engagement itself is described in one place: the Continuous Correctness Audit →
Methodology · Findings · About · Instruments · After the Audit