Things engineering teams ask on the first call.

Each counterparty — human or agent — mints a scoped Ed25519 identity at the start of the relationship. The private key is held by the client; Provably never sees it. Authentication is a signed challenge that ties the request to the same identity every other participant can re-verify, so a verifier only needs the public key plus the signature to trust the counterparty. There is no shared password, no federated SSO, and no session cookie to leak.

An attestation is a compact, signed JSON document: counterparty (identity public key + scope), payload (the SHA-256 hash of the bytes being attested), and moment (a unix timestamp plus the quorum that produced it). It is small enough to put in a request header and big enough for an auditor to reconstruct who decided what, and when — without trusting the issuing service.

Provably produces the signed receipt that an x402 settlement depends on. The payer signs the intent and payment at the start; Provably returns an attestation tying counterparty, hash-locked payload, and moment; the ledger settles against that attestation as the authoritative proof. The facilitator never holds funds in our system — it just routes the receipt to the verification layer both sides already have.

Provably is a verification layer, not a custodian — we do not move money. What we guarantee is non-repudiation: the attestation is cryptographically re-verifiable, the timestamp is anchored to a quorum you select, and the signed payload is hash-locked so neither side can later deny the terms. Final settlement is performed by the rail your integration already uses (bank, ledger, blockchain); Provably turns it into a counterparty-attested event both sides can defend in audit.

Attestations are generated against the hash of a payload, not the payload itself. The body of your transaction — PII, PHI, trade secrets, model weights — stays inside the perimeter you already maintain; Provably sees only what you choose to publish. Per-counterparty scopes and per-request nonces prevent cross-attestation correlation, and the verifier never logs the inputs that produced a hash.

Provably is engineered around the verification obligations those regimes converge on: who decided, against what payload, at what moment. Audit trail obligations under GDPR Article 30, human-oversight and post-market monitoring obligations under EU AI Act Articles 9 / 14 / 72, the Govern + Map + Measure + Manage loop of NIST AI RMF 1.0, and the Plan–Do–Check–Act structure of ISO/IEC 42001:2023 all read cleanly off a Provably receipt. The receipt itself is portable — it is not a lock-in to our stack.

Send a signed request at the start of a transaction, verify the returned attestation at the end. Most teams integrate end-to-end in a single afternoon; deeper flows (delegated agent identity, multi-party settlements) take a few days. Counterparties do not have to be on Provably on day one — they can verify your attestation through a hosted verifier the same way you verify theirs.

Agents sign attestations under a delegated identity that you mint on their behalf. The delegation is revocable, scope-bounded, and auditable, so an agent can transact on your behalf without ever gaining your full identity. If a delegation is compromised or a model is retired, you revoke it once — every attestation the agent produced remains valid against the public key, but no new attestations can issue until a fresh delegation is minted.