Documents
A controlled item with a number and an identity. Its content evolves through versions, under the lifecycle its type declares.
[ 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.
01 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.
01
02
Records
Typed fields instead of a primary file. Case records follow a lifecycle; event records capture something that happened.
03
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.
02 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.
v0.1draftedcreated
v0.2reviewedcomments kept
v1.0approvedsigned, effective
v1.1revisednew draft
v2.0effectivev1.0 superseded
01
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.
02
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.
03
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.
04
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.
05
One version in force
Releasing a version supersedes the previous effective one in the same step, now or at a scheduled time.
06
Comments and comparison
Comments on versions are immutable, and any two versions can be compared by metadata and digest.
03 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 |
01
Locked at capture
Captured fields lock when they are captured, and late entries are flagged at capture.
02
Corrected by amendment
A correction is an amendment that states a reason. The old value stays visible beside the new one.
03
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.
04
Imports without duplicates
Systems capture up to 100 records per call, and a source reference already captured is recognized instead of stored twice.
05
Cases hold their members
A case binds its members in order. Holds, retention triggers, and sealing flow from the case to its members.
06
Signed records
A signature on a record binds its state and the exact field values signed, and a transition can require one.
04 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.
01
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.
02
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.
03
Signatures bound to version and meaning
Each signature names its meaning, binds the exact version, and requires a fresh sign-in.
04
Retention and holds
Retention per record type, the longest period wins, and a hold blocks disposition and destruction.
05
Disclosures and shares
What left the organization, to whom, which version, through which disclosure, with digests.
06
Versioned configuration
The configuration release in force is stamped on every audit entry, so the rules that applied are part of the record.
05 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.
historianraw readingsevery second
event recordexceedancevalue, limit, time
event recordalarm acknowledgedby the shift lead
case recorddeviation openedinvestigation
documentwindow exportattached, 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.
06 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. |
[ Contact ]
Build your product on proof.
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.