v. Infrastructure & Platforms

SILT

Memory Across Time

A Neural Child instance under a different research configuration, run to separate what the architecture produces from what one particular run produced.

Active Python file-based memory

What it does

SILT is Neural Child under a renamed, reconfigured instance. Same five-network architecture, emotional memory, object permanence, pattern recognition, movement prediction and an integration layer, with different configuration and a separate memory tree.

The reason to run a second instance is methodological. A developmental system with file-based memory and a randomized lifespan produces a history, and a history from a single run is an anecdote. Two instances under different configurations make it possible to say which behaviors belong to the architecture.

In the code

Memory is a directory, which is why a run can be audited
instance/silt/
  config.json          # the configuration this instance was run under
  lifespan.seed        # randomized at init, fixed for the run
  memory/emotional/    # one file per retained affective association
  memory/objects/      # conceptual continuity across context breaks
  memory/patterns/
  journal/             # what the instance recorded, in order

Illustrative shape. Because the memory is files rather than a context window, two instances can be diffed after the fact, which is the whole reason to run a second one.

How this differs from the ordinary version

Memory is files, so a run leaves a record

Because memories persist as actual files rather than as a context window, an instance can be inspected after the fact and compared against another. That is what makes a second instance worth the cost.

In the field

What this is not

It is not a product and not a deployment. It is a control condition for a research question about whether developmental behavior is a property of the architecture or of one lucky run.

Questions

How is SILT different from Neural Child?
Same architecture, different configuration and a separate memory tree. It exists so that behaviors can be attributed to the architecture rather than to one run.