Ecosystem¶
Mountainash is a bridge, not an island. Every major capability delegates to or builds on an established open standard or open source project. The value mountainash adds is making these standards compose through a shared expression substrate.
Standards and Projects¶
Ibis — Compilation Target¶
Mountainash compiles expressions to Ibis, extending them with three-valued logic, ternary-aware operations, and Frictionless-aligned type semantics. When Ibis adds a new backend (currently 23+), mountainash inherits it. This brings Ibis reach to domains — rule engines, data contracts, schema conformance — that don't typically benefit from Ibis portability.
Narwhals — Compilation Target¶
Mountainash compiles expressions to Narwhals, extending the reach of Narwhals-compatible DataFrames into rule evaluation, data contracts, and schema conformance. If you already use a Narwhals-compatible library (pandas, PyArrow, cuDF, Modin), you already have a mountainash backend.
Polars — Native Backend and Syntax Model¶
Mountainash adopts Polars-compatible syntax as its user-facing API, so Polars users face near-zero learning curve. Polars is the native backend for maximum performance. Mountainash extends the Polars syntax model to domains (rules, validation, conformance) that pure Polars doesn't cover.
Frictionless Data — Schema Standard Alignment¶
TypeSpec aligns structurally with Frictionless Table Schema. The conform pipeline implements Frictionless type coercion semantics. DataPackage and Resource support enables multi-table workflows with foreign key integrity. Mountainash brings Frictionless schemas into backend-portable validation and conformance pipelines.
Apache Iceberg — Lakehouse Backend¶
Mountainash connects to Iceberg natively — REST, Hive, Glue, and SQL catalogs. The same expressions that validate and transform data can store and query it in Iceberg. Rule tables, validated results, and flattened hierarchical data all land in the lakehouse.
Substrait — Type System Alignment¶
Mountainash's expression type system models the separation between Substrait-covered operations and extension operations. This architectural decision means the path to Substrait serialisation is built in, enabling cross-engine expression portability as Substrait adoption grows.
OMG DMN — Decision Table Export¶
The rule engine's match strategies map to FEEL expressions. Rules-babel exports standards-compliant DMN 1.3 XML. This bridges Python-native rule evaluation with the Java-centric DMN ecosystem that regulated industries use.
Pydantic — Type Modelling Foundation¶
Settings, auth specs, data contracts, and configuration profiles all build on Pydantic. Mountainash inherits Pydantic's serialisation, documentation, and IDE integration. The discriminated-union pattern for auth types and the settings base class both leverage Pydantic's validation model.
The Composability Thesis¶
Each package solves one problem independently. The expression engine doesn't know about rules. The rule engine doesn't know about TreeSpec. But when you compose them, the portability multiplies — because they share a substrate, not just an import path. The capabilities grow and the backends grow, and they grow multiplicatively.
The data ecosystem is converging on composable, portable, standards-based infrastructure. Mountainash is the layer that makes it all compose.