Observed, Derived, Interpreted

"The user wrote football" is an observation. "The user likes football" is an invention. A taxonomy for what software is allowed to write down about you.

Date

/

Category

UI/UX

UI/UX

/

Writer

Keon Hwui Kim

Keon Hwui Kim

A conservator I once spoke to at a museum explained why they photograph an object before cleaning it, after cleaning it, and again after any intervention, and why the three photographs are stored separately with different labels rather than merged into a single "current" image.

The reason is not sentiment. It is that a future conservator needs to be able to tell what the object did on its own from what somebody did to it. Merge the records and that distinction is gone permanently, and no amount of subsequent care recovers it.

The most consequential design decision in JEFIELD is the software version of that rule, and it is invisible in the interface.

A page from Charles Lyell's field notebooks

Fig. 1. A page from Charles Lyell's notebooks. Field science solved this problem in the nineteenth century: observation and interpretation get different ink. University of Edinburgh Heritage Collections, CC BY 3.0, via Wikimedia Commons.

One word, and the border either side of it

Suppose you type the word football into JEFIELD.

The system is now permitted to record exactly one thing: the user wrote "football." That is an observation. It happened, it is timestamped, it is attributable, and it will still be true in ten years no matter what else changes.

The system is not permitted to record: the user likes football.

That second sentence is an inference. It might well be correct. It is probably correct often enough to be commercially useful. And the moment it enters the log it becomes indistinguishable from the first, because a log row has no typography. A future reader, human or machine, sees two facts of equal standing, and one of them was invented by a heuristic on a Tuesday.

The taxonomy

Class

Definition

Durability

Example

OBSERVED

It happened and there is a record of it happening

Permanent, immutable

A note was left at 14:02

DERIVED

Computed deterministically from observations

Disposable, recomputable

This is your ninth visit

INTERPRETED

Something decided what it means

Displayed, labelled, never stored as fact

This image appears to contain text

UNKNOWN

We do not have it

A complete answer, not a gap

Whether you ever read it again

Table 1. Only the first class is durable. The fourth is the one most systems refuse to say out loud.

The fourth class deserves more attention than it gets. Unknown is a legitimate, final, sufficient answer, and software almost never gives it. Asked something it cannot know, a system will estimate, default, or infer, and present the result in the same typeface as everything else. The willingness to render a blank is a design capability, not a failure of one.

Why this is architecture and not posture

It is easy to file this under privacy and move on. It is considerably bigger than privacy.

The entire universe of things JEFIELD observes is ten event kinds. That is the whole list:

world.created      session.opened     session.closed
cat.poked          cat.called         world.imported
world.claimed      identity.linked    note.left
note.forgotten

// plus, on every event:
//   id, origin, at, by, provenance
world.created      session.opened     session.closed
cat.poked          cat.called         world.imported
world.claimed      identity.linked    note.left
note.forgotten

// plus, on every event:
//   id, origin, at, by, provenance
world.created      session.opened     session.closed
cat.poked          cat.called         world.imported
world.claimed      identity.linked    note.left
note.forgotten

// plus, on every event:
//   id, origin, at, by, provenance

Everything else in the product is derived from those ten, or is unknown. Nothing else is written, ever.

The practical benefit of a surface that small is that I can answer the question can the system know X? honestly and immediately, every single time, rather than guessing or going to read code. Most products cannot answer that question about themselves at all, and the inability is not incompetence. It is that the set of things they record grew organically over years and nobody has held the whole of it in mind since about month four.

There is a second structural consequence that I care about more. When a machine reads a file and extracts text from it, that extraction is written beside the bytes, in a disposable cache, never into the log. Which makes this literally true:

Capture succeeds independently of understanding.

The moment the bytes are secured, the record is written. If the reader fails, if the format is unknown, if the file is truncated or corrupt or in a format invented last week, the thing is still kept. Understanding is allowed to fail. Keeping is not. The function that produces understanding returns an empty string on failure and the trace is written regardless.

Compare the ordinary architecture, where a file is processed on ingest and the processing result is the record. In that design a parser failure is a data loss, and the person finds out about it much later.

The two syllables that took a week to agree on

There is a copy decision in JEFIELD that consumed an absurd amount of argument and that I now think is one of the better things in the product.

When you copy the text a machine read out of a screenshot, the button does not say 글 복사 (copy text). It says 읽은 글 복사, which means copy the text that was read.

Two extra syllables, carrying the entire distinction. What you are about to paste is not the text of the image. It is what a machine believed the text of the image was. If it turns out to be wrong, the label already told you where to look, before you had a problem.

Most interfaces flatten this. They show an OCR result as though it were content, a summary as though it were the document, an automatic tag as though you had chosen it. The flattening is nearly always unintentional. Nobody sits down to mislead. The effect, though, is that the user cannot tell which of the things on screen would survive being checked, and so learns to check nothing.

A test you can run on anything

Pick any piece of information a product shows you about yourself, and ask which of the four words it belongs to.

  • A streak count is derived, and usually honest.

  • A "top artist of the year" is derived, though the ranking function is interpreted and undisclosed.

  • A suggested tag is interpreted, presented as observed.

  • A "because you watched" is interpreted twice over, and the second interpretation is about your motives.

  • A "people like you" is an inference about a population, applied to you, rendered as a fact about you.

Most products cannot answer the question. Many have never been asked it internally. And a surprising amount of what feels uncanny about contemporary software is simply an interpreted thing wearing the typography of an observed one.

The rule in its shortest form

Old is not deleted. Superseded is not forgotten. Derived is not observed. And a guess, however good, however useful, however statistically well supported, is not a fact about you.

The conservator's three photographs cost more to store than one merged image, and they are the reason the object can still be understood in fifty years. The cost is always paid up front, and the benefit always arrives later, to somebody else. That is what makes it a discipline rather than a feature.

Sources

  • A page from Charles Lyell's notebooks. University of Edinburgh Heritage Collections, CC BY 3.0, via Wikimedia Commons. commons.wikimedia.org/wiki/File:C_Lyell_notebook_page_1.jpg

Related reading

More from the Moc Mallen Studio journal