Versioning and the Audit Trail: Who Changed What, When, and Why

Two different questions come up once a model has more than one person touching it. First: what changed in the numbers since the last time the board saw this? Second: who changed the workspace’s settings, roles, and invites, and when? Rexfin keeps a separate, purpose-built trail for each, because conflating “the model changed” with “an admin setting changed” produces a log nobody can actually use.

Model versions: snapshot, chain, diff

Every meaningful state of a model gets snapshotted, not just saved over the last version, but captured as an immutable version anchored into a hash chain specific to that deal or engagement. Each new version links back to the one before it using a chained hash, so anyone can verify the sequence independently of Rexfin itself. You don’t have to take the tool’s word that version six really followed from version five; the chain proves it structurally.

The useful part isn’t the snapshot, it’s the diff. Version N compared against version N-1 shows exactly which lines, drivers, or assumptions moved, by how much, and attributed to whom. That diff is what feeds the “what changed since last board” line in the board pack. It isn’t someone’s recollection of what they edited; it’s a computed comparison between two chained, immutable states.

Promotion from a draft model to the published one a board or auditor will see goes through the same discipline: the promotion is diff-reviewed before it happens, the resulting published version is chain-anchored like every other snapshot, and it’s rollbackable if something needs to be walked back. A published model is never a silent overwrite of the draft; it’s a reviewed step with a record attached.

Admin actions: a separate, tenant-level log

Alongside model versioning sits a plainer kind of audit trail: who changed the workspace’s own settings. Preference changes, compliance settings like jurisdiction or fiscal year end, team role changes, and invite creation or revocation all get written to a workspace audit log the moment they happen.

The detail that makes this trustworthy rather than decorative: the audit row is written in the same database transaction as the change itself. If the settings update fails, the audit entry never gets written either: there is no way to end up with a log entry describing a change that didn’t actually take effect, or a change that happened with no record of it. The “before” value in each entry is also read inside that same transaction, so it can’t go stale if two people are editing settings at the same moment.

This log lives on an owner-only activity page, newest changes first, specifically so a workspace owner can answer “who added this person to the team” or “who changed our fiscal year setting” without having to ask around.

Why keep these separate

A model version diff and a settings audit log answer different questions for different audiences. A board member cares whether the driver assumptions changed since last quarter. A workspace owner cares whether someone they didn’t expect got added with edit access. Merging the two into one feed would bury the model-level signal a CFO needs under routine admin noise, and bury admin accountability under model detail nobody outside the finance team wants. Keeping them as two disciplined trails, both immutable and both attributable, means each stays useful for the audience that actually reads it.

Where this fits

Versioning underpins the board pack’s version-diff line and gives the export gate something concrete to check against: a model can’t be exported as final if its own version history doesn’t support that claim. Together with role-based access control, the audit trail is what turns “we think we know who did this” into “here is the record.”

See the full trust chain on the Rexfin product tour.