Your audit trail should be verifiable, not just visible

Every requirements tool has a history view. You open an item, click “History,” and see a list of who changed what and when. For most teams, most of the time, that is enough.

It stops being enough the moment someone asks a harder question: how do you know that history is complete and unaltered?

That question comes up in safety audits, in supplier disputes, in incident post-mortems, and in any process governed by ISO 26262, IEC 62304, EN 50128, or DO-178C. The assessor isn’t asking what your requirement says today. They’re asking you to demonstrate the chain of decisions that produced it — and to show that the record of those decisions is trustworthy.

Visible history and verifiable history are not the same thing

In a conventional ALM tool, history is a feature built on top of a database. The application writes an audit row whenever something changes. That works, but it has a structural weakness: the audit log and the data it describes live in the same database, written by the same application, with the same administrative access. Anyone — or any bug, or any migration script — that can write to the database can in principle write to the history too. The record is visible. It is not independently verifiable.

For day-to-day work, nobody cares. For an audit, it’s the whole game. “Trust us, the log is accurate” is exactly the assurance an assessor is trained not to accept.

What “verifiable” actually requires

A verifiable history has two properties that a visible one doesn’t guarantee:

1. Tamper-evidence. If a past record is altered, it should be detectable — not by policy, but by mathematics. You shouldn’t have to trust that nobody edited the log; you should be able to check.

2. Independent reconstruction. You should be able to take the raw records, hand them to a third party, and have them rebuild the same history with ordinary tools — without your application, your database, or your good faith in the loop.

Most tools can’t offer either. Not because their vendors are careless, but because a database-with-an-audit-table simply isn’t the right shape for it.

How ROPARC gets there

ROPARC stores every requirement, document, link, review, and baseline as a commit in a real Git repository. The database you query against is just a fast, disposable index — it can be deleted and rebuilt from the repository at any time without losing a thing.

That one architectural decision is where verifiability comes from, and it’s worth being precise about why:

• Tamper-evidence is built in. Git is content-addressed: every commit’s identifier is a hash of its contents and of the commit before it. Change a requirement’s wording in a past commit and that commit’s hash changes — and so does every hash after it. You cannot quietly rewrite the past; the chain breaks visibly. The audit trail is tamper-evident by construction, not by a setting someone could turn off.

• The history is the data, not a copy of it. There is no separate audit table that could drift out of sync with reality. The history is the storage. A baseline isn’t a snapshot the app generates on request — it’s a named point in a commit graph that already exists.

• Anyone can reconstruct it. Your repositories are standard Git containing plain-text files. An auditor, a customer, or a future you can clone them and walk the entire decision history with off-the-shelf tools. No ROPARC required. That’s also your exit: if you ever leave, you leave with everything, and the history comes with it.

Why this is the right trade for regulated teams

There’s an honest tension here. A database-backed audit log is easy to build and easy to reason about. Git-native storage is more opinionated, and it asks a tool to be designed around it from the start.

For a general project tracker, that opinion isn’t worth the cost. For a team whose work will be assessed — where the question “prove this record is trustworthy” is not hypothetical — it changes the answer from “trust our process” to “here’s the math.” That’s a better place to be standing in front of an auditor.

It’s also a better place to be standing in front of a supplier you’re exchanging requirements with, or a customer reconstructing what was agreed at a milestone two years ago. Verifiable history isn’t only a compliance artifact. It’s how you keep everyone honest, including yourself.

---

ROPARC is currently accepting beta teams in regulated engineering — automotive, medical, industrial, and software-intensive product development. If you want to test verifiable history against your own workflow, request beta access.