DUNIN7 · LOOMWORKS · RECORD
record.dunin7.com
Status Current
Path foray-reference/foray-loomworks-audit-coverage-requirement-v0_1.html

FORAY Audit Coverage — Requirement for Loomworks — v0.1

Date: 2026-08-18 Status: For Loomworks planning. This is not a FORAY CC brief — it carries no gates, no model directive, and is not written for the foray-api build pipeline. It is a cross-project requirement, delivered by the Operator as carrier, per standing seam discipline: cross-project artifacts move through the Operator, not directly between projects. Raised by: Operator, 2026-08-18, on review of the FORAY-side mapping and coverage sweep below. Source evidence (FORAY-side, available in full): loomworks-foray-mapping-v0_2.md (Brief 23/24) — all sixteen current call sites, source-verified, FORAY-record-mapped, live-validated. A supplementary coverage sweep (2026-08-18, read-only, unwritten) against _ANCHOR_PRIORITY and the Manifestation/Shaping/Rendering module trees. Governing FORAY instruments cited below: Asset-Type Reframe decision sheet v0.3; FORAY Root Data Set v0.7.


1. What FORAY is for, stated plainly

FORAY makes a system’s own record of a transition tamper-evident. It does not decide what happened — it proves that what a system said happened hasn’t been altered since. The seed names this directly: FORAY is for “tamper-evident anchoring of transitions,” and defers everything about mechanism to FORAY’s own specification. This document is that specification speaking to the placement, not the mechanism — it states what’s covered and what isn’t, not how to fix it.

2. What Loomworks currently sends to FORAY

Sixteen reserved call sites exist in loomworks-engine today. All sixteen are documented in full — real source, real data availability, the real FORAY record each would produce, and live validation results — in loomworks-foray-mapping-v0_2.md. Summary:

3. What is missing — three findings, in order of how much they matter

3.1 — Three of the seed’s four rooms have no FORAY presence at all. The seed names four rooms: Memory, Manifestation, Shaping, Rendering. Only Memory has a call site, and even that is narrow — one generic write path carrying 22 registered event kinds, none of them determinably Manifestation, Shaping, or Rendering activity by name, call site, or comment. A direct search of every Manifestation-, Shaping-, and Rendering-named module in the repo — agents/render_*, agents/shaping*, engagement/manifestation*, engagement/render*, engagement/shape*, delegation/rendering.py, rendering/, render_specialists/, the corresponding API routers — found zero occurrences of FORAY or foray in any of them. Not unwired-but-present, the way one credit site (referral_credit) exists in code with no live caller yet. Genuinely absent — no marker, no reserved location, nothing.

Whether this is deliberate sequencing or an oversight is not recorded anywhere in source. FORAY takes no position on which. This document exists so the gap is a decision Loomworks makes deliberately, rather than a fact discovered later by an auditor.

3.2 — At nine of the sixteen existing sites, real identifying data is available and not sent. A grant id, an approving operator’s UUID, a converted-referrer’s identity, the person id behind a settings change — all genuinely in scope, often used one line above the FORAY call for Loomworks’ own audit trail, and never forwarded into the FORAY payload. This is independent of room coverage: it means even the rooms that are wired are sending less than they have. Full detail, site by site, is in the mapping document’s findings.

3.3 — No current record can reference another. Every one of the sixteen sites produces a single-Action record with no other component in it — structurally, not by choice. A credit consumption can’t reference the grant that funded it; a correction can’t reference what it corrects. This is not a missing field; it’s a ceiling on what the current per-call-site emitter design can express at all, regardless of what data is forwarded.

4. Why this is newly actionable

Until today, the eleven credit sites had no honest way to populate FORAY’s currency field — Loomworks credits aren’t a national currency, and FORAY’s F8 was defined as one. That constraint is gone. The Operator ruled F8 an asset-type identifier, scheme-qualified, governed by nobody but the scheme’s own owner (Asset-Type Reframe v0.3, R1/R2). Every one of the eleven credit sites is now expressible with real arithmetic under LOOMWORKS:<asset_id>.

That removes the one technical reason credit could plausibly have dominated FORAY coverage while three whole rooms had none. Whatever explains the current shape, it isn’t “FORAY couldn’t represent the other rooms” — nothing about Manifestation, Shaping, or Rendering activity was ever blocked by the currency constraint. If a reason for the current coverage exists, it’s a Loomworks-side sequencing decision, not a FORAY-side limitation.

5. The requirement

Stated as outcomes. How Loomworks meets them is Loomworks’ engineering decision, not this document’s.

R-1 — Every room the seed names as producing transitions has a determinable FORAY posture. Either it emits, or a stated reason exists for why it doesn’t yet. “Absent, unrecorded” is the state this document exists to end — not necessarily by wiring everything immediately, but by making the absence a decision rather than a gap nobody chose.

R-2 — The nine forward-gap sites are closed, or a reason is stated for each. Where identifying data is genuinely available and dropped, either forward it or record why not. This is independent of R-1 and can be done first — it touches no new room, only sites that already emit.

R-3 — The cross-record question gets an answer. Whether Loomworks needs its FORAY records to reference each other is a Loomworks question about what its own audit trail should prove. If the answer is yes, that requirement should be named — the FORAY-side mechanism for it is a separate, already-tracked open question (Validation Scope decision sheet v0.3, R2, unruled) and doesn’t block Loomworks from stating what it needs.

6. What this document does not do

It does not design Loomworks’ solution. It does not set a timeline. It does not override Loomworks’ own build sequencing or its authority to decide that some of this is deliberately deferred — R-1 is satisfied by a stated deferral, not only by immediate coverage. It does not add any new commitment to the seed; §7 confirms that.

7. Seed conformance

Checked against the standing rule that any Loomworks-touching work is verified against the current seed before proceeding. No conflict. The seed names FORAY for tamper-evident anchoring of transitions and defers mechanism to FORAY’s specification — a document stating which transitions are and aren’t currently covered is inside that deferral, not in tension with it. This document commits Loomworks to nothing the seed hasn’t already named; it asks that the naming be made complete, deliberately, room by room.

8. Handoff

This document is FORAY-side work product, addressed to Loomworks, carried by the Operator per seam discipline. It is input to Loomworks’ own planning, not a directive issued by the FORAY pipeline. The evidence behind every claim above — full source, full mapping, live validation — is loomworks-foray-mapping-v0_2.md, available to whoever picks this up on the Loomworks side.


DUNIN7 — Done In Seven LLC — Miami, Florida FORAY — Audit Coverage Requirement for Loomworks — v0_1 — 2026-08-18