Version: v0.3
Date: 2026-08-18
From: Loomworks (DUNIN7)
To: FORAY project (DUNIN7), carried by the Operator per seam discipline
Changes from v0.2: the last two instruments (Verifier Specification v0.2, Evidence Custody Model v0.6) were retrieved read-only and read against v0.2's items. One item is fully answered and discharged; two sharpen against what the instruments do specify; the instrument-request section is discharged entirely. Change log at §13. v0.1 and v0.2 stand as siblings.
Status: Ready to send. Every question below has been checked against all eight FORAY instruments Loomworks now holds and is not answered by any of them.
Occasioned by: Operator ruling on loomworks-foray-coverage-resolution-proposal-v0_2, D1–D9 accepted 2026-08-18. Filed at build list v1.04.
Instruments 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; Verifier Specification v0.2; Evidence Custody Model v0.6.
This is the version to answer. Loomworks has now read all eight FORAY instruments it could find and has removed from this request everything they settle — including two items that earlier versions asked about. What remains is seven questions, none of which any FORAY document answers.
Three of them block Loomworks from emitting a single real record: there is no rule anywhere for minting the record identifier, no stated rule for computing the envelope's own hashes, and no contract for the anchor endpoint.
One is a ruling rather than a fact: the Validation Scope sheet carries an unruled decision on whether reference arrays may reach outside their own record, and that sheet's own header says it blocks all adaptor work. Loomworks asks for it and offers its own answer as input.
Three shape record construction rather than block it.
One thing the instruments settled changes Loomworks' own design, and it is recorded here so FORAY sees the consequence. The anchoring response comes back exactly once and nothing in it is recoverable from FORAY afterwards. That makes response capture part of the anchoring act itself — an emitter that fires and forgets produces evidence that can never be verified. Loomworks' planned emitter was going to be fire-and-forget, on the pattern it uses elsewhere. It now cannot be, and §11 records that.
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.
Checked against all eight; existence only. The schema constrains F1 to a non-empty string and comments that it identifies the evidence record itself, 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 Verifier Specification lists it among transaction-level requireds without constraining its value. The template's DOMAIN_YYYY_QN_DESCRIPTOR is illustrative, not a rule.
Why it 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.
component_hashes and merkle_root — are they computed at all, and by what rule?
The question, sharpened by what the Verifier Specification actually specifies. Verifier Specification §5.4 fixes the anchor commitment chain, and that chain does not pass through merkle_root: the transaction hash is taken over the submitted body bytes exactly as submitted — no canonicalization, no whitespace adjustment — then salted into a leaf, and in direct mode the tree root is the leaf itself. So the anchoring commitment is over whole body bytes, and the envelope's own component_hashes and merkle_root sit outside that chain.
What Loomworks therefore asks:
component_hashes and merkle_root computed and verified at all, or are they vestigial envelope members that a producer may leave as placeholders permanently?component_hashes entry (the component array alone, or something else), how does an empty array hash, and how does merkle_root derive from those hashes?What Loomworks is not re-asking. The canonical byte form and member ordering (Verifier Specification §6.1 — JCS with a spec-defined member order and a stricter number rule than JCS's own) and the §5.4 anchor chain. Loomworks will build to both.
Why it blocks. Every record in Loomworks' mapping carries the literal sha256:PLACEHOLDER in all four component slots and in merkle_root, and the wire skill treats them as placeholders the anchoring pipeline replaces. If they are genuinely vestigial, Loomworks needs that confirmed so it stops treating a placeholder as a defect. If they are verified, a value computed differently from the verifier's expectation is worse than no value: it looks anchored and proves nothing. Root v0.7 §7.1 books the surrounding rule as a spec work item and warns that without it a second implementer breaks verification. Loomworks is that second implementer.
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 per success and failure class; synchronous or queued; and the retry posture FORAY expects of a well-behaved adaptor.
Checked against all eight; the direct path is undocumented. Evidence Custody Model v0.6 names the route only in a scope note. The retry and failure machinery it specifies governs the batched-mode export to a client-designated target — bounded exponential backoff from one minute to a one-hour cap, with a durable-ack contract — not the direct endpoint. Its single idempotency statement (CF-8) concerns duplicate batch anchoring after a crash, likewise not the direct endpoint. Authentication appears only as an incidental historical mention. The other seven instruments document the validation endpoint only.
Why it blocks, and why §11 makes it sharper. Loomworks' emitter is asynchronous and post-transaction, so it must know what a retry means to the receiver — retrying into a non-idempotent endpoint manufactures duplicate evidence in an append-only system. And now that response capture is known to be mandatory and unrepeatable (§11), the failure classes matter more, not less: Loomworks must know which failures are safe to retry and which have already consumed the one response.
Current behaviour, answered by the instruments: reference arrays resolve strictly in-record. The wire skill requires every referenced identifier to resolve to a component present in the record (E7); the Validation Scope sheet's own inventory records this as narrowed below what the Root assigns.
What Loomworks asks for: the R2 ruling itself — permit cross-record references, or keep the narrowing.
Why Loomworks asks, having earlier decided not to. Request v0.1 deliberately declined to press for this ruling, asking only what the current wire permits, reasoning that FORAY's rulings belong to FORAY's own timing. The sheet's status header states that it blocks all adaptor and reference-implementation work — and Loomworks' adaptor is the adaptor in question, which makes the ruling the gating item for a whole stage of Loomworks' plan rather than something adjacent to it. The prior position is preserved in §12 rather than deleted.
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 cases are concrete and 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.
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 real 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 Loomworks' sixteen 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.
F4 and F26 vocabularies
F4 — requirement ruled, list missing. Root v0.7 §7.2 rules five fields to closed, catalog-governed code lists, F4 among them; the Asset-Type Reframe sheet corroborates. The list does not exist anywhere: the catalog gives F4 only a format (a snake_case type label), the schema only a string type. The contrast is sharp — F17's vocabulary is published, ref_type's is a schema enum. Loomworks asks for F4's code list.
F26 — controlled status 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 rather than blocks. 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, those kinds should be drawn from it rather than invented and reconciled later.
Recorded so FORAY spends no effort on covered ground: the canonical byte form and member-order rule (Verifier Specification §6.1); the anchor hash chain over submitted body bytes, its salted leaf, and direct-mode tree root (§5.4); the all-null pre-anchoring state of blockchain_anchor and its ownership by the anchoring pipeline; the one-shot, non-recoverable delivery of the anchoring response and its enumerated contents (Evidence Custody Model §2–§3); the current in-record-only behaviour of reference arrays; the ruled-closed status of F4; the validation endpoint's contract and result codes; and the batched-mode retry and durable-ack machinery (§8.3–8.4), understood as governing export rather than the direct path.
Discharged. All eight instruments Loomworks reasons about are now held. Earlier versions of this request asked for six, then two more; none remain outstanding. If further instruments govern any question above, naming them would be welcome.
Not a schedule. Not FORAY-side implementation work. Not a position on Loomworks' own coverage sequencing, which is ruled (proposal v0.2, D1–D9, filed at build list v1.04).
Evidence Custody Model §2–§3 establishes that the anchoring response is delivered exactly once, that nothing in it is recoverable from FORAY afterwards, that the whole response must be retained as returned, and that a job whose response was not captured whole should be treated as custody-incomplete from birth and re-anchored if the evidence matters.
This invalidates the emitter shape Loomworks was planning. Loomworks' intended emitter was asynchronous, post-transaction, fire-and-forget — the pattern it uses for derived work elsewhere, chosen so that commit availability never depends on an external API. Fire-and-forget is now impossible: an emit whose response is dropped produces an anchor that can never be verified, which is worse than not emitting, because the record exists and looks anchored.
Loomworks' consequent design constraint, recorded here and to be carried into the emitter scoping when that stage opens: the emitter stays asynchronous with respect to the originating transaction, but the anchoring call and the durable capture of its full response are a single unit — no acknowledgement of an anchor until its custody package is stored. Loomworks states this to FORAY not to ask anything, but because an adaptor that got this wrong would be producing exactly the unverifiable evidence FORAY exists to prevent, and the constraint is worth being visible on both sides of the seam.
Request v0.1 placed the Validation Scope R2 ruling under "not asking for," explicitly narrowing that item to current-wire behaviour and stating that Loomworks did not press for the ruling. §4 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.
Verifier Specification v0.2 and Evidence Custody Model v0.6 retrieved read-only (FORAY repository unmodified) and read against v0.2's items.
merkle_root, so the question is no longer only how these are computed but whether they are computed at all. Split into (a) and (b), with §6.1 and §5.4 named as settled.
Six instruments retrieved and read. Item 5 reversed from a narrow factual question to a request for the R2 ruling, with Loomworks' ruled answer offered as input and a stated refusal to commit an adaptor design to in-record-only while R2 is open — cause: the sheet's blocks-all-adaptor-work header; v0.1's contrary position preserved. Item 2 narrowed to per-component canonicalization and root derivation. Item 4 split (ownership answered, return open). Item 9 split (F4's list owed and missing; F26's controlled status unresolved). Items 1 and 3 confirmed absent. v0.1's instrument list discharged and replaced by the two that surfaced from reading the six. Items 6–8 unchanged.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks → FORAY — Information Request — v0.3 — 2026-08-18