Substrate class, backend, and artifact form are separate axes that get conflated

Type: note · Status: current · Tags: learning-theory

"Weights," "tips," and "repo artifacts" look like parallel terms, but they name things at three different levels. Weights names a substrate class — what kind of thing changes when the system learns. Tips names one artifact form within a substrate. Repo names a storage backend. Conflating the three makes the comparison space blurry: you end up arguing "tips vs weights" when the real contrast is between substrate classes, and treating "repo artifacts" as an umbrella when it is one backend choice.

The primary split is substrate class:

  • Subsymbolic substrate — the learned result lives in model parameters or other latent state. AgeMem and OpenClaw-RL are clean examples.
  • Symbolic artifact substrate — the learned result lives in discrete, inspectable symbolic objects. What those objects look like and where they are stored are separate decisions.

Backend: where symbolic artifacts live

Symbolic artifacts can live in different backends without changing substrate class — repo files, database rows, service-managed memory objects, graph stores, or vector stores with attached symbolic records and provenance. This is why "repo artifacts" is too narrow as the umbrella term. Repo-hosted markdown is one important backend, especially for commonplace, but it is not the whole symbolic artifact substrate. Cognee keeps symbolic units in a database-backed poly-store; the backend changed, the learned result is still symbolic and inspectable.

Artifact form: what symbolic artifacts look like

Within the symbolic artifact substrate, systems can produce many different artifact forms — tips, notes, reflections, rules, prompts, schemas, tests, playbooks, ranked memories. These differ in granularity, retrieval mode, and how directly they constrain later behavior, but they belong to one family: durable symbolic objects that can be inspected, revised, and composed.

Why the distinction matters

The three-level split prevents category mistakes that keep recurring in comparisons across this KB.

Files beat a database for agent-operated knowledge bases argues that a database schema forces premature commitment to access patterns — a claim about which backend to pick within the symbolic artifact substrate, not about whether to use symbolic artifacts at all. Separating the levels makes that scope visible: files can beat a database for a young KB without implying that all symbolic artifact learning must live in files.

The comparison between trajectory-informed memory generation and AgeMem sharpens the same way. The real contrast is not "tips vs weights" but symbolic artifact substrate vs subsymbolic substrate. "Tips" are just one artifact form on the symbolic side.

Deploy-time learning in Commonplace mostly operates through repo-hosted symbolic artifacts, but the repo is a backend choice. A different system could do deploy-time learning through a memory service or database and still remain in the same substrate class.

The taxonomy that falls out:

Learned result Substrate class Backend Artifact form
AgeMem memory policy Subsymbolic Model parameters Learned policy
Trajectory-informed memory Symbolic artifact Memory store / DB / files Tips
Commonplace constraining Symbolic artifact Repo Prompts, rules, schemas, tools, tests

At this level, substrate trade-offs become easier to state. Subsymbolic learning usually buys tighter optimization and gives up inspectability. Symbolic artifact learning usually buys inspectability, diffability, and composability, while depending more heavily on retrieval design, lifecycle management, and governance.

Relevant Notes: