Design Philosophy

Seven principles that guide every design decision across the mountainash ecosystem.

Portability should be architectural, not per-feature

Most tools add backend support feature by feature, release by release. Mountainash compiles everything to a single expression algebra, so every capability inherits every backend at once. When a new backend appears in Ibis, every mountainash package that compiles to expressions gains it automatically. Portability isn't a roadmap item. It's a property of the architecture.

Logic should be data, not code

An API endpoint definition is data. A rule table is data. A tree flattening spec is data. A settings schema is data. An auth type is data. When logic is expressed as typed declarations, the framework can derive runtime behaviour — fetch pipelines, match expressions, flatten/build operations, configuration resolution. Declarations are simple to write, easy to test, and portable across environments. Derived behaviour is complete, correct, and backend-agnostic. The pattern recurs across every mountainash package because it's the right abstraction.

Compose open standards, don't compete with them

Ibis is winning the portable computation layer. Narwhals is winning the DataFrame compatibility layer. Polars is winning the performance and syntax layer. Frictionless Data defines schemas. Iceberg defines lakehouse tables. DMN defines decision tables. Pydantic defines typed Python models. Each of these is excellent in its domain. Mountainash builds the bridge between them — an expression substrate that compiles through Ibis and Narwhals, a schema system aligned with Frictionless, a rule export format based on DMN, a type system built on Pydantic. We don't compete with the standards. We make them compose.

Protocols at every boundary

Extension points aren't an afterthought bolted onto a monolith. Every significant boundary in the ecosystem is a runtime-checkable Protocol: storage backends, database dialects, schema format handlers, auth providers, secret stores, rule format bridges, expression backends, relation backends. New implementations register via entry points. No fork required. The ecosystem is designed from the ground up to be extended by its community.

Data quality is not a separate concern

When validation uses the same expression engine as rules and conformance and querying, quality becomes a property of the pipeline — not an observatory bolted on from outside. Physical schema validation and logical business rule validation compile to the same algebra, run on the same backends, and produce structured results that track trends over time. Quality isn't something you check after the fact. It's woven into how data flows.

Three-valued logic for real-world data

Real data has unknowns. Not just nulls — genuine uncertainty about whether a condition is true or false. Mountainash's expression engine uses three-valued logic (TRUE, FALSE, UNKNOWN) throughout. Rules evaluate with ternary match semantics. Conformance handles missing values as a first-class concept. This isn't academic purity — it's what you need when databases like ClickHouse recommend sentinel values over NULLs for performance, when CSV files use empty strings and zeros interchangeably, when regulatory data distinguishes "not reported" from "reported as zero," and when every system you ingest from has a different idea of what "missing" means. The ternary layer absorbs this complexity so application logic stays clean.

Composable means independently valuable

Each package solves one problem and solves it well, with zero awareness of sibling packages. You can use the rule engine without TreeSpec, TreeSpec without the API client, the API client without settings. There's no "you must adopt the whole ecosystem" tax. But when you do compose them, the portability multiplies — because they share a substrate, not just an import path.