The only Indian AI ledger that hashes every entry into a re-verifiable chain, seals each closed period with a Merkle root, and anchors the root to the Bitcoin blockchain via OpenTimestamps. Built for the CA who has to defend the books — not just produce them.
Compliance with the Companies Act audit-trail mandate is baked in. No "we'll set it up after onboarding".
Hash chain + activity log together satisfy the "lawful processing + accountability" tests under DPDP §8.
Two-person sign-off + immutable activity history match the SQC-1 firm-level quality standard for engagement records.
Each row below is traceable to a specific module in our codebase. You can ask for a code-walkthrough if you're evaluating us against another vendor — we'll do it on a call.
Each journal line records SHA-256(prev_hash || entry_canonical_json). Edit any historical row and every downstream hash diverges — the chain visibly breaks. Peer reviewers run the same hash function and compare; either the chain is intact or it is not. No grey area.
At period-close (or any explicit "seal" event) every leaf-hash in the period is folded into a Merkle tree. The root is stored on the period-seals table and surfaced in your audit pack. An external auditor with only the root + the sealed period's row-hashes can re-derive the same root in O(n) time and verify nothing was altered after sealing.
Every sealed Merkle root is submitted to OpenTimestamps, which batches roots from across the network and commits them into a Bitcoin block roughly every hour. The .ots receipt is permanent — it proves to anyone that this root existed at this Bitcoin block height, which can't be retroactively forged without rewriting Bitcoin.
High-value vouchers, period closes, and statutory submissions require two distinct user IDs to approve. Each approval is logged with its user, timestamp, and contributing hash. ICAI peer review can trace exactly who signed what, when — no "the partner approved verbally" gaps.
Every AI answer in the product cites the source row, section, or document it derived from. The 6-layer hallucination defence (structural / multi-model / lexical grounding / confidence calibration / semantic grounding / adversarial probe) gates every answer that ends up in your books. No black-box "an LLM said so" decisions ever post to the ledger.
Every insert, update, delete, and view of sensitive data lands in activity_events with the actor user-id, the row affected, the before/after hash, and the IP address. Searchable, exportable, immutable. The audit-trail equivalent of CCTV that never gets erased.
Vendor questionnaires reward conservative answers. Here's what we'd say "not yet" to if you asked — every other vendor we've compared against claims at least one of these as live when it isn't.
On the roadmap (Q1 2027). Currently AES-256 at the disk level only. We could claim FLE today but the hash-chain integrity story is what auditors actually ask about; FLE is hygiene, integrity is the moat.
In progress with a Big-4 auditor. Type 1 expected Q3 2026; Type 2 Q1 2027. We refuse to claim it before the report is signed.
Same as SOC 2 — scoped, in progress, refused until the certificate is signed.
If your peer reviewer or your audit committee wants to inspect the hash-chain implementation before you adopt, book a 30-minute walkthrough. We open the code on screen. No marketing slides — just the modules listed above.