MATHILDE is not a raw market-data relay, a charting terminal, an alert feed, a signal product, or an execution layer. It does not tell the reader what to buy, sell, or expect next.

It can expose measured readings about trend, risk, flow, structure, dependency, inflection, and market state, but those readings remain measurements of closed or defended history. They are not trade instructions.

The platform is designed around measurement questions: what happened, what is safely readable now, where did this measured condition appear before, and what did the local context look like around those moments?

Those questions can be useful for research, monitoring, comparison, and machine consumption. They are still not the same thing as telling the user what will happen next. MATHILDE keeps that distinction explicit so measured state remains measured state.

For machines, the failure mode is silent ambiguity. A row can be present but still unclear: what was measured, whether it is stable, why a value is missing, which limits apply, and whether API rows and files describe the same object.

MATHILDE makes that meaning inspectable before the row is consumed. The public surface exposes reading order, contracts, row evidence, diagnostics, file workflows, and discovery paths so automated systems do not have to infer product meaning from field names or private notes.

That also helps human evaluators. A reader can move from product meaning to exact contract without relying on a private walkthrough.

MATHILDE keeps one reading logic across many surfaces. The measured object changes from Aggregator bars to Primitives outputs to Regime outputs, but the question shape remains explicit: latest stable state, bounded history, condition search, or replay around event points.

HTTP APIs, gRPC, WebSocket streams, and parquet files change how the surface is consumed, not what the measurement means.

Aggregator is the measurement foundation. It turns imperfect multi-venue USDT trade streams into canonical UTC-aligned measured bars.

It builds bounded multi-venue 5s frontier objects, a canonical 1m base, and derived 5m, 15m, 30m, 1h, 4h, 6h, 12h, and 1d bars from that base.

This matters because live data and historical data follow the same construction family. A historical bar and a live bar are not produced by two unrelated pipelines. When the canonical minute base improves, affected upper bars and downstream measurement surfaces remain tied to the same measurement chain.

A MATHILDE bar is therefore more than OHLCV. It can carry timing lineage, venue participation, taker-flow fields, frontier input evidence, coverage, readiness, and repair or rebuild context before it enters research, automation, streaming, or closed-span file workflows.

Primitives turns closed Aggregator measurement into a precomputed measurement layer across supported timeframes, live history, and historical backfill. Each output row keeps the original market context and adds the current public surface of 510 persisted scalar outputs across 18 semantic families under one canonical identity.

The surface is broader than a technical-indicator set. It includes familiar price, return, range, drawdown, and channel measurements, but also memory, signal-shape, entropy, Hurst, DFA, DCCA, regression, dependency, seasonality, flow, and sizing measurements.

The point is not to create indicators or trading signals. The point is to give research, risk, data, and machine consumers one governed measurement layer instead of forcing every team to rebuild the same measurements privately and differently.

If the upstream measured base changes, affected primitive outputs can be recomputed under the same row identity. Stop-like, oscillator-like, or signal-like fields remain measured objects. They do not become recommendations.

Regime turns closed Aggregator 1h measurement into MATHILDE's structured market-state layer.

It does not reduce the market to one regime label. It measures defended closed-hour market state by asking different orthogonal questions across the same market episode: trend, momentum, volatility, flow, risk, dependency, structure, inflection, and substructure.

That matters because crypto market state is mixed and nonlinear. A market can trend while becoming fragile, show momentum while losing structure, or look calm at the hourly level while the 60 x 1m path underneath is conflicted. Regime preserves those distinctions instead of compressing them too early.

The current public surface exposes 70 grouped sections and 718 persisted scalar outputs across that matrix. The dependency branch reads fixed BTC and ETH benchmark-relative context, while the substructure branch reads the canonically aligned minute path inside the same closed parent hour.

Regime is therefore a reusable market-state measurement surface: historical, searchable, replayable, streamable, exportable, and repairable when the upstream measured base changes. It is not a forecast surface or a trading engine.

MATHILDE serves measured objects through public APIs and file surfaces:

• REST/HTTP APIs for direct row queries.
• gRPC for protobuf-native request/response reads.
• WebSocket streams for stable-edge updates and predicate-triggered messages.
• parquet files for closed-span historical publication.

Those access paths are not separate products. They are different ways to consume Aggregator bars, Primitives outputs, Regime outputs, status, discovery, and closed-span files.

HTTP and gRPC fit request/response reads such as latest, range, search, and replay. WebSocket surfaces keep a client attached to the stable edge or emit predicate-triggered messages on newly closed objects. Parquet files are closed-span publication artifacts for reproducible offline work, not a different meaning for the same row.

The same read families repeat across systems while the measured object changes:

• latest reads the newest stable object without guessing finality.
• range reads bounded history with explicit pair, timeframe, and interval.
• search discovers where a documented predicate became true.
• time-machine replays context around event points without rebuilding semantics.

This is why predicates matter. They are field conditions over stable rows, with numeric thresholds and simple comparisons that can be combined when the question needs more than one measured condition.

Examples:

• BTCUSDT.dd_drawdown_depth >= 0.030000 && BTCUSDT.sig_permutation_entropy_log_returns_close_entropy_norm_m5_tau1 > 0.900000
• BTCUSDT.tr_klts_score > 0.0 && BTCUSDT.tr_tpe_choppiness > 0.700000

The query shape stays explicit instead of collapsing snapshot, history, event discovery, and event context into one vague retrieval endpoint.

SDKs and MCP sit above the same public surface. They do not create a second product model. The Rust SDK exposes the same public measurement model for typed application code: transport-aware, endpoint-faithful, and scoped to the public MATHILDE systems.

MCP is the agent-facing layer over that same SDK and public surface. It exposes tools, resources, and workflow prompts for discovery, taxonomy, registry, latest rows, ranges, searches, time-machine windows, due-diligence packs, and file workflows. It is not an MCP bolted onto an opaque API. That layer is possible because MATHILDE already serves machine-readable orientation, contracts, measured rows, and export surfaces.

MATHILDE keeps correction as part of the product contract. Aggregator builds a canonical minute base, derives larger bars from it, and exposes readiness, coverage, lineage, and watermarks.

When the base measurement improves, affected upper bars, Primitives outputs, Regime outputs, API rows, streams, and file publication remain accountable to the improved base.

That is why API rows and parquet files are not detached exports. They belong to the same measurement chain, with metadata and diagnostics carrying the evidence needed to distinguish readable, missing, intentionally unavailable, repaired, or still-limited state.

MATHILDE pricing follows data usage, not seat count. A team can use multiple API keys, systems, and access paths under one account-level usage envelope instead of buying separate seats or separate feature bundles.

The meter is based on data volume. API and analytics usage are counted in bytes per UTC minute. File usage is counted in bytes per UTC month. API keys are just access credentials inside the team account; they do not create separate usage pools.

For example, an account envelope with 50 MiB/min API usage and 100 GiB/month file usage means:

• at 20 KiB per metered API response, about 2,560 responses per minute
• sustained at that full API rate, about 110 million responses over a 30-day month
• at 10 MiB per accepted parquet object, about 10,240 file objects per month
• smaller or larger parquet objects consume the same monthly file envelope proportionally

That is closer to utility-style data metering than feature pricing. The team is not buying dashboard switches one by one; it is consuming stable measured data surfaces, query families, streams, SDK access, MCP workflows, and parquet exports under one coherent usage model.

MATHILDE exposes the evidence around the row: boundary, lineage, readiness, coverage, metadata, diagnostics, provenance, and correction state.

Those surfaces are more useful than broad claims because they let a reader inspect why a row can be used and what limits still apply.

A result is not only a number. A row can be read as stable, missing, repaired, intentionally unavailable, or limited by its current state without inventing that interpretation privately.

A stream can show that market events are arriving. A dataset must also explain which intervals are closed, which rows are safely readable, whether the expected grid exists, and what can still improve through repair or recompute.

That distinction is central to MATHILDE. Row existence is not the same thing as readiness. Watermarks, coverage, lineage, and publication rules make the difference visible before the row enters research, automation, streaming, or file workflows.