Standards
FES-1.0 and Program lanes.
AttestLayer publishes an evidence packet specification (FES-1.0-preview) and a set of evidence profiles called Program lanes. Specifications standardize the packet, not the underlying compliance outcome.
FES-1.0 and Program lanes describe packet structure and verification expectations. They do not certify compliance, security, resilience, or legal sufficiency.
FES-1.0-preview
Packet structure
Binder PDF, manifest JSON, signed receipt, artifact hashes, JWKS reference, offline verification.
Receipt rules
Canonical hashing and Ed25519 signature with a publishable key ID.
Verification rules
Fail-closed. Missing files, malformed receipts, mismatched hashes, or missing keys must return FAIL.
Public reference
OpenAPI snapshot and verifier sample kit are available on the API surface.
Program lanes
Program lanes are evidence profiles. They describe what a packet looks like for a given workflow. They are not certifications.
AGENT-01
AI agent authority and action evidence.
PAY-01
High-value payment or funds-movement evidence.
ID-01
Authority and identity evidence.
HUMAN-01
Human approval and change evidence.
VENDOR
Vendor diligence evidence.
DORA / VENDOR
Operational resilience and third-party evidence profiles where applicable; not legal DORA certification.
What standards do not do
- do not certify a customer is compliant or secure
- do not replace audits, regulators, lawyers, or insurers
- do not guarantee that any reviewer, buyer, or counterparty will accept a given packet
- do not opine on the truthfulness of submitted records
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.