Plain-English picture of Loomworks today, grounded in the current-status manifest v0.41, the work that has happened beyond it, and the substrate state we now understand after the FORAY immersion arc. Examples where they help.
You said: "continued cleanup/development of the infrastructure is necessary if we are to get the Memory management to a satisfactory status." This document traces the connection — what infrastructure work serves Memory specifically, in what order, why.
A substrate that's substantially built. About 62 phases closed. Three repos in production-ready state. Engine (FastAPI/Python/PostgreSQL), Operator Layer (Next.js/TypeScript), Workshop (Next.js/TypeScript). The Loomworks engine runs on DUNIN7-M4 with a Cloudflare tunnel for browser-reachable testing. Nothing is deployed publicly — Loomworks works on the build machine.
Memory is what Loomworks is fundamentally for. Everything else exists to support Memory accumulating well. The infrastructure that supports Memory falls into four categories:
memory_events table. The actual event log where every Memory event lands. Columns: event_kind, object_type, the JSONB payload, plus FORAY-readiness columns (content_hash, attestation, foray_tx_ref) added in Phase 25 that were preparing for an integration that never happened in the anticipated form.
Typed MemoryObject subclasses. Phase 25 seed family + Phase 50/52/53/54/55 additions. Each is a typed shape with a Literal[...] object_type field. They give write-time validation and read-time clarity but most aren't registered in OBJECT_TYPE_REGISTRY (registration deferred per Phase 50/52 precedent until a downstream consumer needs typed deserialization).
The _ANCHOR_PRIORITY registry. Tags each event kind by importance ("critical", "high", "standard"). Currently feeds the _foray namespace injection into event payloads — wiring that supports a FORAY integration that hasn't happened.
Memory has multiple backings (per the resident-engagement investigation v0.2):
Specialists — typed agents that read Memory and produce typed outputs. Discovery-to-seed skill, induction skill, classifiers, voice-listening transcription, OCR, image vision, audio transcription. Each is a callable with a defined input and a defined Memory event written on completion.
Companion — the AI that mediates everything between Operator and substrate. Classifier (intent recognition) + Responder (turn composition) + voice composition for tier-drops, near-exhaustion, grant proposals, etc. The Companion is the instrument, not a party (per the FORAY immersion's AGENT-ID pattern — Operator is the principal).
The four-room methodology surface — Memory, Manifestation, Shaping, Rendering rooms in the Workshop frontend. Each room is a facet of the event log (per manifest §2's "rooms as facets of the event log" principle).
Engagement creation pathway — Discovery extraction, seed induction, conversational creation surface, terminal commit. Closed end-to-end through Phase 55.
Upload pathway — file/folder upload with extraction, classification, narration. Closed through Phases 58/59/60.
Credit substrate — token consumption, balance projection, tier resolution, multi-credit-type tier-drop, grant claim with referral chain. Solid foundation.
Voice listening — Web Speech API capture, silence-detect submit, navigation routing. Shipped 2026-05-18.
Authentication and identity — WebAuthn passkeys, Person/Membership/Operator/Contributor model (with Contributor concept being residual per the substrate review priorities).
Three sibling FORAY-shaped tables that pretend Loomworks needs an internal FORAY substrate:
credit.foray_action_flows — credit transactions in FORAY shapeaudit.foray_events — narrative events (setting changes) in FORAY shapememory_events Phase 25 readiness wiring — _foray_* columns + _ANCHOR_PRIORITY registry, populated on every memory eventThese are the cleanup targets from the substrate hygiene scoping note.
OVA-style authorization — not built; reserved space anticipated when Kaspa vProgs are ready.
Now the load-bearing point. Memory work depends on the infrastructure being in a state where Memory's own design choices can be made cleanly. Today the infrastructure has several pieces that confuse Memory's design space:
Memory's event log is memory_events. When you read what gets written to memory_events today, every event carries _foray_* metadata that serves a FORAY integration that doesn't exist. The semantics of "what is a Memory event" are mixed with "what does a FORAY anchor look like" in a way that obscures both.
When an assertion is committed, the memory_events row has the assertion's content_hash (a Memory concept — what was said), the _foray namespace (a FORAY concept — should this be anchored, at what priority, what attestation), and the foray_tx_ref column (also FORAY — the anchor reference if one exists, which it never does). The Memory designer trying to think about "what does Memory commit mean" has to mentally subtract the FORAY material to see Memory clearly.
What the cleanup gives Memory: memory_events becomes cleanly a Memory artifact. Events have their Memory-natural fields. FORAY readiness becomes a reserved code location, not a column on every Memory row.
The registry currently holds Phase 2/3/4/6/7/9/10/11/31/34/37 types. Phase 41+ types aren't registered. The "deferral until a downstream consumer needs it" reasoning made sense at each individual phase — but the accumulated pattern means typed Memory deserialization doesn't work for most newer event types.
If a Memory-reader specialist wants to deserialize a Phase 53 discovery_to_seed_extracted event into its typed shape, it can't — registry doesn't have the entry. The reader gets a generic MemoryObject instead. This works for write paths (where the typed shape validates before write) but breaks for read paths that want typed access.
What the cleanup gives Memory: the registry becomes complete and Memory's typed read paths become reliable. A downstream specialist can confidently say "I want to read every discovery_to_seed_extracted event in this engagement's Memory" and get typed objects.
Memory events carry triggered_by (who caused this event). Today the type system around "who" is unclear — Operator, Contributor, Companion (as instrument), specialist (as actor), system (for automated events). The Contributor concept is residual from earlier architecture.
When a Memory event is "an assertion was committed", the answer to "who committed it" is ideally clean — an Operator (the principal) via a Companion turn (instrument) acting on an assertion the Operator (or another contributor) had drafted. Today the type around this is muddied.
What the cleanup gives Memory: clean provenance semantics. Every Memory event answers "who" with a typed, consistent answer that supports the multi-Operator future without requiring more retrofitting.
Multiple key-value stores have accumulated across the codebase. Identifier patterns are heterogeneous (some events use UUIDs, some use stringified ints, some use custom identifiers). These don't break Memory but they make Memory queries less consistent than they should be.
Asking "show me every Memory event for engagement X with content_hash matching Y" is a different query than asking "show me every assertion in engagement X" today because the underlying patterns differ. A clean identifier scheme makes Memory queries uniform.
Several Memory operations are async-friendly — extraction, indexing, future Memory-stewardship work (duplicate detection, near-duplicate detection, drift-over-time staleness). A proper job table foundation supports these cleanly.
When Memory stewardship eventually runs (a Companion-driven sweep that identifies near-duplicates and prompts the Operator to consolidate), it'll want a job-table-shaped persistence model so the Operator can see what's running, what's queued, what's failed. The current substrate doesn't have this base.
You said: "If we get memory right, everything else will work."
The substrate review's five non-FORAY priorities (DB boundary, Contributor retirement, KV unification, identifier scheme, job table base) plus the FORAY-tables-cleanup (the substrate hygiene scoping note's scope) together form the infrastructure foundation that Memory work depends on.
Not all of these need to land before any Memory work can begin. But the ones that touch Memory directly — the FORAY-tables cleanup, the OBJECT_TYPE_REGISTRY completion, the Contributor retirement — should land first because they affect how Memory is shaped at the substrate level.
The ones that touch Memory indirectly — KV unification, identifier scheme, job table base — can land alongside or after early Memory work, because they affect Memory's environment rather than Memory's shape.
Once Phase A is done, Memory can be approached deliberately. The shape of that work depends on what the cleanup surfaces — but candidates include:
A few clarifications to keep this assessment honest:
1. Does the Phase A / Phase B / Phase C ordering match how you'd sequence the work? The "must precede core Memory work" claim for the three Phase A items rests on the connections I drew (event-log integrity, typed Memory deserialization, provenance semantics). If those connections don't land for you, the ordering is wrong.
2. Is anything missing from the infrastructure picture? I worked from the current-status manifest v0.41 and the project knowledge I could see. If there are pieces of infrastructure you've been tracking that I haven't named, surface them — they probably belong in Phase A or Phase B.
3. Is the Memory work in Phase C close to what you have in mind? I named four candidates (stewardship, multi-backing, multi-Operator, FORAY-relationship). If the Memory work you're picturing is shaped differently — different concerns, different priorities, different architecture — tell me before Phase A starts so we know what Phase A is for beyond just hygiene.
This is a discovery-record artifact. Whatever we land here — even if you correct several pieces of it — is part of the trajectory of arriving at the Memory work. Versions evolve; the trajectory persists.
If we get this assessment substantially right, the next concrete piece of work (the Step 1 inventory kickoff from the hygiene scoping note) gets a clearer purpose: it's not just "clean up wrong-pattern code" — it's "remove the obstacles to Memory's design clarity."
If we get this assessment substantially wrong, v0.2 absorbs the corrections cheaply.