VSABrains

How VSABrains Works

A plain-language walkthrough for readers with high-school science background. No ML jargon required.

Quick mental model

Think of VSABrains as a group of small witnesses (columns) walking across a shared grid. Each witness writes tiny notes into the cells it visits. Later, you can ask questions and retrace where the witnesses were.

  • Column = a small, independent “witness” with its own map.
  • Grid map = a 2D notebook where locations hold recent tokens.
  • Cell = a box in the notebook storing top-K token IDs.
  • Trajectory = the path a column takes over time.

One step of ingestion (what happens per event)

  1. Normalize the event. Convert text or structured input into tokens.
  2. Write tokens. Each column writes the token IDs into its current cell.
  3. Update indexes. Token → location mappings are recorded for fast lookup.
  4. Move. A deterministic displacement moves the column to a new location.
  5. Save a trace. The step is stored in the episodic stream for replay.

The key idea: order is stored as location. “When” becomes “where.”

A tiny example (2 steps)

  1. Step 1: “Alice enters room_A.” Tokens are written at the current cell.
  2. Move: The column shifts to a new cell based on those tokens.
  3. Step 2: “Bob picks up the key.” Tokens are written at the new cell.

After two steps, the grid contains two “addresses” that remember the order. Replay can walk those addresses back in time.

Frames: semantic lenses (optional but powerful)

Frames are extra semantic notes attached to events: emotion, theme, conflict, intent, and so on. They do not replace columns; they ride on top of the same events and make higher-level questions easier to answer.

  • A frame is a label like toneStyle or trustRelation.
  • Frames are defined by a small “CNL” profile (a constrained natural language list).
  • Frames track counts, relations, and trends over time.

Example: “Alice confesses to Bob” can add frames for dialogueAct, trustRelation, and toneStyle.

How a query works (retrieval + verification)

  1. Localize. Use a recent token window to find candidate locations.
  2. Replay. Rebuild state from the nearest checkpoint.
  3. Verify. Check consistency rules (alive/dead, conflicts, etc.).
  4. Answer. Return a statement with a verdict: supported, conflicting, or unsupported.

Why multiple columns?

A single witness can be wrong. Multiple witnesses allow disagreement and voting. Under noise or ambiguity, the system chooses the interpretation supported by most columns.

Where errors come from

  • Noise: the query window has corrupted tokens.
  • Ambiguity: different locations look similar.
  • Compression: heavy‑hitters keep only top‑K tokens per cell.

These errors are explicit and measurable, which is why the system can report conflicts.

What it does well vs. what it does not

  • Good at: fast localization, consistent replay, explicit conflict detection.
  • Not for: hallucinated answers, “magic” meaning from a single endpoint, or deep semantic reasoning without explicit frames.

Next steps

If you want more detail: