Version: v0.1
Date: 2026-08-18
Status: Proposal for Operator ruling. Nothing built; no change request drafted. Decisions D1–D6 in §9 are what need a word.
Responds to: foray-loomworks-audit-coverage-requirement-v0_1 (FORAY-side work product, carried by the Operator per seam discipline, 2026-08-18) — findings 3.1, 3.2, 3.3 and requirements R-1, R-2, R-3.
Grounded on: the Loomworks seed (four rooms; FORAY named for tamper-evident anchoring of transitions, mechanism deferred to FORAY's specification); architecture specification v0.4 §09 (reserved-location pattern); the Phase 61–63 substrate cleanup arc and its four canon principles; build list v1.03 (current queue).
FORAY's brief says three true things: three of the four rooms send FORAY nothing at all, nine of the sixteen existing places that do send something are dropping identifying information they already have in hand, and no FORAY record Loomworks produces can point at another one.
This proposal does not answer "wire everything." It answers with a principle — attest what enters the record and what leaves the system; do not attest derived computation — and then applies that principle room by room, so every room gets a stated posture rather than an unexplained silence. Under that principle, Rendering is the real gap and should be wired first among the rooms, because Rendering is where things leave Loomworks and an auditor's question ("what did you ship, from what, on whose authority?") currently has no tamper-evident answer. Manifestation and Shaping are largely derived from Memory — anchoring Memory already anchors what they compute — so their attestable moments are the Operator's approvals, not their arrangement work. Memory already emits, but through one coarse site that should be split per business event.
The cheapest work comes first and is independent of all of it: close the nine forward gaps. That is editing payload construction at sites that already exist, and it is also what makes the cross-record question answerable later — the identifiers have to be present in the records before anything can link them.
One fact must be verified before any of this is scheduled: whether the sixteen sites are transmitting to FORAY today or are still reserved stubs. The answer changes what this work is, and it is not settled by anything visible from this side.
The brief explicitly does not design the solution, set a timeline, or override Loomworks' build sequencing. This proposal treats it that way — as input to Loomworks planning, answered on Loomworks' terms.
Against the seed: no conflict, and I reach that independently of the brief's own §7. The seed names FORAY for tamper-evident anchoring of transitions and defers mechanism to FORAY's specification. A document that says which transitions Loomworks anchors and which it does not is inside that deferral. Nothing proposed here adds a commitment the seed has not already made.
Against the architecture, one binding constraint the brief does not carry, and it shapes the whole proposal: FORAY emission belongs at the engine substrate layer, never at a surface. Trust must not depend on a surface's cooperation. Two consequences follow directly:
Against the cleanup arc's canon: the reserved-location pattern (_foray_reserved_emit("<namespace>.<event_kind>", payload) with grep markers) is the established mechanism, and canon Principle 1 is one emit per business event, not centralized at the helper writer — validated at 1, 3, and 12 sites across CR-A/B/C. Everything proposed below uses that pattern and that principle. Nothing here invents a new emission mechanism.
The brief states all sixteen sites "validate cleanly against FORAY's live 4.2 endpoint" while also describing "the real FORAY record each would produce." Those two phrasings point at different states of the world. Loomworks' own record describes the sixteen as reserved locations — seams placed deliberately ahead of live wiring.
The reading I am carrying, and its source: the sixteen are reserved emits, and FORAY's validation exercise confirmed the records they would produce are well-formed, not that they are transmitting today. This is propagated from the brief's own wording plus the cleanup-arc record, and it is not verified against current engine state.
It matters because it changes what every item below is:
This is the first question a Step 0 inspection answers, ahead of any design work.
Rather than a room-by-room judgment call, one rule, applied consistently:
> Attest transitions that enter the record or leave the system. Do not attest derived computation.
The reasoning: FORAY proves a system's record of a transition has not been altered since. Something that can be recomputed from an already-anchored source needs no independent anchor — anchoring the source anchors it, and a second anchor over derived output creates the illusion of independent evidence where none exists. What genuinely needs anchoring is (a) the moment something enters the record as fact, (b) the moment a human authority approves a state change, and (c) the moment something crosses out of Loomworks into the world.
This rule is also what makes a stated absence honest rather than convenient. A room that computes and does not decide has a reason to be quiet, and the reason is stateable in one sentence.
A worked example from work that just shipped: CR-2026-225 added embedding rows derived from committed assertions. Under this rule they get no emit — a vector recomputed from an anchored assertion proves nothing the assertion does not already prove. The commit that produced the assertion is the attestable event, and it already has a site. The rule classifies new work correctly without a fresh judgment call each time.
Memory has a site, but the brief is right that it is narrow in the wrong way: one generic write path carrying 22 registered event kinds. Under canon Principle 1 that is exactly the shape the cleanup arc moved away from — an emit at the helper writer rather than at each business event.
Posture: emits, refinement owed. The consequential Memory transitions are the record-entering ones and the Operator-authority ones: commit, revise, retract, discard. Each is a distinct business event and warrants its own site with its own payload. Held drafts and derived projections do not emit — they never entered the record.
Manifestation is Memory organized at a moment in time. The organizing itself is derived: given anchored Memory and a timestamp, it is reproducible, and anchoring the organization would be anchoring an output whose inputs are already anchored.
Posture: no emit on organization. Emit on Operator approval of a Manifestation state transition, where such approval exists. The Operator's approval is not derived — it is a human authority act that Memory alone does not determine, and it is precisely the thing an auditor would want tamper-evident. Whether such approvals exist as distinct state transitions today is an inspection item, not an assumption.
Same shape and same reasoning. Shaping arranges Manifestation-organized knowledge for a specific reader; the arrangement is derived from anchored inputs plus declared shape-type. The Operator's approval of a Shape is the attestable act.
Posture: no emit on arrangement. Emit on Operator approval.
Rendering is where the rule bites hardest in the other direction. Rendering is the boundary: Mode A produces the artifact directly, Mode B produces the specification a downstream production system consumes. Either way something leaves Loomworks, and once it has left, Loomworks' own record of what it sent is the only account that exists.
The auditor's question — what was rendered, from which Manifestation and Shape, by which specialist, under whose approval, and what came back — currently has no tamper-evident answer anywhere in the system. That is the most consequential of the brief's three findings and it is the one I would fix first among the rooms.
Posture: emits, and this is the first room wired. Two sub-cases, and the distinction is load-bearing:
Where the specialist is external, the emit sits at the engine's dispatch and receipt boundary per §2 — never inside the specialist.
Close all nine. No exceptions proposed. In every case named, the identifier is already in scope at the call site, and in several it is used one line above for Loomworks' own audit trail. There is no defensible reason to have data in hand, write it to one audit surface, and drop it from the other. A record that says a grant was consumed without saying which grant is weaker than the code around it already is.
Why this is first in the whole sequence:
Loomworks' answer is yes — it needs its FORAY records to be able to reference each other, and the reason is architectural rather than convenient.
Loomworks' memory model is corrections-preserved and provenance-threaded. Every contribution carries threads to its origin; superseded assertions remain as corrections with their successors; a revision is meaningless without the thing it revised. If Loomworks' own memory can walk those links but its attestation of the same events cannot, the audit trail is structurally weaker than the record it attests — and the gap shows up exactly where it matters most, in corrections. A correction that cannot name what it corrects is the least useful record in the set.
The same holds outside Memory: a consumption that cannot reference the grant that funded it, or a Mode B handoff that cannot reference the Shape it derived from, each loses the one relationship that makes the record answer a real question.
Stated as a requirement, and non-blocking: the FORAY-side mechanism is a separate, already-tracked open question (Validation Scope decision sheet v0.3, R2, unruled). Loomworks does not wait on it.
Interim posture: carry the referenced identifiers as flat payload fields now — which is what §6's forward-gap closure does anyway — and upgrade them to structural references when FORAY's mechanism lands. The records written in the meantime remain upgradable rather than lossy. This is the same reserved-location logic that produced the sixteen sites: put the seam in before the mechanism arrives.
This does not jump the queue. Build list v1.03 carries a ruled order, and the engagement-recall effort has just landed with two Operator acts still outstanding on it. This work is filed and sequenced, not inserted.
Proposed arc shape, in order:
| Stage | Work | Depends on | |---|---|---| | 0 | Step 0 inspection: settle §3's reserved-vs-live question; confirm the nine sites and their available data at current HEAD; determine whether Manifestation and Shaping have distinct Operator-approval state transitions today; locate the Rendering dispatch and receipt boundaries | — | | 1 | R-2: close the nine forward gaps | Stage 0 | | 2 | R-1 Rendering: emit sites at the engine's render dispatch and receipt boundaries, Mode A and Mode B distinguished | Stage 0 | | 3 | R-1 Memory refinement: split the generic site into per-business-event sites | Stage 0 | | 4 | R-1 Manifestation and Shaping: approval-act emits, or stated deferral with the reason recorded | Stage 0's approval-state finding | | 5 | R-3: structural references, when FORAY's mechanism lands | FORAY-side ruling |
Stage 1 is small and self-contained enough to run as a single change request. Stages 2–4 want their own scoping note, because Stage 2 in particular touches the render boundary where a standing note already governs (loomworks-standing-note-shaping-render-boundary).
On R-1 satisfaction: the brief accepts a stated deferral. Stages 2–4 do not all have to execute for R-1 to be met — but every room needs its posture recorded in the record, not just decided in conversation. That recording is what ends "absent, unrecorded."
Rejected alternatives, recorded: (a) wire all four rooms uniformly — treats derived computation as if it were evidence, and produces anchors that prove nothing their inputs do not already prove; (b) defer R-2 until the room work is settled — leaves the forward gaps open for the entire duration and leaves R-3 unanswerable, for no saving; (c) attest Mode B render outcomes — Loomworks does not execute those renders and cannot honestly attest what it did not do.
It does not draft a change request, design emit payloads, name specific call sites in the three unwired rooms, or set dates. It does not settle whether Manifestation and Shaping have distinct Operator-approval transitions today — that is a Step 0 finding, not an assumption. It does not verify the reserved-versus-live question in §3, which no document available on this side can settle. It does not touch the FORAY-side mechanism questions, which belong to FORAY's own pipeline.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — FORAY Audit Coverage — Resolution Proposal — v0.1 — 2026-08-18