Six primitives. Composable by default.
The Ferro suite is the engines the MorphIQ Platform is built from: matching, signal analysis, pricing, spread construction, market data, and deterministic replay foundations. Some are trading-specific; others — wavelet analysis, deterministic replay — are general-purpose math and infrastructure. Built into Anvil, consumed by the applications, and marketable on their own to any builder who needs the primitive.
The engines are not a monolith. A Ferro name means there is, or will be, a reusable artifact: a crate, service, wire contract, managed component, or licensed module. Internal utilities do not get promoted into the family just because they are useful.
Deterministic limit-order-book matching. Price-time priority, configurable tick semantics, explicit tiebreakers, no wall-clock dependencies.
Discrete wavelet transforms for non-stationary return series. Best-basis selection, thresholding, derived statistics for signal construction.
Option pricing, Greeks, and implied-vol surface fitting. Reference implementations with property and mutation testing, benchmarked against industry parity points.
Spread construction and risk decomposition. Builds vertical, calendar, diagonal, butterfly, and condor structures with clean leg-level accounting. Embedded in the applications.
Provider-agnostic market-data plumbing. Snapshot semantics, ingestion contracts, replayable buffers. The ingest side of a deterministic system.
Deterministic clock, replay, and journal primitives. The small foundation Anvil uses to make time and state evolution reproducible.
Line coverage is a ceiling, not a floor. Each Ferro crate is gated on mutation score, property tests for invariants, and reference-implementation parity checks. A test that does not catch a planted mutation does not count. CI enforces it before publication.
The engines are infrastructure. They are not wrapped in a marketing narrative, they are not sold as a bundle, and they are not trying to compete with trading desks on features. They exist because serious systems — trading applications first among them — need serious mathematical and systems primitives that can be audited line by line.
A trading signal marketplace. Signals are the output of consuming engines, not the product being sold.
A black-box risk service. Every output is derived from documented methodology, tested implementations, and auditable evaluation materials.
A single product bundle. Each engine can have a small developer-marketing surface, but the suite itself is not sold as one SaaS.
An advertisement. If an engine does not do a thing, it does not claim to. The docs are the specification.
Each Ferro engine can have a technical brief, a deep docs section, and a small developer-marketing domain when evaluators need a front door. Those surfaces explain the primitive to builders; they do not turn Ferro into a consumer brand.
The deterministic runtime.