Short-Term Memory: Holding the Present
For new readers
This page documents one component of the self-model reference implementation, a working PatLang system that models cognitive processes for study. Short Term is deliberately the simplest component in the whole pipeline — no classification, no storage, no language model call — and that simplicity is itself the design point worth understanding.
What Short Term does
Short Term's required function, per the requirements specification's component table, is to hold "current, specific percept content." In the actual implementation that means something narrower and more mechanical: Short Term reads every percept Perception publishes and fans it out, unchanged, to four independent downstream topics — one each for Abstraction, Episodic Memory, Procedural Memory, and Representation. It performs no parsing, no classification, and (per Requirement 4.6) makes no language-model call at all — Short Term is not a language boundary; it is pure PatLang symbolic code.
Why four topics, not one shared topic
The implementation's own header comment in components/short_term.patlang is explicit about a real design mistake it avoids: a single shared topic won't do the fan-out job, because queue_consume on one topic hands a message to whichever consumer claims it first, and nobody else. If Abstraction, Episodic Memory, Procedural Memory, and Representation all read from one topic, each percept would go to exactly one of them, chosen by a race, rather than to all four. So short_term_fan_out republishes the same percept JSON onto four separate topics — short_term_abstraction, short_term_episodic, short_term_procedural, and short_term_representation — so each downstream reader gets its own independent copy of every percept.
The same header notes a second, related decision: Short Term reads Perception's own writer-topics using lib/topic_observer.patlang's non-consuming, cursor-tracked read rather than qh_claim_one/queue_ack. This was found necessary directly, not chosen up front — an ack-based claim on the percept topics raced Reason/Plan for the same messages, since every Reason/Plan instance also independently reads the same percept topics (Requirement 4.1's parallel-drafts model), and Short Term would silently lose some percepts whenever Reason/Plan won the race first.
Reading from multiple Perception instances
Short Term is started with a comma-separated list of Perception instance ids (st_source_topics splits this and builds one writer-topic per id via queue_writer_topic("percept", id)), reflecting that Perception itself runs as multiple competing instances under Requirement 4.1's parallel-drafts model — Short Term has to watch all of them, not just one, to see everything that gets perceived.
Instrumentation and lifecycle
Short Term composes the same lib/component_base.patlang / lib/instrumentation.patlang pair every component in this project uses: it claims a signals port and announces itself via component_start, answers status queries through st_status_text (built on the shared instr_snapshot format, reporting the last percept it fanned out), and shuts down cleanly on quit. Its whole "cognitive" loop is short_term_tick: for each source topic, pull any new rows since the last check and fan each one out.
See also
Short Term sits directly between Perception and four downstream consumers: Episodic Memory, Procedural Memory, Abstraction, and Representation. See the architecture overview for the full data-flow diagram and safety and ethics for how trust-gating downstream depends on identity Short Term simply passes through unchanged.