Versions, never edits
Every change creates a new version. Stored versions are never edited in place, and the database refuses attempts to tamper with them.
[ Platform ]
One core for every record.
Documents, records, signatures, workflows, retention, and a verifiable audit trail, in one engine that people and AI agents use under the same rules. Each industry is configuration, not code.
01 Documents and records
Every item has an identity.
A document is a controlled item with a number, and its content evolves through versions. A record holds typed fields instead of a file. Both keep their full history.
01
02
Encrypted, checked on every read
Each file is one encrypted content object with its own key. Its digest is checked on every read, and PDF/A viewing copies and extracted text are derived from it.
03
Scanned before it is served
Every file is scanned for malware. A file is served or published only after the scanner answers clean.
04
Case records and event records
Case records follow a lifecycle, such as a CAPA or a change request. Event records capture something that happened, such as a cleaning or an exceedance.
05
Locked at capture
Captured fields lock when they are captured. A correction is an amendment with a reason, and the original value stays visible.
06
Links that hold
An event links to the procedure version in force when it happened, and that link never moves.
02 Lifecycles and signatures
Every step, declared.
Lifecycles are state machines you configure, checked for completeness before they load. Workflows move items through them, and each signature records what the approval meant.
01
Lifecycles you configure
Every state must handle or explicitly ignore every event. Exhaustive transition tables are generated from each lifecycle as evidence for your validation.
02
Release and supersede
Draft, review, and approve into a new major version, effective now or at a scheduled time. The previous effective version is superseded in the same step.
03
No self-approval
An author cannot approve their own work, and the refusal is recorded.
04
Signatures with meaning
Each signature records its meaning, binds the exact version and viewing copy the signer saw, and requires a fresh sign-in. It adds a signature page to a new PDF/A.
05
Workflows and tasks
Steps of parallel tasks, with delegation and overdue marking. Completing a task takes the assignee's own signature with the meaning of the step.
06
Training and periodic review
A version going into force starts a training campaign for the people in the role, and each acknowledgement becomes a training record. Periodic reviews start on schedule.
03 The audit ledger
Every change, chained.
Each change is written to a hash-chained ledger in the same transaction as the change itself. Signed, timestamped checkpoints let anyone verify the history offline.
01
No change without its entry
The audit entry and the change commit together, or neither does.
02
Signed checkpoints
Checkpoints are signed with a key the database cannot use and timestamped by an independent RFC 3161 authority.
03
Access is on the record
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.
04
Verified offline
Disclosure bundles, exports, and period evidence are verified with no network and no database.
05
Checked continuously
A background verifier re-checks the ledger all the time and raises an alarm if it stalls.
06
Refusals recorded too
A refused sensitive action is recorded in the ledger, without naming anything the person may not see.
04 Retention and privacy
Kept exactly as long as required.
Retention is set per record type, and the longest period that applies wins. Holds stop the clock, people approve every disposal, and personal data can be erased without breaking the audit trail.
01
Retention per type
Periods per record type, including permanent retention, above a minimum the deployment enforces.
02
Legal holds
A hold blocks disposition and destruction, whatever the schedule says. Narrowing a hold needs approval.
03
People approve disposal
The system proposes what is due, and records administrators approve or reject each disposition.
04
Destruction by crypto-shredding
Destroying the key makes the content unreadable. The record's identity and history remain, and the ledger still verifies.
05
A key per person
Personal data about each person that records concern sits under its own key. Erasure destroys that key and keeps the records and their links.
06
Pseudonymous attribution
The ledger names people by stable IDs. Display names are resolved when read, under their own permission.
06 Search
Search that respects every permission.
Ranked full-text search applies permissions inside the same database query, so results and counts never include what a person may not see.
01
Ranked and language-aware
Field-weighted ranking in each language the deployment uses, with exact and prefix filters on your own document references.
02
Permissions in the query
Only what the person may read comes back, in complete pages. Hidden and missing records look the same.
03
Stable paging
Page tokens are bound to the person and the filters, so pages stay stable while new content is indexed.
04
Text from files
With an optional text extraction service, the text of stored files becomes searchable, including files stored before it was switched on.
07 Configuration
Configured at four levels.
Changes below the deployment ship as configuration releases: reviewed as a diff, approved by people other than the author, checked against existing data, and live in seconds without a restart.
L1
DeploymentSet at installation and recorded at every startup
Access logging modeSignature re-authentication windowStorage lock modeMinimum retentionEarly destructionBreak-glassAgent presetIdentity providersBranding
L2
Object typePer document, record, or case type
Lifecycle and guardsFields and capture rulesRetention policiesPeriodic reviewAccepted media typesEncrypted contentCase access attributes
L3
ReleaseApproved by people other than the author, applied in seconds
Roles, permits, and denialsAgent allow, confirm, or denySignature meaningsWorkflowsTriggersRedaction codes
L4
Agent presetA regulated baseline, or each permission set individually
Signing, by meaningDestruction approvalSharingHold releaseRelease activationBreak-glass
01
One release per request
Every request and job runs under exactly one configuration release, and its digest is stamped on every audit entry.
02
Safe changes to lifecycles
When a lifecycle changes, existing items move to the new states through audited transitions.
03
The deployment profile is recorded
The read-only deployment profile has its hash recorded at every start, so any change to it is visible.
04
No industry in the engine
No industry concept lives in the engine code. Each vertical is a configuration pack.
08 Agents and MCP
Built for agents.
Every staff capability is reachable over MCP, under the authority of the person the agent acts for. The deployer decides how far agents may go, and the audit trail shows who did what.
01
Every capability, by policy
142 operations are reachable through MCP, each governed by policy and placed in a risk tier that decides whether an agent may read, write, must wait for a person, or may not act at all.
02
Never above the person
An agent gets only what its person may do and the agent policy allows. A missing or failing agent policy denies.
03
People confirm what matters
High-risk actions wait for the person to confirm them out of band, with a fresh sign-in. The agent cannot approve its own request.
04
Two presets
Under the regulated preset, only named people approve and sign. Under the flexible preset, the deployer opens individual permissions, and an agent's signature always says it was the agent's.
05
Trust only goes down
When an agent reads another party's text or unscanned content, its session trust drops, and lower trust narrows what it may write.
06
Standard MCP
The server passes the official MCP conformance scenarios that apply to a product server, and acts as an OAuth 2.1 resource server.
09 Interfaces
One contract, every protocol.
The same contract is served as gRPC, gRPC-Web, JSON over HTTP, and resource-style REST with a generated OpenAPI, and as MCP for agents. You build against one contract.
01
A compatibility gate
A release that removes or changes a field, a method, or an error mapping is refused before it ships. Additive changes pass.
02
Events from the ledger
Committed events reach consumers with their own cursors, over signed webhooks or an optional NATS JetStream bridge. Webhooks follow Standard Webhooks and CloudEvents and carry no content.
03
Long-running operations
Wait up to a timeout or take a handle, then poll, or get a webhook, NATS, or MCP notification.
04
A catalog to render from
Types, lifecycles, signature meanings, roles, and labels are readable, so your application can render itself from configuration.
05
Your identity provider
Any OIDC provider for sign-in, and SCIM 2.0 to provision people and map directory groups to roles.
06
Your brand
One setting puts your product name on every customer-visible surface Tabellix provides, from the agent server and confirmation text to evidence titles and webhooks.
10 Where it fits
A core, not an application.
The QMS, banking, case management, or public records product built on Tabellix is the application. Tabellix is the record layer underneath it, embedded and shipped under your brand, or used directly through its API and MCP.
OEM and white label[ 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.