Use Cases¶
These scenarios show how mountainash packages compose to solve real problems. Each uses multiple packages — the portability and quality guarantees multiply because everything compiles to the same expression algebra.
The Backend Migration¶
From DuckDB to Snowflake to BigQuery. No rewrites.
A data team builds their analytics logic during development — expressions, validation contracts, business rules, conformance pipelines — all running against a local DuckDB instance. When the pipeline moves to staging, it connects to Snowflake. The same expressions. The same contracts. The same rules. Nothing is rewritten. When the organisation later adopts BigQuery, the same logic moves again. The backend is a deployment decision.
Packages: mountainash, mountainash-data
The Regulatory Filing¶
Complex XML becomes queryable, validated relational data — and back again.
A regulatory XML file arrives — hundreds of element types, deeply nested. TreeSpec auto-derives a flattening spec from the XSD and walks the hierarchy into clean relational tables with referential integrity intact. The conform pipeline coerces messy sentinel values and multi-format dates into typed data. Data contracts validate both structure and business rules. The rule engine evaluates compliance logic with per-dimension explainability and exports results as DMN decision tables for audit. When it's time to file a response, TreeSpec rebuilds compliant XML from the relational tables. Round-trip fidelity.
Packages: mountainash-treespec, mountainash, mountainash-rules, mountainash-rules-babel, mountainash-data
The Pricing Engine¶
Business rules that evaluate where the data lives and explain every decision.
A pricing team maintains discount and eligibility rules across customer segment, geography, product tier, and contract terms. The rule engine loads them as tabular data and evaluates directly against the production Snowflake table — no ETL to a separate engine. The accumulator resolves all consistent combinations and traces which rules contributed to each result. Every evaluation explains itself. When compliance needs to review, the rules export as DMN decision tables. The same definitions run on DuckDB in development and Polars in the analyst's notebook.
Packages: mountainash-rules, mountainash-rules-babel, mountainash-data, mountainash
The Data Integration Pipeline¶
Twenty APIs, five formats, one algebra validating everything before it lands.
Each API endpoint is declared as a typed dataclass — the framework derives auth, pagination, retry, and rate-limiting. Nested JSON and XML responses arrive in wildly different shapes. TreeSpec flattens them all into relational tables. The conform pipeline normalises everything to TypeSpec schemas. Data contracts validate physical and logical quality — the same contracts, whether testing locally against DuckDB or running in production against Iceberg. Violation results feed dashboards that track quality trends per source, per contract, per week.
Packages: mountainash-api-client, mountainash-auth-client, mountainash-treespec, mountainash, mountainash-data
The Data Quality Programme¶
Physical and logical validation, same engine, same backend, structured results for governance.
TypeSpec schemas define the physical contract for every dataset. Data contracts add business rules: revenue is positive, end dates follow start dates, foreign keys resolve, category values come from a reference set. Both layers compile to the same expression engine. The same contracts validate local test data during development and production tables in Snowflake. Validation produces structured results that feed governance dashboards tracking quality trends over time.
Packages: mountainash, mountainash-data
The Handover That Isn't a Rewrite¶
Data scientist builds it in Polars. ML engineer deploys it to Snowflake. No rewrite.
A data scientist develops feature engineering in a Jupyter notebook — ternary expressions, rule evaluation for feature selection, schema conformance, data quality contracts. It works. It's tested. The ML engineer points mountainash-data at Snowflake. The expressions compile through Ibis to Snowflake's SQL dialect. The data scientist confirms it matches their notebook — because it's the same code. Six months later, the model needs updating. Changes flow from notebook to production without a rewrite cycle.
Packages: mountainash, mountainash-rules, mountainash-data
The ClickHouse Analytics Platform¶
Sentinel values in storage. Ternary semantics in logic. No compromises.
Following ClickHouse's guidance, the team avoids nullable columns — missing integers stored as zero, missing strings as empty. Storage is clean and fast. But application logic needs to distinguish real zeros from sentinel zeros. Mountainash's ternary column wrapper solves this at the expression layer: declare which values are sentinels, and three-valued logic handles the rest. Comparisons propagate UNKNOWN correctly, aggregations exclude sentinels automatically, rule evaluations distinguish "matched FALSE" from "had no data." The Ibis backend compiles it all to ClickHouse's native SQL dialect.
Packages: mountainash, mountainash-rules, mountainash-data
The Logic-First Data Product¶
Business logic as a portable, versioned library — not SQL views locked to one database.
A central team maintains conformed definitions: how revenue is recognised, how segments are defined, how churn is measured. They publish mountainash expressions as a versioned Python library: revenue.net_revenue(), segments.enterprise_tier(). Analysts import the library and get expressions that compile to whatever backend they're connected to. Data contracts bundled into the library validate inputs before logic runs. The SQL views still exist — but now they're materialisation targets generated from the expression library, not the source of truth.
Packages: mountainash, mountainash-rules, mountainash-data
The Healthcare Data Flattener¶
FHIR bundles, HL7 messages, proprietary XML — all flattened, all validated, all queryable.
Healthcare data arrives in every conceivable hierarchical format. TreeSpec handles them all: auto-derive from schemas where they exist, hand-tune specs where formats are proprietary, flatten into normalised relational tables with referential integrity, stream gigabyte files through Parquet batch output. Generate Python dataclasses from schemas for type-safe downstream processing. When a downstream system needs the original format, TreeSpec rebuilds it — round-trip fidelity.
Packages: mountainash-treespec, mountainash, mountainash-data
The ML Scoring Specification¶
The scoring spec IS the production code. No translation step.
Feature engineering expressed as mountainash expressions: continuous variables binned into risk bands, categorical variables mapped to points via rule engine match strategies, interaction terms composed as expressions, missing data handled via ternary logic. The specification document that used to be a PDF is now executable, testable code. The same expressions deploy to Snowflake for batch scoring, DuckDB for the low-latency API, and BigQuery for analytics. When the model is recalibrated, the data scientist updates expressions, tests locally, and publishes a new library version.
Packages: mountainash, mountainash-rules, mountainash-data