The source line
The source line is the one line of provenance an AI cites beside an answer it built from a MasterDB record, so the person reading the answer — or anyone they show it to — can check it without an account: who published the record, that it is exactly what they published, and that it was the version being served when the AI read it.
Every fetch carries a ready-made line in provenance.source_line; for a search row, compose it from the row and the response’s receipt. The verifier libraries format and read it (formatSourceLine / parseSourceLine).
The two forms
Section titled “The two forms”What a person sees — you render it; the wording is yours:
Source: Acme Fashion Ltd · Verified business · Updated 2 min ago · Check
where Check links to the verify URL below, and the name comes from the row’s business_name or the verify page’s business.name.
What a machine carries — the source line itself, one ASCII line:
mdb-source/1 record={record_id} origin={adl_origin} cert={cert_id} served={served_at} verify={verify_url}| Member | Required | Where you get it | Meaning |
|---|---|---|---|
mdb-source/1 |
yes | — | The version tag. A reader refuses any other tag rather than guessing. |
record |
yes | a row’s record_id; a fetch’s record_id |
The record id (mdb_…, bf_…, evt_…, job_…, upd_…). |
origin |
yes | a row’s adl_origin; a fetch’s receipt row |
sha256: of the record’s exact bytes. Possession of the record, never a bare id, is what the public page takes. |
cert |
no | a row’s adl_origin_cert; the fetch sidecar’s cert_id |
The certificate the record’s seal named. Omit it when you do not have it; the page reports the certificate either way. |
served |
yes | the receipt’s served_at |
When MasterDB served the record to you (RFC 3339, UTC). |
verify |
yes | computed from the four above | https://verify.masterdb.ai/v1/verify/{record}?origin={origin}[&cert={cert}]&served_at={served}, query values percent-encoded. Always last. |
Members are separated by one space and appear in this order; cert may be absent. A reader re-derives verify from the other members and refuses a line whose URL does not match — its host may differ (the sandbox’s is https://sandbox.verify.masterdb.ai) but not its path or query — so a line whose link was swapped is caught.
What the verify page answers
Section titled “What the verify page answers”GET /v1/verify/{record_id}?origin=…[&cert=…][&served_at=…] on verify.masterdb.ai — HTML for a browser, JSON otherwise (?format=html|json overrides). The JSON is signed by MasterDB’s statement key as its own payload type, DSSE application/vnd.masterdb.verify-page.v1+json; the verifier libraries check it with verifyVerifyPage / verify_verify_page. See the Verification API.
| Field | Answer |
|---|---|
valid |
The business published a record with these exact bytes, and nothing the line says contradicts that (cert matches the certificate the seal named; served falls while this version was being served, with ten minutes’ grace). |
status |
current — the version served now; superseded, withdrawn, deleted — when it stopped; pulled — MasterDB took it out of serving for review. |
business |
The business’s uuid, legal name and certificate today (status, since when, statement). Nothing on how the business was verified. |
version |
Its generation, sealed_at, published_at, ended_at and the certificate its seal named. |
checks |
cert: matches / differs / not_given; served_at: within / outside / not_given. |
endpoints |
For a Business & Brand file served now: its authorised-endpoints section as MasterDB stands behind it today — live, or suspended with when and why — and when control of each domain was last confirmed. |
source_line |
The line as MasterDB writes it for these facts, when served_at was given. |
An unknown id and a hash that does not match answer the same 404, so the page is no oracle for which records exist. The page does not re-check the seal: POST /v1/verify with the record’s bytes and its seal does that.
What it does not claim
Section titled “What it does not claim”The line proves where a record came from and when it was served. It cannot prove your answer was faithful to the record — that is why the line points at the record, so a reader can compare. A superseded record’s line still verifies as valid then; to say “current”, fetch again. How fresh the business expects a record of its type to be is on the row as freshness_expectation (see Search).
Versioning
Section titled “Versioning”A change to the members, their order or the URL is mdb-source/2, never an edit to version 1: lines already cited keep verifying.