Plain-language summary. This seed creates the Murex adapter as a Loomworks engagement. The work already exists in the adapter repository — a brief, a type map grounded in real FpML samples, a worked FX spot example, generated visuals. The engagement gives that work Memory: the classification decisions, the corrections (two landed already), and the auditor-conversation material accumulate with provenance instead of living only in files and chat history. The decisions needing your eye are flagged in the drafter's notes.
A FORAY adapter for Murex MX.3, the capital markets platform: deterministic decomposition of MX.3's FX transaction types — spot, forward, swap, option, with exotics deferred until the grammar is proven on vanilla flow — into the four FORAY components, plus the lifecycle events (amendment, exercise, expiry, maturity) that emit against existing transactions.
The type map is the system-specific part. Its active profile is FpML 5.x, the public standard MX.3 speaks natively, grounded in real FpML specification samples held in the repository. Native MxML trade-type codes are installation-specific and are carried as pending aliases, to be filled from the bank relationship rather than from Murex corporate. The tether observes; it never writes back. The attestation boundary is fixed: the adapter attests that MX.3 emitted this event at this time and that it decomposes to this grammar — accountable, not accurate.
The engagement is vendor-track: depth on one system for a live audit conversation.
The bank auditor in the live Murex conversation — the external worked example and its scope-and-honesty section are written for this reader first, and the FX option's worthless expiry is the row to walk this reader through.
Institutions running MX.3 — reached through auditors and customers, not through the vendor.
The program's production stream — Claude drafting sessions, Claude Code, and the repository's automated checks consuming the type map as source of truth.
The program engagement — this adapter has already produced two pattern learnings that flow up: the two-map split (trade types versus lifecycle events) and the discriminator mechanism, both now in the program's type-map schema.
Per the template: descriptive and argued, auditor's problem first. External vocabulary fixed — "tamper-evident" never "tamper-proof"; "accountable, not accurate"; no internal product names beyond FORAY; anchoring substrate named by placement only, with the neutral anchor-commitment naming in external records. Operator-facing text in plain language, abbreviations spelled out.
All template constraints apply unmodified: fixed universal pattern; unknown types to the review queue, never guessed; read-only; protocol pinned at FORAY 4.1.2 with example records validating against the pinned schema; exposure split enforced mechanically including inside compressed bundles; commercial hold in force — the partner-exclusivity window and the patent-disclosure sensitivity are both live for this adapter, and any external move beyond the existing auditor conversation is checked with the Operator first.
One Murex-specific constraint: FpML is the buildable surface; MxML is the accurate one. The two tether profiles are not interchangeable — FpML entries carry discriminators because the standard does not structurally distinguish spot from forward, while MxML codes, once obtained from the bank installation, are expected to be strongly typed. The type map holds both honestly rather than pretending either is complete.
Sufficient when: the type map covers the four vanilla FX types and the observed lifecycle events, validating clean; the brief (currently at v0.2 outside the repository — migration owed) and the FX spot worked example stand at production quality with the record validating in the automated checks; the worthless-expiry case is documented from the real FpML sample as the terminal-resolution demonstration; the review queue carries no undecided entries; and the corrections already landed — MxML placeholders demoted to aliases, the spot/forward discriminator, the two-map split — are preserved with reasoning walkable.
For the live relationship: the worked example has been placed in the auditor conversation and survived it. High clean volume is the demonstration corpus; MX.3's daily FX flow is the strongest available proof of the decomposition claim.
Operator: Marvin Percival. Contributors: Claude as drafting specialist under Operator direction; Claude Code as execution arm for repository operations. Domain contributor: the bank auditor in the live Murex conversation — named here by role; the person's identity is recorded in Memory when their first contribution lands, not in this seed.
Per the template: adapter execution context; external audit narrative; program pattern learnings. No Murex-specific additions at v0.1.
Per the template, all modes as declared there: adapter brief (Mode A, HTML primary with Markdown source); worked example (Mode A, HTML primary, external-ready); example FORAY record (Mode A, JSON validating against protocol 4.1.2); machine type map (Mode B specification consumed by the repository's validator and renderer); type map visual (product of that Mode B chain, versioned, never hand-edited).
Existing instances at engagement creation: brief v0.2 (outside the repository; markdown source requested), FX spot worked example v0.1, FX spot record v0.1 (validating), type map 0.2, type map visuals v0.1 and v0.2, and two real FpML 5.9 reference samples with license and provenance recorded.
Per the template. Marvin Percival is Operator; engagement-scoped decisions his; program-level decisions sit above at the program engagement; technical execution delegated to Claude Code.
Drawn from: charter v0.1 (target landscape, prioritization scores — this adapter scores the maximum on all four axes; deliverable pattern), repository state at scaffold v0.3, and the 2026-08-14 sessions (FpML pull, both corrections). Discovery-record posture: the prior positions are preserved in the type map itself — version 0.1's MxML-primary assumption stands as aliases with the demotion reasoning in the file header.
Flags for Operator decision:
1. Record home. The template and this seed are proposed for loomworks-record/candidate-seeds/foray-adapters/. The adapter's technical artifacts stay canonical in the foray-adapters repository; this seed references them rather than mirroring them. Confirm or redirect.
2. Brief migration. The Murex brief exists at v0.2 outside the repository; only v0.1 was ever uploaded to these sessions. The v0.2 markdown source is item 3 of the standing materials brief. Induction can proceed without it; the success condition cannot close without it.
3. Consumer-render check (structural). All render-type consumers appear in "Who consumes the work" — no inconsistency found. Voice-constraint check: no tension found. Version-filename agreement: holds.
4. What was not included. The anchoring and batching design (settled 2026-08-14 per the charter) is program-level, not adapter-level; it belongs in the program engagement's seed, not here.