Date: 2026-08-18
From: FORAY project (DUNIN7)
To: Loomworks (DUNIN7), carried by the Operator per seam discipline
Responds to: loomworks-foray-information-request-v0_3.md
Status: Answers §1 (ruled) and §2 (fully answered) without qualification. §3 is answered honestly, including a defect the request's own reasoning surfaced but did not name. §4 needs an Operator ruling and is not answered here. §5–§7 answered where FORAY can; one is a genuine open gap.
Checking your §3 against the actual route code (not the surrounding documents) surfaced something your request didn't ask about directly, but that your own reasoning in §11 makes urgent: POST /api/anchor has no idempotency protection. Two identical submissions do not get deduped, rejected, or merged. They anchor twice — different leaf salt, different window, different on-chain artifact, same content. This is answered fully in §3 below, with what it means for the emitter design you've already committed to.
This is being filed as a FORAY-side defect independent of your request. You get the honest current state either way.
Ruling, 2026-08-18. F1 is adaptor-minted. FORAY imposes no format beyond the schema's non-empty-string requirement and runs no registry.
The uniqueness rule, stated concretely, following the same pattern the asset-type scheme ruling already established today: F1 should take the form <originator-prefix>_<locally-unique descriptor>, where the originator prefix is self-chosen by the adaptor — not registered with FORAY, not coordinated with any other adaptor — the same open-namespace, no-central-registry model F8's SCHEME:CODE form already uses. Two adaptors choosing an identical prefix and an identical local descriptor could in principle collide; two adaptors choosing distinct prefixes cannot. This is a convention, not an enforcement mechanism — FORAY does not check it and will not reject a collision if one occurs.
Why not global uniqueness enforced by FORAY: F1's stated job (Root v0.7 §6.2) is retrieval and citation, not identity. Enforcing it would mean FORAY becoming a registry — a role the standing architectural principle ("mechanism, not custodian") argues against for the same reason it argued against retaining custody material.
What this means for Loomworks concretely: pick a prefix — LOOMWORKS is available and not claimed by anything else in FORAY's own material — and mint F1 as LOOMWORKS_<locally-meaningful descriptor>. The template's DOMAIN_YYYY_QN_DESCRIPTOR shape remains a style suggestion, not a rule; Loomworks is free to follow it or not.
component_hashes and merkle_root — vestigial, confirmedAnswered in full, no ruling needed — the code already settles it.
Checked directly against the Verifier Specification §5.4 anchor chain and against every file in the anchor-commitment path (foray-validate-4-2.mjs, foray-anchor.mjs, foray-direct-anchor.mjs, foray-tree.mjs, foray-abh.mjs, and the live route handler): neither field is computed, checked, or compared to anything, anywhere. The anchor commitment runs tx_hash = SHA-256(submitted body bytes) directly — no canonicalization, no pass through either field. They exist only as schema-permitted envelope keys and as the literal string "sha256:PLACEHOLDER" written by FORAY's own example generator.
Leave them as sha256:PLACEHOLDER permanently. That is not a defect in Loomworks' records; it is the correct, permanent state of those two fields under the current specification. Stop treating it as something to resolve.
Authentication: Authorization: Bearer <ANCHOR_CONSUMER_TOKEN>. One shared token across all consumers, no per-client identity. A bad or missing token returns 401. ANCHOR_MODE off returns 404 — checked before auth, so the route denies its own existence rather than reporting itself disabled. This is real, current behavior; do not build logic that distinguishes "disabled" from "does not exist," because the route itself doesn't.
Idempotency — do not assume any. Confirmed at source: the handler always proceeds to sign and enqueue, with no prior check against an existing anchor for the same content. Two identical submissions produce two separate on-chain anchors. The leaf salt and window id are freshly generated on every call, so even byte-identical bodies do not collapse into the same anchor.
This is a defect, not a documented contract, and it directly threatens the design your §11 already committed to. Your emitter is required (correctly) to capture the full response before acknowledging an anchor. If that capture fails — network drop, process crash between the response arriving and the write completing — you will not know whether the anchor succeeded. Retrying is the obvious response to that uncertainty, and retrying today guarantees a second, independent anchor of the same content, while the first becomes permanently unprovable (see §4). Do not build retry-on-uncertain-failure into the emitter against the current endpoint. A dropped response should be treated as: this specific attempt is now unprovable; do not retry it silently; surface it as an operational exception requiring a human decision, the same posture Custody Model v0.6 already requires internally for an unreproducible aggregate.
Rate limits: none currently enforced on /api/anchor, confirmed by code — the rate limiter is wired only to the AI-generation and validation routes.
Synchronous or queued: queued. The route signs, enqueues, and returns immediately. A 200 response confirms signing and enqueueing succeeded — it does not confirm the transaction has broadcast or confirmed on-chain.
Response shape on success, quoted exactly:
{
status: 'enqueued',
jobId, txHash, leafSalt, expectedAnchoredValue,
address, fee, spentUtxo, extension
}
Failure codes: 413 (body over 1 MiB), 400 (empty body), 500 (construction failure or missing infrastructure binding, with message/stack — do not build production logic that parses stack, that field is for FORAY-side debugging only and its content is not a stable contract).
A defect is being filed for the no-dedupe gap. Until it is fixed, the operationally safe posture for an adaptor is: submit once, capture the full response as an atomic part of the same operation (as §11 already requires), and treat any submission whose outcome is genuinely unknown as needing a human decision rather than an automatic retry.
This is not FORAY's technical team declining to answer — it is an open Operator ruling, and it was open before your request arrived. Your independent architectural reasoning (memory model needs corrections-preserved, provenance-threaded records) and the Validation Scope sheet's own §3 finding (the Root's admission test already routes prior-event links to the reference arrays; the validator narrowed them below what Root assigns) point the same direction from two independent starting points. That is real corroboration, not pressure, and it is recorded as such for the ruling.
Your stated position — will not commit to in-record-only while R2 is open — is reasonable and noted. This item is being escalated for a ruling now, on the basis that it blocks a real cross-project consumer, not only internal adaptor-program work.
No registry, by ruling (Asset-Type Reframe v0.3, R2). LOOMWORKS: is yours to use; FORAY governs the delimiter syntax only, never scheme-prefix content. LOOMWORKS:<asset_id> for Loomworks' own instruments is correct as adopted.
Foreign assets — the two provider-token sites. An Anthropic-denominated API token consumed by Loomworks is not a Loomworks asset, and LOOMWORKS: would misrepresent it. The reframe's own reasoning answers this directly: the scheme names whoever owns the asset type, not who is transacting in it. Use the issuing party's own scheme where one exists and is knowable (an Anthropic-specific prefix, if Loomworks can name one meaningfully) or a generic PROVIDER:-style prefix where it cannot be resolved to a specific named issuer. Both are legitimate under R2 — FORAY does not adjudicate which; the requirement is only that the prefix names something real about provenance, not that it resolve to a formally external standard. This was flagged as unresolved in the mapping; it is resolved now.
The placeholder pattern is the expected shape — Root §5 governance column, confirmed. F7/F9 at zero for a non-monetary event is the stated honest value, not an omission. F3/F8 requiring non-empty strings even where no genuine value exists is a real, known tension the schema does not resolve elegantly, and "UNATTRIBUTED"/"LOOMWORKS:NONE" as explicit, self-describing placeholders is the correct current answer. This is not being read as a defect on either side.
F4 and F26 vocabularies
F4: confirmed missing, and this is a real gap. Root v0.7 §7.2 rules it closed and catalog-governed; no list exists anywhere. This needs to be produced — filed as owed, not answered here, because inventing one without checking it against every component type already in use across FORAY's own exemplars and Loomworks' sixteen sites risks the list needing revision immediately.
F26: genuinely unresolved, not merely undocumented. Whether F26 is meant to be closed-list-governed at all is itself unsettled — §7.2's own enumeration omits it. This is an open question about the catalog's own completeness, not a missing document. Filed as owed alongside F4.
component_hashes/merkle_root — confirmed vestigial; no further action, closed./api/anchor no-dedupe defect — filed as a carry-forward. Not fixed by this document. Loomworks should not build against an assumption of safe retries until it is.F4 code list — owed, not yet produced.F26 controlled-status question — owed, not yet resolved.It does not commit to a timeline for the two owed items or the filed defect. It does not alter anything already ruled or built in FORAY's own repos. It answers what could be answered honestly today, and names precisely what could not.
DUNIN7 — Done In Seven LLC — Miami, Florida FORAY → Loomworks — Response to Information Request v0.3 — v0_1 — 2026-08-18