Your Bug Reports Do Not Say Which Fields Were Measured and Which Were Typed

Two tickets arrive. Both have an Environment field. Both say Chrome 141, macOS.

One of them was read off the browser by a script. The other was typed by a person recalling what they think they use. In your tracker they are the same eleven characters, in the same field, in the same font.

You are going to trust them equally. One of them does not deserve it.

Typed values fail in a specific direction

If typed fields were merely noisy, this would not matter much: sometimes right, sometimes wrong, average out over enough tickets.

They are not noisy. They are wrong in a systematic way, and the bias runs exactly opposite to what you need.

• People report the browser they chose, which on an iPhone is not the browser that rendered the page, because every iOS browser is WebKit underneath.
• People report "latest", which is a statement about their intentions rather than their build. Chrome had three live major versions in one week this month.
• People report the time by looking at the clock that is wrong, which is the same clock that produced the timestamp you are trying to match against your logs.

In each case the person is being careful and truthful, and the answer is still wrong. Worse, the answer is most wrong precisely in the cases where the field would have been decisive. A correctly typed "Chrome 141" tells you nothing you needed; an incorrectly typed one costs you the afternoon.

Provenance is part of the value

The fix is not more fields or better form copy. It is that a value and how you got it are one piece of information, and splitting them throws half away.

{
  "browser":  { "value": "Chrome 141.0.7390.55", "source": "measured" },
  "os":       { "value": "macOS 15.6",           "source": "measured" },
  "steps":    { "value": "...",                   "source": "stated" },
  "started":  { "value": "2026-09-22T13:05:00Z",  "source": "stated" }
}

Four fields, and a reader now knows which two to argue with. Nothing about the values changed. What changed is that the ticket stopped presenting a guess and a reading as the same kind of thing.

I did not come up with that framing. A reader named Sven Andreas put it in a comment on an earlier post here, describing an open-source reporting client he is building: it reads the values the project declares, shows each one to the reporter before sending, and labels it as measured rather than typed. That last clause is the part worth stealing. Collecting automatically is common. Saying so in the artefact is not.

The measurement you get for free afterwards

Once the two are distinguishable, you can compare them, and the comparison is the useful bit.

Ask for the browser and measure it. Then count how often they disagree. If the typed answer matches the measured one 95% of the time, stop asking, the question is noise in your form. If it matches 60% of the time, you have just learned that the field has been quietly poisoning triage for years, and roughly how much.

You cannot run that comparison on a form that merges them into one box, which most forms do, including the default one in most trackers.

The cheap version

You do not need a schema change to start.

Keep them as two fields, not one. "Browser (detected)" and "Browser (as reported)". Let them disagree on the ticket rather than resolving the disagreement in the form, which is the moment the information is destroyed. Whoever picks the ticket up can see both, and the gap between them is often the fastest read on the whole report: a person who believes they are on Safari 26 while the string says 27.0 has just told you what kind of week you are having.

And for the fields that can only ever be stated, steps, expectations, what they were trying to do, mark them as such and stop apologising for them. A stated field is not a worse field. It is a different kind of claim, and the only failure is presenting it as the other kind.

The unlabelled ticket is the one that costs you, because it asks you to trust everything on it equally, and you will.