Version. 0.1
Date. 2026-08-14
Status. Advisory note for the Loomworks project. Produced in the FORAY Adapter Program project; carries the use case across so Loomworks build work can account for it. Companion documents: FORAY adapter engagement seed template v0.1 and Murex MX.3 adapter candidate seed v0.1, both staged for loomworks-record/candidate-seeds/foray-adapters/.
Plain-language summary. The FORAY adapter program will run each adapter — Murex, MISMO, SAP, and the rest — as its own Loomworks engagement, created from a standard seed template. This note tells the Loomworks project what that use case needs. The headline: almost nothing unusual. The pipeline as committed in seed v0.14 fits the use case as designed. Two items are genuine capability points (Mode B rendering gets its first real exercise; renders whose canonical home is an outside repository), two are validations of machinery already built (the review-queue pattern maps onto the held-contribution gate; the vocabulary discipline maps onto Shaping), and one names the acceptance test for the current build arc. Nothing here asks for new architecture.
Each FORAY adapter becomes one Loomworks engagement, vendor-track or standards-track, instantiated from the adapter seed template. The engagement's Memory holds classification decisions, corrections, and audit-conversation material with provenance. Shaping splits internal from external audiences. Rendering produces the adapter's briefs, worked examples, records, type maps, and eventually its build specification. The adapter repository (foray-adapters) remains the technical home for machine artifacts and automated checks; the engagement is where the knowledge and the decisions live.
The first instance is the Murex MX.3 adapter. The second, when cut, is MISMO. The template makes new instances a one-page decision set.
The adapter engagements declare Mode B render-types from day one: the machine type map is a specification consumed by external production systems (the repository's validator and visual renderer), and the future adapter build specification will be a REQ document consumed by Claude Code, producing the running tether. Seed v0.14 notes the current Loomworks declared set is entirely Mode A; the Mode B path — specification-grammar declaration (Phase 38 machinery), specialist registration, lineage recording for a render whose product is made elsewhere — is architecturally present but barely exercised. The adapter engagements will lean on it. No new build is requested; the request is that when render-layer work is sequenced, Mode B correctness is tested against this consumer, not deferred as theoretical.
Adapter technical artifacts land canonically in the foray-adapters repository, not in loomworks-record. The engagement produces the render; the render's file lives outside Loomworks's document home, under that repository's continuous-integration gates. The render lineage record (which Shape, which specialist, which scopes) should be able to point at an external destination without treating it as an error. Expected to be trivially fine — Mode B already implies external consumption — but worth one deliberate check rather than an assumption.
The adapter program's hardest rule — an unknown native type is never guessed; it is held until a human decision classifies it, and the decision edits the type map — is structurally the same shape as the held-until-admitted contribution gate the substrate already built (the non-member contribution pathway, and the trusted-core gate the seed commits for shared scopes). A classification decision is an assertion; a superseded decomposition is a correction preserved with reasoning. The adapter engagements exercise this machinery with real, frequent, consequential decisions. No build needed; this is evidence the existing design carries a demanding real workload.
Adapter artifacts split into internal and external exposure classes, with a mechanical vocabulary rule on external material ("tamper-evident" never "tamper-proof"; substrates named by placement only; no internal product names). Today the adapter repository's automated checks enforce this, and they will keep doing so. Longer-term, this is naturally a Shaping rule — a reader-class constraint attached to a shaping — and the adapter engagements are a ready test case whenever Shaping grows per-reader constraint machinery. Awareness only; nothing requested now.
"Induct the Murex MX.3 adapter engagement from its candidate seed and run it end to end" — create from seed, contribute the existing corrections into Memory, derive a Manifestation, shape for two audiences, render one document — is the concrete finish line the current queue is being cleared for. Two queue items bear on it directly: B-77 (the Companion watching the wrong engagement's log for seed changes) matters more once many similar adapter engagements exist side by side, and the create-and-induct path gets its next real exercise from this seed. When B-77 through B-85 and the suite-hygiene items (B-33, B-34) close and the merged work is deployed, the Murex induction is the test that says the factory is open.
A scope above the per-adapter engagements for shared program knowledge (pattern, schemas, vocabulary) is the right eventual home, but Memory scopes above the engagement are not yet in the substrate schema. The interim posture — the program engagement holds shared material; adapter engagements reference it by convention — is stated in the seed template and needs nothing from the build now. When the domain layer (C5) is scoped, the adapter program is a ready worked case with real content, and the template's scope-posture section owes an amendment at that time.
Time-bound commercial constraints (the exclusivity window, the patent-disclosure sensitivity) were examined for special handling and need none: they are ordinary seed constraints checked with the Operator, not machinery.
/Users/dunin7/Downloads/.
mkdir -p /Users/dunin7/loomworks-record/scoping-notes
cp /Users/dunin7/Downloads/loomworks-adapter-engagements-use-case-advisory-v0_1.md /Users/dunin7/loomworks-record/scoping-notes/
cp /Users/dunin7/Downloads/loomworks-adapter-engagements-use-case-advisory-v0_1.html /Users/dunin7/loomworks-record/scoping-notes/
cd /Users/dunin7/loomworks-record
git add scoping-notes/loomworks-adapter-engagements-use-case-advisory-v0_1.md scoping-notes/loomworks-adapter-engagements-use-case-advisory-v0_1.html
git commit -m "Adapter engagements use-case advisory v0.1"
Halt before push.
DUNIN7 — Done In Seven LLC — Miami, Florida Adapter engagements as a Loomworks use case — advisory note — v0.1 — 2026-08-14