Version: v0.2
Date: 2026-08-18
Status: Proposal for Operator ruling. Nothing built; no change request drafted. Decisions D1–D9 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.
Changes from v0.1: the source evidence (loomworks-foray-mapping-v0_2, engine HEAD eb9392f) was read in full after v0.1 was drafted. It settles v0.1 §3's open question and surfaces four items the brief did not raise. Change log at §11. v0.1 stands as sibling; nothing overwritten.
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; loomworks-foray-mapping-v0_2 (site-by-site source evidence); 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 answers with a principle — attest what enters the record and what leaves the system; do not attest derived computation — and applies it 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 has a site, but a coarse one that also drops everything it holds.
The cheapest work comes first and is independent of all of it: close the forward gaps. That is editing payload construction at sites that already exist, and it is also what makes the cross-record question answerable later — identifiers have to be present in the records before anything can link them.
The evidence settles the largest uncertainty in v0.1 and it settles it favorably. Nothing is transmitting to FORAY today. All sixteen sites are reserved stubs; the mapping's live validation checked hand-built records against FORAY's schema, not live emissions. Every item in this proposal is therefore substrate preparation with no production behavior at risk.
It also surfaces something neither the brief nor v0.1 named: Loomworks cannot emit to FORAY at all yet, for a reason unrelated to coverage. No convention exists for minting FORAY-side record identifiers — the mapping invented one for its worked examples and states plainly that no such scheme exists in either repository. That decision gates live emission from every site, wired or not, and it belongs at the front of the sequence.
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, reached 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:
Against the cleanup arc's canon: the reserved-location pattern (_foray_reserved_emit("<namespace>.<event_kind>", payload) with # FORAY_RESERVED_LOCATION 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 below uses that pattern and that principle; nothing here invents a new emission mechanism.
v0.1 flagged this as unverified and carried the reserved reading provisionally. The mapping settles it, and the source is explicit:
POST /api/anchor was never called._foray_reserved_emit(...) call under a # FORAY_RESERVED_LOCATION marker — the cleanup arc's reserved-location pattern, exactly as the Loomworks record describes it.Consequence, and it is good news for sequencing: every item in this proposal is substrate preparation. Closing forward gaps changes payload construction in stubs; wiring Rendering adds stubs in new places. No production behavior changes anywhere in Stages 1–4, which lowers the risk posture of the whole arc and means the work can proceed without a deployment-coupled halt.
One qualification the mapping is careful about, worth carrying: a schema pass certifies shape, not truth. At the five governance-shaped sites, F3 and F8 currently hold stated placeholders ("UNATTRIBUTED", "LOOMWORKS:NONE") because the schema forbids nulls and no real value reaches the emit. Those records validate and would still say nothing. Shape-conformance is not coverage.
One rule, applied consistently, rather than four judgment calls:
> 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 recomputable 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 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 narrow in the wrong way: one generic write path carrying roughly twenty registered event kinds. Under canon Principle 1 that is the shape the cleanup arc moved away from — an emit at the helper writer rather than at each business event.
The evidence sharpens this beyond what the brief said. At that site the object id, the engagement id, the actor id, and the actor kind are all in scope as required parameters, and none of them reach the payload, which carries only an event id and an anchor priority. That is why F3 there is the placeholder "UNATTRIBUTED" — no identity reaches the emit at all. So Memory is simultaneously the one wired room and one of the worst forward-gap sites in the set.
Posture: emits, refinement owed, and its forward gap closes in Stage 1 with the others. The consequential Memory transitions are the record-entering and Operator-authority ones — commit, revise, retract, discard. Each is a distinct business event warranting its own site and 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 is derived: given anchored Memory and a timestamp it is reproducible, and anchoring it would anchor 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 Memory alone does not determine, and it is precisely what an auditor would want tamper-evident. Whether such approvals exist as distinct state transitions today is an inspection item, not an assumption.
Same shape, 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 — has no tamper-evident answer anywhere in the system today. That is the most consequential of the brief's three findings and the one to fix first among the rooms.
Posture: emits, 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 them all. No exceptions proposed. In every case the identifier is already in scope at the call site, and in several it is used one line above for Loomworks' own audit trail — the settings sites pass person_id into the audit write immediately before the FORAY emit, then drop it. 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.
Three items the evidence adds to this stage, not in the brief's count of nine:
flow.id is read before flush, unlike its siblings, which flush first. This is not a forward gap — it is a correctness bug in what the record would carry, and it should be fixed with the same pass rather than filed separately.Why this stage is first overall:
Loomworks' answer is yes — it needs its FORAY records 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 evidence makes this concrete in three places: a corrective record with no pointer to the proposal it corrects; a credit consumption whose four token-leg records have no link to the credit-debit record produced in the same act; a deletion that triggers balance-zeroing records with nothing tying them together.
The evidence also sharpens the ceiling, and the sharpening matters. The mapping's own recheck upgraded this from a data gap to a structural one: under the current per-call-site, single-Action-record design, a reference field cannot exist at all — there is no second component in the record for a reference to resolve against. Forwarding more data does not fix it. That means R-3 is not a payload change at any point; it is a record-shape change, and it stays properly outside Stages 1–4.
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 closure does anyway — and upgrade them to structural references when FORAY's mechanism lands. Records written meanwhile stay upgradable rather than lossy. This is the same reserved-location logic that produced the sixteen sites: put the seam in before the mechanism arrives.
The mapping states it plainly and it is stated once there rather than sixteen times, which is why it is easy to miss: no scheme exists in Loomworks for minting FORAY-side record identifiers. The mapping invented a legible one for its worked examples and names it as an open design decision not yet made in either repository.
Two consequences, and the second is the important one:
A related open item at the same level: two sites carry provider token assets rather than Loomworks-scheme assets, and the mapping breaks its own convention there with a different prefix. Whether Loomworks' asset-type scheme admits foreign-scheme identifiers is a convention question of the same kind — small, but unruled, and it will recur every time a non-Loomworks asset appears in a record.
Both belong in the same stage: a short conventions ruling, ahead of any emitter work.
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.
| Stage | Work | Depends on | |---|---|---| | 0 | Step 0 inspection: confirm the 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; confirm the suspension-site ordering defect | — | | 1 | Conventions ruling (§8): FORAY-side identifier minting scheme; foreign-asset-scheme admissibility | — (can run in parallel with Stage 0) | | 2 | R-2: close the forward gaps, including Memory's; fix the suspension ordering defect; de-duplicate the settings emit construction | Stage 0 | | 3 | R-1 Rendering: emit sites at the engine's render dispatch and receipt boundaries, Mode A and Mode B distinguished | Stage 0 | | 4 | R-1 Memory refinement: split the generic site into per-business-event sites | Stage 0, Stage 2 | | 5 | R-1 Manifestation and Shaping: approval-act emits, or stated deferral with the reason recorded | Stage 0's approval-state finding | | 6 | R-3: structural references, when FORAY's mechanism lands | FORAY-side ruling |
Stage 2 is small and self-contained enough to run as a single change request. Stages 3–5 want their own scoping note, because Stage 3 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 3–5 do not all have to execute for R-1 to be met — but every room's posture must be recorded in the record, not merely decided in conversation. That recording is what ends "absent, unrecorded."
Rejected alternatives, recorded: (a) wire all four rooms uniformly — treats derived computation as evidence and produces anchors proving nothing their inputs do not already prove; (b) defer R-2 until the room work settles — leaves gaps open for the whole duration and 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; (d) treat the identifier-minting gap as an emitter-build detail — it is a convention decision, and discovering it during a build is how conventions get set by accident.
The source evidence (loomworks-foray-mapping-v0_2, engine HEAD eb9392f, sixteen sites documented site by site) was read in full after v0.1 was drafted. v0.1 stands as sibling.
Unchanged from v0.1: the attestation principle (D1) and every room posture derived from it; Rendering first with the Mode A/Mode B distinction (D2); R-2 before the room work (D3); R-3's answer and interim carry (D4); queue posture (D5); substrate-only emit placement (D6); §2's conformance findings; the rejected alternatives, now with a fourth.
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 rule the identifier-minting convention; it names the decision and where it belongs. 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.2 — 2026-08-18