Loomworks — Resident Engagement Investigation — v0.2

Version. 0.2 Date. 2026-05-09 Status. Investigation. Names a methodology construct (resident engagements) and the axes that separate it from delivery engagements. v0.2 calibrates the database-backed Memory framing in response to the Operator's correction: database-backed Memory is an available backing for engagements that warrant it — notably application-type engagements with a data repository, and transactional/operational engagements — not a default that displaces assertion-backed Memory generally. v0.1 is superseded by this version; the construct is unchanged but its claims about Memory backings are tightened. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. Conversation initiated by the Operator's question about whether the line between Loomworks engagements and applications is blurring. Concrete framing: what is the difference between (option 1) an engagement that describes an Expenses application, versus (option 2) an engagement whose Memory holds what expenses are and into which expenses are uploaded, with a render that delivers answers? The question surfaced that option 2 is architecturally already supported and is the more natural shape for a large class of cases the methodology had been quietly framing as option 1. Informed by. Current-status manifest v0.36 (engagement-as-universal-adapter; operational vs infrastructure engagements; the Credit Management as first infrastructure engagement). Methodology v0.20 (engagement, Memory, four-room pipeline, render-as-deliverable framing). Phase 47 invitation/credit/referral scoping notes v0.3–v0.7 (Credit Management Engagement as standard engagement with own data store; the seam read; archetype generality). Closed-loop engagement investigation v0.1 (closed-loop as a use-case class distinct from delivery-class; observation/attribution separation). Agent Fabric investigation v0.1 (Companion as manager, specialists as workers). Memory-space-extensibility investigation v0.1 (N-space Memory, organization/team/role/domain Memory). Operator Layer discovery v0.4 (three populations of SDK consumers; applications named as a first-class render category; Specialist SDK). Queued directions v0.4 (engagement creation + Discovery-to-seed; metadata-driven runtime; non-text-shaped knowledge; quick-capture engagement). Render-feasibility puppy investigation v0.1 (delivery-class examples worked through; the kennel website case, the buyer contract case).

1. The framing question

The Operator opened with the observation that the line between Loomworks engagements and applications feels blurred, illustrated with two readings of an Expenses use case:

Option 1. An engagement that describes an Expenses application. The engagement produces a specification for an expense-tracking app; a render specialist builds the app; the Operator (or whoever) uses the app, which lives outside Loomworks, with its own data store, its own UI, its own lifecycle.
Option 2. An engagement that is the Expenses environment. Memory holds what expenses are (categories, deductibility rules, vendor conventions, tax-period relationships). Memory (or a co-located data store) also holds the accumulated expense records. The Operator interacts via the Companion. The render is a query answer — "show me Q3 deductibles," "categorize this batch," "what's my travel total."

The Operator's reading: option 2 has what expenses are and what expenses have been uploaded, and "all we need then is a shape/render that is delivering answers." The question implicitly proposes that option 2 is not just a stylistic choice but a recognition about what engagements naturally do.

2. What lands

The line is genuinely blurring, and the blur is real because two readings of "engagement" have been carried forward in tension:

Engagement-as-specification-for-deliverable (the older reading). The engagement specifies; the render produces a deliverable; the deliverable is consumed somewhere. Most early methodology examples land here — contracts, storybooks, IRB submissions, application code.
Engagement-as-environment (the newer reading, named here). The engagement is the system the user wants. Memory holds the domain. Memory or a co-located store holds the accumulated records. The Companion is the interaction surface. Renders are answers, not deliverables to ship.

The newer reading is not a thought experiment. Phase 47's Credit Management Engagement was the architectural commitment that engagement-as-environment is a real category. The credit system doesn't describe a credit-tracking app — it is the credit system. The Operator never ships a credit application anywhere; they interact with the engagement via the Companion, and the engagement runs the system.

This investigation names the construct (resident engagement versus delivery engagement), identifies the axes that separate them, and shows that most cases the methodology had been framing as "applications-to-be-built" are more naturally framed as resident engagements doing what engagements already do.

The records-substrate question — whether records live as Memory assertions or in a co-located data store — was raised initially as a refinement, but follow-up turns of the conversation sharpened it into a primary axis: Memory backings. The architecture admits more than one backing for Memory; the assertion store is one backing, and what Phase 47 named as a "co-located data store" for Credit Management is structurally a second backing. Naming these as peer backings of the same construct rather than as Memory-plus-adjacent-store changes the language, the governance posture, and what an engagement's specialist is allowed to read and write without crossing a boundary. Sections §8 and §9 work this out; §10 names what governance looks like when held-then-commit is the wrong-shaped ceremony for the data being held.

3. Naming the construct

The two engagement classes are named:

Resident engagement. The engagement is the system. Memory holds the domain; Memory holds the records (in whichever backing fits); the Companion is the interaction surface; renders are answers, decisions, or operational outputs that don't ship outside Loomworks. The Operator (and Contributors) reach the system by entering the engagement.
Delivery engagement. The engagement specifies a deliverable. The render produces an artifact (a contract, a website, a storybook, a deployable application, a printable document, an ad creative) that is consumed somewhere outside the engagement — often outside Loomworks entirely.

The names emphasize the directional axis the question turns on: where does the consuming experience live? Inside the engagement (resident) or delivered out of the engagement (delivery)?

Naming alternatives considered and set aside:

In-situ vs external. Captures the spatial sense but reads as jargon and doesn't carry the active sense that resident does. Set aside.
Self-contained vs shipped. "Self-contained" implies a closure the methodology doesn't actually have — a resident engagement still composes with N-space Memory (personal, organization, domain), so it's not literally self-contained. Set aside as misleading.
Environment vs deliverable. Useful framing in the prior turn that surfaced the construct, but "environment" already names something larger in Loomworks vocabulary (Loomworks itself is the environment in product framing). Reusing the word at the engagement level invites confusion. Set aside.
Intrinsic vs extrinsic. Captures the philosophical axis but is too abstract to do practical work in conversations about specific engagements. Set aside.

Resident and delivery hold the directional sense without overloading existing vocabulary. They also make the common middle case nameable: a delivery engagement that has a resident reading (Credit Management, technically — its renders are corrective FORAY flows that ship into the credit substrate, but the substrate is itself part of the engagement, so the delivery isn't external) and a resident engagement that occasionally produces deliverables (Expenses producing a year-end PDF report for the accountant). The classes are dominant readings, not exclusive boxes.

4. Why the question felt like a blur

The blur is real, and tracing where it came from is worth the exercise because the architecture has been quietly absorbing the resident reading for months while the language stayed delivery-shaped.

The original methodology framing was delivery-shaped. Methodology v0.20 and earlier treats an engagement as the journey from intent to a confirmed shape that a render specialist produces. The default mental model is: someone wants something, the engagement specifies it, the render produces it, the deliverable lands. Most worked examples in early documents — contracts, IRB submissions, application code, storybooks — are delivery-shaped, and they reinforced the reading.

Phase 47 introduced the universal-adapter recognition without renaming. Credit Management was built as "an engagement whose specialist owns its own data store." The substrate change was real (a separate database schema, hot-path reads from outside the engagement, FORAY governance over operations). But the framing carried forward language like "co-located data store" and "the integration seam," which positions the data store as outside the engagement even though it's owned, operated, and governed by the engagement's specialist. The language treated the engagement as having an outside; the architecture treated the engagement as containing the substrate.

Engagement-as-universal-adapter was the right naming for the substrate move but didn't name the consuming-experience move. The recent-updates note in the manifest does name it ("any system wrapped as a Loomworks engagement gets Companion, pipeline, approvals, FORAY, OVA"), but the consuming-experience question — who reaches the system, and where do they reach it — is what makes resident a real category. Credit Management is consumed by Loomworks core (engine reads on the hot path) and by the Operator (via the Companion). Both consumers are inside Loomworks. There is no external delivery in the picture.

Most "applications" people think they need are resident. This is the load-bearing recognition. When someone says "I need an expenses app," they almost always mean: I want a place where I can put expenses and ask questions about them. That is what an engagement already is. The "app" framing is a habit imported from a world where the only way to have a place-with-questions was to build a separate piece of software with its own database, UI, and lifecycle. Loomworks gives that for free, with provenance, FORAY governance, Companion interaction, and N-space Memory composition included. The engagement isn't a specification for an expenses app; the engagement is the expenses environment.

The blur dissolves when both moves are named together: engagement-as-universal-adapter (the substrate move) plus engagement-as-environment (the consuming-experience move) jointly produce the resident class.

5. The axes that separate the classes

Three axes carry the distinction. They compose; they're not mutually exclusive.

5.1 Axis A — Where consumers live

Inside Loomworks. The Operator alone (personal engagements), the Operator plus Contributors (workspace engagements), the engine itself (infrastructure engagements consumed on the hot path), or other engagements (engagements that read each other's Memory through the elevation pathway).
Outside Loomworks. External counterparties (a contract sent to a buyer), customers (a kennel website found by people searching), readers (a child reading a Goosey storybook), deployment targets (an application deployed to Cloudflare), or marketplaces (an ad placed on Facebook).

When all consumers are inside, the engagement is naturally resident. When any consumer is outside, the engagement is pulled toward delivery for the part of its work that reaches that consumer.

5.2 Axis B — What the engagement primarily produces

Answers drawn from accumulated knowledge and records. "What did I spend last quarter," "which puppies are still available," "what does the soil data say about next year's irrigation."
Operational state and operations that the engagement runs. Credit balances. Reconciliation flows. Account lifecycle transitions.
Deliverable artifacts shipped to consumers. Contracts, websites, storybook PDFs, deployed applications, ad creatives.

These aren't exclusive — Credit Management produces both operational state and answers (the Companion answers "what's my balance" by reading state). An ad-management engagement produces both shipped deliverables (the ad creative) and operational state (placement, performance metrics). The axis is about which output dominates the engagement's purpose.

5.3 Axis C — Where substrate lives

Inside the engagement. Memory (in any of its backings — assertion-backed, database-backed, future binary-content-backed) carries the engagement's substrate. The engagement's specialists read and write it directly.
Outside the engagement. The substrate is a deployed application's database, a third-party SaaS platform's storage, an ad network's placement system, a deployment target's runtime. The engagement specifies; specialists reach the substrate via APIs; the substrate doesn't belong to the engagement.

When the substrate is inside, governance, audit, and provenance are uniform across the engagement's lifetime. When the substrate is outside, the engagement gives up some governance in exchange for reach.

5.4 How the axes compose

The cleanest reading of the resident/delivery distinction is Axis A and Axis C jointly. When consumers and substrate are both inside, the engagement is resident. When either is outside, it's delivery (or has a delivery component). Axis B then determines the flavor within whichever class:

Personal resident. Inside consumers, inside substrate, answer-dominant output. Expenses, journaling, personal task tracking, personal CRM.
Workspace resident. Inside consumers (Operator + Contributors), inside substrate, mixed answer/decision output. FarmGuard, the methodology engagement (Loomworks itself), most current build engagements.
Operational/infrastructure resident. Inside consumers (engine on hot path, plus Operator), inside substrate, operational-state-dominant output. Credit Management, Accounting.
Pure delivery. Outside consumers, outside or inside substrate, artifact-dominant output. Goosey storybook, kennel website, buyer contract, IRB submission.
Mixed. Outside consumers for the deliverable, inside substrate for the engagement's working state. Ad-management engagement (creative ships outside; performance observation lives inside; closed-loop applies orthogonally).

6. Worked examples positioned across the axes

Six examples. Each is a real or near-real engagement; positioning them surfaces how the axes do their work.

Expenses (resident, personal). Memory holds what an expense is — categories, deductibility rules, vendor patterns, tax-period relationships, the Operator's filing conventions. Memory also holds the accumulated records (in database-backed Memory; see §9). Consumers: the Operator alone. Output: answers ("Q3 deductibles," "travel total," "uncategorized items"), occasional shipped deliverables (year-end PDF for the accountant — a delivery-component within an otherwise resident engagement). No external substrate.

FarmGuard (resident, workspace). Memory holds the agricultural domain — soil types, crop rotations, irrigation strategies, the farm's specific topology and history. Memory also holds sensor readings and observations over time. Consumers: the Operator and Contributors (farm operator, agronomist, researchers). Output: decisions ("when to irrigate," "which fields to rotate"), answers about the farm's state, occasional shipped reports (for crop insurance, for grant applications). Substrate inside.

Credit Management (resident, operational/infrastructure). Memory holds model profiles, oracle rates, asset taxonomy, codes, governance assertions for Companion-as-Authority. Database-backed Memory holds FORAY action flows. Consumers: Loomworks engine on the hot path (key resolution, balance reads), the Operator via Companion (balance answers, grant requests). Output: operational state plus answers. Substrate inside (in a database-backed Memory space). No external substrate, no external consumer.

The Loomworks methodology engagement (resident, workspace). Memory holds the methodology itself — the principles, the patterns, the build-record material, the queued directions. Consumers: the Operator (Marvin) and Claude.ai as Contributor. Output: methodology decisions, scoping notes, CRs (which are themselves delivery artifacts shipped to CC, but the engagement-as-thinking-ground is resident). The methodology engagement is interesting because it's resident and its renders are sometimes delivery artifacts — the engagement isn't classified by what its renders happen to be at any moment but by how the consuming experience composes.

Goosey storybook (delivery, with a resident scaffolding). Memory holds the Goosey domain — characters, story arcs, art style, target reading level, the parent's authoring preferences. Renders are storybook PDFs (or printed books) shipped to a child reader. Consumer: outside Loomworks. Substrate: the rendered storybook lives outside (it's a file the child reads). The engagement has a resident scaffolding (the domain, the working notes, the version history) and a delivery surface (the rendered book). Both readings are real; the dominant reading is delivery because that's the work the engagement primarily exists to do.

Custom kennel website (pure delivery). Memory holds the kennel domain — breeds, available litters, past breeding history, brand voice. Renders are a deployed website. Consumer: outside Loomworks (buyers searching the web). Substrate: the deployed website's runtime, hosted on Cloudflare or similar — outside Loomworks entirely. The engagement specifies; specialists deploy; the website lives elsewhere. Pure delivery.

The point of working through six examples: the resident/delivery distinction does real classification work. It doesn't put every engagement in a clean box, but it correctly identifies the dominant reading and surfaces where engagements have mixed components that the axes name explicitly.

7. The forces that push to delivery

Three forces, any one of which is sufficient to pull an engagement (or a part of an engagement) toward delivery:

Audience beyond the Operator. When users of the thing-being-built aren't themselves Loomworks Operators interacting through Companions, delivery is forced. A public website is the canonical case. A customer portal, a SaaS product sold to small businesses, a mobile app distributed through app stores, a printed book sold through a bookstore — all force delivery because the consumers can't reach a Loomworks engagement.
Substrate Loomworks can't host. When the operating envelope requires real-time interaction at sub-second latency, embedded systems, mobile apps that work offline, transactional systems with regulatory holds Memory's discipline can't satisfy, or any other shape where Memory's held-then-commit ceremony or the engagement's pipeline pacing is wrong-shaped — the substrate goes outside. The render produces something that lives elsewhere because it has to.
Distribution as the deliverable. When the thing built is itself the product — Goosey storybooks shipped to a child, a contract drafted for a counterparty's signature, an ad creative that has to live on Facebook to do its work — delivery is the point. The engagement specifies; the render delivers. Even if the consumer is technically a Loomworks Operator (rare), the artifact is the value being produced.

When none of these apply — and for most personal-tracking, workspace, and operational-infrastructure cases none of them do — resident is the natural shape, and any push toward delivery is overbuilding.

A good test for an unclassified engagement: ask "could the Operator do this work by talking to their Companion in the engagement, with the engagement holding everything?" If yes, resident. If the answer needs a piece of software somewhere else, or a person somewhere else, or a substrate somewhere else, the part that needs to be elsewhere is delivery.

8. Memory backings as a primary axis

This section names what was raised initially as a sub-question and sharpened across follow-up turns into a primary architectural construct.

The calibration up front. This is not a claim that Memory should default to database-backed, or that Memory currently held in the assertion store should migrate. The recognition is narrower and more practical: certain engagements have data shapes for which database-backed Memory is the appropriate backing — most clearly application-type engagements that include a data repository, and transactional or operational engagements like Credit Management. For those engagements, database-backed Memory belongs in the architecture as a peer backing rather than as adjacent infrastructure. For everything else — most engagements in current scope, including the Loomworks methodology engagement itself, FarmGuard's working state, and the considered-claim portions of any engagement — assertion-backed Memory remains the default and the right shape. The construct adds a backing to the available set; it does not promote that backing to a new default.

Memory is a category that admits multiple backings. Today the methodology has framed Memory as a single thing — assertions in the assertion store, governed by held-then-commit, retrieved semantically. That framing was right for the assertion shape it described, but the framing implicitly forecloses a recognition the architecture has already made: Credit Management's "co-located data store" is also Memory, holding the engagement's records, governed by the engagement's specialist, contributing to the Companion's access set when queried. Naming it as a Memory backing instead of an adjacent store changes the language to match what's already true.

Two backings exist today, with a third sketched. Each has a fitness-for-purpose; the engagement chooses which backings it uses based on the data shapes it holds.

Assertion-backed Memory. The current assertion store, and the default for almost everything Loomworks holds. Held-then-commit lifecycle. Semantic retrieval. Topic-shaped reads. Right for considered claims, domain definitions, vocabulary, decisions, learning that compounds over time, working state in a thinking-ground engagement. The shape that everything called "Memory" before this investigation has been, and the shape most Memory remains. No engagement is required to add database-backed Memory; many engagements never will.
Database-backed Memory. Available when an engagement warrants it. The Credit Management pattern, named here as a peer backing rather than as adjacent infrastructure. Tabular, row-shaped, query-shaped. Ingestion gate (upload, import, row-event) instead of held-then-commit. Right for accumulated records in application-type engagements with a data repository, transactional state in operational engagements, and any case where the data is fundamentally row-shaped at high volume. §9 names the database choice for engagements that adopt this backing; §10 names the governance shape.
Binary-content-backed Memory (sketched, not built). The non-text-shaped knowledge queued direction lives here. Image, audio, video, structured binary formats. The backing is object storage with references in the structured backings; the governance shape is closer to database-backed (ingestion gate) than to assertion-backed. Filed for when non-text knowledge becomes load-bearing for any engagement.

Backing is orthogonal to scope. The N-space Memory pattern (memory-space-extensibility investigation) named the scope axis: personal, engagement, organization, team, role, domain. The backing axis is independent. An engagement's Memory at the engagement scope can have an assertion-backed face (its domain knowledge: what an expense is) and a database-backed face (its records: what expenses have been uploaded). Personal Memory might be assertion-only today and gain database-backed personal records later (a personal task list with structured fields). Organization Memory might be primarily assertion-backed for shared knowledge and gain database-backed organizational records (employee directory, asset registry) as organizations adopt Loomworks.

Cross-backing reads are the interesting work. The richest case is when an engagement's assertion-Memory and database-Memory reference each other. "Categorize this expense as travel because the vendor matches the airline-pattern assertion in domain Memory" requires the Companion to read both backings and join across them. The composition is reasoning work for the Companion, not infrastructure work — provided the backings live in the same database technology, where joins are a native operation rather than a federation problem. §9 names why this single-technology constraint matters and what it implies.

What stays unchanged across backings. The Companion is still bound to the person. FORAY still attests at the appropriate granularity (per-assertion for assertion-backed; per-flow for database-backed). OVA still authorizes. The four-room pipeline still operates. The engagement still has its lifecycle. Renders are still produced from confirmed shapes. The only thing that changes is that Memory is now a category with multiple backings rather than a single store with one shape, and engagements declare which backings they use for which kinds of held material.

9. Database backing — Postgres, with declared sub-shapes

The database choice for the database-backed Memory backing is dispositive rather than weakly preferential. Postgres, with three declared sub-shapes per engagement.

9.1 Why Postgres

Schema-as-vocabulary composes natively. The Phase 38 declare-and-register pattern is structurally relational — declare a type, register handlers, engine matches at runtime. Postgres tables are that pattern materialized. The "flexibility" of schemaless storage is a misfit for Loomworks because declaration is the governance event the methodology wants. Schemalessness would let the engagement drift schema without methodology cost; that's a regression dressed as flexibility.
FORAY governance is already there. FORAY action flows live in Postgres today. Database-backed Memory in Postgres means FORAY's audit shape over records and FORAY's audit shape over the rest of the engagement share one query surface. A second database type would force federation between governance flows and the operations they govern.
Cross-backing reads stay one query. The richest case from §8 — joining assertion-Memory and database-Memory in a single Companion read — stays a standard SQL join when both backings live in Postgres. A different database would force application-level federation, which is workable but pays cost on every Companion read and complicates every Companion reasoning step that crosses backings.
Extension headroom absorbs specialty needs. pgvector for semantic indexing if assertion-Memory ever wants hybrid retrieval. TimescaleDB extension for time-series patterns (FarmGuard sensor readings, ad performance metrics, any temporal data). PostGIS for geospatial. JSONB for fields-within-typed-rows. Postgres absorbs these without becoming a different database — the operational surface stays one.
Constraint-creep cuts against a second database type. Adding Mongo, Neo4j, Cassandra, or anything else means a new backup story, a new migration story, a new auth story, a new monitoring story, new failure modes, a new vocabulary the engagement's specialist must know. Each is a small subtraction from coherence. The threshold for paying that cost should be high; today nothing meets it.

9.2 Alternatives considered and set aside

Document stores (MongoDB, Couchbase). Set aside. The schema flexibility is exactly what the methodology wants to not have. Declaration is the governance event.
Graph databases (Neo4j, Dgraph). Set aside. Assertion-Memory already has relationships as first-class. Multi-hop graph queries don't dominate any engagement's pattern that's currently in flight; recursive CTEs handle moderate graph workloads in Postgres adequately.
Time-series databases (InfluxDB, QuestDB). Set aside as standalone — but TimescaleDB is a Postgres extension, so the time-series case stays inside Postgres if and when it becomes load-bearing.
Key-value stores (Redis, DynamoDB). Set aside. These are caches and ephemeral state, not Memory. Memory needs durability and queryability; KV stores trade those for latency that records don't need.
Object/blob stores (S3, MinIO, GCS). Different category, not an alternative. Object stores belong as the binary-content-backed Memory sketched in §8, with references in Postgres tables. Sit alongside, not in place of.
Vector databases (Pinecone, Weaviate, Qdrant standalone). Set aside as standalone. pgvector covers the hybrid-retrieval use case inside Postgres if and when assertion-Memory wants semantic indexing.

9.3 Three declared sub-shapes per engagement

Within Postgres, an engagement chooses among three sub-shapes based on the data's operational pattern. These mirror the engine's existing event-projection-state structure at the Memory-backing layer:

Append-only event tables. The FORAY shape — canonical record of what happened, never mutated. Right for ingestions, transactions, observations, any "what occurred" data. Credit Management's credit.foray_action_flows is the archetype.
Mutable row tables, or projection views over event tables. Current state derived from events, or a state table mutated directly. Right for "what is the state right now" reads. The credit balance projection is the archetype.
JSONB columns within typed rows. When the schema is genuinely fluid within a row's typed envelope. The engagement declares the table; rows carry a small open payload. Right for cases where part of the record's shape varies by case (an Expenses row's typed columns plus a vendor_metadata JSONB for vendor-specific fields).

The sub-shape is part of what the engagement declares when it adopts a database-backed Memory space. The declaration is the governance event; CC and the engine know what to expect; the Companion knows what query patterns are available against it.

9.4 What this resolves

The records-substrate question raised at the close of the prior conversation turn — whether accumulated records in an engagement that warrants a data repository belong as assertions or in a separate store — is now reframed: for the engagements that warrant database-backed Memory in the first place (application-type engagements with a data repository, transactional/operational engagements), the records belong in Memory in a database-backed Memory space, on Postgres, in one of three declared sub-shapes. Engagements that don't warrant database-backed Memory (the majority) are not affected by this resolution; their records, where they have records, remain assertion-backed.

Credit Management is the existing instance (its co-located data store retroactively becomes its database-backed Memory space). Expenses with accumulated records — if the induction confirms that Expenses warrants a data repository, which the Operator's framing strongly suggests — is the next instance. The "co-located data store" language in Phase 47's scoping notes becomes a vocabulary residue to absorb in methodology v0.21.

10. Ingestion without held-then-commit — the analogous gate

Held-then-commit is the right ceremony for considered claims (assertions). It is the wrong ceremony for records arriving operationally (an expense uploaded from a receipt, a sensor reading from a field, a credit consumption from an LLM call). The methodology needs a peer ceremony for the database-backed case.

The analogue is an ingestion gate. The shape:

Ingestion event — the record arrives. Captured, validated against the declared schema, attributed to a contributor (Operator, Companion, specialist, external system through a registered seam).
Hold (briefly, when the case warrants). Some ingestions are direct-commit — sensor readings, system-generated FORAY flows, an authenticated upload from a known integration. Some warrant a hold — an Operator's batch upload of receipts that should be reviewed before commit, an inference-classified expense that the Operator might want to override.
Commit. The record enters the queryable state. Held records are committed by Operator action (or by delegation, in the Phase 45+ model) the same way held assertions are.
Retract / supersede. Records can be marked retracted (kept for audit, hidden from queries) or superseded by a corrected version (with provenance threading from the corrected to the original). FORAY governance applies — every state transition is an attested flow.

Schema declarations remain held-then-commit. Even though row-level events skip the hold for direct-commit cases, changes to the schema itself — declaring a new table, adding a column, registering a new ingestion handler — are governance-bearing in the assertion sense. They are considered claims about how the engagement structures its records. Held-then-commit applies. The schema is part of the engagement's vocabulary and travels through the same ceremony as any other vocabulary change.

What the gate gives. Three things:

Audit symmetry. Every record's lifecycle is FORAY-attested, just as every assertion's lifecycle is event-logged. The Companion can answer "where did this record come from" the same way it can answer "where did this assertion come from."
Reversibility at the right granularity. Retraction and supersession are first-class at the row level, not just at the schema level. An Expenses engagement can correct a mis-categorized batch without rewriting history.
Companion intelligibility. The Companion reading database-Memory has the same provenance access as when reading assertion-Memory. "This expense was uploaded by you on April 12 and committed without review" is the database analogue of "this assertion was contributed by Sarah and committed by you on April 12." The vocabulary the Companion uses to talk about the engagement's state is uniform across backings.

What this means for Credit Management retrospectively. The pattern is already there — FORAY action flows are append-only event tables; balance is a projection; the writes happen through specialist-mediated paths that match the gate shape. Phase 47 built the right thing; the methodology naming was the gap. Methodology v0.21 should name the ingestion gate as the peer ceremony to held-then-commit and recognize Credit Management's pattern as the first instance.

11. Composition with existing engagement classes

The methodology has accumulated several engagement-class names across investigations. The resident/delivery construct sits among them as the top-level split; the others compose with it on different axes.

Closed-loop (closed-loop engagement investigation v0.1). Closed-loop describes the feedback shape — renders feed back into Memory as observations or refinements. It is orthogonal to resident/delivery. An ad-management engagement is delivery (the creative ships outside) AND closed-loop (performance observation feeds back into Memory). An Expenses engagement that refines categorization patterns over time is resident AND closed-loop. Closed-loop is a property of the production cycle; resident/delivery is a property of consumption locality.
Operational vs infrastructure engagements (manifest v0.36 recent updates). This naming distinguished engagements whose data the engine doesn't depend on (operational) from engagements whose data the engine does depend on, requiring co-location (infrastructure). With the Memory-backings recognition in §8, the operational/infrastructure distinction is best read as a property of which Memory backings the engagement uses and where they sit. Infrastructure engagements have database-backed Memory in the engine's database (because the engine reads on the hot path). Operational engagements may have database-backed Memory in their own database (when the engine doesn't need hot-path reads). Both are flavors of resident; the difference is colocation of the database backing relative to the engine.
Personal / workspace / organization engagements. This sits on the consumer-scope axis (Axis A in §5). All three flavors can be resident; some can also be delivery when they ship artifacts outside their scope. Useful for naming who's in the engagement, but doesn't replace resident/delivery.
Application engagements. This was the framing carried forward in the Operator Layer Discovery — "applications are a first-class render category." The recognition this investigation makes is that most engagements that look like they're about producing applications are actually resident engagements. The application-engagement category survives, but its membership is much smaller than the original framing implied — it's specifically the cases where the three forces in §7 push to delivery and the deliverable happens to be an application.

Composition example: Credit Management is resident, infrastructure, with closed-loop reconciliation feedback, at organization scope (Loomworks itself). Expenses is resident, operational, potentially closed-loop (as categorization refines), at personal scope. The kennel website is delivery, with a resident scaffolding, at workspace scope (the kennel as an organization).

The classes don't replace each other; they describe different axes. Methodology v0.21 should consolidate them into a single coherent taxonomy.

12. What this means for engagements currently in scope

Six engagements are in motion or queued. The construct repositions some of them.

Loomworks (the methodology engagement itself). Resident, workspace, at organization scope. The engagement-as-thinking-ground reading was always implicit; naming it as resident makes the implicit posture available for reasoning about its own structure.
Credit Management. Resident, infrastructure, with database-backed Memory in the engine database. The "co-located data store" language in Phase 47 scoping notes becomes "database-backed Memory in the engine-resident space," which is a vocabulary update for v0.21 consolidation, not an architectural change.
Accounting. Same position as Credit Management. Resident, infrastructure, database-backed.
Enrollium. Pending induction. Likely resident (it holds a domain — student enrollment processes — and accumulates records — applications, decisions, communications). The induction work should consider whether records are assertion-backed (small volume, considered) or database-backed (high volume, structured) — and the answer probably varies by record kind. Some kinds (advisory notes about a student) belong as assertions; some kinds (enrollment events, decision audits) belong as database-backed records.
ExpenseDesk. Pending induction, and the worked example throughout this investigation. Resident, personal scope, database-backed Memory for records, assertion-backed Memory for the domain. The induction should explicitly position ExpenseDesk as resident from the seed onward, not as a specification for an expenses application.
FarmGuard. Currently positioned as a specification engagement. The framing should be revisited. The agricultural domain belongs as assertion-backed Memory. Sensor readings and observations probably belong as database-backed Memory (potentially with TimescaleDB if temporal patterns become load-bearing). Decisions and reports are renders — some shipped (insurance reports), most consumed inside the engagement (irrigation decisions). The dominant reading is resident-workspace; deliveries are occasional.
Goosey. Pending. Delivery-dominant (storybooks ship to children) with a resident scaffolding (the Goosey domain — characters, art style, story arcs — lives in the engagement's Memory). The induction should explicitly carry both readings.

The pattern across these positions: most engagements have a dominant reading and a secondary component on the other side. The construct doesn't force engagements into single boxes; it gives them precise vocabulary for the mixed cases.

13. Filed for consideration

13.1 Methodology v0.21 absorption

The v0.21 consolidation should absorb the following from this investigation:

Resident vs delivery as the top-level engagement-class distinction.
The three axes (Axis A consumer locality, Axis B output kind, Axis C substrate locality).
Memory backings as a primary architectural construct, peer to (and orthogonal to) Memory scope.
The calibration that database-backed Memory is an available backing for engagements that warrant it (notably application-type engagements with a data repository, and transactional/operational engagements), not a default for Memory generally. Assertion-backed Memory remains the default for considered claims, domain definitions, working state, and the majority of what engagements hold.
Postgres as the dispositive database choice for engagements that adopt database-backed Memory, with the three declared sub-shapes.
The ingestion gate as the peer ceremony to held-then-commit for database-backed records; schema declarations stay held-then-commit.
The composition rules with closed-loop, operational/infrastructure, scope-based naming.
Vocabulary update: Phase 47's "co-located data store" becomes "database-backed Memory in the engine-resident space."

13.2 Queued directions update

loomworks-queued-directions-and-deferred-work should gain or update:

Database-backed Memory as a build direction. Today it exists in Credit Management's specific implementation. Generalizing it as a Memory backing available to any engagement is a build direction whose trigger is the second engagement that wants it (likely ExpenseDesk at induction or Enrollium).
Binary-content-backed Memory as a sketched future direction. Sketched in §8; trigger is the first engagement whose load-bearing knowledge is non-text-shaped.
Cross-backing query patterns in the Companion. The Companion's reasoning across assertion-Memory and database-Memory in a single read is interesting work that doesn't exist today. Trigger: the first engagement whose Companion behavior depends on cross-backing reasoning (likely ExpenseDesk's categorization-by-domain-pattern).
Schema declaration as a Phase 38 instance. The pattern (engagement declares a database-backed Memory table; engine accepts; specialist registers handlers) is structurally a Phase 38 declare-and-register case. The phase pattern doesn't need to be re-invented — it's reusable for this case.

13.3 Retroactive reading of Phase 47

Phase 47's Credit Management Engagement was the architectural commitment that engagement-as-environment is a real category. The framing language hadn't caught up; the vocabulary residue ("co-located data store," "the integration seam") positioned the substrate as outside-the-engagement when the architecture treats it as engagement-owned. v0.21 should retroactively rename without rebuilding — Phase 47 built the right thing; the naming is the consolidation work.

13.4 Open question — when assertion-backed Memory should adopt the ingestion-gate vocabulary

A finer question this investigation surfaces but doesn't resolve. Some assertions arrive operationally — a Companion-authored held assertion from a Phase 42 intent classification, an automated observation from a closed-loop performance loop. The Operator-confirmation step is structurally similar to the ingestion gate's commit step. Whether held-then-commit and the ingestion gate are two ceremonies or one ceremony with two parameterizations is worth examining when methodology v0.21 consolidates. This investigation files it as open; it doesn't push a resolution.

13.5 What this investigation does not do

It does not specify build for any of the constructs named. Database-backed Memory as a generalized backing (beyond Credit Management's specific instance) is a build direction, not a build phase. The trigger is a second engagement that wants it.
It does not retroactively rewrite Phase 47's CR. Phase 47 shipped clean. The renaming work is methodology consolidation, not substrate change.
It does not resolve the assertion-vs-row governance unification (§13.4). That belongs in v0.21 consolidation work.
It does not redesign the Companion's cross-backing reasoning. That's a build direction for whenever the first cross-backing-dependent engagement lands.

14. Trajectory worth preserving

The conversation moved through five turns, and each one corrected the framing of the prior:

Turn one. The Operator asked whether plugins and MCP have a logical use case in Loomworks. The answer surfaced that Loomworks already runs on plugin-shaped extensibility (specialist registries, the SDK), and that MCP fits as the wire under external-capability task agents, not as a substitute for the SDK.
Turn two. The Operator asked whether the line between engagements and applications is blurring, with the Expenses option-1-vs-option-2 framing. The answer recognized that engagement-as-environment is the default reading for most cases that had been framed as applications, and named the records-substrate question as a sub-question.
Turn three. The Operator asked whether Memory could be a database. The answer reframed the records-substrate question from a sub-question into a primary axis (Memory backings) and recognized that Phase 47's "co-located data store" was structurally a database-backed Memory space.
Turn four. The Operator asked which database type best suits database-backed Memory. The answer was dispositive: Postgres, with three declared sub-shapes, and a worked-through alternatives-considered list.
Turn five (v0.2 calibration). The Operator corrected an over-reading in v0.1: not all Memory should be in a database. Database-backed Memory is relevant when appropriate — most clearly as a data repository for an application-type engagement — not as a wholesale shift in how Memory is conceived. The construct is added to the architecture's available shapes; assertion-backed Memory remains the default for the majority of what engagements hold. v0.2 tightens §8 (calibration paragraph at head; backing list reframed as fitness-for-purpose), §9.4 (categorical claim removed), and §13.1 (calibration item added to absorption checklist).

Each turn refined what the prior turn left underspecified. The pattern matters for trajectory preservation: the resident-engagement construct didn't land in one move. It landed across five moves, each correcting the prior framing's blur or overreach. Future readers reconstructing the path should see all five; none of them is dispensable.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Resident Engagement Investigation — v0.2 — 2026-05-09