STOP REBUILDING YOUR AUDIT HISTORY.
START RETRIEVING IT.
RAIC fingerprints every artifact on arrival, chains every governance action, seals each day, and signs the audit packs you hand over — so the record you produce is the record that happened, and your auditor can check it without taking your word for it.
Most evidence is a story, not a record.
Audit season starts the same way every year. Someone exports a spreadsheet, someone screenshots a dashboard, someone digs through email for the attachment that proves the review actually happened. Three weeks later you hand over a bundle whose only guarantee is that you assembled it in good faith.
That bundle cannot answer the question an examiner really asks: how do I know this wasn't edited? Vague words carry the weight instead — immutable, tamper-proof — and vague words are exactly what a skeptical reader discounts.
RAIC replaces the adjective with a mechanism. Every action is chained, every day is sealed, every file is fingerprinted, and every pack is signed.
Proof you can hand to a stranger.
Nobody edits history
Every governance action writes to a per-organization append-only audit ledger as a chained entry — entry_hash = SHA-256(prev_hash | payload_hash | seq), a running fingerprint where each record locks in the one before it. Any inserted, altered, or removed entry breaks the chain at a detectable sequence number.
Yesterday closes for good
A nightly seal computes each organization's day root — the SHA-256 of that day's entry hashes joined in sequence order, one value that stands for the whole day. Prior days cannot be silently rewritten after the seal lands.
Every file carries its own proof
RAIC fingerprints each evidence file with SHA-256 at upload and stores the digest beside it, so anyone can confirm the file they hold is the file you filed. Artifacts predating fingerprinting are flagged unverifiable rather than presented as verified — never backfilled with a fabricated hash.
Packs your auditor can trust on sight
Audit packs ship with a canonical manifest — a fixed-order inventory of everything inside — whose hash is signed with ECDSA P-256 / SHA-256. The public key half is published in the app, so verification never depends on us.
Examiners verify without an account
An examiner verifies a pack offline, at the public verification page https://app.rhindoncyber.com/verify, or against the raw endpoint https://app.rhindoncyber.com/api/public/verify-evidence for programmatic checks, with no RAIC login and no seat to buy.
One walk from clause to signature
Follow the lineage in a straight line: framework clause, then control, then test and result, then the fingerprinted artifact, then the signed pack it shipped in. No reconstruction, no guesswork about which export came from where.
Someone other than us witnessed the seal
Each nightly day root is submitted to an independent RFC 3161 timestamp authority — DigiCert as primary in the United States, FreeTSA as failover in Germany — and the returned token is stored with the seal. The token binds our root to a time we did not set. An examiner reads which authority issued it and checks the token themselves.
Prove one record without opening the book
Day roots are committed as a Merkle tree as well as a linear hash, so RAIC produces an inclusion proof for a single record: evidence that this artifact was sealed on that day, verifiable against the published root, without disclosing the rest of the day's activity.
Two verifiers, one written without our code
The published verification specification is versioned and frozen per version (text v1.4). A second verifier was written from that page alone — Python, standard library plus one public crypto library, no RAIC source — and it verifies real packs: manifest hash, artifact digests, both day-root modes, inclusion proof, the P-256 signature, and the RFC 3161 token. It runs in CI with networking disabled. Where the exercise found the specification insufficient, the gaps are published in a defect register rather than quietly patched.
Publish your continuity on your own site
A portable continuity badge renders as JSON or SVG on your own site or trust page: sealed-day count, coverage percentage, longest unbroken run, earned continuity milestone, and a certificate hash prefix. It resolves through an opaque Trust Portal slug you control on an unauthenticated cacheable endpoint, and it never publishes gap dates, ledger volumes, record contents, or tenant identifiers. The contract is published at https://app.rhindoncyber.com/support/continuity-badge.
Where the line sits: independent in interpretation, not yet externally attested — we say so on the page rather than in a footnote. Read the full write-up in Independent Verification, including the defect register.
Verify a record yourself.
Paste a hash, read a receipt. Anyone holding a RAIC audit pack, sealed day root, or continuity certificate pastes its SHA-256 hash and gets a readable receipt confirming RAIC issued that record. No account, no login, no contact with Rhindon Cyber.
The receipt gives up nothing about the tenant. It never reveals which organization the record belongs to, what it contains, or how much activity it covers. The response schema enforces that restriction, so the limit holds by design rather than by editorial discretion.
Programmatic examiners keep the raw endpoint. Scripted checks call https://app.rhindoncyber.com/api/public/verify-evidence directly, and offline verification against the published public key works the same as it always has.
Frameworks ask for completeness. Buyers ask for integrity.
Nobody mandates hash chaining. ISO/IEC 42001 clause 7.5, SOC 2, and NIST CSF 2.0 all ask for documented information that is complete, current, and traceable to the control it supports — they do not require a cryptographic ledger, and we will not pretend otherwise.
Integrity is what wins the room. Traceability is far easier to demonstrate when every artifact points back to the action that produced it, and an auditor cannot fault you for evidence you labeled accurately.
Your buyers already ask. Enterprise security reviews and insurers increasingly want to know how you would detect a doctored record. A signed pack answers that in one sentence.
Retrieval, not reconstruction.
- Answer an evidence request by retrieving a record, not rebuilding one
- Give the board mathematical assurance instead of "trust our export"
- Hand an examiner a pack they verify themselves, offline
- Label older evidence honestly instead of overclaiming it
- Show which control, test, and artifact back every clause you cite
- Give every MSP client a defensible record of their own
Works with the agents: Autonomous governance agents watch evidence freshness and queue the refresh before your pack goes stale. See Automation Agents.
Evidence lineage, answered.
What makes RAIC evidence verifiable rather than just stored?
Every governance action lands in a per-organization append-only audit ledger as a chained entry: entry_hash = SHA-256(prev_hash | payload_hash | seq), where payload_hash is a SHA-256 digest over the canonicalized event payload and the first entry links to a fixed genesis hash. Insert, alter, or remove an entry and the chain breaks at a detectable sequence number.
How do you stop someone rewriting last quarter?
Each organization's day closes with a day root — the SHA-256 of that day's entry hashes joined in sequence order — Sealed nightly. Once a day is sealed, prior days cannot be silently rewritten.
Can an auditor check an audit pack without a RAIC account?
Yes. Audit packs ship with a canonical manifest whose hash is signed with ECDSA P-256 / SHA-256, and the public key half is published in the app. An examiner verifies the pack offline, at the public verification page https://app.rhindoncyber.com/verify, or against the raw endpoint https://app.rhindoncyber.com/api/public/verify-evidence, with no RAIC login.
What does the public verification page actually tell someone?
Anyone holding a RAIC audit pack, sealed day root, or continuity certificate pastes its SHA-256 hash at https://app.rhindoncyber.com/verify and gets a readable receipt confirming RAIC issued that record. The receipt never reveals which tenant the record belongs to, what it contains, or how much activity it covers, and the response schema enforces that restriction rather than editorial discretion.
Can we publish our sealed history on our own trust page?
Yes. A portable continuity badge renders as JSON or SVG on your own site or trust page, showing sealed-day count, coverage percentage, longest unbroken run, earned continuity milestone, and a certificate hash prefix. It resolves through an opaque Trust Portal slug you control on an unauthenticated cacheable endpoint, and it never publishes gap dates, ledger volumes, record contents, or tenant identifiers. The contract is published at https://app.rhindoncyber.com/support/continuity-badge.
What happens to evidence collected before fingerprinting existed?
RAIC flags it unverifiable rather than presenting it as verified — never backfilled with a fabricated hash. An auditor cannot fault you for evidence you labeled accurately.
What does a lineage walk actually show?
One continuous path: framework clause to control, control to test and result, result to the fingerprinted artifact that proves it, and artifact to the signed audit pack it shipped in.
Who else besides Rhindon confirms a day was sealed when you say it was?
An independent RFC 3161 timestamp authority does. Each nightly day root is submitted for timestamping — DigiCert as primary in the United States, FreeTSA as failover in Germany — and the returned token is stored with the seal. The token binds our root to a time we did not set, and the pack records which authority issued it so an examiner can check the token against that authority directly.
Can you prove a single artifact was sealed without exposing the rest of the day?
Yes. Day roots are committed as a Merkle tree as well as a linear hash, so RAIC produces an inclusion proof for one record: evidence that this artifact was sealed on that day, checkable against the published root, without disclosing the rest of the day's activity.
What stops your verifier from agreeing with your platform because you wrote both?
A second verifier written from the published specification alone — Python, standard library plus one public cryptography library, no RAIC source — verifies real packs in CI with networking disabled: manifest hash, artifact digests, both day-root modes, the inclusion proof, the P-256 signature, and the RFC 3161 token. Where the exercise found the specification insufficient, the gaps are published in a defect register. This is independence in interpretation, not external attestation, and we state that plainly.
From the Resources library
Take the mechanism to your audit committee with the buyer's guide.
MAKE YOUR EVIDENCE VERIFIABLE
Spin up RAIC in your tenant and see Shadow AI in your environment within a day.
Self-service online demo — explore RAIC's modules and workflows on your own time, no scheduling required.
MSP, reseller, and audit-partner programs. Email the partner desk.