Audit Integrity & Compliance

1. Audit Integrity Approach

Vivaryum is designed around a core principle: record actions, once committed, should not be alterable after the fact. The application provides no mechanism for rewriting history or removing historical entries for any role, including administrators.

For compliance purposes, the distinction between policy-enforced immutability and architecture-enforced immutability matters. A policy can be changed; an administrator with sufficient privileges can override access controls. Vivaryum takes a stronger approach: the application code itself provides no delete or history-rewrite operations. The underlying storage model is designed to make alteration of historical records detectable.

This design addresses a common audit concern: whether a record could have been altered after the fact. With Vivaryum, any such alteration would produce a detectable divergence in the record chain.

From the user's perspective, the system works like any modern record-keeping application. Staff create records, update them, and delete them when appropriate. No technical knowledge of the underlying storage layer is required — the versioning happens automatically in the background.

2. How the Audit Log Works

Vivaryum's audit log is built on content-addressed storage — a model where each record version is identified by a cryptographic hash of its content. This has a fundamental consequence for immutability.

Each action in the system produces a versioned entry that references its predecessor by hash. This creates a cryptographically linked chain: version B references version A's hash; version C references version B's hash; and so on. To alter any historical record, an attacker would need to recompute every subsequent hash in the chain. More practically, even a single recomputed hash would produce a chain that diverges from the known-good state, making the tampering immediately detectable.

Timestamps are embedded in the versioned entries themselves and are part of the hashed content. They cannot be retroactively changed without invalidating the hash. The server-side timestamp is applied at the moment of recording — it is not user-supplied and cannot be manipulated by client software.

Vivaryum exposes no destructive operations whatsoever. There is no rewrite endpoint, no amend facility, no reset capability. These are not features restricted to certain roles — they are simply absent from the application. The API surface of the system has no pathway for rewriting history.

3. Record Lifecycle

Vivaryum treats records as a ledger, not a mutable database. Every action appends a new entry. Nothing is ever overwritten. The following describes each stage of a record's life.

Create

When a user creates a new record — a free-form note, an observation log, or any custom record — the system serialises the record data and stores a versioned entry. That entry has a unique identifier, a timestamp, and an attributed author. It is written to the append-only log.

Update

When a user updates an existing record, the system creates a new version that references the previous one. The new version contains the updated content and a new timestamp. The previous version is not overwritten — it remains accessible in the history. An auditor can retrieve any prior version of any record at any time, and can see precisely what changed between any two versions.

Delete

When a user deletes a record in Vivaryum, what actually occurs is a soft delete: a new entry is appended that marks the record as deleted. The record no longer appears in normal operational views, but it has not been erased. All previous versions remain in the log, intact and retrievable. The deletion itself is also logged — showing who deleted the record and when.

This approach ensures that even records which are no longer operationally relevant cannot disappear from the audit trail. An animal that was euthanised, a study that was terminated, a facility that was decommissioned — all retain their complete record history indefinitely within the system.

4. Chain of Custody

Every entry in the audit log is attributed to a specific, authenticated user. Because git uses UUID-only authorship, attribution is tied to the authenticated session rather than a human-readable email embedded in the commit. This simplifies the model while maintaining a reliable audit trail. The single source of truth (all data in git) eliminates any sync risk between a database and the version store.

For any record in the system, a complete chain of custody is available that answers the following questions precisely:

• Who created the record, and when?
• Who subsequently modified it, and when — for every modification?
• What exactly changed in each modification (field-level diff)?
• Who deleted the record, if it was deleted, and when?

The attribution cannot be transferred or impersonated post-hoc. If a user makes an entry, that attribution is preserved. There is no "edit as" functionality, no backdating capability, and no way to change the authorship of a historical entry.

For institutions that need to export chain-of-custody documentation — for IACUC reviews, accreditation audits, or regulatory inspections — Vivaryum provides structured audit exports that present the complete history of any record or set of records in human-readable form.

5. Access Control

Vivaryum implements role-based access control (RBAC) with five default roles, each designed around realistic institutional staffing structures. Custom roles can be defined for institutions with specific requirements.

The Auditor role warrants particular attention. It is designed specifically for compliance use cases: an auditor gains unrestricted read access to the entire record history — including deleted records, previous versions, and field-level diffs — without any ability to modify anything. This enables an institution to provide an external auditor with a named account and full visibility into the record system, without any risk of the audit itself affecting the integrity of the records.

Access control decisions are themselves logged. Role assignments, permission changes, and login events are recorded in the audit trail, providing a complete picture of who had access to what, and when.

6. Compliance Framework Relevance

Vivaryum's design was informed by the specific requirements of regulated research environments. The following addresses how the system maps to widely referenced compliance standards and frameworks.

GxP — ALCOA+ Principles

ALCOA+ is the dominant framework for data integrity in regulated research, particularly in GLP (Good Laboratory Practice) and GCP (Good Clinical Practice) environments. The following describes how Vivaryum's capabilities map to each principle:

IACUC / Animal Welfare Act

The Animal Welfare Act and the associated IACUC framework impose specific requirements on the maintenance of records related to animal use in research. These include requirements for complete records of animal acquisition, housing, medical treatment, surgical procedures, and disposition. Records must be available for inspection by USDA inspectors and institutional officials.

Vivaryum's record structure maps directly to these requirements. Free-form records with custom metadata fields provide the flexibility to capture any type of animal-related documentation. The append-only audit trail means that every record required by the Animal Welfare Act is preserved in its original form, with full history, indefinitely. Deleted records (for animals that have been euthanised or transferred) remain accessible to authorised roles and include their complete history.

The Auditor role enables USDA inspectors or IACUC reviewers to be granted read-only access to relevant records without any operational disruption. Export facilities allow the generation of structured inspection reports on demand.

ISO 9001 — Document Control

ISO 9001 requires that documented information be controlled to ensure it is available and suitable for use, adequately protected, and that changes and current revision status be identified. It further requires that records be retained as evidence of conformity and be legible, identifiable, and retrievable.

Vivaryum addresses these requirements by design. Every record has a current version and a complete revision history. The current revision status is unambiguous — it is the most recent version. Changes are identified at the field level. Records are retained indefinitely with full traceability. The system provides the technical controls relevant to ISO 9001 clause 7.5 without requiring additional document management infrastructure.

GDPR / Privacy Considerations

Vivaryum is a cloud-hosted SaaS platform. Your institution acts as the data controller; Vivaryum acts as the data processor. A Data Processing Agreement (DPA) is available for institutions operating under GDPR or equivalent data protection legislation — contact us to request one.

Record data is encrypted in transit. Vivaryum does not use institutional data for any purpose other than providing the service, and does not share or sell record data to third parties.