Publishing on MasterDB

A business publishes five types of record — products, its Business & Brand file, events, jobs and updates — plus its AI policy: what it permits AIs to do with its data, and the contexts it does not want it used in. AI companies retrieve them through signed requests, and receive them exactly as the business sealed them.

One rule: sealed, or not published

Every record is signed over its exact bytes before MasterDB stores it. A business that holds its own keys seals with them, and MasterDB never holds them; a business that uses hosted signing has MasterDB sign each publish for it only after a person at the business confirms it, and MasterDB’s signed key custody statement says which. A seal that does not verify is refused, with a reason that names the seal — distinct from a validation failure — and the refusal is recorded where you can see it.

Two ways in

	Path B — a person in the Business Portal	Path A — your own system
Who	anyone at the business with a publishing role	your catalogue system, a connector, an agency’s feed
Seals with	their passkey, at the moment they save	your integration key, under a mandate a person sealed with their passkey
What is sealed	a canonical form of the draft the browser builds	the records’ exact bytes, as your system sent them
Per	save	batch of up to 10,000 records, or a bulk file of up to 100,000
Meaning	a save publishes the draft	a push replaces each record it names
Imports	a CSV merges into drafts; the person reviews and seals the result	—

Read: Publishing through the portal, Sealing with a passkey, Pushes and mandates.

What happens when you publish

1. Checks. The bytes must be one strict JSON value with its schema; every reason is returned at once. Plain text only, role addresses only, money as decimal strings, a price only for a country the record is published in, safe URLs, and the scope rule: a record may speak for your business and the brands it owns or sells, and may not make claims about another company or direct how other sources are treated.
2. The seal is verified: the key was valid at sealed_at, the certificate and AI policy version named were in force, and the person or key was allowed to publish this type.
3. Stored, byte for byte, with MasterDB’s signed sidecar (what it checked, the resolved scope, a geocoded coordinate where there is an address), and recorded in the transparency log.
4. Projected into signed index rows and fanned out to every region; the record is live everywhere within seconds.
5. A confirmation: for a save in the portal, an email to your owners and admins naming who published, with a plain link to the portal (each chooses how often: Choosing which emails you get); for a push, the response names each record’s id, version and hash.

Your identity

MasterDB verifies your business before you publish, and issues a certificate: your legal name, your country, that MasterDB verified you and since when, and your status, signed by MasterDB and public. It does not say how you were verified. Verification raises the cost of impersonation; it does not make it impossible, and it is not an endorsement of what you publish. See What an AI company sees.

Testing

Everything above works in the sandbox, where a business publishes without verification and nothing is served to a production AI company.