Written in the same transaction
There is no change without its audit entry, and no audit entry for a change that did not commit.
[ Trust and verifiability ]
Don't trust us. Verify.
Every change is written to a hash-chained ledger in the same transaction. Checkpoints are signed with a key the database cannot use and timestamped by an independent authority, so an auditor can check records, disclosures, and evidence offline, on their own machine.
01 The ledger
Every change, chained.
Each change and its audit entry commit together, or neither does. Each entry carries the hash of the one before it, so changing any entry breaks every entry after it.
#48210createdprev 00a1…
#48211reviewedprev 9f3a…
#48212signedprev 4be1…
#48213effectiveprev c21e…
#48214disclosedprev 7d0f…
checkpointsignedRFC 3161
✓ verified offline
01
02
Who, when, under which rules
Each entry names the person, and for agents the agent session, with the request and the configuration release in force when it happened.
03
Access is on the record
Views and downloads are logged before content is served, at the level the deployment sets, sealed into the ledger in segments, and provable like any other entry.
04
Refusals recorded too
A refused sensitive action is appended to the ledger without naming anything the person may not see, and a flood of refusals cannot fill it.
05
Checked all the time
A background verifier re-checks the ledger continuously and raises an alarm if it stalls.
06
Readable by role
Audit queries reveal only what the reader may see. An auditor role sees everything.
02 Checkpoints
Sealed by a key the database cannot use.
At intervals the ledger is sealed into a signed Merkle checkpoint. The key that signs it is out of the database's reach, so whoever controls the database still cannot forge a seal.
01
Signed checkpoints
Checkpoints are signed notes in the open C2SP signed-note format, with a key held by the key manager that the database cannot use.
02
Independent time stamps
Each sealed checkpoint is stamped by the RFC 3161 time stamping authority you configure, and the stamp verifies offline. No write ever waits for the authority.
03
Inclusion and consistency proofs
Any entry can be proven part of a checkpoint, and any later checkpoint proven to extend an earlier one, with proofs in the RFC 9162 form.
04
Kept apart
Checkpoints are written to their own bucket, separate from the content, and locked there where the store supports locks.
05
Restores are visible
A database restored behind a sealed checkpoint continues in a new epoch, with a signed record of what was lost. The restored history is proven a prefix of the sealed one.
06
Your origin, pinned
The checkpoint origin is chosen at installation and cannot change once data exists, so every seal names the deployment it came from.
03 Offline verification
Verified on the auditor's machine.
The offline verifier checks what Tabellix hands out with no network and no database: only the artifact, the deployment's origin, and its public keys.
| What the auditor holds | What the verifier proves |
|---|---|
| A disclosure bundle | The bundle is the one that was signed and released, and every file in it matches its digest. |
| An export | The export has not changed since it was produced, checked against the signed checkpoints. |
| A period evidence bundle | The control events of a period are proven against one closing checkpoint, with sampled checkpoints, their time stamps, and consistency proofs. |
01
No access to our systems
Verification needs nothing from the vendor or the deployment beyond the artifact and the deployment's public verification data.
02
Deterministic bundles
Disclosure bundles are deterministic and signed, with the signing key version named, so the same release always verifies the same way.
03
Gaps are stated
Period evidence lists its own gaps instead of hiding them.
04 Immutability
Tamper-evident first.
Immutability is enforced by the system itself, whatever the store underneath. Store-level locking is added where the deployer's store supports it, and the system reports the level it actually has.
L1
The databaseAlways on
Stored versions insert-onlyUpdates and deletes refusedTampering refused by guards
L2
The ledgerAlways on
Hash-chained entriesSigned checkpointsRFC 3161 time stampsOffline verification
L3
The storeWhere the store supports Object Lock
WORM until retention endsCompliance or governance modeHolds extend the lockLock level reported
01
Locks where the store has them
On S3 with Object Lock, Azure Blob or Google Cloud Storage, content can be written locked until its retention ends, in the mode the deployment chooses.
02
Never assumed
The lock level the store actually enforces (object, bucket or none) is reported in the evidence, the deployment report, the IQ and OQ tables, and the start log.
03
Detected where not prevented
On a store without locks, retention is enforced by the application, and the ledger detects any tampering with what the store holds.
04
Fixity on a schedule
Stored content is re-verified on a schedule. Damaged content is marked, never served again, and repaired from locked copies where they exist.
05
Lawful destruction leaves a trace
Crypto-shredding makes content unreadable while its identity, its history and the ledger still verify.
06
Audit values sealed per object
When an object is destroyed, its audit entries stay verifiable and their sealed values become unreadable.
05 Signatures
A signature says what it meant.
Each electronic signature records its meaning, binds the exact version and viewing copy the signer saw, and needs a fresh interactive sign-in. An independent reader can read it back from the signed PDF/A.
01
Meaning
Approved, reviewed, or any meaning you configure, recorded with the signature.
02
Bound
To the version digest and the viewing copy, or to the content digest for exact-bytes formats.
03
Fresh
An interactive sign-in inside the deployment's window, with step-up where your identity provider supports it.
04
Manifested
A new PDF/A with a signature page that names the signer, the meaning, the time and the manifest digest.
06 Validation evidence
Evidence generated from the same traces as the code.
Requirements, traceability and the IQ/OQ protocols are generated from the domain model, the control catalog and the test headers. When the product changes, the evidence changes with it.
01
Requirements and traceability
A requirements specification traced to 21 CFR Part 11, EU GMP Annex 11 and GDPR, with recorded accepted gaps, and a traceability matrix from requirement to test.
02
OQ protocol and report
One OQ case per end-to-end and fault test, with its report, plus validation plan and PQ templates for your own work.
03
IQ in the product
Installation checks run read-only in every pod, and an operator tool adds checks of the bundle, the running images, the installed chart, the live objects and the network policy.
04
Your lifecycles, as evidence
Exhaustive transition tables are generated from each lifecycle you configure, usable as OQ evidence for that configuration.
05
Live control state
An evidence endpoint reports the live state of the controls, the profile hash, transport, backups, the last recovery drill, the store lock level and the license.
06
Machine-readable
Environment reports for a chosen framework are sealed in the ledger, and control evidence is also produced as OSCAL.
07 In the catalog
Specified, not assumed.
Failure behavior, controls, installation checks, invariants and agent reach are written down as catalogs, so what the system must do is specified before it is tested.
0failure modes specified, each with defined behavior
0product controls tied to tests, invariants and runtime checks
0installation checks that qualify each deployment
0domain invariants checked by a traceability tool
Catalog figures from the current release line. They count what is specified, not test results.
01
Failure modes
Dependency outages, partial writes, job crashes, leader changes, tampering, clock skew, expired tokens and scanner limits, each with the behavior the system must show.
02
Agent reach
142 operations are reachable by agents through MCP, each governed by policy and placed in a risk tier that decides whether an agent may act alone, must wait for a person, or may not act at all.
03
Controls the deployer owns
For controls that belong to the deployer, such as staff MFA, key rotation and emergency access, the product names the events, settings and checks it exposes as evidence.
08 Frameworks
Mapped to the frameworks your auditors use.
Product controls and requirements map to eight regulations and standards and provide evidence for your own validation and audits. Tabellix holds no third-party attestation under any framework and claims none; attestation belongs to each deployment and its independent audits. The clause-by-clause mappings are working drafts in review: ask us for the current crosswalk and judge each mapping yourself.
Controls map to
- 21 CFR Part 11
- EU GMP Annex 11
- GDPR
- EU AI Act
- ISO 13485
- SOC 2
- ISO/IEC 27001
- HIPAA
Product controls map to these regulations and standards and provide evidence for your own validation and audits.
Agent oversight built for
- EU GMP Annex 22 (draft)
The draft EU GMP Annex 22 keeps generative AI out of critical GMP applications and expects qualified people to stay responsible for AI outputs. Under the regulated agent preset, only named people approve and sign.
01
Packs the product checks
Framework packs can be declared in the deployment profile, and the product checks their controls against the live configuration.
02
One catalog, many frameworks
SOC 2, ISO/IEC 27001, HIPAA, ISO 13485 and the EU AI Act are mapped from one control catalog, so one control provides evidence for each framework it maps to.
03
Regulated records
21 CFR Part 11, EU GMP Annex 11 and GDPR are traced from requirement to test in the validation package.
09 FAQ
Questions from auditors.
01Can an auditor verify records without access to the vendor's systems?
Yes. The offline verifier checks disclosure bundles, exports and period evidence with no network and no database, against signed checkpoints and their RFC 3161 time stamps.
02Are records immutable?
Records are tamper-evident: stored versions are insert-only, the database refuses tampering, and the hash-chained ledger with signed checkpoints makes any change detectable offline. Where the store supports Object Lock, content can also be written in WORM mode until its retention ends. That is a per-deployment setting, and the lock level actually in force is reported.
03What happens if someone restores an old database backup?
The ledger continues in a new epoch with a signed record of what was lost, and the restored history is proven a prefix of the sealed one. A rollback shows in the history.
04Does Tabellix hold a certification?
No. Tabellix holds no third-party attestation under any framework and claims none. Product controls map to 21 CFR Part 11, EU GMP Annex 11, GDPR, the EU AI Act, ISO 13485, SOC 2, ISO/IEC 27001 and HIPAA, and provide evidence for validation and audits; attestation belongs to each deployment and its independent audits.
05What validation evidence comes with it?
A generated requirements specification, traceability matrix, IQ and OQ protocols and reports, validation plan and PQ templates, transition tables for every lifecycle you configure, and installation checks that run in the product.
06Do the catalog figures mean every test passes?
No. They count what is specified: failure modes with their defined behavior, operations under policy, controls, installation checks and invariants. They are catalog facts, not pass rates.
[ Contact ]
Bring your auditor.
Tell us who audits your product and what they ask for. We'll walk them through the ledger, the offline verifier and the validation evidence.