Designing your data model from the vocabulary practitioners already use
A schema is a claim about which things in the world are different. Practitioners settled that argument long before you opened the editor, and they say the answer out loud.
The short answer: pull the domain nouns out of your corpus, keep the ones that get counted, modified or given a lifecycle, and let practitioner usage decide which distinctions are real. Words that take states are entities; words that only appear attached to something else are fields. The exercise takes an afternoon and prevents the migration that takes a quarter.
Schema design is usually treated as an engineering task performed after the product decisions are made. It is actually a modelling claim about the world: these two things are the same kind of thing, those two are not, this one belongs inside that one. Get a claim wrong and the product argues with its users forever, in small ways that never quite rise to a bug report.
The grammatical tells
Practitioner speech encodes structure more reliably than practitioner opinion does, because nobody is guarding it. Three patterns do most of the work.
| Pattern in speech | What it implies | Example shape |
|---|---|---|
| People count it | Entity, not attribute | “three of them open right now” |
| It has states | Lifecycle worth modelling explicitly | “draft, sent, accepted, expired” |
| It gets handed over | Ownership field and an audit trail | “then it goes to whoever is on rota” |
| It is always possessive | Field on the parent, not its own table | “the client’s reference” |
The handover tell is the one most often missed and it is the most expensive to retrofit. A thing that moves between people needs ownership, history and usually notification, none of which are cheap to add to a model designed as if it sat still.
If practitioners name three or more states for a thing, a boolean will not survive contact with the domain. The fourth state always exists — it is the one people handle by convention today, and it shows up in your database as a flag bolted onto the side within six months.
Reconciling synonyms without doubling the schema
Twenty creators will produce more than twenty terms. The reconciliation rule that works is majority-of-independent-sources: whichever word the most unrelated practitioners use becomes the canonical term, the rest become recorded synonyms, and the synonyms live in search, in help content and in your API aliases rather than in the schema.
Which word ends up canonical is also a product decision beyond the database, because it leaks into every label in the interface and eventually into the name of the product itself — the argument in naming a product from research vocabulary. The same synonym list is the correct seed for help content, per writing product docs from the questions people actually ask.
The expensive mistake is collapsing, not splitting
- ✗Two domain concepts merged because they share columns
- ✗Lifecycle flattened into a boolean
- ✗Vocabulary invented in the design doc
- ✗Relationships inferred from the happy path only
- ✓Distinctions kept where the domain keeps them
- ✓States enumerated from how people actually talk
- ✓Canonical term chosen by independent-source majority
- ✓Exceptions gathered before the schema is frozen
Splitting a table later is unpleasant but bounded. Merging two things the domain treats as different is unbounded, because every workflow built on top of the merge has to be unpicked, and users will have entered data that only makes sense under one interpretation.
The signal for a real distinction is behavioural rather than semantic: if people apply different rules, different approvers or different deadlines to two things, they are different things regardless of how similar the fields look. Those rule differences surface most clearly in recorded workflows — the reading in workflow mapping from day-in-the-life videos.
Exceptions belong in the model, not in the backlog
Practitioner content is full of edge cases stated casually: the client who gets billed differently, the job that skips a step, the region with its own rule. Each is a modelling decision deferred, and deferring them all produces a schema that is elegant for the demo and wrong for the third customer.
You do not have to support every exception in version one. You do have to decide whether the model can express it, because a model that structurally cannot represent a real case forces a rewrite rather than a feature. Where those exceptions are regulatory rather than operational, they are worth separating out deliberately — the reading in spotting compliance constraints in practitioner content.
Why this matters more with a coding agent, not less
An agent will produce a complete, plausible schema from a paragraph of prompt in under a minute. It cannot know that your domain treats two similar-looking records as categorically different, because that fact lives in practice rather than in the general corpus the model learned from.
The practical consequence is that the vocabulary and entity list belong in the context file rather than in your head. That is exactly what the domain section of a CLAUDE.md is for — see how to write a CLAUDE.md and, for the handoff shape, turning research notes into a coding-agent spec.
The model constrains the stack, not the other way round
Once the entities and their relationships come from the domain, several stack arguments settle themselves: whether you need real relational integrity, whether the workload is document-shaped, how much of the lifecycle needs history. Choosing infrastructure first and bending the domain to fit is the sequence that produces the awkward compromises.
Practitioner videos are also a decent source of stack evidence in their own right, as long as you discount for fashion — the caveats in choosing a tech stack from practitioner videos.
Start with the nouns, then mine the verbs
Nouns give you tables. Verbs give you everything harder: state transitions, permissions, notifications and audit requirements, all of which are more expensive to retrofit than a column.
Practitioner speech is dense with domain verbs that carry structure. Approve, reject, escalate, reopen, archive, assign, sign off, hand back — each one implies at least a state change and usually an actor, a permission and someone who wants to be told. A model built only from nouns will represent the things correctly and be unable to express what people do to them.
Two verb patterns deserve particular attention. Verbs that take a person as the object — hand to, assign to, escalate to — mean ownership is a first-class field rather than a convenience. Verbs that can be undone — reopen, unarchive, reverse — mean the state machine is not a one-way flow, and a schema that assumed it was will need history added later under pressure.
The reversal case is worth pushing on deliberately, because practitioners mention it casually and it changes the design substantially. Something that can move backwards through its lifecycle needs a record of the transitions rather than just a current state, and the moment anybody asks who changed it and when, you need the actor on each transition too.
Collecting verbs alongside nouns costs nothing extra during the same pass, and it is the difference between a schema that stores the domain and one that can actually run it.
What this costs
The vocabulary pass reuses the corpus you already gathered. As of September 2026, Hobby is $19 a month with 25 videos and 2 projects, Pro is $59 with 80 videos and 8 projects, and Studio is $199 with 250 videos, 20 projects and 3 seats, each with a 7-day free trial — see the pricing page.
Run a synthesis that extracts the entities, states and synonyms practitioners actually use, with the sources attached. 7-day free trial.
Closing thought
Users will forgive a plain interface. They will not stop noticing a product that insists two different things are the same thing, because they have to work around it every single day.
Frequently asked
Why derive a data model from video research rather than from first principles?
Because a schema is a bet about which things in the world are separate and which are the same, and practitioners have already settled that question through daily use. Modelling from first principles means guessing at distinctions the domain resolved years ago, and every wrong guess becomes a migration.
What am I looking for in the transcript?
Nouns that take modifiers, nouns people count, and nouns that have a lifecycle. If practitioners say open, closed, reopened about the same thing, it has states. If they say three of them, it is a countable entity rather than an attribute.
How do I know whether something is an entity or a field?
Ask whether it can exist independently and whether people ever refer to one without its parent. If a thing gets its own name, its own history, or is handed between people on its own, it is an entity. If it only ever appears as a property of something else, it is a field.
What if two practitioners use different words for the same thing?
That is normal and it is the reconciliation work. Pick the term the majority of independent sources use, record the synonyms, and expose the synonyms in search and documentation. The wrong response is to model both words as separate concepts, which silently doubles your schema.
Does this matter if I am prototyping with an AI coding agent?
More, not less. An agent will happily generate whatever schema your prompt implies, at speed, and a wrong model gets built out further in a day than it used to in a month. The vocabulary work is cheap insurance against fast wrong turns.
What is the most expensive modelling mistake in practice?
Collapsing two things practitioners treat as different, usually because they look similar in a database. The domain will keep insisting they are different through every support ticket, and separating them later touches every row you have.
What does this cost?
As of September 2026, Hobby is $19 a month for 25 videos and 2 projects, Pro is $59 for 80 videos and 8 projects, and Studio is $199 for 250 videos, 20 projects and 3 seats, with a 7-day free trial on every plan. The vocabulary pass runs over an existing corpus, so it is a synthesis rather than new sourcing.