MorphIQ Crucible
Runtime architecture
Crucible ownership, strategy boundaries, recorded state and the planned strategy composition.
Crucible separates strategy decisions from trading infrastructure. The current implementation is a Rust workspace with an SDK, a strategy registry and platform crates. The retail product vision builds on that foundation.
Responsibilities
| Boundary | Responsibility |
|---|---|
| FerroFeed | Acquire, normalize and publish market data with source status |
| Crucible input handling | Accept inputs and define the order used for decisions |
| Strategy client | Evaluate a setup and propose a trade |
| Crucible risk and execution | Validate proposals, manage risk, orders and feedback |
| Crucible journal and recovery | Retain evidence, reconstruct state and reconcile |
Strategy boundary
The current anvil-sdk exposes a Strategy interface, read-only context and
order intents. Strategies do not receive a broker execution handle through
that interface. Dependency rules are checked with cargo deny.
These are engineering boundaries, not a sandbox for hostile Rust code. A same-process strategy can fail or overrun; safe operation also needs testing, explicit failure behavior and operational controls.
Planned client composition
The accepted direction is a client-owned executable that registers setups with Crucible's SDK and public runner API. The client owns its strategy implementation; Crucible owns the loop, accepted cutoffs, risk, dispatch and recovery. This composition is in development and must be qualified as a complete path.
Strategy evaluation uses direct synchronous calls. Blocking storage, broker network activity and queue-capacity waits stay outside the target decision loop. Admission and dispatch still follow the selected durability policy.
Performance boundaries
The architectural goal is to preserve time for strategy computation. The intended decision path is accepted input, direct strategy evaluation, and risk admission inside one runtime. Broker dispatch and feedback belong to the execution lifecycle; sending a command is not evidence of broker acceptance or a fill.
The design keeps blocking storage, broker network calls and queue-capacity waits outside strategy evaluation. This does not remove durability ordering: an approved command can be dispatched only when its recording requirements are satisfied under the configured policy. Saturation requires an explicit response rather than an unbounded wait inside the decision loop.
Performance evidence must name its measurement boundaries:
- Decision latency: accepted input to completed strategy evaluation and risk decision, including the actual strategy computation.
- Dispatch latency: the separate path to order submission, including the selected durability policy and execution handoff.
- Broker latency: acknowledgement and fill observations, reported separately from local processing.
- Load and headroom: instrument/subscription scope, sustained load and bursts, tail percentiles, queue pressure, and overload behavior.
- Reproducibility: hardware, build/configuration identity, workload inputs, recording settings and measurement methodology.
The product page describes architectural intent and separately labels the recorded replay experiment and Source checkpoint benchmark below. It does not publish a qualified end-to-end latency claim. Feed-only measurements or empty-strategy benchmarks cannot establish the compute headroom of a complete trading path.
Recorded replay experiment
The product headlines ~100K events/second and 1.75 microseconds replay event-step p99 summarize five measured runs of the standalone options-contract prototype. Throughput is the median of the five whole-run rates (95,445.372 inputs/s), presented as an approximate 100K; latency is the median of their event-step p99 values (1.746 microseconds), rounded to 1.75 microseconds. It is not a pooled p99, a whole-strategy tick percentile, or input-to-broker latency.
Each run processed 9,532,417 recorded inputs. The median elapsed time was 99.873 seconds. These observations describe historical replay, not the complete production strategy path.
The series ran on October 13, 2026, on a shared Intel Core i9-10920X host with fixed CPUs 8 and 9. Unrelated workloads and all outliers were retained. Release builds had boundary/allocation profiling disabled. One warm-up was excluded from the five-run summary, and baseline/candidate ordering alternated.
Each candidate run consumed the same recorded input archive, valued one options vertical, and computed 93,601 regular-session ticks at a historical 250 ms cadence. Chained journaling, sync every 1,000 records, pre-command sync and final sync remained enabled. Independent rational-oracle and full-replay checks passed separately; their verification time is not included in the reported replay duration.
| Measured round | Replay duration |
|---|---|
| 1 | 75.294 s |
| 2 | 122.038 s |
| 3 | 99.414 s |
| 4 | 107.562 s |
| 5 | 99.873 s |
Median throughput was 95,445 inputs/s. The five runs ranged from 78,110 to 126,603 inputs/s. These are whole-run observations, not peak-rate samples.
Latency tails and failed timing limits
The median of run-level event p99 values was 1.746 microseconds; the equivalent tick p99 was 30.122 microseconds. However, the worst observed event took 1,425.965 milliseconds and the worst tick took 467.134 milliseconds. The proposed limits were 5 ms per event and 50 ms per tick. Every measured options run failed the overall timing acceptance. The median fraction of elapsed time attributed to sync was 51.4%, including flush/fsync and scheduling delays.
The result therefore supports a scoped historical throughput observation. It does not establish a live deadline, whole-chain calculation budget, stable speedup against the baseline, or current production capacity. Rare sync stalls are not made harmless by a small event p99.
Download all five run statistics and provenance. The receipt retains exact nanosecond values, source report identity and hash, measured candidate revision, workload and limitations. Licensed input data is not redistributed with the public documentation.
Source checkpoint benchmark
The October 23, 2026 measurement isolates MorphIQ Feed's Source reader with BLAKE3 checkpoint history binding. A saved checkpoint binds the consumed session prefix, so resume refuses changed history at the same position. This is the candidate reader for Crucible's planned Source adoption; the measurement does not establish that the released Crucible runtime already consumes it.
The product page reports 225 ns/event with checkpoints every 1,024 events and 436 ns/event with a checkpoint after every event. Full-prefix resume verification measured 170 ns/event, retained here as a recovery cost. These are medians of aggregate nanoseconds per event, not latency percentiles. They do not measure strategy evaluation, risk, journal durability or broker handoff, and cannot be added to the replay p99 above.
Measured Source costs
All costs are nanoseconds per event. Intervals count events between checkpoint requests. Seven samples per algorithm and interval are retained.
| Interval | BLAKE3 delivery | BLAKE3 resume | SHA-256 delivery | SHA-256 resume |
|---|---|---|---|---|
| 1 | 436.2 | 172.4 | 867.7 | 594.4 |
| 64 | 227.5 | 171.0 | 594.3 | 594.2 |
| 1,024 | 224.8 | 169.9 | 586.2 | 590.0 |
The paired campaign reduces median batched delivery cost by about 62% and checkpoint-every-event delivery cost by about 50%. These are comparisons on this workload and host. Resume still scans the entire saved prefix; total recovery time grows with the number and size of consumed frames.
Methodology and timing boundaries
- Input: the same 1,183 normalized events converted from the retained
October 5 OPRA SPY 0DTE capture used in the earlier campaign: definition,
quote (
cbbo-1s) and trade (tcbbo) files. Input hashes were checked before and after. No provider requests are made by this benchmark. - Host: shared Intel Core i9-10920X without SHA-NI, pinned CPU 2 (SMT sibling 14), Linux 7.2.10, Rust 1.97.1 release builds. Other host workloads remained active. The on-disk log is repeatedly read with warm page cache; this is not a cold-storage or controlled-host capacity measurement.
- Variants: SHA-256 (
sha20.11.0) versus the final review candidate usingblake31.8.7, single-threaded with SIMD and no Rayon. The BLAKE3 candidate uses its actual transcript domain and version-3 checkpoint format. Source hashes, binary hashes, baseline revision and experiment-patch identity are retained in the downloadable receipt. - Sampling: seven samples per algorithm and interval, alternating algorithm order. Each sample opens and consumes the log 1,000 times. All 42 samples are retained; no warm-up sample is excluded. Every replay must deliver exactly 1,183 events and the resumed checkpoint must match the saved checkpoint.
- Delivery clock: includes
Source::poll, the timestamp-reading callback, per-event hash-state snapshots and checkpoint requests after each batch. The final short batch, empty poll and checkpoint request are included. Opening the initial reader is outside this clock. - Resume clock: includes opening from the saved checkpoint and verifying the complete consumed prefix. The checkpoint equality assertion follows the timed operation.
- Aggregation: divide each sample's accumulated time by 1,000 × 1,183, then take the median of the seven costs. Display values round to whole nanoseconds. Batched delivery and resume use interval 1,024; every-event delivery uses interval 1. These clocks provide no event p50/p99 distribution.
Hashing covers frame lengths and bytes, including definitions and multipart frames. A completed event snapshots the hash state. Checkpoint creation finalizes that saved state by reference. There is no per-event prefix rescan or publisher hashing. The existing Source replacement-refusal tests pass for both algorithms; the BLAKE3 transcript has an independently generated golden vector from the upstream scalar reference implementation.
Checkpoint format and adoption
The BLAKE3 transcript domain is morphiq-feed/source-prefix/blake3-v1 followed
by a zero byte. Saved checkpoints use envelope version 3 and binding kind
blake3. Pre-release version-2 SHA-256 checkpoints are rejected, including
attempted version relabeling. Rebuild state from trusted retained history;
never strip or relabel a digest to make recovery succeed. md:v2 event frames
and logs are unchanged. Consumer adoption still requires a released reader,
saved-state migration and a recovery witness in Crucible.
Qualification scope
This small captured workload does not qualify whole SPY 0DTE and nearest standard monthly expirations, arbitrary expiries, live recovery, cold-page faults or the complete strategy path. BLAKE3 provides content binding relative to trusted saved state; it does not authenticate a producer, retain cross-venue acceptance order or establish host-loss durability.
Download all 42 samples, exact summaries and provenance.
No licensed market records are redistributed. The Source measure_source_cost
harness and docs/evidence/source-blake3-2026-10-23/run-comparison.py reproduce
the campaign when the licensed input is available.
Historical SHA-256 measurement
The October 22 candidate reported 590 ns/event for batched delivery, 868 ns/event for checkpoint-every-event delivery and 596 ns/event for full-prefix resume. Its code and checkpoint format differ from the BLAKE3 candidate above; retain those figures as historical evidence, not current BLAKE3 results. Download the original 21 samples and provenance.
Recorded state and replay
The shipping runner appends typed events and applies its reducer. FerroReplay provides journal framing and integrity primitives. An append is not necessarily a durable disk sync: the selected policy determines crash-loss guarantees.
Journal integrity checks verify retained records. State hashes compare reconstructed state. These are separate checks; INFO-level per-event state logging is not an unconditional execution guarantee. Startup currently verifies the journal, including checkpoint state, rather than promising snapshot-only restart cost.
Implementation boundaries
| Crate | Responsibility |
|---|---|
platform-core | Domain types, reducer, accounting and journal mapping |
platform-feed | Market-data consumer integration |
platform-execution | Order management and execution adapters |
platform-risk | Risk admission |
platform-backtest | Replay |
platform-monitoring | Metrics, health and tracing |
anvil-sdk | Public strategy interface |
strategy-registry | Compiled and configured strategy selection |
The workspace generally denies unsafe code, with explicit exceptions at the feed memory/codec boundary. It is not an unsafe-free codebase.
See Reference for arithmetic and replay limits.