Program · Trust
Trust boundary
AttestLayer is designed to make evidence packets easier to verify, not to replace auditors, insurers, procurement teams, legal counsel, or customer controls.
AttestLayer is not an audit opinion, compliance certification, insurer, bank regulator, payment processor, law firm, or procurement approver. Record-only evidence issuance for review workflows.
Trust proof architecture
AttestLayer’s trust model should be explained as a packet-verification architecture, not as a certification claim.
File integrity
The manifest records SHA-256 hashes for files inside the issued kit.
Receipt signature
The receipt is signed with an issuer key, allowing verification of the issued packet material.
Public trust surface
The registry exposes public verification material such as JWKS, checkpoints, proof material, and related endpoints where registry logging applies.
Review boundary
Verification confirms packet integrity and issuance material. It does not decide whether a buyer, insurer, bank, regulator, or auditor accepts the evidence.
What AttestLayer verifies
- That issued kit files match the manifest.
- That the receipt signature verifies against the relevant issuer key.
- That the packet was issued under stated metadata.
- That the verification path can inspect integrity and issuance material.
- That public registry material can support inspection where registry logging applies.
What AttestLayer does not verify
- Whether the customer is secure.
- Whether the customer is compliant.
- Whether controls operated effectively in production.
- Whether a buyer should approve the vendor.
- Whether an insurer should bind, renew, deny, or price coverage.
- Whether a claim should be paid.
- Whether a regulator, auditor, or court will accept the evidence.
- Whether submitted artifacts were complete beyond the applicable intake/ruleset requirements.
Registry and verification surface
The public registry is a read-only trust surface for public verification material. Reviewers may inspect keys, checkpoints, proof material, and related endpoints. Non-technical reviewers should usually start with the Verify page when they have a kit ZIP.
The registry page currently states that it is a public transparency surface for AttestLayer-issued PASS attestations and that reviewers can inspect public keys, checkpoints, and related proof material.
Current trust status
Current status: AttestLayer’s public registry is live and publicly readable. Checkpoints are currently self-issued by AttestLayer and signed with the registry key. Receipts inside verification kits are signed with a separate issuer key. External witnessing and external anchoring must only be described when active.
This matches the current registry trust boundary and prevents overclaiming. The registry page already states that checkpoints are self-issued, receipts use a separate issuer key, and external witnessing/anchoring should only be described when active.
Enterprise trust checklist
- Legal seller visible
- Operating name visible
- NEQ visible
- Head office visible
- Security contact visible
- Billing contact visible
- Privacy link visible
- Terms link visible
- DPA link visible
- Subprocessors link visible
- Data retention link visible
- Support/SLA link visible
- Product terms visible
- Sample Kit visible
- Registry visible
- Verify page visible
- Trust boundary visible
- No certification claim
- No approval guarantee
- No insurer acceptance claim
- No external anchoring claim unless active
Ready to standardize the packet layer?
Review the verification boundary before using AttestLayer in MSP, insurer, bank, PSP, procurement, portfolio, or enterprise review workflows.