One record, one hash, one leading location

This experience report is anonymized (organization ORG-1, entrepreneur E1). It describes a design insight from operating a small group of companies that are managed together and share the same office and IT infrastructure.

Starting point

ORG-1 runs a group of companies: an asset/infrastructure company and several subsidiaries. One company (the "landlord") lets the others (the "tenants") use offices, workstations, and facilities on a pro-rata basis. Contracts, invoices, and records are created on both sides — landlord and tenant.

On top of that comes a site infrastructure (server, database, file sharing, local AI) acting as a "helper": a document management service and a RAG system are meant to make the same records usable.

The problem: redundancy creates errors

The obvious approach would be to store every record on both sides — or to keep a separate copy in each service. That is exactly what creates problems:

• Divergence: If a record is later replaced or corrected, several versions exist.
• Duplicate scheduling: Dates and deadlines get scheduled multiple times, once per copy.
• RAG hallucination: Retrieval finds the same fact via several object IDs — seemingly different "truths".
• Audit problem: During an audit it is unclear which of the several copies is the "leading" one.

The insight

A record is uniquely identified by its SHA-256 hash. Therefore it needs exactly one leading location — everywhere else there is only a reference (path + hash + object ID).

One record, one hash, one leading location. The record itself exists once; all other locations hold a structured reference container that points to the leading record.

In the subletting case, the record is held by the landlord. The tenant only holds the reference container pointing to the record and its metadata (SHA-256 as the anchor).

Why this works

• No redundancy → no conflicting versions.
• Pairwise coupling: The landlord's and tenant's views are linked through the identical hash and can be edited together (dates, bookings, services).
• Deterministic retrieval: DMS/RAG return the same fact via one object ID.
• Auditable: The leading location is unambiguous; the hash proves integrity.

The Git repo as a land register

Here, "compliance" does not come from an extra tool but from the structure of the Git repository: records and their metadata are versioned, every state is traceable, and a hash makes every file unique. The reference container is itself a versioned Git artifact — the chain of evidence is therefore complete.

Lessons learned: Don't copy, reference. Anyone who keeps the same file multiple times builds redundancy errors into scheduling, search, and audit. Anyone who relies on one hash gets consistency for free — in Git repositories this uniqueness is already built in.

Mirror files: the same hash, arranged as needed

Because the SHA-256 identifies the record "naturally", mirror files can be created at any time for any conceivable purpose: the original records are arranged as the purpose requires and output as ZIP files or file structures — for example for Z3 collections from audit orders. The mirror file is an output, not a second source: the underlying hash stays the same, the arrangement is freely choosable.

The Git repo references (which point to the SHA-256) thereby always reproduce the revision-safe, verifiable state of the original doc — regardless of which mirror file it currently appears in.

Tools and agents on revision-safe data

Any tooling for evaluations, audit reports, audits, etc. can be applied to this revision-safe data — all the way to agents that draw the desired insights and reports from the records. Because reference is always made to the one hash, every output remains traceable and reproducible.

Data protection: This makes it possible to comply with GDPR rules for free data exchange — what is shared is a verifiable hash reference, not an uncontrolled copy.

Transferability

The pattern applies wherever the same evidence is needed by several parties or services: corporate groups, holdings, tax-advisor engagements, supply chains. It is independent of industry and of specific products.