Ready for recipient verification
Voidproof is a verifiable absence proof service
Proof packages for what did not happen.
We issue portable Proof Packages for scoped security, cloud, access, and release claims a recipient can verify without a Voidproof account or issuer explanation.
Explaining non-occurrence with screenshots, exports, and private assurances.
Make the answer portable, bounded, signed, and independently checkable.
No confidence scores, issuer overrides, soft versions, or account-gated verification.
Operating model
The page is the product path, not a brochure.
Voidproof is organized around the state changes that make an absence claim receivable: define the claim, lock the boundary, assemble the package, publish the receipt state, and let the recipient verify.
Request the claim they actually need to rely on.
The buyer does not submit a vague security story. They submit the specific absence question a recipient is asking them to prove.
Did a declared administrative mutation occur inside the proof window?
External reviewer
Bounded to scope, evidence basis, and register state.
- Scope
- AWS IAM policy, role, group, user, and access-path mutation events. Locked
- Window
- June 1, 2026 through June 24, 2026. Locked
- Evidence basis
- CloudTrail management events, S3 log delivery, and digest validation. Validated
- Excluded
- Whole-cloud security, authorized action quality, and unmediated surfaces. Declared
If any row is missing or changed after review, the package cannot be issued as accepted.
Lock the claim boundary before the result exists.
Scope, time window, evidence basis, and explicit exclusions prevent the package from becoming a negotiable marketing claim after the fact.
Issue the Proof Package as the product.
The package is what the buyer receives and what the recipient verifies. The platform is infrastructure. The package carries the commercial and adversarial value.
Let the recipient accept, reject, or refuse reliance.
A failed package cannot be saved by a private explanation. That refusal is what makes the accepted package worth sending.
Recipient verification
Verification is a public sequence.
The recipient reads the boundary, checks the files, runs the verifier, and respects the returned outcome. No sales conversation upgrades a failed package.
Manifest, proof JSON, receipt, checksums, coverage limits, and current registers.
Accepted Bounded reliance allowed.
Inconclusive Evidence cannot carry the claim.
Rejected Package fails verification.
Revoked Prior acceptance no longer stands.
Malformed Package is not receivable.
Returned receipt
Result: Accepted
Reliance allowed only inside the declared boundary. The package does not prove surfaces it excludes.
Run public verifierProof families
IAM is the first family, not the whole product.
Voidproof expands only where durable evidence can carry a bounded non-occurrence claim. The product is the proof package. Each family defines what evidence can prove, what it cannot prove, and what a recipient can verify.
AWS IAM mutation absence
Declared identity-policy, role, group, user, and access-path mutation did not occur inside the stated window, subject to coverage and limits.
Cloud control-plane changes
Administrative changes where event records and integrity checks can carry absence.
Release and package events
Publish, signing, replacement, or release actions with durable records.
Access grants and revocations
Privilege state changes where registers and evidence can support a boundary.
Public state
The package is checked against current registers.
The verification surface keeps receipt, revocation, and defect state outside private support channels. The recipient can verify current state before relying on the package.
Evidence setup
Issuance starts with what the evidence can support.
For the first proof family, customers prepare read-only evidence access, management event logs, S3 delivery, log file validation, and digest files for the proof window.
Download setup packet- Declare scope and windowClaim boundary opens the package.
- Create evidence roleRead-only inputs, not dashboard trust.
- Enable log deliveryManagement events land in durable storage.
- Validate digest filesIntegrity checks decide receivability.
- Issue or refuseThe package only exists when evidence can carry it.
Use cases
Use it when someone else has to accept the boundary.
Replace screenshot evidence with a package the reviewer can run.
Give the auditor a receivable boundary, not a private dashboard tour.
Separate what evidence proves from what remains outside the claim.
Evidence context
The surrounding world is logs, signatures, registers, and verification.
Reliance boundary
Voidproof is valuable because it refuses weak claims.
- It does not prove the whole cloud was secure.
- It does not prove authorized actions were wise or harmless.
- It does not cover excluded or unmediated surfaces.
- It does not use confidence scores or issuer overrides.
- It does not let a private explanation upgrade a failed package.
Pricing
Verification is free. Proof-package issuance is paid.
Customers pay Voidproof to intake a declared absence claim, check whether the evidence can carry it, issue the proof package, sign the receipt, register the result, and deliver a package the recipient can verify without a Voidproof account.
Single-scope proof-package issuance
For a focused absence claim tied to a defined review, audit response, or incident boundary.
- One supported proof family to start
- Declared scope, window, coverage, and limits
- Issued proof package with receipt and checksums
- Free public verifier for recipients
Managed proof-package workflow
For teams that expect recurring proof requests and need a steadier operating path.
- Multiple proof-package requests
- Claim intake and boundary review
- Register currentness checks
- Recipient-ready package delivery language
Custom evidence program
For organizations needing procurement support, custom boundaries, and higher-touch onboarding.
- Enterprise intake and onboarding
- Custom proof-family planning
- Security and procurement support
- Reliance-boundary review for stakeholders
Voidproof issues externally usable proof packages only when the evidence supports the declared claim. If evidence is incomplete, ambiguous, stale, revoked, or outside supported coverage, the result is refused or marked inconclusive.
Access
Start with the absence claim your recipient will actually verify.
Define the recipient, the claim, the proof family, the evidence basis, and the reliance boundary before asking Voidproof to issue a package.
Choose a plan