Governed vocabulary

“Customer count” can mean two things in two reports.

Marketing counts trials; finance counts paying accounts. A field name cannot resolve that disagreement. A reviewable contract gives agents and reviewers the term, its owner, and the evidence it is expected to have.

The review: A release changes the order model and may affect “monthly active customers.” The reviewer needs its governed subject, owner, and evidence expectation—not an agent’s guess based on a column name.

Keep the definition where it can be reviewed

Write the term as a versioned contract

Keep version-1 dbcli.contracts.json beside the semantic file. Each contract has a canonical name, a model:, field:, relationship:, or metric: subject, and a draft, approved, or deprecated status.

Validate before an agent sees the definition

Fix an invalid artifact before treating it as context. Once valid, approved contracts can be inspected or searched, so “customer” has a source rather than an interpretation.

dbcli contract validate --format json
dbcli contract context --format json
dbcli contract search customer --format json

Check the definition before the change

An evidence policy is none, receipt-required, or verification-required. Run drift before changing the design. Stale or inconsistent local semantic evidence becomes a review item, rather than being silently ignored, and a malformed artifact is reported as invalid rather than stale.

dbcli contract drift --format json