Indexing and Querying

The Three Public Interfaces

Myria’s normal agent interaction surface is:

• append_event
• query_event_nodes
• query_references

Everything else exists to support or observe those flows.

Append Flow

append_event is deterministic.

The current implementation:

1. validates the event
2. normalizes participants
3. checks (channel, source_event_key) for idempotency when present
4. generates event_id
5. writes the event
6. evaluates the threshold trigger

If the unindexed tail reaches the configured threshold, Myria immediately starts a build.

Query Event Nodes

query_event_nodes is the simple read path.

It:

• reads matching raw events directly from the event log
• filters by participants, context, text query, topic-hint query, and internal visibility
• returns a rooted tree whose children are raw event nodes

No LLM is required.

Query References

query_references is the non-trivial read path.

It combines two lanes:

• snapshot lane Walk the visible TopicIndex forest in the active snapshot.
• fresh-tail lane Read events newer than the active snapshot cutoff.

The response is always one rooted multi-child tree. A shallow list is represented as a root with direct children. A hybrid result can mix leaf-topic branches and fresh event children under the same root.

Build Triggers

Builds start globally through exactly three paths:

• manual trigger
• inactivity timeout
• unindexed-tail threshold

When a build starts, Myria captures the current event_seq high-water mark. Only events at or below that cutoff enter the in-flight build. Newer events remain in the fresh tail.

Build Pipeline

The current build flow is:

1. load the active snapshot cutoff
2. capture a new cutoff
3. load the eligible event slice
4. partition events by exact participant set
5. build leaf groups
6. create leaf-topic nodes
7. create one internal root when a participant set has multiple leaves
8. validate the snapshot bundle
9. publish atomically

LLM vs Deterministic Control

Myria uses an internal LLM for two workflows:

• builder planning
• reference-tree walking

Deterministic Go code still owns:

• snapshot pinning
• participant masking
• SQL execution
• structural validation
• final tree assembly
• snapshot publish

Bounded Inspection

Both LLM workflows use bounded tools. The current system enforces limits on:

• subtree depth
• node count
• ref count
• payload bytes
• tool-call rounds

Raw event payloads are not part of structural inspection by default.

Deterministic Fallback

If an internal LLM workflow fails, Myria falls back to deterministic behavior:

• builder falls back to heuristic leaf grouping
• query_references falls back to a bounded deterministic reference tree

Fallback results are marked as degraded in the response metadata when applicable.