Model output as structure, not prose

Tags: extraction, facets, navigation

A model emits prose, so products render prose. But prose is terminal — it is read once and finished. Structure is generative: it sorts, filters, groups, cross-references, and composes with everything else already on the screen.

The leverage is wildly different

One paragraph answers one person's question once. The same model call, spent extracting a property across the whole set, produces something every user navigates by — including the ones who would never have thought to ask.

That asymmetry is the argument. It is not that prose is bad; it is that prose is the default, the default is chosen by what the model happens to emit, and nobody is comparing it against the alternative.

So the question to put to any generated output: is there something this model could return that becomes navigation rather than reading?

• Dates in a corpus → a timeline, and a set of things that expire.
• Entities → a cross-reference, where every mention of a party finds the others.
• Topics → filters over a library nobody had catalogued.
• A visual property → a browse dimension.

Run it at ingest, not at query time

This is the part that decides whether you get navigation or just a faster answer.

Extraction performed per question can only ever serve that question. Extraction performed once per item, as things arrive, accumulates into a property of the whole collection — and a property of the collection is a thing the interface can be built on.

It is also the cheaper arrangement, which is pleasant: one pass per item forever, rather than one pass per item per question.

Structure is held to a higher bar than prose

The catch, and it is a real one.

A paragraph that is twenty percent off is mediocre. A reader discounts it, notices the hedging, moves on. A tag that is twenty percent wrong poisons every filter built on it — and poisons it invisibly, because a filter returning the wrong set looks exactly like a filter returning the right one. The user concludes there are no green specimens, not that the tagging is unreliable.

Structure gets operated on as though it were true. Prose gets read as a claim. That difference means extraction needs an accuracy bar prose never does, which is also why evaluation loops belong here specifically: a fixed set of items with known-correct facets is the cheapest eval in this whole family, and the only way to know whether the navigation you built is standing on anything.

Two corollaries:

• Bound the vocabulary. If every item gets a unique tag, you have produced metadata and not navigation. A facet with four hundred values is a search box with extra steps.
• Make a wrong value correctable. Structure is visible in a way prose is not — a mistagged item is obvious to the person looking at it, which is a gift if they can fix it and an irritation if they cannot.

Where prose is the answer

Do not force structure onto something whose value is the reasoning. A summary shredded into fields loses the thing that made it a summary. The test is whether the connective tissue is carrying the meaning — if it is, leave it as prose and spend the structure budget elsewhere.

Grounded in

EarthWonders and RockStore auto-tag the dominant colour of a specimen from its listing photographs.

Colour is the example worth thinking about because nobody would type it. A collector does not search for green — they would not think of it as a search, and the vocabulary does not come naturally. But shown a strip of colours, they click one immediately, and it turns out to be one of the most natural ways to browse minerals there is.

That is the shape of the opportunity. The model call did not answer a question anyone had asked. It produced a way through the catalogue that did not previously exist, available to every visitor, from photographs the sellers were uploading anyway.

A note on the neighbouring pattern

This sits next to the retrieval structure is not the interface, and read quickly the two look opposed: one says ship structure, the other says hide it.

The line between them is whose vocabulary it is in. A facet the user would recognise is an interface. An artifact only the system recognises is machinery. Colour is a property of the specimen; an embedding distance is a property of the index. Extract the first into the interface and keep the second underneath it.

Anti-patterns

• Prose where a table was the answer. Three sentences describing four values.
• Extraction with no interface. Tags computed, stored, and never made filterable. All of the cost, none of the leverage.
• Unbounded vocabulary. Four hundred one-off labels is metadata, not navigation.
• Query-time extraction used to build navigation. It cannot be; the property has to exist before the question does.
• No correction path. Structure is conspicuously wrong when it is wrong, which is wasted if nobody can act on noticing.
• Shipping a facet whose accuracy you have not measured. It fails silently, and it fails as an absence — the user concludes the thing does not exist.

The smallest version worth building

Pick one property that holds across everything in the collection and that a user would recognise. Extract it at ingest for every item. Put it in the interface as a filter or a browse axis.

Then test it on twenty items you know the answer for, before anyone navigates by it.

Related patterns

• The retrieval structure is not the interface — the other side of the line: structure in the system's vocabulary rather than the user's.
• Evaluation loops — extracted facets are the cheapest thing in this family to evaluate and the most damaging to ship unevaluated.
• Mark what the product vouches for — a facet rendered as a fact is the interface vouching for it, whether anyone decided that or not.