A modular registry, or one tool per function: what changes for an audit

The risk isn't the software, it's the handoff between two

A well-validated cytometry tool stays well-validated. The risk appears the moment its results leave that tool: a CSV export, a copy-paste, a file renamed "final_v3". That handoff is tracked by neither the tool that produced it nor the one that receives it.

The more tools in the chain, the more handoffs. And it is at each handoff, not inside each tool, that the trail stops.

One module, one registry

Here is what we claim: Biotraxion's modules (analyses, cytometry, protocols, structure, sequences…) share the same registry and the same audit trail as the run they come from. A cytometry result linked to a run goes to the analysis workbook or to that run's results without an export or a copy-paste.

Concretely, this closes one handoff, not every handoff. Between two runs, between two teams, between the registry and a third-party tool you keep (an existing ELN, a quality system), the handoff still exists and must be tracked some other way.

What this doesn't prove

One registry for several functions doesn't prove each function is individually validated for your use. Cytometry, statistical analysis, protocol management: each still needs qualifying for what you expect of it, whether it comes from a module or a separate piece of software.

It doesn't prove your current tools are poorly run either. A lab that carefully documents every export can have a trail just as solid as a single registry used carelessly. Structure helps; it does not replace discipline.

What a single registry does not settle

It forces nothing to migrate. A legacy tool that is already validated has no reason to change because a new module exists elsewhere.

It does not fix the quality of data entry. A value misread at the bench stays misread, whether it lands in a module or a spreadsheet.

It does not decide what your quality framework requires to validate each software function. That stays your responsibility, module or not.

The audit trail across modules

The audit log is append-only, timestamped and chained with SHA-256: any alteration shows, whatever module the entry came from.

The limit: a hash chain reveals an alteration; it does not prevent a value from being entered wrong in one module rather than another to begin with. Whether a module can write into another module's log, or only its own, is a question worth asking.

Five questions to ask any tool

1. When a result moves between functions (from cytometry to the analysis workbook, say), does it also move to a different audit registry?
2. How many manual exports separate the raw measurement from the final report, and which of them are tracked?
3. Does a module added later genuinely share the same registry, or run its own system alongside it?
4. If a specialized tool remains preferable for one function, does the central registry know that, or does the trail break at the boundary?
5. For a single run, can you reconstruct the full path from measurement to signed report?

For the last one, our answer is the Audit Pack: approved protocol, signatures, deviations and results from every module a study used, exported in one click into a sealed deliverable. Does your Audit Pack reconstruct that path without stitching exports back together? Worth asking any vendor, us included.

See where your own exports go

We'll walk through how many tools currently separate a measurement from your final report, and what a shared registry would or would not close: contact@biotraxion.com, or request a pilot from the home page. Product changes are dated in the release notes.

Keep reading

• Signing every step: what an inspector can check
• Bench execution record vs ELN: what changes at inspection
• The Audit Pack: what a sponsor can verify on their own
• Keeping several sponsors' studies apart
• ALCOA+ from the bench: what each letter asks of you
• Declare a deviation at the moment it happens