Version: v0.1
Date: 2026-08-18
From: Loomworks (DUNIN7)
To: FORAY project (DUNIN7), carried by the Operator per seam discipline
Occasioned by: Operator ruling on loomworks-foray-coverage-resolution-proposal-v0_2, D1–D9 accepted 2026-08-18. That proposal identified a Loomworks-side conventions gap (D7, D9); working the ruling through to what an emitter actually needs surfaced that most of the missing pieces are FORAY-side, not Loomworks-side.
Answers feed: proposal v0.2 Stage 1 (conventions ruling), Stage 3 (Rendering emit design), Stage 6 (cross-record references).
Status: Request. Nothing is blocked today — no Loomworks site transmits (all sixteen are reserved stubs) — but every item below stands between Loomworks and its first real emission.
Loomworks has sixteen places in its engine where a FORAY record would be produced, and a full site-by-site mapping showing what each would contain. What it does not have is enough of FORAY's own specification to produce a real record rather than a well-formed example. The mapping worked around this honestly — it invented an identifier scheme for its examples and wrote the word PLACEHOLDER into every hash field — and said so plainly each time. Those workarounds are exactly the gap this request is about.
Nine items follow, in three tiers: four that block any real emission at all, one that decides whether Loomworks can link its records to each other now or must wait, and four that shape how the records are built. Each names what Loomworks needs, why it needs it, and what happens if the answer does not come. A tenth item asks for copies of five FORAY instruments Loomworks reasons about but does not hold.
None of this is urgent in the schedule sense. It is a prerequisite in the ordering sense: an emitter built before these answers arrive will encode guesses, and guesses in a convention are how conventions get set by accident.
What Loomworks needs. Whether FORAY specifies a format for F1 (the FORAY-side evidence-record identifier), and if so, what: character set, length bounds, uniqueness scope (global across all 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 anywhere or freely chosen.
Why. No such scheme exists in Loomworks — the mapping states this once, explicitly, and invents LW_<event_kind>_<first 8 hex of source UUID> for its worked examples, naming it as an open design decision not made in either repository. F2 is settled by contrast: the originating system's own key travels verbatim under adaptor-mediated origination, so the flow id, event id, or turn id goes as-is. F1 has no such rule.
If unanswered. Loomworks either invents a convention unilaterally and lives with it permanently, or does not emit. Neither is good; the first is worse, because it is silent.
component_hashes and merkle_root
What Loomworks needs. The exact algorithm: what byte sequence is hashed for each component key, how a component array is canonicalized before hashing (field ordering, whitespace, number spelling, empty-array handling), how merkle_root derives from the component hashes, and whether the adaptor computes these or FORAY does at anchor time.
Why. Every one of the seventeen records in the mapping carries the literal string sha256:PLACEHOLDER in all four component-hash slots and in merkle_root. They validate — shape-conformance does not check hash correctness — but a placeholder hash is the one field where a wrong value silently defeats the entire purpose. Tamper-evidence is the hash.
If unanswered. Loomworks cannot emit anything meaningful. A record whose hashes are computed a different way than the verifier expects is worse than no record: it looks anchored and proves nothing.
What Loomworks needs. For POST /api/anchor: authentication method; idempotency semantics (may the same F2 be submitted twice — is there a dedupe key, and is re-submission an error or a no-op); rate limits; response shape on success and on each failure class; whether anchoring is synchronous or queued; and the retry posture FORAY expects a well-behaved adaptor to take.
Why. Loomworks' emitter will be asynchronous and post-transaction — the same shape as the embedding dispatch 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 that retries into a non-idempotent endpoint manufactures duplicate evidence, which is its own integrity problem.
If unanswered. The emitter cannot be built honestly. Loomworks would be guessing at duplicate semantics in an append-only evidence system.
blockchain_anchor ownership
What Loomworks needs. Confirmation that the adaptor submits kaspa_tx_id, block_height, confirmation_time_ms, and anchored_at as nulls and FORAY populates them at anchor time — and if that is right, whether the anchoring result is returned to the adaptor, retrievable later, or neither.
Why. The mapping sends nulls in all four fields at every site. That reads as correct but is inferred, not confirmed. It also determines whether Loomworks needs to store an anchor receipt against its own rows — which is a schema question on the Loomworks side, cheaper to answer before the tables exist than after.
If unanswered. Loomworks builds without knowing whether it owes itself a receipt column, and retrofits one later.
F22/F23/F24 point outside their own record?
What Loomworks needs. Whether a reference array may resolve against a component in a different transaction — by F1, by F2, or by any other means — or whether reference resolution is strictly in-record.
Why. This is the pivotal question for the whole cross-record requirement, and answering it either way unblocks a decision Loomworks has already ruled. Loomworks has ruled that it needs its records to reference each other (proposal v0.2 D4), on the grounds that its own memory model is corrections-preserved and provenance-threaded: a correction that cannot name what it corrects is the least useful record in the set. The concrete cases are specific — a corrective record with no pointer to the proposal it corrects; four token-leg records and the converted credit-debit record from the same act, mutually meaningless and mutually unlinked; a deletion that triggers balance-zeroing records with nothing tying them together.
The mapping's own recheck established that under the current per-call-site, single-Action-record design, an in-record reference cannot exist at all — there is no second component for a reference to resolve against. So the answer determines the shape of the fix:
Related, and acknowledged as already tracked: Validation Scope decision sheet v0.3 R2 is unruled on the FORAY side. This request does not press for that ruling. It asks the narrower factual question — what the current 4.2 wire permits — which is answerable now regardless.
What Loomworks needs. 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.
Why. The asset-type reframe (v0.3 R1/R2) is what made the eleven credit sites expressible at all, and Loomworks has adopted LOOMWORKS:<asset_id> carrying its real tier-identified asset names. But two sites carry provider tokens rather than Loomworks assets, and the mapping breaks its own convention there with a different prefix — flagged as a mismatch, not resolved. This recurs every time a non-Loomworks asset appears in a record.
What Loomworks needs. Whether FORAY has an intended representation for non-financial governance events, or whether the placeholder pattern is the expected shape.
Why. Five of the sixteen sites — a memory write, three settings changes, a conversation turn — have no asset and no amount. The schema forbids nulls in F3 and F8, so those records currently carry the literal strings "UNATTRIBUTED" and "LOOMWORKS:NONE". They validate. They also say nothing, and the mapping is careful to mark each one as a schema-compliance placeholder rather than a fact. If a governance-event 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
What Loomworks needs. Whether FORAY prefers, permits, or expects a hashed owner identifier (the sha256:-prefixed form) over cleartext, and if hashed, the canonical derivation.
Why. Loomworks' identity is a system-assigned UUID and its architecture leans structurally toward privacy — content-blindness enforced at the channel rather than by promise. Putting a raw person UUID into an external attestation record is a decision worth making deliberately rather than by default. The mapping uses cleartext throughout, correctly per the brief it was written under, but flags it as a stated design choice rather than a settled one.
F4 and F26
What Loomworks needs. Whether action-type (F4) and event-kind (F26) values come from a controlled catalog or are free strings, and if controlled, the catalog itself.
Why. Loomworks currently emits its own namespaced kinds (credit.issuance, memory.<event_kind>, audit.setting_change, conversation.turn) and will add Rendering kinds under proposal v0.2 Stage 3. If FORAY has a vocabulary, the Rendering kinds should be drawn from it rather than invented and reconciled later. The ratified catalog addendum v1.1 is cited in the mapping's grounding but is not held on the Loomworks side.
Loomworks documents cite these FORAY instruments; none are in loomworks-record. Copies, or a durable pointer, would let Loomworks ground its own work without re-deriving FORAY's positions second-hand:
foray-transaction-v4_2.schema.json — the 4.2 wire schemaWhy it matters beyond convenience: the mapping's own correction notice records that its first pass produced sixteen structurally wrong records because they were built without checking against the schema and the wire skill. That is the cost of reasoning about an instrument one does not hold, and it has already been paid once.
Not a ruling on Validation Scope v0.3 R2 — that is FORAY's to make on its own timing, and item 5 is deliberately narrowed to what the current wire permits. Not a schedule. Not FORAY-side implementation work. Not a position on Loomworks' own coverage sequencing, which is ruled (proposal v0.2, D1–D9, 2026-08-18).
Items 1–4 are prerequisites for a first real emission. Item 5 changes the shape of one stage. Items 6–9 shape record construction and can arrive later without rework, provided they arrive before the emitter is built rather than after.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks → FORAY — Information Request — v0.1 — 2026-08-18