Loomworks — Standing Note: Two Records, and What Crosses Between Them — v0.1

Version: v0.1 Date: 2026-08-21 Status: STANDING. Rules CR-2026-231 §6. Binding on change requests that decide where a fact is recorded. Markdown primary — the consumer is Claude Code and change-request drafting. Operator ruling: split — keep the two records, name them, and state the relationship (2026-08-21). Occasion: CR-2026-231 Gate 2 halted because three of five grant-lifecycle transitions could not be written into Memory's event log. The halt was correct and the reason generalises. Reads with: change-requests/cr-2026-231-w6-writing-the-grant-into-the-record-v0_3 §5, §6; foray-reference/loomworks-contribution-credential-event-log-bypass-v0_1; standing-notes/loomworks-standing-note-agent-accountability-v0_1; seed v0.14, the Memory section.

Plain-language summary

Loomworks keeps two records, not one. It has kept two for some time; nobody had said so.

The first is Memory — what an engagement knows. Assertions contributed by people and agents, carrying provenance, at engagement scope and the scopes above it. This is what the seed describes and what the four rooms run on.

The second is the substrate operational record — what the system did. Grants issued and refused, sessions opened and ended, identities frozen, credits spent, migrations applied. Facts about the machinery rather than knowledge about a subject.

The split is not a compromise and it is not new. H0's own traversal ends with walk the record, and what it walks is the sessions table, not the event log. The lifecycle table did not create the crossing; it made it visible.

What was missing is a name and a stated relationship. Without them, someone later "fixes" the split by collapsing it — and a claim about walking the record turns out to mean walking half of it.

The rule this note sets: a fact goes to Memory if it is knowledge about an engagement's subject, and to the operational record if it is a fact about what the substrate did. Both are the record. Neither is a lesser copy of the other.

1. The split is already load-bearing

Before agent_lifecycle_events existed:

• agent_sessions — H0's traversal walks it. One identity, four sessions, four distinct ends.
• credit_flows — every spend, with its metering and its payer.
• contribution_credentials — issuance, claim and revocation, written by raw SQL.
• MigrationEventRow — migration facts, which is where membership_created actually lands.

None of these is in memory_events, and none of them is wrong to be outside it. The question CR-2026-231 §6 raised was not whether to create a second store. It was whether to admit that one exists.

2. Why Memory cannot hold the second kind

Not preference — mechanism. append_event requires an engagement_id, locks the engagement row, and advances engagement_version. That is correct machinery for knowledge about an engagement, and it is the wrong machinery for a fact that belongs to no engagement or to all of them at once.

Three of the five grant-lifecycle transitions demonstrate it:

• A freeze is platform-wide by design. One identity, per-role, ending sessions across many engagements in one call. There is no engagement to file it under, and choosing one would be false for the others.
• A refusal has no engagement at all. It happens before one is settled.
• No memory-object type exists for any of them, and the only generic one names itself in its own docstring as Phase-1 test machinery.

Mint and close appeared to fit and did not. They have an engagement in scope because the job does. A session's engagement is a property of the job, not of the grant.

3. The boundary test

For any new fact a change request must place:

> Is this knowledge contributed about an engagement's subject — or a fact about what the substrate did?

• Knowledge about a subject → Memory. It has a contributor, it has provenance, it can be corrected by a later contribution, and someone might reasonably disagree with it.
• A fact about the machinery → the operational record. It has an actor and a timestamp, it is not contributed, and it cannot be disagreed with — it either happened or it did not.

Two clarifying cases. An agent's shape is knowledge — it goes to Memory. The grant under which the agent produced it is a fact about the machinery — it goes to the operational record. A person's assertion about a supplier is knowledge; the credit spent generating the render of it is not.

When a fact answers both, it is two facts. Record each in its own place rather than compromising one.

4. What crossing means

An agent's full story spans both records, and after CR-2026-231 the link exists in both directions: an action in Memory carries its session id in provenance.wasAttributedTo, and the grant lifecycle in the operational record carries the identity and the session.

So the crossing must be a capability, not an act of manual assembly. Walk the record has to mean walking both, joined, or the phrase is misleading. Nothing builds that join today and this note does not scope it — but any surface or claim that offers to walk an agent's history owes both halves.

This is the obligation the split creates. A split without a join is two half-records.

5. What the seed says, and where it is silent

The seed's Memory section describes knowledge with provenance at scopes — contributed, corrected, never erased. It does not describe the substrate operational record. The seed is silent, so the architecture specification governs, and the specification's engagement-scoped event log is what append_event implements.

The line that reads closest to a conflict, and why it does not bite:

> Every other operation in the system draws from Memory. Memory is the source. Nothing downstream exists without it.

That is a claim about the pipeline — Manifestation, Shaping and Rendering draw on knowledge, and they do. It is not a claim that every fact the system records is knowledge. A grant is not something Manifestation organizes or Shaping selects from.

Two seed commitments do extend to the operational record, and this note carries them across explicitly rather than leaving it to inference:

• Non-erasure. Corrections preserved, nothing deleted. The operational record is append-only on the same terms.
• Provenance. Every row carries who acted and when. agent_lifecycle_events does; the credential lifecycle does not, which is why its bypass is filed as a gap.

6. What follows for FORAY

FORAY emission belongs at the auditable-event layer, wherever that layer is. The operational record is such a layer, so its writers carry reserved locations on the same terms as Memory's — as CR-2026-231 §7 did for the lifecycle writer.

This is what the credential bypass gets wrong, and naming the split names the defect precisely: contribution_credentials is an operational record written by raw SQL with no actor, no reserved location, and no event. It is not wrong for being outside Memory. It is wrong for being outside both. A third place, unnamed and unattested, is what this note exists to prevent.

7. Naming

• Memory — unchanged, as the seed defines it. Engagement-scoped and above; knowledge; contributed.
• The substrate operational record — the tables recording what the system did. Not a room. Not a scope. Not part of the four-room pipeline.

Neither is "the audit trail", because both are. When a document means one, it says which.

8. What this note does not do

It does not move anything that currently lives in Memory. It does not merge the existing operational tables, which have their own shapes for their own reasons. It does not build the join at §4. It does not close the credential bypass. It does not rule the candidate-discard deletion question, which is about Memory's own commitments and is filed separately. And it does not create a licence to put a fact outside Memory because Memory is inconvenient — §3 is a test, not an escape hatch.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Standing Note: Two Records, and What Crosses Between Them — v0.1 — 2026-08-21