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, or 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 is the current stable state, when did this condition occur, what did the local context look like around those moments, and where have similar measured states appeared before?

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.

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 are delivery surfaces for that measured history. They change how the surface is consumed, not what the measurement means.

Aggregator is the system that turns raw exchange trades into the bar truth used by the rest of MATHILDE. It first builds bounded multi-venue 5s frontier bars, then combines those closed inputs into canonical 1m bars. Larger bars such as 5m, 15m, 1h, and 1d are derived from that canonical minute 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 canonical minute truth improves, affected upper bars and downstream measurement surfaces can be rebuilt from the same truth chain.

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

Primitives turns closed Aggregator bar truth 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. Taxonomy and family organization keep that breadth readable and discoverable, so different primitive questions stay grouped instead of becoming one undifferentiated field dump.

If upstream bar truth 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 truth into MATHILDE's canonical market-state layer. It does not reduce the market to one regime label. It organizes market state across 9 dimensions, each built around 7 measured questions, with fixed BTC and ETH dependency branches exposed separately.

The structure exists because market state is not one linear condition. A closed hour can be trending but fragile, volatile but internally compressed, dependent on benchmarks but locally contested, or directionally simple at the endpoint while complex inside the minute path. Regime keeps those questions separate before any downstream interpretation is made.

Those dimensions are trend, momentum, volatility, flow, risk, dependency, structure, inflection, and substructure. The current public surface exposes 70 grouped sections and 718 persisted scalar outputs across that matrix.

The public Regime lane is defended 1h state, not a generic multi-timeframe label. Each row keeps inherited Aggregator market truth, Regime-owned measurements, optional metadata, and diagnostics under one canonical identity. The dependency branch reads fixed BTC and ETH benchmark-relative context, while the substructure branch reads the canonically aligned 60 x 1m path inside the same closed parent hour.

Regime is therefore a reusable market-state measurement surface: historical, searchable, replayable, streamable, exportable, and repairable when upstream truth 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 exports.

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 API surface carries its own orientation layer. intro, summary, system, taxonomy, registry, endpoints, and openapi are served surfaces, not private notes and not an MCP wrapper added after the fact.

That matters because the platform entry point can lead to the right subsystem, measured object, family, group, route, and exact contract. OpenAPI remains the exact schema surface, but MATHILDE exposes the discovery steps before it so product meaning does not have to be inferred from route names alone.

That orientation layer is also machine-readable. Agents and internal systems can inspect the entry point, discover the subsystem, narrow taxonomy or registry scope, and select the exact route or contract without relying on external notes or private operator knowledge.

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

• latest returns the newest stable closed bar or output row.
• range returns a bounded historical window.
• search finds stable close times where a predicate over fields becomes true.
• time-machine replays rows around those hit points so local context is not reconstructed privately.

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 is a thin public client-contract layer for 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 data surface. Aggregator builds canonical minute truth, derives larger bars from it, and exposes readiness, coverage, lineage, and watermarks. When upstream truth improves, affected upper bars, downstream Primitives outputs, Regime outputs, and file publication can be repaired or recomputed under the same row identity.

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 is built so machines can navigate the platform without private notes. The public surface exposes structured docs, taxonomy, registry, endpoint guides, OpenAPI contracts, stable row identities, typed SDK access, MCP tools, metadata, diagnostics, and file workflows.

That machine-first structure also helps human readers. A serious evaluator can follow the same public trail from product meaning to exact contract instead of relying on a sales explanation or private walkthrough.

Human readers can sometimes compensate for ambiguity. Automated consumers usually cannot. They consume the contract they are given, and unclear meaning becomes an infrastructure problem.

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 are the trust surfaces. They are more useful than broad claims because they let a reader inspect why a row can be used and what limits still apply.

MATHILDE does not ask the reader to trust broad claims about market understanding. It exposes the pieces that make a row interpretable before interpretation moves downstream.

That means 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.