Version: v0.2
Date: 2026-08-18
From: Loomworks (DUNIN7)
To: FORAY project (DUNIN7), carried by the Operator per seam discipline
Changes from v0.1: six FORAY instruments were retrieved from the FORAY repository (read-only, repository unmodified) and read against v0.1's nine items. Four items narrow, one reverses, one splits, two are answered outright. Change log at §12. **v0.1 stands as sibling; nothing overwritten — in particular, v0.1's decision not to press for the Validation Scope R2 ruling is preserved in §12 alongside the reversal, because the reversal is the substantive finding.**
Occasioned by: Operator ruling on loomworks-foray-coverage-resolution-proposal-v0_2, D1–D9 accepted 2026-08-18.
Answers feed: proposal v0.2 Stage 1 (conventions ruling), Stage 3 (Rendering emit design), Stage 6 (cross-record references).
Instruments now held by Loomworks: foray-transaction-v4_2.schema.json; FORAY Root Data Set v0.7; Asset-Type Reframe decision sheet v0.3; Validation Scope decision sheet v0.3; ratified catalog addendum v1.1; wire skill FORAY_SKILL_WIRE-4_2-v1_0. Two further instruments are named in those documents but not yet held — see §11.
Status: Request. Nothing is blocked today — no Loomworks site transmits — but every item below stands between Loomworks and its first real emission.
Loomworks asked FORAY nine questions in v0.1 of this request. Six FORAY documents have since been read directly, and they answer some of it — which is what this version records, so FORAY is asked only what its own instruments do not already say.
Two questions are settled. The adaptor sends an all-null anchor block and FORAY's pipeline fills it. And reference arrays today resolve strictly inside their own record.
That second answer turned out to matter more than the question did. The Validation Scope decision sheet says the in-record narrowing was never the design — the Root's own admission test assigns reference arrays to prior events, meaning they were always meant to reach outside the record, and the validator narrowed them by building its component index from one record alone. The sheet carries an unruled decision to permit cross-record references, marked as recommended, and its own header states that it blocks all adaptor and reference-implementation work.
So Loomworks reverses a position it took in v0.1. That version deliberately declined to press for that ruling, asking only the narrower factual question about current behaviour, on the reasoning that FORAY's rulings are FORAY's own timing. That reasoning was wrong on the facts: the sheet itself names this as blocking adaptor work, and Loomworks' adaptor is the adaptor in question. Loomworks now asks for the ruling — and asks that its own answer to the same question be treated as input, since Loomworks has independently ruled that it needs cross-record references and the reason is the same one the sheet gives.
Four questions narrow rather than disappear, because the documents settle their neighbours without settling them. The hashing question is the clearest case: a Verifier Specification not among the six has fixed the canonical byte form and the anchor chain, but nothing states what goes into each component hash or how the root derives from them — so the request now names that gap precisely rather than asking FORAY to re-explain what it has already written.
What Loomworks needs. Whether FORAY specifies a format for F1: character set, length bounds, uniqueness scope (global across originators, or per-originating-system), and whether the adaptor mints it or FORAY assigns it on receipt. If the adaptor mints it, whether originator prefixes are registered or freely chosen.
What the instruments say. Existence only. The schema constrains F1 to a non-empty string and comments that it identifies the evidence record itself, with source-linkage living in F2. The catalog gives a one-line gloss; Root v0.7 §6.2 gives its job — retrieval and citation — and no format. The template's DOMAIN_YYYY_QN_DESCRIPTOR is illustrative, not a rule.
Why it still blocks. F2 is settled — the originating system's key travels verbatim under adaptor-mediated origination. F1 has no rule anywhere, and Loomworks would otherwise invent one permanently and silently.
What Loomworks needs, precisely: (a) what byte sequence is canonicalized into each entry of component_hashes — the component array alone, or something else, and how an empty array hashes; and (b) how merkle_root derives from those component hashes.
What is already settled, and not being re-asked. Verifier Specification v0.2 §6.1 fixes the canonical byte form as JCS (RFC 8785) with a spec-defined member order and a stricter number rule than JCS's own. Its §5.4 fixes the anchor chain: transaction hash over the body bytes, leaf as a salted hash of that, and in direct mode the tree root is the leaf itself. Loomworks does not need any of that restated.
Why the gap remains. That chain hashes the whole body. Neither the Verifier Specification nor the six instruments states what is canonicalized into each component_hashes entry, nor how merkle_root relates to them — the schema leaves both unconstrained, and the wire skill treats them as placeholders the anchoring pipeline replaces. Root v0.7 §7.1 books the surrounding rule as a spec work item and warns in its own words that without it a second implementer breaks verification. Loomworks would be that second implementer.
If unanswered. Loomworks cannot emit a meaningful record. A hash computed differently from the verifier's expectation is worse than no hash: it looks anchored and proves nothing.
What Loomworks needs. For POST /api/anchor: authentication; idempotency semantics (may the same F2 be submitted twice — dedupe key, and is re-submission an error or a no-op); rate limits; response shape on success and per failure class; synchronous or queued; and the retry posture FORAY expects of a well-behaved adaptor.
What the instruments say. The six document only the validation endpoint and its result shape and codes. The anchor endpoint is named in Evidence Custody Model v0.6 §5 as a scope note, with no auth, idempotency, retry, or failure-class contract stated there either.
Why it blocks. Loomworks' emitter will be asynchronous and post-transaction — the shape shipped in CR-2026-225, where commit availability must never depend on an external API. That design requires knowing what a retry means to the receiver. An emitter retrying into a non-idempotent endpoint manufactures duplicate evidence, which is its own integrity problem in an append-only system.
blockchain_anchor — half answered; one question remainsAnswered, and Loomworks will build to it: the adaptor emits the all-null block and FORAY's anchoring pipeline replaces it. The wire skill states the all-null form is the canonical pre-anchoring state.
Still needed: whether the anchoring result is returned to the adaptor, retrievable later, or neither. The nearest statement — the custody model's note that the direct endpoint returns the leaf salt to the caller once and does not retain it — establishes that something returns, but says nothing about the anchor fields.
Why it matters now rather than later. It decides whether Loomworks owes itself an anchor-receipt column, which is cheaper to answer before the tables exist than after.
Current behaviour, answered: reference arrays resolve strictly in-record. The wire skill requires every referenced identifier to resolve to a component present in the record (E7), and the Validation Scope sheet's own inventory records this as narrowed below what the Root assigns.
What Loomworks now asks for: the R2 ruling itself — permit cross-record references, or keep the narrowing.
Why Loomworks reverses v0.1's position. v0.1 deliberately declined to press for this ruling, asking only what the current wire permits, on the reasoning that FORAY's rulings belong to FORAY's own timing. That reasoning does not survive contact with the sheet. The sheet's status header states that it blocks all adaptor and reference-implementation work — and Loomworks' adaptor is the adaptor in question, so the ruling is not adjacent to this request, it is the gating item for the whole of Stage 6 and part of Stage 3. Declining to ask was politeness at the cost of accuracy.
Loomworks' answer to the same question, offered as input rather than pressure. Loomworks has independently ruled (proposal v0.2, D4, accepted 2026-08-18) that it needs its FORAY records to reference each other, on architectural grounds: Loomworks' memory model is corrections-preserved and provenance-threaded, and if its own memory can walk those links while its attestation of the same events cannot, the audit trail is structurally weaker than the record it attests. The concrete cases are specific and already documented — a corrective record with no pointer to the proposal it corrects; four token-leg records and the converted credit-debit record from a single act, mutually meaningless and mutually unlinked; a deletion triggering balance-zeroing records with nothing tying them together.
Loomworks notes, without arguing FORAY's case for it, that the sheet reaches the same place on its own reasoning — that the Root's admission test already routes a link to a prior event into the reference arrays, that the arrays were always meant to reach outside the record, and that cross-record resolution already exists in the bundle-class verifier though not in the 4.2 path Loomworks would use.
Consequence either way, so the ruling is useful in both directions. Permit → Loomworks links records at emit time with no record-shape change, and proposal v0.2's Stage 6 collapses into the earlier stages. Keep the narrowing → Loomworks must emit multi-component records, a genuine change to the per-call-site emitter design, and Loomworks would want FORAY's view on whether multi-component records are the intended pattern for related events. Loomworks will not commit an adaptor design to in-record-only while R2 is open.
Whether scheme prefixes are registered anywhere or freely chosen; whether LOOMWORKS: is claimable as Loomworks' own; and how a foreign asset should be named — an Anthropic API token consumed by Loomworks is not a Loomworks asset. Specifically whether PROVIDER:-style generic prefixes are admissible, or whether foreign assets should carry the issuing party's own scheme. The reframe (v0.3 R1/R2) made the eleven credit sites expressible at all, and Loomworks has adopted LOOMWORKS:<asset_id> with its real tier-identified names; two sites carry provider tokens and break that convention, flagged in the mapping and unresolved.
Whether FORAY has an intended representation for non-financial governance events, or whether the placeholder pattern is the expected shape. Five of the sixteen Loomworks sites have no asset and no amount; the schema forbids nulls in F3 and F8, so those records carry "UNATTRIBUTED" and "LOOMWORKS:NONE". They validate and say nothing. If a governance shape exists, Loomworks should use it; if the placeholder is genuinely the pattern, Loomworks would like that confirmed so it stops reading as a defect.
F3 owner form — cleartext or hashed — unchanged
Whether FORAY prefers, permits, or expects the sha256:-prefixed owner form over cleartext, and if hashed, the canonical derivation. Loomworks' identity is a system-assigned UUID and its architecture leans structurally toward privacy; putting a raw person UUID into an external attestation record is a decision worth making deliberately rather than by default.
F4 and F26 vocabularies — split, and both halves are gaps
F4 — the requirement is ruled, the list is missing. Root v0.7 §7.2 rules five fields to closed, catalog-governed code lists, F4 among them, and the Asset-Type Reframe sheet corroborates. The list itself does not exist: the catalog gives F4 only a format (a snake_case type label) and the schema only a string type. The contrast is sharp — F17's vocabulary is published, and ref_type's is a schema enum. Loomworks asks for F4's code list.
F26 — the controlled status is itself unresolved. F26 is a ratified catalog entry that selects the reference set, but §7.2's closed-list enumeration omits it and no vocabulary is stated anywhere. Loomworks asks whether F26 is meant to be catalog-governed, and if so for its list.
Why this shapes work rather than blocks it. Loomworks emits its own namespaced kinds today and will add Rendering kinds under proposal v0.2 Stage 3. If a vocabulary exists or is owed, the Rendering kinds should be drawn from it rather than invented and reconciled later.
Recorded so FORAY does not spend effort on ground already covered: the canonical byte form and member-order rule (Verifier Specification v0.2 §6.1); the anchor hash chain (§5.4); the all-null pre-anchoring state of blockchain_anchor and its ownership by the anchoring pipeline; the current in-record-only behaviour of reference arrays; the ruled-closed status of F4; and the validation endpoint's contract and result codes.
Both are named in documents Loomworks now holds, and both bear directly on items above:
POST /api/anchor is named at all (item 3), and its leaf-salt return note is the nearest thing to an answer for item 4.The cost of reasoning about an unheld instrument has already been paid once in this seam: the mapping's own correction notice records sixteen structurally wrong records in its first pass, built without the schema and wire skill in hand.
Not a schedule. Not FORAY-side implementation work. Not a position on Loomworks' own coverage sequencing, which is ruled (proposal v0.2, D1–D9).
No longer on this list, and the removal is the point: v0.1 placed the Validation Scope R2 ruling here, explicitly narrowing item 5 to "what the current wire permits" and stating that Loomworks did not press for the ruling. §5 reverses that. The prior position is preserved here rather than deleted, because the reversal — and its cause, the sheet's own blocks-all-adaptor-work header — is a finding in its own right.
Six FORAY instruments retrieved read-only from the FORAY repository (repository unmodified) and read against v0.1's nine items.
merkle_root derivation, citing Verifier Specification v0.2 §6.1/§5.4 as already settled so FORAY answers the remaining gap rather than re-explaining.F4's closed-list status is ruled but its list is missing; F26's controlled status is itself unresolved.DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks → FORAY — Information Request — v0.2 — 2026-08-18