Partner onboarding
From qualification to first packet, in 5 steps.
A short walk-through of how a service-provider partner moves from qualification to issuing the first AttestLayer-backed packet for a client.
Onboarding describes process only. It does not promise that any specific client packet will PASS, or that any reviewer, buyer, regulator, insurer, or PSP will accept a given packet.
The 5 onboarding steps
1. Qualification
Partner contacts AttestLayer with intended tier (Starter / Growth / Portfolio) and a description of the partner workflow. AttestLayer confirms scope, boundaries, and tier fit.
2. Workspace setup
AttestLayer provisions the partner workspace with the agreed tier, credit balance, and contact list. No installs, no scanners, no client-system access required.
3. First client intake
Partner adds the first client packet workspace. Client submits the supplied records through the partner-shared intake. AttestLayer runs structured intake checks and blocker review.
4. Packet issuance
If submitted records are complete enough, the workspace issues the packet (binder, manifest, signed receipt, hash trail). PASS consumes one credit. If the records are not complete, the workspace produces a blocker report and FAIL burns zero credits.
5. Reviewer verification
The partner shares the packet with the reviewer, buyer, or counterparty. Reviewers can verify integrity and issuance through verify.attestlayer.com or the offline verifier.
6. Renewal and continuity
Partners can renew or upgrade tier, add reserved capacity for repeat client cohorts, and bundle continuity offerings around the record-only rail.
Partner support split
Partner owns
- client relationship and advisory work
- client communication and scoping
- deciding which client records to submit
- compliance, legal, business, and security interpretation
AttestLayer owns
- workspace workflow
- record-only ruleset checks
- blocker output
- packet generation
- manifests, receipts, verification paths
- technical support for the packet workflow
The AttestLayer trust model
AttestLayer’s trust model is intentionally narrow. It records what was submitted, what was accepted into scope, what was issued, and how the issued kit can be checked.
The model uses
- SHA-256 artifact hashing
- manifest-based evidence inventory
- canonical receipt hashing
- Ed25519 receipt signatures
- JWKS public-key discovery
- offline verification
- fail-closed verification behavior
What it proves
- files match the manifest
- manifest matches the receipt
- receipt key ID matches a public key
- receipt signature verifies
- the kit has not been modified since issuance
What it does not prove
- company compliance status
- company security status
- controls are operating effectively
- a buyer, auditor, insurer, bank, regulator, or PSP has accepted the packet
- the evidence content is legally sufficient
Integrity and issuance evidence only. Not audit, certification, or compliance guarantee.