Propagate semantic series kinds from producer contracts through the graph #293

New Issue

2026-07-20T14:22:12+02:00

claude commented

2026-07-20 14:22:12 +02:00

Parked from the 2026-07-20 tap-drain design discussion on #283 — an architecture direction that is deliberately NOT needed there, filed so the trigger is named.

The idea

Semantic series kinds (bounded level in [-1,+1], R-multiple event sequence, price level, monotone counter, ...) originate at the producing node's contract and propagate through the graph, exactly the way scalar kinds already do: node signatures carry FieldSpec { name, kind: ScalarKind }, and composite boundary ports derive their kind from the interior producer instead of annotating it (crates/aura-engine/src/blueprint.rs:122-127, interior_slot_kind at blueprint.rs:138). A semantic kind would be a refinement layer over ScalarKind with a minimal propagation algebra: kinds originate only where a node contract fixes them (a strategy's bias output is a bounded level by contract; a RiskExecutor's net-R output is an R-sequence), structure-preserving nodes pass them through, semantics-destroying ops degrade honestly to plain f64 — never guessed. Metadata beside the hot path, propagated once at bootstrap, zero runtime cost.

A tap then carries nothing but its name and surfaces whatever the port already knows. Consumer-side annotation would be duplication that can lie; a producer-contract kind cannot drift from reality because it defines it.

Why it is NOT needed now

Each candidate consumer has a semantics-free path (established on #283, 2026-07-20):

Fold applicability checks (e.g. an expectancy fold applies only to an R-sequence): a guardrail against typo-class mistakes — the author of the subscription also authored the graph and knows what the tap emits. Guiding image from the discussion: a tap is a faucet — whoever turns the handle knows the water will come out warm; the water does not have to announce it.
Generic chart rendering: min/max envelope decimation is aliasing-safe for any series, and a per-tap y-scale is always correct (merely sometimes less pretty than a shared one). Unknown taps render safely as plain f64.
Live in-process consumers: specialized by construction; they know what they subscribed to.

reduce_for_tap (crates/aura-cli/src/main.rs:197), which infers decimation policy from the tap name (exposure), remains a tolerated convention shortcut for the wrap-convention taps — it is the ad-hoc reconstruction of exactly this information at the wrong end of the pipeline, and the smell that motivated the idea.

Trigger

Becomes worth building when a generic viewer must do better than the safe degradation for arbitrary declared taps without the author in the loop — e.g. shared y-scales across foreign taps, or semantic aggregation in the trace explorer, surfacing as a real requirement.

Parked from the 2026-07-20 tap-drain design discussion on #283 — an architecture direction that is deliberately NOT needed there, filed so the trigger is named. ## The idea Semantic series kinds (bounded level in [-1,+1], R-multiple event sequence, price level, monotone counter, ...) originate at the producing node's contract and propagate through the graph, exactly the way scalar kinds already do: node signatures carry `FieldSpec { name, kind: ScalarKind }`, and composite boundary ports *derive* their kind from the interior producer instead of annotating it (`crates/aura-engine/src/blueprint.rs:122-127`, `interior_slot_kind` at `blueprint.rs:138`). A semantic kind would be a refinement layer over `ScalarKind` with a minimal propagation algebra: kinds originate only where a node contract fixes them (a strategy's bias output is a bounded level by contract; a RiskExecutor's net-R output is an R-sequence), structure-preserving nodes pass them through, semantics-destroying ops degrade honestly to plain `f64` — never guessed. Metadata beside the hot path, propagated once at bootstrap, zero runtime cost. A tap then carries nothing but its name and surfaces whatever the port already knows. Consumer-side annotation would be duplication that can lie; a producer-contract kind cannot drift from reality because it defines it. ## Why it is NOT needed now Each candidate consumer has a semantics-free path (established on #283, 2026-07-20): - **Fold applicability checks** (e.g. an expectancy fold applies only to an R-sequence): a guardrail against typo-class mistakes — the author of the subscription also authored the graph and knows what the tap emits. Guiding image from the discussion: a tap is a faucet — whoever turns the handle knows the water will come out warm; the water does not have to announce it. - **Generic chart rendering**: min/max envelope decimation is aliasing-safe for *any* series, and a per-tap y-scale is always correct (merely sometimes less pretty than a shared one). Unknown taps render safely as plain `f64`. - **Live in-process consumers**: specialized by construction; they know what they subscribed to. `reduce_for_tap` (`crates/aura-cli/src/main.rs:197`), which infers decimation policy from the tap *name* (`exposure`), remains a tolerated convention shortcut for the wrap-convention taps — it is the ad-hoc reconstruction of exactly this information at the wrong end of the pipeline, and the smell that motivated the idea. ## Trigger Becomes worth building when a generic viewer must do better than the safe degradation for *arbitrary* declared taps without the author in the loop — e.g. shared y-scales across foreign taps, or semantic aggregation in the trace explorer, surfacing as a real requirement.

claude added the idea label 2026-07-20 14:22:12 +02:00

claude referenced this issue

2026-07-20 14:22:27 +02:00

Drain taps during the run — subscribers (stream-to-disk, fold, live consumer) replace buffer-then-drain #283

claude commented

2026-07-20 14:27:57 +02:00

Closed as mis-filed against the forward-queue discipline, 2026-07-20: the body demonstrates the absence of a need rather than a benefit — no concrete consumer of propagated semantic kinds exists today, and every candidate examined has a semantics-free path. A hypothetical trigger is not a queue item. The architectural rationale stays recorded on the originating discussion (the no-semantics refinement on the tap-drain issue); a future filing requires a demonstrated concrete consumer, not a named hypothesis.

Closed as mis-filed against the forward-queue discipline, 2026-07-20: the body demonstrates the absence of a need rather than a benefit — no concrete consumer of propagated semantic kinds exists today, and every candidate examined has a semantics-free path. A hypothetical trigger is not a queue item. The architectural rationale stays recorded on the originating discussion ([the no-semantics refinement on the tap-drain issue](issues/283#issuecomment-3927)); a future filing requires a demonstrated concrete consumer, not a named hypothesis.

claude closed this issue

2026-07-20 14:27:58 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Aura#293