runtime: let signal enter as geometry, not as prose about signal #141

2026-08-16T16:13:13Z

will.anderson commented

2026-08-16 16:13:13 +00:00

No ingest path could carry a vector — text was the mandatory entry medium, so any non-text modality had to be described in prose and the geometry we reasoned over was the geometry of the description, not of the signal.

Measured: POST /api/nodes accepted an emb field, returned 200 with a fresh id, and stored nothing (emb_dim=None, embedded=false).

Changes

engram_node_set_emb(id, hex, dim) attaches a vector to an existing node. Off-dimension vectors are stored but not indexed (the HNSW build loop already filters on emb_dim), so modality geometry is durable without perturbing the canonical index. Setting emb also makes the node ineligible for embed_backfill, so a realizer vector is never overwritten by a text-derived one.
Create response reports emb_set instead of being success-shaped regardless.
Node document always emits emb_dim and embedded — without which a genuine ingest drop and a mere reporting gap are indistinguishable. That gap is exactly what made this defect invisible.

Verified live (isolated port + data dir):

case	emb_dim	embedded
voice node (64-dim MFCC)	64	true
text-only control	0	false

Negative controls — malformed hex, length mismatch, dim<=0 — all reject with emb_set:0.

Known placement defect (deliberate, stated up front). This is at the consumer. Ingest is a language concern, not an engram feature — every el program touching any modality needs it. The vector also marshals as a hex string because el has no first-class geometry value, which reintroduces text as the transport medium one layer below the problem being fixed. The durable shape is geometry as an el value plus declarable realizers, after which the engram stops having an ingest concept at all. Landing this as the verified probe that proves the path.

No ingest path could carry a vector — text was the mandatory entry medium, so any non-text modality had to be described in prose and the geometry we reasoned over was the geometry of the *description*, not of the signal. Measured: `POST /api/nodes` accepted an `emb` field, returned 200 with a fresh id, and stored nothing (`emb_dim=None`, `embedded=false`). **Changes** - `engram_node_set_emb(id, hex, dim)` attaches a vector to an existing node. Off-dimension vectors are stored but not indexed (the HNSW build loop already filters on `emb_dim`), so modality geometry is durable without perturbing the canonical index. Setting `emb` also makes the node ineligible for `embed_backfill`, so a realizer vector is never overwritten by a text-derived one. - Create response reports `emb_set` instead of being success-shaped regardless. - Node document always emits `emb_dim` and `embedded` — without which a genuine ingest drop and a mere reporting gap are indistinguishable. That gap is exactly what made this defect invisible. **Verified live** (isolated port + data dir): | case | emb_dim | embedded | |---|---|---| | voice node (64-dim MFCC) | 64 | true | | text-only control | 0 | false | Negative controls — malformed hex, length mismatch, `dim<=0` — all reject with `emb_set:0`. **Known placement defect (deliberate, stated up front).** This is at the consumer. Ingest is a *language* concern, not an engram feature — every el program touching any modality needs it. The vector also marshals as a hex **string** because el has no first-class geometry value, which reintroduces text as the *transport* medium one layer below the problem being fixed. The durable shape is geometry as an el value plus declarable realizers, after which the engram stops having an ingest concept at all. Landing this as the verified probe that proves the path.

will.anderson added 1 commit 2026-08-16 16:13:15 +00:00

runtime: let signal enter as geometry, not as prose about signal

El SDK CI - dev / build-and-test (pull_request) Failing after 10m55s

Details

c79033b749

No ingest path could carry a vector. engram_node/_full/_layered take text
only, and a node acquired an embedding solely via engram_embed_backfill
DERIVING one from n->content. That made text the mandatory entry medium:
any non-text modality had to be described in prose first, so the geometry
we then reasoned over was the geometry OF THE DESCRIPTION, not of the
signal. Measured: POST /api/nodes accepted an "emb" field, returned 200
with a fresh id, and stored nothing — emb_dim=None, embedded=false.

engram_node_set_emb attaches a vector to an existing node. Off-dimension
vectors are stored but not indexed (the HNSW build loop already filters on
emb_dim), so modality geometry is durable and addressable without
perturbing the canonical index. Setting emb also makes the node ineligible
for embed_backfill, so a realizer's vector is never overwritten by a
text-derived one.

Two reporting fixes ride along, because both are how the drop stayed
invisible: the create response now reports emb_set instead of being
success-shaped regardless, and the node document now always emits emb_dim
and embedded — without which a genuine ingest drop and a mere reporting
gap are indistinguishable.

Verified live: voice node emb_dim=64 embedded=true; text control emb_dim=0
embedded=false; malformed hex, length mismatch and dim<=0 all reject.

KNOWN PLACEMENT DEFECT: this is at the consumer. Ingest is a language
concern, not an engram feature — every el program touching any modality
needs it. The vector also marshals as a hex STRING because el has no
first-class geometry value, which reintroduces text as the transport
medium one layer below the problem being fixed. The durable shape is
geometry as an el value plus declarable realizers, after which the engram
stops having an ingest concept at all. Landing this as the verified probe
that proves the path.

will.anderson merged commit b5b96c05ed into dev

2026-08-16 16:13:30 +00:00

will.anderson referenced this pull request

2026-08-16 16:33:03 +00:00

runtime: publish the vector index instead of guarding it #143

will.anderson referenced this issue from a commit

2026-08-16 16:38:13 +00:00

runtime: transduction is a language concern, so move it into the language

will.anderson referenced this pull request

2026-08-16 16:39:06 +00:00

runtime: transduction is a language concern, so move it into the language #144

will.anderson referenced this issue from a commit