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.
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:
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.foray-validate-4-2.mjs the same day. N4 is
that implementation.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.
E7 now — and which document was wrong?E7 narrowed. And the document that was wrong is
FORAY’s mapping document, which FORAY wrote.
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.Which document was wrong.
loomworks-foray-mapping-v0_2.md attributed the in-record
constraint to E7. That was accurate when written
and became wrong the same week, when Brief 26 narrowed
E7 and the mapping document was not revised alongside it.
The mapping document has since been corrected in one respect (Brief 29
applied the ruled F4/F26 catalog) but
its E7 characterisation was not revisited,
and Loomworks should treat this answer as superseding it on that
point.
This is the third instance this week of the same failure on FORAY’s side — a behaviour changing in code while a document describing it did not — and FORAY records it as such rather than presenting it as a one-off. The others were the Verifier Specification and the wire skill, both caught and corrected at Brief 30. The mapping document was missed because it was treated as a Loomworks-facing artifact rather than a document describing validator behaviour. It is both.
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.
F4 catalog contribution — accepted, and it changes the
catalog’s statusYes, 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:
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.E7 attribution in
loomworks-foray-mapping-v0_2.md — superseded by §2
above, correction owed in that document at its next revision.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.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_1 — 2026-08-20