Trust / Audit and retention
One door, and it writes down who came through
Every status change in the platform passes through a single controlled path that validates the move, records who made it and why, and writes an audit row. There is no second path.
Most systems have a well-behaved main path and three scripts that set a status field directly. That is why their history cannot be trusted, and it is the specific thing this design prevents.
Test the audit trailCan a record be changed without the change being recorded?
No, because there is only one way to change one. Status transitions are funnelled through a single function that refuses invalid moves and writes the audit row as part of the same transaction — so a change that happened without a record is not a gap in the log, it is an impossible state.
The transition door
What gets recorded, and what cannot be undone
- 01
Validation before the change
The controlled path checks whether the move is legal from the current state. A claim cannot close while an SIU referral is open; the transition refuses rather than warns.
- 02
Actor, timestamp, entity, action
Every write is audited with all four, and — where the action is a decision rather than a data entry — a reason. “Who reduced this reserve and why” is a query, not an interview.
- 03
Sensitive reads are audited too
Unusual and deliberate: knowing who looked at a customer record is often the question that matters more than who edited one, particularly after a complaint.
- 04
Nothing is destroyed
Claims close with a reason, agencies terminate, contacts merge rather than overwrite, and delinquency history is append-only. Deletion as a concept is largely absent from the platform.
- 05
Retention is configured, not assumed
Retention schedules are set per organization because the statutory answer differs by jurisdiction and line. We ship no default that pretends to know your obligations.
For the auditor in the room
What the log will actually tell you
The value of an audit trail is measured by the questions it answers under pressure, months later, when nobody remembers the week in question.
| Question asked in an audit | Where the answer lives |
|---|---|
| Who granted this person access, and when? | Audit log — every grant and revocation passes the same controlled path |
| Why was this reserve increased? | Reserve change history: old value, new value, actor, reason |
| Who viewed this customer’s record? | Sensitive-read audit on the relevant endpoints |
| Why did this claim close? | Closure reason, recorded at the transition |
| Was this policy canceled properly? | The single policy transition door, plus the two-desk Cancel-for-Cause record |
| What happened to this deleted claim? | Nothing was deleted — there is no delete path to explain |
| Who ran this batch? | A named service principal, which cannot be a person |
What an audit trail is not
A complete log is necessary and insufficient. It records what happened; it does not make what happened correct, and it does not answer every regulatory question by itself.
Not a compliance program
The platform records and retains. Interpreting your obligations under a given state’s regulations remains your counsel’s work, and retention schedules are yours to configure.
Not proof of good handling
A well-documented bad decision is still a bad decision. The log makes the file defensible where the handling was sound — it cannot rescue handling that was not.
Retention defaults are absent on purpose
We ship no retention schedule. That means configuration work during onboarding, and we would rather that cost than a guessed statutory period.