answer with collapse function — return value with the explicit projection to inner worlds

[matt-beanland]

Description

When the framework answers a question, the answer should be available at two granularities:

1. A value — the answer pre-collapsed to the level the consumer asked for. Ready to use, no further work.
2. A rich value plus a collapse function to an inner world — the answer at its native richness, paired with the explicit, named projection the consumer can apply when they want the simpler view.

The consumer chooses when to spend the collapse. Same rich answer can collapse differently for different consumers — each picks the inner world they live in.

This is the IEEE 1164 conversion functions (To_X01Z, To_X01, To_StdLogic) made composable and consumer-driven. The conversion is explicit, named, returned alongside the value — so even the projection is honest about what's being lost.

Why it matters

It preserves the consumer's agency over resolution. Three concrete consequences:

• Lazy collapse. A consumer who doesn't need the simpler form never pays the projection cost. A consumer who needs it applies the collapse on demand.
• Multiple projections from one source. The same rich answer can be collapsed into Provider-world for one consumer, into the aspect family (see #41) for another, into TMF638 for a third. No need for the framework to pre-decide which world wins.
• Honest about loss. The collapse function being a thing returned alongside the value means the consumer can see — even at runtime — what projection is being applied. Hidden conversions in implicit casts are where wrong assumptions hide; explicit collapse functions surface them.

This matches the whole yarn we've been on about projections, collapse, agency over control. Worlds don't see across themselves except through named collapse functions; this is the runtime expression of that.

What we'd find useful

The answer-shape convention for queries that can produce values at multiple worlds:

# pre-collapsed
{:ok, %Aspect{value: :truthy, data: %{shelf: ...}}} = Access.serviceability(loc, :aspect)

# rich + collapse
{:ok, %Feasibility.Result{...rich...} = answer, collapse_to_aspect} =
  Access.serviceability(loc, :rich)

# consumer applies the collapse when they need it
%Aspect{value: :truthy} = collapse_to_aspect.(answer)

The collapse function itself is a value — first-class, passable, composable with other collapse functions. A consumer can hold multiple collapses (to_aspect, to_tmf638, to_provider) and pick at the boundary of their world.

A possible direction

The mechanism is general — any function that produces a richer answer can also expose its collapse functions. Convention candidates:

• A trailing arg granularity: :rich (or :simple, :tmf638, etc.) that controls what's returned.
• A two-tuple-by-default {value, collapsers} where collapsers is a map of named projection functions.
• A protocol that any rich-answer struct implements so Collapse.to(answer, :aspect) works generically.

The Access serviceability query from #38 is the natural first ground — its rich form carries shelf+technology+distance+headroom; its aspect collapse is :truthy/:falsey/:unknowny/(possibly :unattempted per TMF four-state — see the #38 reframing); its TMF638 collapse is the TMF service-qualification payload. One question, three projections, the consumer picks.

Related:

• #41 — the answer-shape family that collapse functions project into.
• #38, #39, #40 — the questions whose rich answers need collapses.
• diffo#169 — the typed-characteristic surfacing yarn; collapse is the mechanism that lets typed values reach Provider's view.