White label
One setting puts your product name on every customer-visible surface Tabellix provides: the agent server, confirmation text, sign-in realms, evidence titles, webhooks, and configuration documents.
[ For software vendors ]
The record layer inside your product.
Build the product your customers buy. Tabellix keeps the records underneath it: versions, signatures, retention, sharing, and an audit trail anyone can verify offline, shipped under your own brand.
01 Who builds what
You build the product. We keep the record.
Your team owns the experience, the workflows your market expects, and the customer relationship. Tabellix owns the parts an auditor checks, so you do not have to build them.
[ Your product ]
- The user experience. Screens, flows, and the language of your market, rendered from the catalog of your configuration.
- Your vertical. The record types, lifecycles, policies, and retention rules your customers need, written as configuration.
- Your brand. Your product name on every customer-visible surface Tabellix provides.
[ Tabellix ]
- The record. Versions that are never edited in place, encrypted content, locked capture, and amendments with reasons.
- The rules. Policy as code, deny by default, hidden existence, signatures with meaning, and retention with holds.
- The proof. A hash-chained ledger with signed, timestamped checkpoints, verified offline by anyone.
02 Why embed
Record-keeping, already built.
A regulated record layer is far more than storage. These come with it, ready for your customers' auditors.
01
02
One API for records
Records, documents, signatures, workflows, retention, and the audit trail through one contract over gRPC and REST. You build the user experience.
03
Every capability through MCP
Your customers' AI agents reach every staff capability over MCP, under your agent policy and never above the person they act for.
04
Validation evidence, generated
Requirements, traceability, and IQ/OQ protocols are generated from the same traces as the code, with checks that qualify each installation.
05
Any cloud, air-gappable by design
Kubernetes with no dependency on a cloud provider, in your cloud or your customer's data center, and built for closed networks. It never calls home.
06
Isolation per company
Each company is provisioned with its own database, encryption keys, storage, and audit trail.
03 White label
Your name, everywhere it shows.
The product name your customers see comes from one setting in the deployment profile. Wire identifiers and signed bytes never change, so integrations and signed evidence do not depend on the name.
01
Your screens
A public branding endpoint your screens can read, even before the deployment is activated, so they show the same name.
02
Agents
The MCP server name and its instructions, and the text people see when they confirm an agent's request.
03
Evidence
The titles of evidence and machine-readable control reports, and the names of configuration documents.
04
Integrations
Sign-in realms and the identity your webhooks present to receivers.
04 Verticals as configuration
Each vertical is configuration, not code.
No industry concept lives in the engine. A QMS, a banking system of record, and a records office differ in object types, lifecycles, policies, and retention, all of it configuration.
| What you configure | For example |
|---|---|
| Object types | Controlled documents such as SOP-0042, case records such as a CAPA or a KYC file, event records such as an equipment cleaning. |
| Lifecycles | Draft, review, approve, effective, superseded, or any states your market uses, checked for completeness before they load. |
| Policies | Roles, permits, and forbids, restricted types, and what agents may do, confirm, or never do. |
| Retention | Periods per type, the triggers that start them, permanent retention, and what happens at the end. |
| Signatures and workflows | The meanings a signature can carry, and the steps and tasks that move an item through its lifecycle. |
01
Evidence for each configuration
Exhaustive transition tables are generated from each of your lifecycles, as evidence for your customer's validation.
02
A light reference configuration
A ready profile and configuration for a document library without quality-system machinery: neutral roles, restricted types and folders, and every read logged.
05 What a deployer controls
Configured at four levels.
The deployment profile is changed by redeploying, and its hash is recorded at every start. Everything below it ships as configuration releases, approved by the distinct approvers the profile requires, never the author.
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
Set once for the whole deployment.
Some choices are never made per type: access logging, encryption, scanning, the store lock mode, early destruction, and erasure rules apply to the whole deployment.
06 Isolation and many companies
One company, one of everything.
Each company is provisioned with its own database, encryption keys, storage, and ledger, and an operator keeps every company in shape.
01
A provisioning operator
One company resource creates and keeps everything a company needs, from its database and keys to its identity realm and first configuration release.
02
Kept in shape
The operator upgrades each company, rotates credentials, and repairs drift. It creates keys and cannot use them.
03
Two people for big steps
Freezing, thawing, adopting, and retiring a company need two people. Agents' writes to the operator need confirmation.
04
An operator ledger
The operator has its own tamper-evident ledger, authenticated API, and MCP server, and its events are written into each company's own ledger.
05
A signed way out
A company can be exported as a signed, verifiable package. A frozen company serves nothing publicly.
06
Ordered retirement
Retirement takes approvals and a grace period, then destroys in order and seals the record of what was destroyed.
07 Inside your product
Fits behind your gateway.
Tabellix sits behind your product as a dedicated deployment. It records your gateway's request ids in its ledger and sends security events to your collector.
01
Your gateway's context
Request ids and client addresses from your front end are recorded when it connects over mutual TLS with an allow-listed name. Otherwise the engine records its own.
02
Your security collector
Authentication failures, policy denials, and refusals go to your collector as OpenTelemetry logs, with no tokens, content, or hidden names. An outage there does not slow requests.
03
Support only with consent
Off by default. Your support staff get a bounded, time-boxed session only when your customer's approvers agree, and every read lands on the customer's own ledger first.
04
Your customers' identity
Each customer signs in with its own OIDC provider and provisions through SCIM. Your support staff use a separate issuer.
05
Binary-only delivery
Tabellix ships as binaries, charts, and documentation. Source, build systems, and development environments never ship.
06
Documentation for your team
Deployment, operations, security, recovery, and API guides, generated references, and an agent skill so a coding agent can build on Tabellix.
08 Validation evidence
Evidence your customers' auditors ask for.
Your customers validate what they run. Tabellix generates the evidence from the same traces as the code.
01
IQ/OQ package
A requirements specification mapped to 21 CFR Part 11, EU GMP Annex 11, and GDPR, a traceability matrix, IQ and OQ protocols and reports, and a validation plan and PQ templates.
02
83 product controls
Each control is tied to tests, invariants, failure modes, and a runtime check.
03
Controls your customer owns
For the controls a deployer owns, such as staff MFA or penetration testing, the events, settings, and checks the product exposes.
09 FAQ
Vendor questions.
01Can Tabellix be white-labeled?
Yes. One setting in the deployment profile puts your product name on every customer-visible surface Tabellix provides, including the agent server, confirmation text, sign-in realms, evidence titles, and webhooks. Wire identifiers and signed bytes do not change.
02Do we have to use a Tabellix user interface?
No. Tabellix is a core, not an application. You build the interface on the API, and the catalog lets it render from your configuration.
03How do we support a new industry?
With configuration: object types, lifecycles, policies, retention, signature meanings, and workflows. No industry concept lives in the engine code.
04How are our customers kept apart?
Each company gets its own database, encryption keys, storage, and ledger. An operator provisions and maintains each company, and creates keys it cannot use.
05Can our customers run it in their own data centers?
Yes. Tabellix runs on Kubernetes in any cloud or on premises, is designed for air-gapped networks, and never calls home.
06Can our support staff see customer data?
Only if the customer allows it. Vendor support access is off by default, needs approval by the customer's own approvers, is time-boxed, and records every read on the customer's ledger.
[ Contact ]
Build your product on proof.
Tell us what you build and who audits it. We will show you how Tabellix fits into your product and how it answers your auditors.