In a case repository shared by several teams, how do you decide which selectors become controlled attribute fields with a fixed vocabulary and which stay free labels anyone can invent?

## The decision is a schema decision, not a tagging preference In a repository one team owns, this barely matters — conventions hold because everyone can see each other. In a shared repository it becomes the governing decision about the whole case inventory, because a controlled attribute field is imposed on **every** case, including the cases of teams who were not in the room. That asymmetry is the heart of it: labels are locally cheap and globally weak; fields are globally strong and locally expensive. ## Three tests, applied in order **1. Completeness.** Ask what consumes the selector, and whether the consumer needs *all* matching cases or merely *some*. A release gate, a coverage claim, an audit list — these are broken by a partial set, and only a mandatory controlled field can promise completeness. A maintenance sweep, a working list, a reminder to revisit something — these are fine with whatever the query happens to catch. If nobody will ever assert completeness over the selector, it does not need a field, and adding one buys nothing but ceremony. **2. Stability.** Will this dimension still mean the same thing in a year? Product components and check types generally will. A migration name, a sprint identifier, a code name for an in-flight redesign will not — and a controlled field whose values must be added every fortnight has all the cost of governance and none of the benefit, because the vocabulary is churning anyway. **3. Universality.** Can every case in the repository answer the question, including cases owned by teams with a different shape of work? If a proposed field only makes sense for one team's cases, the rest of the repository will answer it with a catch-all value that means *not applicable*, and a field where most rows say *not applicable* is noise in every authoring form forever. A selector passing all three is a field. Failing any one of them, it is a label — or, more often, a label for now. ## What each choice actually costs | | Controlled field | Free label | |---|---|---| | Cost at authoring | every case, every time, forever | only when someone chooses to | | Cost to introduce | definition, agreement, backfill of existing cases | none | | Cost to retire | a migration and a conversation | delete the value, mostly | | Failure mode | form fatigue; authors pick the first value to escape | forked spellings; incomplete sets | | Who pays | everybody | the team that wanted it | The row that gets underestimated is **form fatigue**. Every mandatory field is another obstacle between an author and a saved case, and past a small number people stop answering honestly. They pick whatever is first in the list. That is strictly worse than an empty field, because an empty field is visibly empty while a wrong value looks like data and passes every completeness check you build. ## A workable operating model 1. **Start everything as a label.** It costs nothing and it is reversible. Let the team that wants it use it. 2. **Watch which labels persist.** A label that survives two or three releases, spreads beyond the team that invented it, and starts appearing in queries other people rely on has demonstrated demand that no design meeting could have predicted. 3. **Promote on evidence, not on proposal.** When a persistent label starts being treated as complete — when somebody builds a gate on it — that is the moment it must become a field, because that is the moment its incompleteness starts to cost something. 4. **Backfill as part of the promotion.** A new mandatory field constrains only new and edited cases. Until the existing inventory is populated, the field is a label wearing a uniform, and queries on it are exactly as partial as before. 5. **Retire deliberately.** Fields and labels both accumulate. Someone must be able to say a dimension is dead, merge its forked spellings, and remove it. Without that role the schema only grows. ## Where the judgment actually lies The tempting failure is to promote everything useful — the reasoning sounds impeccable at every individual step, and the result is an authoring form nobody fills honestly. The opposite failure is to govern nothing, and then discover that the release gate everyone trusts is built on a typed label three teams never heard of. The defensible position is a **small, mandatory, universal core** — component, type, priority, owner is a reasonable default core and covers most selection people actually do — plus a permissive, churning tail of labels, with a named owner for the vocabulary who can promote, merge and retire. And one standing rule worth stating out loud: **no gate, no coverage claim and no release decision may depend on a free label.** If somebody wants to build one, that is the promotion trigger, and the conversation happens then rather than after the escape.