value metrics — combinable, processable per the configured worldview

[matt-beanland]

Description

Once the qualification queries (#38, #39) produce the feasible set — what shelves can serve, what installers can come — we need each option in that set to carry metrics of value, and the framework needs to combine and process those metrics according to the configured worldview.

Without this, the choreography stops at feasibility. With it, the parties can yarn meaningfully about which of the feasible options is best for them, and the team can yarn about which is best for the whole — both grounded in named, declared, observable metrics rather than hidden assumptions.

The dimensions of value

Each feasible option carries multiple metrics. Some examples drawn from the qualification stories:

• Cost — install fee, monthly recurring, equipment, truck-roll.
• Time — earliest available install date, time to repair, network response latency.
• Distance — physical distance customer↔shelf, installer↔customer, etc.
• Quality — uptime history, mean-time-to-repair, customer satisfaction scores.
• Capacity — port utilisation, headroom, load on the path.
• Fairness-ledger position — what each party has given/taken with the team recently (the "taking one for the team" mechanic).
• Environmental — energy use, equipment lifecycle impact.
• Plan alignment — does this choice support future upgrades, or paint into a corner.

Different worldviews care about different subsets, with different weights, combined in different ways.

What we'd find useful

Two layers:

Metrics as declared, brought-up characteristics. Each option in the feasible set exposes its value metrics as live characteristic values (per the #10 / #32 bring-up pattern). A shelf's serve-this-customer option brings up its cost, distance, capacity headroom, etc. An installer's come-at-this-time option brings up their travel cost, slot conflict score, technology-match quality. Metrics are derived, not stored — current at read time.

Combination machinery that honours the worldview. Preferences declared in the DSL (per the transformers introspecting preference direction) describe how to combine metrics — weighted sums, lexicographic ordering, Pareto frontiers, soft constraints, harder gates. The framework processes the feasible set against the declared combination, producing a ranking (or a Pareto set, or a recommendation, depending on what the worldview asks for).

# sketch — actual DSL shape is for the framework to settle
preferences :customer_centric do
  weight :distance, 0.4
  weight :cost, 0.4
  weight :install_time, 0.2
  honour :technology_preference, lexicographic: :first
end

preferences :network_balanced do
  weight :capacity_headroom, 0.5
  weight :plan_alignment, 0.3
  weight :cost, 0.2
end

Both worldviews score the same feasible set differently. Swapping worldview swaps best.

Why it matters

Metrics-as-numbers-on-options is the substrate the preference / worldview / fairness machinery operates on. Without declared, comparable, combinable metrics, the "configured worldview shapes best" dream collapses to ad-hoc imperative logic in every consumer. With it, the choreography becomes:

1. Qualification produces feasible options (#38, #39).
2. Each option brings up its value metrics (live, derived, observable).
3. The introspected worldview combines metrics into a score (or a Pareto set).
4. Parties yarn over the result, ledger updates, agency preserved.

It also makes the system honest about value. You can read the metrics being computed and the combination rules being applied. You can swap worldview and watch the recommendation reshape. You can audit why a choice was made because the math is declared.

A possible direction

Spike on a shape for metric characteristics:

• A metric DSL section (or extension) where Instance and Party resources declare which value metrics they expose, with type and unit (decimal, integer, score-out-of-100, monetary, distance, time-interval).
• Metrics live as live calculations — derived from the graph at read time, not stored attributes (mirrors #10, #32).
• A separate preferences DSL (or whatever the upstream reasoning/valuing framework provides) declares how to combine metrics into a score or ranking under a named worldview.
• A query primitive that takes a feasible set + a worldview and returns ranked options.

The Access domain is the natural first ground — shelf serve-cost / distance / capacity-headroom for the network-side, installer travel-cost / slot-conflict / technology-match for the field-side. Once it works there, NBN inherits naturally.

Related:

• #3 — persistent expectations might themselves carry value (the team-cost of an unmet expectation).
• #38, #39 — the feasibility queries that produce the set this operates over.
• Upstream — the reasoning/valuing framework that diffo will eventually inherit; this issue is about the substrate that framework lands on.