# The record layer inside your product

> For software vendors. 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.

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

## Why embed: Record-keeping, already built.

A regulated record layer is far more than storage. These come with it, ready for your customers' auditors.

- **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.
- **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.
- **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.
- **Validation evidence, generated.** Requirements, traceability, and IQ/OQ protocols are generated from the same traces as the code, with checks that qualify each installation.
- **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.
- **Isolation per company.** Each company is provisioned with its own database, encryption keys, storage, and audit trail.

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

- **Your screens.** A public branding endpoint your screens can read, even before the deployment is activated, so they show the same name.
- **Agents.** The MCP server name and its instructions, and the text people see when they confirm an agent's request.
- **Evidence.** The titles of evidence and machine-readable control reports, and the names of configuration documents.
- **Integrations.** Sign-in realms and the identity your webhooks present to receivers.

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

- **Evidence for each configuration.** Exhaustive transition tables are generated from each of your lifecycles, as evidence for your customer's validation.
- **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.

[Industries](https://tabellix.dev/industries/)

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

- **Deployment** (Set at installation and recorded at every startup): Access logging mode; Signature re-authentication window; Storage lock mode; Minimum retention; Early destruction; Break-glass; Agent preset; Identity providers; Branding.
- **Object type** (Per document, record, or case type): Lifecycle and guards; Fields and capture rules; Retention policies; Periodic review; Accepted media types; Encrypted content; Case access attributes.
- **Release** (Approved by people other than the author, applied in seconds): Roles, permits, and denials; Agent allow, confirm, or deny; Signature meanings; Workflows; Triggers; Redaction codes.
- **Agent preset** (A regulated baseline, or each permission set individually): Signing, by meaning; Destruction approval; Sharing; Hold release; Release activation; Break-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.

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

- **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.
- **Kept in shape.** The operator upgrades each company, rotates credentials, and repairs drift. It creates keys and cannot use them.
- **Two people for big steps.** Freezing, thawing, adopting, and retiring a company need two people. Agents' writes to the operator need confirmation.
- **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.
- **A signed way out.** A company can be exported as a signed, verifiable package. A frozen company serves nothing publicly.
- **Ordered retirement.** Retirement takes approvals and a grace period, then destroys in order and seals the record of what was destroyed.

[Deployment shapes](https://tabellix.dev/deployment/)

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

- **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.
- **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.
- **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.
- **Your customers' identity.** Each customer signs in with its own OIDC provider and provisions through SCIM. Your support staff use a separate issuer.
- **Binary-only delivery.** Tabellix ships as binaries, charts, and documentation. Source, build systems, and development environments never ship.
- **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.

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

- **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.
- **83 product controls.** Each control is tied to tests, invariants, failure modes, and a runtime check.
- **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.

[Trust and verifiability](https://tabellix.dev/trust/)

## FAQ: Vendor questions.

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

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

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

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

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

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

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.

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

---

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