# Don't trust us. Verify

> Trust and verifiability. 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.

## 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.

1. **created** (#48210; prev 00a1…)
2. **reviewed** (#48211; prev 9f3a…)
3. **signed** (#48212; prev 4be1…)
4. **effective** (#48213; prev c21e…)
5. **disclosed** (#48214; prev 7d0f…)
6. **signed** (checkpoint; RFC 3161)

verified offline

- **Written in the same transaction.** There is no change without its audit entry, and no audit entry for a change that did not commit.
- **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.
- **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.
- **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.
- **Checked all the time.** A background verifier re-checks the ledger continuously and raises an alarm if it stalls.
- **Readable by role.** Audit queries reveal only what the reader may see. An auditor role sees everything.

## 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.

- **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.
- **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.
- **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.
- **Kept apart.** Checkpoints are written to their own bucket, separate from the content, and locked there where the store supports locks.
- **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.
- **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.

## 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. |

- **No access to our systems.** Verification needs nothing from the vendor or the deployment beyond the artifact and the deployment's public verification data.
- **Deterministic bundles.** Disclosure bundles are deterministic and signed, with the signing key version named, so the same release always verifies the same way.
- **Gaps are stated.** Period evidence lists its own gaps instead of hiding them.

## 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.

- **The database** (Always on): Stored versions insert-only; Updates and deletes refused; Tampering refused by guards.
- **The ledger** (Always on): Hash-chained entries; Signed checkpoints; RFC 3161 time stamps; Offline verification.
- **The store** (Where the store supports Object Lock): WORM until retention ends; Compliance or governance mode; Holds extend the lock; Lock level reported.

- **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.
- **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.
- **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.
- **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.
- **Lawful destruction leaves a trace.** Crypto-shredding makes content unreadable while its identity, its history and the ledger still verify.
- **Audit values sealed per object.** When an object is destroyed, its audit entries stay verifiable and their sealed values become unreadable.

[Retention, holds and destruction](https://tabellix.dev/privacy-retention/)

## 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.

- **Meaning.** Approved, reviewed, or any meaning you configure, recorded with the signature.
- **Bound.** To the version digest and the viewing copy, or to the content digest for exact-bytes formats.
- **Fresh.** An interactive sign-in inside the deployment's window, with step-up where your identity provider supports it.
- **Manifested.** A new PDF/A with a signature page that names the signer, the meaning, the time and the manifest digest.

## 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.

- **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.
- **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.
- **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.
- **Your lifecycles, as evidence.** Exhaustive transition tables are generated from each lifecycle you configure, usable as OQ evidence for that configuration.
- **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.
- **Machine-readable.** Environment reports for a chosen framework are sealed in the ledger, and control evidence is also produced as OSCAL.

## 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.

- **448** failure modes specified, each with defined behavior
- **83** product controls tied to tests, invariants and runtime checks
- **36** installation checks that qualify each deployment
- **153** domain invariants checked by a traceability tool

Catalog figures from the current release line. They count what is specified, not test results.

- **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.
- **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.
- **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.

## 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.

**Mapped regulations and standards:** 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.

- **Packs the product checks.** Framework packs can be declared in the deployment profile, and the product checks their controls against the live configuration.
- **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.
- **Regulated records.** 21 CFR Part 11, EU GMP Annex 11 and GDPR are traced from requirement to test in the validation package.

## FAQ: Questions from auditors.

### Can 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.

### Are 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.

### What 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.

### Does 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.

### What 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.

### Do 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

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.

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

---

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