CRI touches revenue decisions, so it's held to the same bar as the accounting systems it feeds. Here's what that actually means, not just what it sounds like.
Your data is isolated at the database layer, not just by rules written into the application. Every query CRI runs is scoped to your organization by the database itself — the boundary is enforced by the system storing the data, not only by the code asking for it.
Why that distinction matters: application-level isolation depends on every code path remembering to check the right permission, every time, forever. One missed check in one endpoint is enough to let a query return rows that belong to a different customer. Database-enforced isolation makes that class of bug structurally impossible — the database refuses to return rows outside your boundary regardless of what the application code does or doesn't check. It's the difference between a rule people have to remember to follow and a rule the system can't break.
Every detection, every approval decision, and every billing action writes an entry to a permanent ledger — who did it, what it was, and when. Entries are append-only: nothing rewrites or deletes a past record, including CRI itself.
For an audit, that means the full lifecycle of any dollar CRI touched can be reconstructed from the ledger alone — from the original field record, through the approval that signed off on it, to the moment it was billed and collected — without relying on anyone's memory or a system that could have been quietly edited after the fact.
CRI detects and recommends. It never bills, approves, or moves money on its own — at any tier, with no automation-only mode.
In practice: a detected item sits in a queue with the documentation behind it until a Project Accountant or Controller reviews it and chooses Approve, Reject, or Request more info. Only an explicit approval moves an item toward billing, and that decision — who made it, when — is what gets written to the ledger next to the original detection.
CRI is pre-launch, with no paying customers yet. We'd rather tell you that directly than let a polished page imply otherwise.
Already in place: database-enforced tenant isolation and the immutable audit ledger described above are built and running today, not roadmap items. Every approval workflow requires a human decision — there's no autonomous mode to disable.
Still being built: we do not have a SOC 2 report or any third-party security certification yet, and we won't claim one until it's real. Formal security policies, incident response processes, and a completed third-party audit are in progress as we take on early design partners. If a certification matters for your evaluation, ask us where we are on it — we'll give you a straight answer.