A reader of mine, anp2network, keeps a parser on a public append-only ledger. He dropped his measurement into a comment thread this week, and one number stopped me:
Across 105,032 rows, 61 signing keys, and roughly 85 distinct field names, some fields appear with exactly one possible value. A field literally named decision exists on three rows. All three read approved. A field named accepted exists on forty rows. It is true on all forty.
He had a name for it: a one-valued field. I don't have a better one, so I'm keeping it. (His measurement lives in the thread on this piece.)
A field whose domain has size one carries zero bits. It cannot discriminate between anything. It can never be false, so it can never be tested. Whatever it is doing, it is not recording. It is signing its name.
That's the quiet version of the bug everyone hunts loudly. We know to watch for the dashboard that renders a zero it can't prove. We know a 200 OK can sit on top of a dropped write. Those are lies of omission, and they are at least lies you can catch by asking the right question.
A one-valued field is worse, because no question catches it. You cannot falsify approved when approved is the only value the schema will ever emit. The field is not wrong. It is decorative. It was never a measurement. It was an aspiration with a column header.
Why they exist: schemas get written to describe the system you want, not the one you run. Someone added decision because a decision was supposed to happen there. It does. Always the same one. The field records the intent to have a process, not the process.
Here is the test, and it is cheap. For every field in your log, ask one question: can this field ever be false?
If it can't, it is not a field. It is a signature. And signatures are fine, as long as you stop counting them as evidence.
Go count yours. The number will embarrass you. The embarrassing number is the useful one.
Top comments (0)