What Is a "Record" (And Why It's Not a File)

In Archivos Atlas, a Record isn't a file with a name — it's an entity with identity, versions, and a retention policy. Here's what that actually changes.

Published on 2026-08-17

Editorial illustration of a document turning into a structured record with a version history

When someone says "just save it to the file," they usually mean dropping a PDF into a folder. But a saved file and a managed record aren't the same thing, even though they look identical at first glance. The difference isn't cosmetic — it determines whether your company can answer, six months later, who uploaded which version of a contract, why, and whether that version is still the valid one.

The problem with thinking in "files"

A shared folder (Google Drive, SharePoint, a network drive) organizes bytes: a PDF named contract_v2_final(1).pdf sits next to another file with the same name in a different folder, and nothing in the system tells you which one is current, who uploaded it last, or whether someone edited it after it was signed.

The physical file — the PDF, the scanned image, the byte — is an implementation detail. It can live in the cloud, on a local disk, or in a box in storage; that doesn't change what the company actually needs to know about that document: who produced it, which retention policy it falls under, and what has happened to it since it came into existence.

What a Record actually is

A Record is an entity with its own identity: it has a type (invoice, contract, blueprint, case file), belongs to an organization, and that identity doesn't change even though the document itself does. What evolves are versions: every new upload tied to that Record is recorded as an additional version, never as a silent replacement of the previous one.

That means "the previous version of the contract" doesn't disappear when you upload a new one — it stays in the history, with who uploaded it and when, available for audit. The physical file itself is just one attribute of a version, not the whole record.

The difference in practice

With a shared folder, answering "who changed this contract last week?" means digging through unreliable file metadata (which changes just by someone opening the document) or asking around and hoping someone remembers. With a Record, that question has a direct answer: the audit tab shows every access and every change, with user and date.

With a shared folder, deleting a file by mistake is usually irreversible unless someone happens to have a backup handy. A Record never allows physical deletion during its active lifecycle — it gets archived, and if applicable, anonymized under a retention policy — so "I deleted it by accident" stops being a dead end.

Why this matters more than it seems

No company thinks about this until it needs to: an audit, a legal dispute, a client asking when an agreement was signed. At that point, the difference between "we have the file somewhere" and "we have the full record, with its history" is the difference between answering in minutes or spending days digging through folders.

Thinking in Records instead of files isn't a technical preference — it's the foundation that makes automated retention policies, role-based access control, and an audit trail that actually holds up when someone needs it possible. Future posts on this blog will dig into each of those pieces on its own.

Frequently asked questions

Does a Record replace my current file storage system (Drive, SharePoint, a network drive)?

Not in the sense of competing for where the byte lives — the physical file still exists. What changes is that the file stops being the primary unit: it becomes an attribute of a version, inside a Record with its own identity, history, and retention policy.

If a Record can never be deleted, how do I remove a document uploaded by mistake?

It isn't physically deleted during its active lifecycle, but it is archived immediately, so it stops appearing in normal use. If the document contains data that must be fully removed — personal data under a habeas data request, for example — there's an anonymization flow that erases that sensitive content without destroying the audit trail that the Record ever existed.

Back to blog