Artificial intelligence is moving into environments where continuous internet access, centralized logs, or blind trust in a cloud provider cannot be assumed. Healthcare devices, industrial systems, defence applications, financial workflows, and public-sector deployments may need to prove what an AI system did without sending sensitive data to a remote server.
Offline verifiable AI receipts address this problem. They are tamper-evident records—typically containing a model-output commitment, execution metadata, policy results, and a cryptographic signature—that a third party can verify locally. Verification does not require the verifier to contact the model operator or trust an online database at the time of inspection.
This guide explains the architecture, cryptographic building blocks, implementation choices, limitations, and India-specific considerations for building offline verifiable AI receipts.
What Are Offline Verifiable AI Receipts?
An AI receipt is a structured record describing a specific inference or AI-assisted action. Depending on the application, it may include:
- A unique receipt identifier
- The model name, version, and provider
- Input and output hashes rather than raw sensitive content
- Timestamp and execution environment
- Policy checks and safety classifications
- Token usage, latency, and cost information
- A signature from the model service or trusted execution environment
- Optional proof that a particular model or software version was used
The word offline means that a verifier can validate the receipt using locally available public keys, schemas, model manifests, and verification software. The verifier should not need to call an API, query a central log, or ask the issuer whether the receipt is genuine.
The receipt does not necessarily reveal the prompt, response, personal data, or proprietary model weights. Instead, it can prove that specific committed data and execution claims were associated with a signed event.
Why Offline Verification Matters
Online verification creates operational and governance dependencies. If an AI provider's service is unavailable, a compliance review can be blocked. If a central audit database is altered, deleted, or compromised, historical evidence may become difficult to validate. If every verifier must upload sensitive records to a vendor, privacy risk increases.
Offline verification is valuable for several reasons:
Evidence survives connectivity failures
A field device can generate receipts in an aircraft, factory, rural clinic, or remote research site. Auditors can validate them later—or immediately—without network access.
Sensitive data stays local
A receipt can commit to an input or output using a cryptographic digest without disclosing the underlying content. This is useful for medical records, financial documents, biometric data, and confidential enterprise prompts.
Audits become independently repeatable
A regulator, customer, or internal reviewer can run verification tools independently rather than accepting a provider's dashboard as the sole source of truth.
Multi-provider systems become easier to govern
A common receipt format can make events from different model providers comparable. This is increasingly important when an application routes requests between open-source models, commercial APIs, and on-device models.
Core Architecture of a Verifiable AI Receipt
A robust system separates four layers: the event, the evidence, the signature, and the verification package.
1. Event record
The event record describes what happened. A minimal example might contain:
{
"receipt_version": "1.0",
"receipt_id": "urn:uuid:...",
"issued_at": "2026-10-10T09:30:00Z",
"model": {
"provider": "example-provider",
"name": "classifier-in",
"version": "2026.04"
},
"input_sha256": "...",
"output_sha256": "...",
"policy_result": "passed",
"latency_ms": 184,
"usage": {
"input_tokens": 512,
"output_tokens": 96
}
}The exact fields should be governed by a versioned schema. Avoid free-form text for fields that must be audited, such as model version, policy decision, timestamp, or jurisdiction.
2. Evidence commitments
A hash commits the issuer to a particular input or output. If the verifier later receives the original content, it can calculate the hash and compare it with the receipt.
For stronger privacy, systems may use:
- Salted hashes for low-entropy inputs
- Merkle trees for batches of events
- Selective disclosure credentials
- Zero-knowledge proofs for narrowly defined claims
- Encrypted payloads stored separately from public receipts
A hash alone does not prove that the model produced a correct answer. It proves integrity of the committed bytes. That distinction is essential in AI governance.
3. Digital signature
The issuer signs a canonical representation of the receipt. Common choices include Ed25519, ECDSA, or standards-based JSON Web Signature profiles. The signature must cover all security-relevant fields, not merely the receipt ID.
The public key must be distributed through a trustworthy mechanism. Options include a local trust store, a certificate chain, a signed key manifest, hardware provisioning, or an enterprise key-management system. A signature is only useful if the verifier can establish which key is authorised to sign receipts.
4. Verification package
Offline verification requires more than a signed JSON file. A practical package can include:
- The receipt itself
- The issuer's public key or certificate chain
- The schema and canonicalisation rules
- The verification program or a reproducible reference implementation
- Model and policy manifests
- Key status and revocation information current to the audit context
- Optional input/output files for hash recomputation
For long-term audits, preserve the verification environment and document algorithm choices. Cryptographic algorithms and software dependencies can become obsolete.
How Offline Verification Works
A verifier typically follows this sequence:
1. Parse the receipt according to its versioned schema.
2. Canonicalise the signed fields deterministically.
3. Resolve the issuer public key from the local trust store.
4. Verify the digital signature.
5. Check timestamp format, receipt version, and required fields.
6. Recompute hashes for any supplied input or output artifacts.
7. Compare model and policy identifiers with approved local manifests.
8. Check key validity, expiry, and revocation data available offline.
9. Produce a human-readable and machine-readable verification result.
A verification result should distinguish between different outcomes. For example:
- Authentic and complete: signature valid and all referenced evidence available
- Authentic but incomplete: signature valid, but input or output content was not supplied
- Authentic, policy mismatch: receipt is signed but references an unapproved model or policy version
- Invalid signature: receipt cannot be trusted as issued
- Expired trust: signature may be mathematically valid, but the signing key is no longer trusted
This granularity prevents stakeholders from treating every valid signature as proof of compliance.
Cryptographic Design Choices
Hashing
SHA-256 remains widely supported for content commitments. SHA-3 or another approved modern hash may be appropriate where policy requires it. Define encoding, normalisation, compression, and serialization rules before hashing. Hashing a JSON object without canonicalisation can produce different digests for semantically identical documents.
Signatures
Ed25519 offers compact signatures and fast verification, making it suitable for constrained devices. ECDSA may integrate more easily with existing public-key infrastructure. Choose algorithms based on device support, regulatory requirements, hardware acceleration, and expected cryptographic lifetime.
Key rotation
Receipt systems need explicit key-rotation procedures. Include a key ID, issuance time, validity period, and issuer identity. Maintain signed key manifests so an offline verifier can determine whether a key was authorised at the time of signing.
Merkle aggregation
High-volume systems can place receipt hashes in a Merkle tree and sign only the root. This reduces signature overhead while allowing a verifier to validate inclusion through a Merkle path. The system must preserve the tree structure, root timestamp, and inclusion proof.
Trusted execution and attestation
A signature proves that an authorised key signed a receipt; it does not automatically prove where the computation occurred. Hardware-backed keys, secure enclaves, measured boot, and remote or local attestation can strengthen claims about the execution environment. Attestation formats should be linked to a specific platform and threat model rather than treated as universal proof.
What an AI Receipt Can and Cannot Prove
Receipts can provide strong evidence about:
- Which software identity issued a record
- Whether the record changed after signing
- Which model and policy identifiers were declared
- Whether supplied artifacts match committed hashes
- What usage and timing information was recorded
- Whether a policy evaluation was reported as passed or failed
Receipts cannot automatically prove:
- That the model's answer was factually correct
- That the training data was lawful or unbiased
- That the declared model actually ran unless execution is independently attested
- That a policy was well designed
- That a human decision-maker acted appropriately
- That an output was safe merely because a safety field says “passed”
This is why receipts should complement evaluation, monitoring, access control, incident response, and human oversight.
Privacy and Data Protection Considerations in India
Indian deployments must design receipts alongside privacy and sectoral obligations. The Digital Personal Data Protection Act, 2023 and applicable rules create important considerations when receipts relate to identifiable individuals. A receipt architecture should minimise personal data, define retention periods, control access, and document purposes for processing.
For regulated sectors, additional requirements may arise from:
- Reserve Bank of India expectations for outsourcing, technology risk, and auditability
- National Health Authority and health-data governance practices
- CERT-In directions and incident-reporting processes
- Sector-specific requirements for insurance, telecom, education, and public services
- Government procurement, localisation, and security-assessment conditions
Do not place raw prompts, medical notes, Aadhaar-related data, or customer documents into a broadly accessible receipt ledger by default. Use data minimisation, pseudonymous identifiers, encryption, and separate evidence stores. A hash can still be personal data in some contexts if it remains linkable to an individual or source record.
Building an Offline Receipt System
A practical implementation roadmap is:
Define the claim model
List the claims stakeholders actually need to verify. Examples include “model version X generated this output,” “input artifact Y was processed,” or “the policy bundle approved this action.” Avoid collecting fields that have no verification purpose.
Create a versioned schema
Use JSON Schema, Protocol Buffers, CBOR, or another documented format. Specify canonicalisation, time precision, units, enumerations, and error handling. Include a schema version in every receipt.
Establish identity and trust
Determine which entities may issue receipts: a device, gateway, model provider, enterprise application, or hardware module. Define key custody, rotation, compromise response, and offline revocation handling.
Implement deterministic signing
Sign a canonical payload and test it across languages and operating systems. Include negative tests for altered fields, invalid encodings, unknown algorithms, duplicate keys, and timestamp manipulation.
Package verification assets
Ship an offline verifier with trust anchors, schemas, policy manifests, and documented output. Consider a small command-line tool for auditors and a library for integrating verification into enterprise systems.
Test adversarial scenarios
Evaluate replay attacks, receipt duplication, stolen signing keys, rollback to vulnerable model versions, clock tampering, missing evidence, and compromised devices. Add receipt sequence numbers or trusted counters where ordering matters.
Common Implementation Mistakes
- Signing only a receipt ID: Security-relevant fields can be changed without detection.
- Using non-canonical JSON: Different serializers generate different signatures.
- Treating hashes as proof of correctness: Integrity and quality are separate properties.
- Ignoring clock trust: A device-controlled clock may make timestamps unreliable.
- No key lifecycle plan: Expired, rotated, or compromised keys can invalidate audits.
- Overexposing personal data: Receipts should usually contain commitments and references, not raw content.
- No schema evolution strategy: Future verifiers may not understand old records.
- Relying on a central online registry: This defeats the resilience objective of offline verification.
- Failing open: If verification assets are missing, the system should report “unable to verify,” not “verified.”
Use Cases for Offline Verifiable AI Receipts
Healthcare and diagnostics
A medical device can record model version, input commitment, confidence thresholds, and clinician override status without exporting patient data. A hospital auditor can later verify the record locally.
Financial services
Lenders and insurers can retain evidence of model version, policy evaluation, and decision inputs while limiting access to sensitive customer data. Receipts can support dispute resolution and internal model-risk reviews.
Industrial and edge AI
Factories, mines, and logistics networks may have intermittent connectivity. Signed local receipts can document machine-vision alerts, predictive-maintenance actions, and operator acknowledgements.
Government and public services
Offline-capable systems can preserve an audit trail for document classification, eligibility assistance, or language translation. Verification packages can be distributed to authorised reviewers without exposing all citizen data to a third party.
AI agents and automated workflows
An agent can issue receipts for tool calls, approvals, retrieved documents, and policy decisions. This makes it easier to reconstruct an action chain and identify where an automated process exceeded its authority.
FAQ
Are offline verifiable AI receipts the same as blockchain records?
No. A receipt can use ordinary digital signatures and local trust stores without a blockchain. Distributed ledgers may help with timestamping or shared ordering, but they are not required for offline verification.
Can a receipt prove an AI answer is correct?
No. It can prove integrity and provide evidence about execution claims. Correctness requires independent testing, ground-truth evaluation, human review, or domain-specific validation.
Do offline receipts need to contain the prompt and response?
Not usually. Hashes, encrypted references, selective disclosure, or zero-knowledge techniques can reduce exposure while preserving verifiability.
How should Indian startups begin?
Start with a narrow claim model, a versioned schema, hardware-backed or well-managed signing keys, and a simple offline verifier. Pilot the design in one workflow before expanding to regulated or high-impact decisions.
Apply for AI Grants India
Building trustworthy AI infrastructure—including offline verifiable AI receipts—can benefit from focused support, mentorship, and funding. Indian AI founders can apply through AI Grants India to explore opportunities for developing and deploying responsible AI products.