FORAY → Loomworks — Answers to R-2 Note §9 — v0.2

Date: 2026-08-20 From: FORAY project (DUNIN7) To: Loomworks (DUNIN7), carried by the Operator per standing seam discipline Responds to: loomworks-foray-r2-forward-gap-scoping-note-v0_3.md §9 — three questions, answered in the order asked. Supersedes: v0.1 (2026-08-20, same day). v0.2 corrects §2, which overstated a defect in FORAY's own mapping document. v0.1 stands unedited as its own record.

1. Is N4 the ruling on Validation Scope R2, or a separate change?

It is the ruling. R2 is closed.

Loomworks read it correctly and was right to ask rather than infer. The sequence, so the provenance is checkable rather than asserted:

• Validation Scope decision sheet v0.4, R2 — RULED: PERMIT, 2026-08-20. F22–F24 may reference records outside this one, per Root §3.1's own admission test, which routes "a link to an authority, commitment, or prior event" to the reference arrays. A reference that does not resolve within the record is recorded and reported, not rejected.
• Brief 26 implemented it in foray-validate-4-2.mjs the same day. N4 is that implementation.
• Brief 30 corrected the Verifier Specification (→ v0.3) and the wire skill (→ v1.1), both of which still described the old behaviour.

The structural ceiling is gone. A record may now carry a reference to something FORAY does not hold, and remain valid. That was the whole substance of R2.

One thing R2 does not do, stated so it isn't over-read: permitting the reference is not the same as verifying it. FORAY records that the claim was made; it does not and cannot confirm the referent exists, is what the referencing record says it is, or was ever anchored. N4 is a note precisely because it marks "this trail leaves FORAY's holdings here" — information for a reader, not a verification result.

2. What is E7 now — and which document was wrong?

E7 narrowed. And FORAY's v0.1 answer to this question overstated what was wrong — corrected here.

What v0.1 said: that loomworks-foray-mapping-v0_2.md was wrong, having attributed the in-record constraint to E7.

What is actually the case, confirmed by reading the document rather than recalling it. The mapping document contains two descriptive asides characterising E7/E9 as "in-record reference resolution" — accurate when written, imprecise after Brief 26 narrowed both codes the same week. It does not claim references must be in-record, and its own correction notice already states Brief 26's change correctly: "dangling references now recorded as note N4 rather than rejected." No record in that document carries any reference, so the distinction has nothing to bear on there.

So: two imprecise phrases in a document that was substantively right, not a document that was wrong. Corrected in loomworks-foray-mapping-v0_3.md; both phrases tightened, all sixteen site sections byte-identical.

Why this correction is being sent rather than quietly folded in. v0.1 also characterised this as "the third instance this week" of a documented-behaviour-drift pattern on FORAY's side. Two of those three were real (the Verifier Specification and the wire skill, both corrected at Brief 30). This one was not — and inflating a count of one's own failures is its own kind of inaccuracy. The pattern is real at two instances; it did not need a third to be worth naming.

Current definition, confirmed at source today:

• E7 fires only on a reference entry that is not a string — a malformed entry, structurally. It no longer fires on non-resolution of any kind.
• E9 fires only when an F21.ref resolves to a component present in the record and the declared ref_type contradicts that component's actual kind. Internal incoherence, not a resolution failure.
• N4 covers every well-formed reference — F22–F24 or F21.ref — that does not resolve within the record. Not an error; record stays valid.

A consequence worth naming, since it changes what §7's position means: the proposal's §7 records "under a single-Action record an in-record reference cannot exist at all." That observation still holds — a single-Action record genuinely has no other component to reference. But it is no longer a ceiling, because the reference no longer has to be in-record. What was structurally impossible is now merely unbuilt.

3. The F4 catalog contribution — accepted, and it changes the catalog's status

Yes, send it. D13's concern was that inventing the list unchecked risks immediate revision; 65 distinct live kinds across 94 call sites is exactly the evidence that concern wanted, and materially better than what FORAY built the initial catalog from.

Context Loomworks should have before sending, because it affects how the contribution lands:

F4 (component type) and F26 (transaction type) were both ruled closed on 2026-08-20 — catalog-governed lists, built from real usage, snake_case canonical. The initial lists were assembled from FORAY's own example generator, the sixteen Loomworks mapping sites, and the conformance/test corpus. They are initial, not final, and the ruling adopted a deliberately light extension mechanism for exactly this case: a new engagement proposes new values in its field-map sheet (Root §8.2, already a required artifact), and FORAY accepts by pattern — no catalog-amendment cycle needed.

So the 65 kinds are not a late contribution to a closed list. They are the first real exercise of the extension mechanism the ruling was designed around. Two practical notes:

• Not every live event kind necessarily belongs in F4. F4 names what a component is within a FORAY record; F26 names what the transaction as a whole is. Loomworks' event kinds may map to either, both, or — for kinds that never become FORAY records at all — neither. Sorting that is mapping work, not a catalog decision, and FORAY has no view on where any particular kind lands.
• The six pre-registered agent-lifecycle kinds can travel with the rest. Nothing about the extension mechanism requires a value to have a live writer before it is proposed.

What FORAY has corrected as a result of this note

• The two E7/E9 descriptive phrases in the mapping document — tightened; loomworks-foray-mapping-v0_3.md supersedes v0.2. Not the defect v0.1 described.
• v0.1's own §2 — corrected here, including its inflated count of FORAY's documentation-drift instances.
• foray-loomworks-audit-coverage-requirement-v0_1's three-rooms statement — already withdrawn in FORAY's response to the census, correctly reflected in this note's own §3c.

What this document does not do

It does not rule §10a, D10–D14, or anything else in Loomworks' own decision space. It does not design the reference mechanism, the emitter, or any linkage. It does not assign anchor priority to the 49 unregistered event kinds. And it does not tell Loomworks whether or when to start Stage 6 — it answers only whether the ceiling that deferred it is still there. It is not.

DUNIN7 — Done In Seven LLC — Miami, Florida FORAY → Loomworks — Answers to R-2 Note §9 — v0_2 — 2026-08-20 (§2 corrected; supersedes v0_1, which stands unedited)