Version. 0.2 Date. 2026-08-14 Status. Template, second version. Adds the "One engine, many type maps" section — a plain-English statement of how the engagements relate to the running software, previously implied across the charter and repository but stated nowhere. Also names the engine's build specification as program-level, not adapter-level. Everything else carries forward from v0.1 unchanged. Not itself an engagement seed — the standard structure every FORAY adapter engagement's candidate seed instantiates. Bracketed slots are per-adapter; unbracketed text is fixed program commitment carried into every instance. Conforms to seed requirements R-A5 through R-A11. Written against Loomworks candidate seed v0.14 and the FORAY Adapter Program charter v0.1.
Plain-language summary. This template turns "build a FORAY adapter for system X" into a Loomworks engagement with one page of decisions. The fixed parts — the three-part adapter pattern, the never-guess rule, the vocabulary rules, the commercial checks — are written once here and inherited by every adapter. An operator instantiating it fills the bracketed slots: which system, which export surface, who the live contact is, and the priority scores. The first instance is the Murex MX.3 adapter seed, filed alongside.
A FORAY adapter for [target system]: the deterministic decomposition of the system's transaction types into the four FORAY components (Arrangements, Accruals, Anticipations, Actions), delivered as a set of committed artifacts — an adapter brief, a machine-readable type map, worked examples with full FORAY records, and generated visuals — following the pattern the Murex MX.3 adapter established.
Every adapter is the same three parts; only the type map changes per system. The type map carries fixed templates from known native types to the four components. The ingestion tether is a read-only subscription to the system's native export surface ([export surface]). The attestation boundary limits every claim to "this system emitted this event at this time, and it decomposes to this grammar" — accountable, not accurate.
The engagement is [track: vendor or standards]-track. A vendor-track adapter goes deep on one commercial system for a live conversation; a standards-track adapter covers a message standard and every system that speaks it.
In plain English: there is one adapter program — one piece of running software — and each engagement feeds it one file.
The running software, called the adapter engine, has three fixed parts: a listener that receives what a source system emits, a decomposition engine that breaks each event into the four FORAY components, and an attestation layer that stores records locally and anchors only aggregated commitments. The engine is built once and maintained once. A fix to batching or anchoring lands once and every adapter has it.
What makes the engine act as "the Murex adapter" rather than "the SAP adapter" is which type map it is loaded with. The type map is the file this engagement produces — its main Mode B render. The Murex engagement renders the Murex type map; the MISMO engagement renders the MISMO type map; the one engine, loaded with each, becomes each system's adapter.
One honest qualification: the listener needs a small connector per export surface — the piece that physically reads FpML rather than IDocs rather than ISO 20022 messages. Connectors follow surfaces, not systems, so one FpML connector serves every platform that speaks FpML. A thin connector set, one engine, and one type map per engagement.
The division of ownership follows from this. The engine's build specification is program-level work, owned by the program engagement — no single adapter engagement owns it. An adapter engagement's software contribution is its type map and nothing more. This is also why the type map lives under a schema with automated checks: it is the interface between the engagement and the engine, and an interface is held to a contract.
Auditors and examiners evaluating what FORAY gives them against [target system] — the external worked examples and their visuals are written for this reader first. [Named live relationship, if one exists — the specific human conversation this adapter serves.]
Institutions operating [target system] — operators and their technology owners who would run the adapter, reached through auditors and customers rather than through the platform vendor.
The FORAY adapter program's own production stream — Claude drafting sessions, Claude Code executing repository work, and the repository's automated checks, which consume the type map as their source of truth.
The program engagement — cross-adapter pattern learnings (a correction discovered in one adapter's type map that changes the template for all) flow up to the program level.
Descriptive and argued, in plain English. External-facing artifacts argue from the auditor's problem, never from the technology: the platform-held-log argument first, the grammar second, the record third.
Vocabulary discipline in anything external-facing is fixed: "tamper-evident," never "tamper-proof"; "accountable, not accurate"; no internal product names beyond FORAY; the anchoring substrate is named by placement, not function — external records use the neutral anchor-commitment naming, and the substrate's internals are its own specification's to govern. This mirrors the naming discipline the Loomworks seed applies to its own substrates.
Operator-facing text spells out abbreviations and stays in plain language. Technical vocabulary is reserved for technical-reader documents.
The universal pattern is fixed. Type map plus read-only tether plus attestation boundary, with local emission and aggregated anchoring for volume. Adapter work that departs from the pattern is a program-level decision, not an engagement-level one.
Unknown types are never guessed. A native type absent from the type map is rejected to a review queue and classified by a human decision that edits the map. Probabilistic tools may propose; deterministic, gated systems record.
Read-only. The adapter never writes into the source system, never prices, never calculates risk, never interprets.
Native type identifiers come from installations, not vendors. Where a system's native typology is installation-specific (Murex MxML is the worked case), the real identifiers are filled from the engagement's institution relationship. Public standard profiles (FpML, ISO 20022, MISMO) are the buildable surface until then, and entries carry a discriminator where one standard element covers several FORAY types.
Protocol version pinned. The engagement pins its FORAY protocol version; example records validate against the pinned schema. Protocol migration is a deliberate act per adapter, never a silent break.
Exposure split enforced mechanically. Internal and external artifact classes are declared per artifact; external artifacts pass the vocabulary check, including inside compressed bundles.
Commercial hold until cleared. Before any external or commercial move, the current partner-exclusivity and patent-disclosure constraints are checked with the Operator rather than assumed lapsed. Vendor pitches are additionally deprioritized on strategy: demand arrives through auditors and customers.
Corrections preserved, not smoothed. Superseded decomposition positions remain in Memory as corrections with the reasoning walkable. The spot/forward discriminator correction in the Murex type map is the standing worked case.
The adapter engagement is sufficient when: the type map validates against the program schema and covers the system's vanilla high-volume flow; the internal brief and at least one external-ready worked example exist at production quality with the full FORAY record validating in the repository's automated checks; lifecycle events (amendments, exercise, expiry, maturity) are mapped, including at least one terminal-resolution case where an Anticipation ends without an Action; the review queue is empty or every entry carries a decision; and the trajectory — what was assumed, what a real sample corrected — is preserved and walkable.
For a vendor-track adapter with a live relationship: the worked example has been placed in that conversation and survived it.
Operator: Marvin Percival. Contributors: Claude as drafting specialist under Operator direction; Claude Code as execution arm for all repository operations. [Named domain contributor(s) for this system — the auditor, the institution contact, or the standards-body material steward, if any.] The roster evolves; this names it at creation.
Each render-type names its Rendering mode per the Loomworks seed's two-mode commitment.
Every render-type traces to a shape-type above; the machine type map and its visual trace to adapter execution context.
The adapter engine build specification (Mode B, REQ format, consumer: Claude Code, product: the running engine) is deliberately absent from this list: it is a program-level render-type, declared once in the program engagement's seed, per the "One engine, many type maps" section. An adapter engagement never declares it.
Marvin Percival, founder of DUNIN7 (Done In Seven LLC, Miami), is the Operator. Engagement-scoped decisions are his. Program-level decisions — pattern changes, protocol migrations, vocabulary rules, commercial timing — sit with him at the program engagement, above any single adapter. Technical execution is delegated to Claude Code under Operator direction.
Shared program knowledge — the universal pattern, conventions, schemas, vocabulary rules — belongs at a scope above the per-adapter engagements, which each adapter references. Memory scopes above the engagement are committed in the Loomworks seed but not yet present in the substrate schema; until the domain layer lands, the program engagement holds the shared material and per-adapter engagements reference it by convention. This is posture, stated honestly, in the same manner the Loomworks seed states its own unenforced seams.
Drawn from: the FORAY Adapter Program charter v0.1, the adapter repository design v0.2, this project's build sessions of 2026-08-14 (the FpML pull, the two-map correction, the discriminator correction), and Loomworks candidate seed v0.14. Fixed text encodes charter commitments; slots mark the only per-adapter decisions.
v0.2 change, and its origin (Discovery-record note): the Operator asked whether there is a single adapter fed by a render from each engagement — and the answer, yes, was implied across the charter ("only the type map changes") and the repository (the type map schema, the shared tooling) but stated plainly nowhere. The "One engine, many type maps" section is that statement. Two consequences were made explicit at the same time: the engine build specification is program-owned and never declared by an adapter engagement, and connectors follow export surfaces rather than systems. The prior v0.1 text was not wrong; it was silent on the relationship, and silence on the load-bearing relationship is the defect v0.2 corrects.
Flags: (1) R-A10 requires a named roster — the domain-contributor slot must be filled or explicitly declared empty per instance. (2) The type map visual is listed as a render-type though it is machine-produced; alternative considered was omitting it as a mere by-product, set aside because it travels externally and therefore needs declared discipline. (3) The scope posture in the final section anticipates the Loomworks domain layer; if the domain layer lands differently, this section of the template owes an amendment before new instances are cut.
DUNIN7 — Done In Seven LLC — Miami, Florida FORAY adapter engagement — seed template — v0.2 — 2026-08-14