Observe value relations with their intended tail during derivation

[antejavor]

Moved out of map #344 when that map closes with PR #373 (see the comment below): derivation continues with the evolution-loop work.

Question

Do relations into core value types survive derivation when observe constrains them to their intended value-type tail? #372 found both seeds lose 25:50: under the permissive pass the value relations never fire into a value, so prune drops them.

What to build (prototype branch)

• In derive_batched.py's observe schema, give a relation whose intended_tail is a core value type (Duration, Quantity, Money, Date, TimeWindow) that tail. The head stays permissive. Every other relation is unchanged.
• Re-observe only those relations, reusing S1/S2's cached proposals, then prune and read again.
• Shard observe across processes. It is single-core today, and 3.7 h per derivation.

Acceptance

• 25:50 lands in a user→Duration relation in both seeds.
• No regression on the Place/MoMA read.
• Note, but don't gate on, S2's missing education domain; it needs its own decision.

[antejavor]

Result: fixed at observe, but 25:50 is still lost, now to entity typing. Not accepted.

Evidence is on the prototype branch: derive_value_observe.py, derive_value_observe.log, read_386.log, derivation/S{1,2}V.json.

Observe works. Constraining the value relations' tails, the relations now fire into values:

	S1V	S2V
value relations re-observed	18	12
kept by prune (was 0 into values)	7	9

For example, event_duration fired 354 times into values and has_duration 374. Sharded over 4 processes, observe took 8–9 min against #372's 3.7 h. Prune cost $0.36–0.44.

The answer still misses, for a different reason: the span isn't typed Duration.

vocabulary	how 25:50 is typed	edge
hand (13 types)	Duration	personal_best(user → 25:50)
S1V (17 types)	not extracted at all	none
S2V (19 types)	Food	cooks_food(user → 25:50)

S1's candidate relation improved_personal_best_by fired into Duration only on noise (user → data analysis skills), so prune dropped it. That again traces to Duration typing, not to the relation.

This is #361's "adding types taxes the others", at entity level: in a larger derived vocabulary the core value types lose spans to domain types. Everything else holds: Place/MoMA visited is recovered in both seeds, there are no tense pairs, and stability is 84%.

Left open for a decision on the typing problem. Candidates:

• cap the number of derived domain types;
• per-type thresholds for the core value types;
• sharper value-type descriptions;
• a separate value-only extraction pass.

[antejavor]

Moved out of map #344, which closes with PR #373. #344's destination was the typed relation model implemented on a hand-written vocabulary. Deriving that vocabulary (LlmRecommendationStrategy) is its own track, and this ticket's open question goes with it: in larger derived vocabularies the core value types lose spans to domain types. It fits the evolution-loop map, or a derivation map, when that work resumes. The hybrid-retrieval map doesn't depend on it, since it measures on the hand vocabulary.

[antejavor]

Resolution: a separate value-only pass. Accepted.

Decision. The core value types (Duration, Quantity, Money, Date, TimeWindow) get their own GLiNER2 pass. It holds those types, the model's relations into values, and the head types of those relations. A value span from this pass wins over the main pass's typing wherever the two overlap. Main-pass edges with an endpoint on such a span drop unless they already typed it as that value. The pass runs both at observe (derivation) and at extraction, so the core types never compete with the derived domain types, however large the active vocabulary grows under the cap of about 40 types.

Rejected: per-type thresholds (a post-filter can't recover a span already typed as something else), sharper descriptions (still a contest between labels in one pass, which weakens with every added type), and capping the domain types (contradicts the aggregation decision's cap).

Evidence: read_value_pass.py and read_value_pass.log on prototype/gliner2-constrained-edges (c07155a). Same 10 evidence sessions; the hand-arm guard reproduced 895 edges.

	S1V	S2V
25:50 typed	Duration (was not extracted)	Duration (was Food)
main mentions overridden / edges dropped / value edges added	15 / 12 / 156	22 / 21 / 260
wrong cooks_food(user → 25:50)	none	dropped
Place/MoMA visited	held	held

What's left, and why it isn't this ticket. No edge lands on 25:50, because neither derived vocabulary keeps a relation for a personal best:

• S1 proposed improved_personal_best_by and race_finish_time from the one propose-sample session that mentions one.
• The 60-session observe sample has no instance, so prune correctly dropped them.
• S2 never proposed one.

This comes from the held-out evaluation design, which excludes the evidence sessions from every derivation sample. Under the schedule decision, each derivation run reads the user's own delta, so the session that states a fact is in the observed data.

For the build: the value pass belongs in the extraction backend (one extra pass, with a small schema) and in derive's observe step. Merge by span overlap, with value spans winning.