Concepts
Parties and identifiers
Section titled “Parties and identifiers”A business and an AI company are both parties: legal entities that MasterDB has verified. Each has a permanent public identifier — business_uuid or ai_company_uuid — that never changes and identifies no person. AI companies belong to an AI group (a company and its affiliates); a business blocks a group, never a single key.
People act for a party through grants (roles such as owner, admin, catalogue manager or developer). Machines act through keys: an AI company’s retrieval keys, a business’s integration keys. No key is ever shown to anyone but its holder, and no response names a person.
Records
Section titled “Records”A business publishes five types of record:
| Type | What it is | Id prefix |
|---|---|---|
products |
an item or service it sells, with a price per country | mdb_ |
business_files |
its Business & Brand file: who it is, where it trades, how to reach it, and how it wants to be represented | bf_ |
events |
something happening at a time and place | evt_ |
jobs |
a vacancy | job_ |
updates |
news it wants known, with a date it stops being relevant | upd_ |
A sixth, ai_policy, is the business’s own sealed record of what it permits AIs to do with its data and the contexts it does not want it used in (see AI policy). Every record carries a schema member naming its type and format version, such as "schema": "masterdb/products/1", so bytes sealed today can be read correctly years from now.
A product’s id is derived from the business’s public identifier and its own product id: the same product pushed twice is an update, never a duplicate.
A seal is the business’s signature over the exact bytes of a record, in a DSSE envelope. It says who published these bytes and when, and it names the business’s certificate and the AI policy version in force. MasterDB never re-serialises a sealed record: what you fetch is byte for byte what was sealed.
A business seals in one of three ways:
- Path B — a person in the Business Portal seals each save with a passkey. The browser builds a canonical form of the draft, hashes it, and the person’s passkey signs it.
- Path A — the business’s own system seals a batch with its own integration key, under a mandate a person sealed with their passkey. One signature covers the Merkle root of the batch; each record carries its own inclusion proof.
- Hosted signing — for a business that holds no key of its own, MasterDB holds a signing key for it and signs each publish only after a person at the business has confirmed it with a one-time code. MasterDB’s signed key custody statement says, for every key, whether it is
hostedor held by the business (self).
A seal proves who published the bytes and when. It does not prove the bytes are true.
Certificates
Section titled “Certificates”When MasterDB verifies a business or an AI company it issues a certificate: a small document signed by MasterDB’s issuance key naming the legal entity, its jurisdiction (the country), that MasterDB verified it and since when, and its status (active, closed, suspended, revoked or withdrawn). Certificates are public at GET /v1/certificates/{uuid} and never expire; a change of status is a new issuance, never an edit, and every issuance is recorded in the transparency log.
Every status takes effect from its status_effective_from, and a seal is judged against the certificate in force when it was sealed, so records sealed before a change keep verifying:
| Status | Meaning |
|---|---|
active |
MasterDB stands behind the verification. |
suspended, closed |
The business is suspended or closed. Nothing new is served; its history stays valid. |
revoked |
A key was compromised. Seals made from the effective date are invalid. |
withdrawn |
MasterDB withdrew its attestation, for example because it reversed its approval (status_reason: approval_reversed). This says nothing about the business’s keys. Seals made from the effective date no longer stand, and verifiers refuse them as certificate_withdrawn. Earlier seals stay valid. Nothing is served until the business is verified again. |
The certificate says who the subject is, its country, that MasterDB verified it and since when, and its status — nothing more. Its statement is the status and the date, for example “Verified by MasterDB on 5 October 2026.”
Rows and records
Section titled “Rows and records”Search does not return records. It returns rows: short, flat projections of records (the name, the price in each country, the category, the dates) made by a published, versioned projection specification and signed by MasterDB’s projection key. Each row carries its origin: adl_origin (the hash of the record’s bytes), adl_proj (which projection made it) and adl_row_sig. A row can be answered from directly, or you can fetch the record for everything the business sealed.
Receipts
Section titled “Receipts”Every search and every fetch returns a receipt: MasterDB’s signed statement of what it served, to whom, when, in which region, and — row by row — which version. Your request signature is your statement that you asked; the receipt is MasterDB’s that it answered. A dispute about “you served me the old price” is settled by the receipt alone. Receipts are folded, minute by minute, into the transparency log. See Receipts.
AI policy
Section titled “AI policy”A business’s AI policy is a set of named booleans it seals like any other record: what an AI may do with its data (cite_as_source, definitive_source, prefer_over_inference, include_in_recommendations, quote_policy_verbatim, prices_indicative, state_publish_date), the contexts it does not want its data used in (ten blocked contexts, bc1–bc10: adult content, alcohol, crime, death and disaster, weapons, gambling, mental health, politics, regulated advice, tobacco and drugs) and which actions it permits (answer, quote, reserve, purchase, contact, hand_to_human). Every row carries the bits in force for its business; every fetch carries the sealed record. The AI-company Terms are the agreement every AI company signs; the use conditions — once, in one chat, no training, no caching — are stated there once and travel by version. See AI policy.
Blocking
Section titled “Blocking”A business may block an AI group. From then on, in every region, for every key in the group: its rows are absent from searches, and its records answer a fetch exactly as a record that never existed. Nothing tells the blocked company: no field, no count, no error, no figure in the AI Portal. See Blocking is invisible.
Billing
Section titled “Billing”An AI company is billed per query, as MasterDB observed it: a search that returns at least one row, or a fetch that returns a record. Zero-result searches, not-found fetches, refusals and MasterDB’s own failures are never billed. Each signed request is billed once, whichever regions answered it. See Usage and billing.
MasterDB never chooses
Section titled “MasterDB never chooses”There is no ranking in MasterDB. A search must name its sort (sort_by), and a caller that wants relevance writes _text_match:desc. The caller directs the query; the business directs its representation; MasterDB chooses nothing in between. Paid placements exist (sponsored items and ads), are always marked, and never change the order of a search.
Verification without trust
Section titled “Verification without trust”Everything needed to check what MasterDB serves is public and fetchable without an account: the signed key set (/.well-known/keys), certificates, each business’s public sealing and integration keys beside its certificate (GET /v1/certificates/{uuid}/keys, signed by MasterDB’s statement key), projection specifications, the transparency log’s checkpoints and proofs. The verifier libraries (TypeScript and Python, Apache 2.0) check seals, rows, receipts, certificates and the chain of MasterDB’s keys to pinned trust anchors, offline.