Frequently Asked Questions
Plain-language answers about what attest verifies, what it does not, and where responsibility begins and ends.
Effective date: August 26, 2026
What attest is
What does attest actually do?
attest receives a machine activity Event, applies its verification rules, persists an independently held Verification Record, and returns supported receipt information. It creates evidence outside the originating system’s own recordkeeping boundary.
How is this different from logging?
Logs are operational records created and controlled by the systems producing them. attest adds a separate verification record outside that self-reporting boundary. Logs operate and explain the system; attest provides independent evidence. Both can—and generally should—coexist.
What is a Verification Pass?
One unique verified Production Event is one Verification Pass at $0.001. A duplicate recognized under replay protection creates no additional Pass or charge. Sandbox activity is non-billable.
What does “verified” mean?
attest verifies the record and process it receives according to the Service’s verification rules and independently preserves the resulting attest record. It does not certify objective source truth. The source remains responsible for the underlying claim and submission.
What kinds of machine activity can I send?
Minimal descriptors for AI, API, workflow, tool, financial, legal, operational, or other machine activity can use the same Event primitive when lawful and supported. Classification should use eventType. Domain labels do not change the truth boundary.
Paired boundary verification
What is paired boundary verification?
attest can record an assembly observation before an operation crosses a system boundary and a delivery observation afterward. It reconciles those observations as matched, divergent, incomplete, or orphaned.
Does a missing delivery observation prove the operation did not happen?
No. Missing delivery means only that attest did not accept a delivery observation; it does not prove whether the underlying operation happened. Recovery does not rerun the operation or invent a delivery observation, and preserves executionState: "unknown".
Is paired boundary verification available now?
Yes. It is available in @attestinfra/sdk@0.2.0 through attest.witness() and the recoverable attest.prepareWitness() and attest.resumeWitness() flow. Each newly accepted Production assembly or delivery observation is one Verification Pass; duplicates and recovery inspection are not additional passes.
What attest is not
Does attest verify that an Event is true?
No. It does not establish factual correctness, legality, wisdom, appropriateness, compliance, or that a model or tool behaved as claimed unless attest directly observed the relevant boundary.
Does attest approve or authorize machine actions?
No. attest is a verification/evidence layer, not an authorization system. Customer controls whether an AI agent, API, payment, workflow, or other action may execute.
Does using attest make me compliant?
No. Regulatory, contractual, evidentiary, and audit requirements vary by jurisdiction and use case. attest provides verification and evidence infrastructure; it does not certify compliance or replace legal or compliance judgment.
Is a Verification Receipt automatically legal proof?
No. attest does not provide legal advice or guarantee acceptance by a court, regulator, auditor, or counterparty. The applicable authority determines evidentiary value.
Trust and custody
Where does attest’s responsibility begin?
Before receipt and acceptance, the origin is responsible for the underlying claim and transmission. After attest accepts and persists its record, attest is responsible for preserving the integrity of that record—not for owning or proving the underlying Event.
Who owns the underlying data?
Customer does. attest’s custody relates to the Verification Record; it transfers no ownership in Customer data or intellectual property.
How can a verification record be checked?
Current accepted records use SHA-256 hashing and RSA-SHA256 signatures. Supported receipt fields include hashes and signatures, and current APIs provide verification functions for supported records. Cryptography helps detect modification of a specific signed record; operational and infrastructure controls still matter, and cryptography does not prove objective source truth.
What if my source never submits an Event?
attest cannot verify an Event it never receives. An action can occur without an attest record if the source never successfully submits it.
What happens during downtime?
If submission and acceptance do not complete under the API contract, there may be no record. Customer chooses whether its workflow retries, queues, continues, fails open, or fails closed. attest does not make that authorization decision.
What happens to records if I leave?
A 90-day export window follows termination. Records are then deleted subject to legal requirements or valid legal hold. Certain billing and usage records may remain for up to seven years.
Data and privacy
What data does attest need?
Minimal machine-event descriptors and account, security, usage, and billing data required to deliver the Service. See the Privacy Policy and DPA.
What should I avoid sending?
Do not use attest as general-purpose storage. Generally do not send passwords, API keys, authentication headers, payment-card numbers, financial account credentials, full medical records, legal documents, raw confidential payloads, or unnecessary Personal Data.
Does attest sell data, advertise with it, or train AI on it?
No. attest does not sell Customer/event data, use Customer event metadata for advertising, or train machine-learning models on Customer event metadata.
Where is data stored and who processes it?
Current application hosting and managed PostgreSQL processing are US-based. Confirmed providers are Render, managed PostgreSQL via Render, Stripe for billing, and Resend for transactional email.
How long is data retained?
Verification Records remain during active Service, then for a 90-day export window after termination, and are deleted afterward subject to law or legal hold. Billing and usage records may remain up to seven years.
How do export and deletion rights work?
Authenticated customers have supported search, record retrieval, and CSV activity export. Customers may request other access, account deletion, or deletion through applicable account or support controls. Specific record and account deletion are not represented as current self-service dashboard or API buttons.
Usage and billing
What does it cost?
$0.001 per unique verified Production Event, which equals one Verification Pass. Sandbox is non-billable.
Are duplicates billed?
No. A retry or replay recognized as the same Event identity does not create another billable Verification Pass.
What is the difference between Sandbox and Production?
Sandbox is for non-billable testing. Production generates billable Verification Passes. Use the correct environment-scoped API credential.
Integration
How do I integrate—API or SDK?
Use the current SDK’s attest.verify(...) method or authenticated POST /v1/events. POST /v1/traces also accepts supported trace ingestion. For paired boundary verification the SDK exposes attest.prepareWitness(...) and attest.witness(...) over POST /v1/witness. Use eventType for Event classification. Keep detailed mechanics in Docs.
Do I need to replace logs or build separate domain integrations?
No. Keep logs for operations and debugging. The same Event concept can describe supported machine activity across domains; separate AI, finance, legal, or other SDKs are not required merely because the domain differs.