# Records, not files

> Records, not files. A file store keeps bytes. A system of record keeps what an auditor asks for: which version applied, who approved it and what that meant, who looked at it, and whether anything changed afterward.

## Three layers: Documents, records, and the evidence about both.

Tabellix keeps three kinds of thing, and treats each the way a regulated organization has to.

- **Documents.** A controlled item with a number and an identity. Its content evolves through versions, under the lifecycle its type declares.
- **Records.** Typed fields instead of a primary file. Case records follow a lifecycle; event records capture something that happened.
- **Evidence about both.** A chained audit trail that includes access, signatures bound to version and meaning, retention and holds, disclosures and shares, and versioned configuration.

## Documents: A document is an identity, not a file.

Procedure SOP-0042 stays SOP-0042 through every revision. What changes is its content, one version at a time, and every version stays in the history.

1. **drafted** (v0.1; created)
2. **reviewed** (v0.2; comments kept)
3. **approved** (v1.0; signed, effective)
4. **revised** (v1.1; new draft)
5. **effective** (v2.0; v1.0 superseded)

- **One file, encrypted.** The file of a version is one encrypted content object with its own key. Its digest is checked on every read and re-verified on a schedule.
- **Derived copies.** A PDF/A viewing copy and the extracted text are derived from that file, so people can read and search it. A signature binds the viewing copy the signer saw.
- **Exact bytes when they matter.** Formats such as CSV or JSON can be kept exactly as uploaded, with no viewing copy, and signed over their content digest.
- **Versions, never edits.** Drafts are minor versions and releases are major ones. Saving over a version that is no longer the latest is refused before any byte is stored.
- **One version in force.** Releasing a version supersedes the previous effective one in the same step, now or at a scheduled time.
- **Comments and comparison.** Comments on versions are immutable, and any two versions can be compared by metadata and digest.

## Records: A record is a fact, with fields.

Many regulated facts are not documents at all. A record holds typed fields, captured once and never overwritten, and the record type decides which fields and which rules apply.

| Kind | What it is | Examples |
| --- | --- | --- |
| Case record | Work with a beginning and an end, following a lifecycle | A CAPA, a change request, a deviation, a KYC file |
| Event record | Something that happened, at a time and a place | An equipment cleaning, a pressure exceedance, a training completion |

- **Locked at capture.** Captured fields lock when they are captured, and late entries are flagged at capture.
- **Corrected by amendment.** A correction is an amendment that states a reason. The old value stays visible beside the new one.
- **The source on every record.** Every record notes where it came from: a person, a form at the point of work, a device or system through the API, or an import.
- **Imports without duplicates.** Systems capture up to 100 records per call, and a source reference already captured is recognized instead of stored twice.
- **Cases hold their members.** A case binds its members in order. Holds, retention triggers, and sealing flow from the case to its members.
- **Signed records.** A signature on a record binds its state and the exact field values signed, and a transition can require one.

## Evidence: The evidence about both.

Around every document and record, Tabellix keeps what an auditor asks for, in a form they can check without trusting the vendor.

- **An append-only, chained trail.** Every change is written in the same transaction to a hash-chained ledger, with signed and timestamped checkpoints that verify offline.
- **Access, too.** Views and downloads are logged before content is served, at the level the deployment sets. Reads of the personal data held about a person are logged at every level.
- **Signatures bound to version and meaning.** Each signature names its meaning, binds the exact version, and requires a fresh sign-in.
- **Retention and holds.** Retention per record type, the longest period wins, and a hold blocks disposition and destruction.
- **Disclosures and shares.** What left the organization, to whom, which version, through which disclosure, with digests.
- **Versioned configuration.** The configuration release in force is stamped on every audit entry, so the rules that applied are part of the record.

[Trust and verifiability](https://tabellix.dev/trust/)

## What belongs: Not every reading is a record.

A pressure sensor on a filling line reports every second. Most of those readings never need an answer. Some do, and those become records.

1. **raw readings** (historian; every second)
2. **exceedance** (event record; value, limit, time)
3. **alarm acknowledged** (event record; by the shift lead)
4. **deviation opened** (case record; investigation)
5. **window export** (document; attached, versioned)

### Stays in the historian

- **Raw telemetry.** Every reading at its full rate, in the historian or time-series store built for it.
- **Trends and dashboards.** Live views over the raw series, for the people running the line.

### Becomes a record

- **An exceedance.** The value, the limit, the time, and the equipment, captured once.
- **An acknowledged alarm.** Who acknowledged it, and when.
- **A calibration or an override.** What changed, who changed it, and the reason.
- **The investigation it opens.** A case record with its lifecycle, its members, and its signatures.

The rule is simple: what someone must answer for later becomes a record. Raw data becomes an attached, versioned document only when it is itself evidence, such as an export of the window around the event, or a periodic summary that someone reviews and signs.

## The auditor's questions: A file store answers what the bytes are. Tabellix answers the auditor.

| The question | Where the answer comes from |
| --- | --- |
| Which version was in force on a given date? | Release, supersession, and scheduled effective dates are transitions on the ledger, so the version in force on any date is a lookup. |
| Who approved it, and what did the signature mean? | Each signature names its meaning, binds the version digest, and required a fresh sign-in at the time. |
| Who looked at it, and why? | Views and downloads are logged with the person and the session before content is served, at the level the deployment sets. Emergency access carries its justification and its review. |
| Did anything change after the fact? | Versions are never edited, and the hash chain with signed checkpoints shows any change. An auditor can check it offline. |
| May it be destroyed yet? | Retention per type decides when, the longest period wins, any active hold blocks destruction, and a person approves each disposal. |

[The whole platform](https://tabellix.dev/platform/)

## Contact

Tell us what you build and who audits it. We'll show you how Tabellix fits into your product and how it answers your auditors' most common questions.

Contact form: https://tabellix.dev/contact/

---

This page as HTML: https://tabellix.dev/records/ · [Site guide for language models](https://tabellix.dev/llms.txt)