Main idea

A product glossary defines words one at a time: "order", "invoice", "customer". Each entry can be correct, and the whole teaches you almost nothing about what the software does. An order described on its own stays a label. That same order placed by a customer, containing lines, invoiced in an invoice, describes a product — because the verbs carry what the business allows and forbids.

A reference model that names its links is thereby distinct from the three artifacts that already existed around the product: the glossary, which defines without connecting; the database schema, which connects tables according to technical constraints rather than business ones; the documentation, which tells a story for a human reader and exposes no queryable structure.

The operative constraint fits in one writing rule: no link is ever written "is linked to". Every link carries a verb and the cardinalities on both sides — an order is placed by exactly one customer, it contains at least one line.

Why it matters

This is what makes the description usable beyond reading. A named link can be checked, tested, contradicted; "is linked to" is never contradicted, so it proves nothing. It is also what lets an agent answer a question about behavior without opening the code: the answer sits in the path between two cards.

And it gives a stopping criterion for writing a card: as long as the links stay vague, the card is not written, even if every field is filled in.

Nuances and limits

The precise verb has a cost: it forces you to settle cases the definition left in shadow — is an automatically generated order placed by anyone? That cost is precisely what surfaces product questions, but it slows the first pass down.

And a network of correct links says nothing about its own completeness: a set of cards that only cite each other closes long before it has covered the product.

Open questions

• How far do the verbs themselves have to be standardized before two writers stop naming the same relation in two different ways?