Ask a team why their Linear board has drifted and you will rarely hear “people forgot to fill in a field.” You hear that issues reached Done without an estimate, so the velocity chart is fiction. That work sat in Triage for three weeks because nobody set a priority. That half the In Progress column has no assignee, so standup is a round of is anyone on this?
Those are all field problems in the narrowest sense. But none of them is solved by making a field required.
The usual implementation is: mark a field mandatory, block issue creation until it is filled. That fails in both directions.
It is too strict at the start. Most issues begin as a sentence someone typed on their phone. Forcing an estimate, a priority, and a cycle at that moment means people either enter garbage to get past the form, or file the issue somewhere else entirely — a doc, a DM, their head.
And it is too lax later. An estimate matters when work is finishing, not when it is captured. A priority matters when the issue leaves Triage. An assignee matters when it enters In Progress. Requiredness is not a property of a field. It is a property of a field at a transition.
Look at what people write in their team handbooks, and almost none of it is a field constraint:
Every one of these is a trigger (a state boundary being crossed), a condition (something about the issue at that moment), and a consequence. That last clause is where most tools stop existing. A rule that only says no is a rule the team learns to route around.
When enforcement fires, three things have to happen or the rule becomes a nuisance:
The third point is the one teams underrate. Enforcement without a record is a policy you cannot evaluate. Six weeks in, the useful question is never “is the rule on?” It is “which rule fires most, and should it still exist?”
Worth being direct about a constraint here, because it shapes everything above: LineGuard works off Linear’s webhooks, which arrive after a change has been committed. It cannot stop a change from happening. It detects the change and reverses it, usually within a couple of seconds.
That sounds like a weakness and mostly isn’t. Prevention requires sitting in front of every write path — the UI, the API, the Slack integration, the git branch automation — and there is no such position in a modern tool. Correction only requires seeing the result. It covers every path, including the ones you forgot existed.
What it does mean is that there is a brief window where the invalid state is real, and that you should not use this — or anything built this way — as the sole safeguard where a few seconds of wrong state would cause actual harm. For workflow hygiene, a few seconds is nothing. For a payment approval gate, it is everything. Know which one you are building.
The failure mode for teams adopting this is writing fifteen rules on day one, drowning in reverts, and turning the whole thing off by Friday.
Pick the single constraint your team already agreed to in writing and already fails to follow. Usually it is estimates at Done. Turn on that one rule, for one team, and watch the audit log for two weeks. Either it stops firing — the process took — or it keeps firing, and you have learned something more useful than any retro would have told you.