bloomery 0.1.0__tar.gz

bloomery-0.1.0/.gitignore

@@ -0,0 +1,245 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer,
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml
+
+# ....................... #
+# bloomery-specific (RFC 0001)
+
+# hatch-vcs generated version file
+src/bloomery/_version.py
+
+# Docs build output
+pages/site/
+pages/.cache/
+
+# Tooling state
+.benchmarks
+.just/
+junit.xml
+# Per-interpreter results the CI test matrix writes (junit-3.12.xml, …).
+junit-*.xml
+coverage-data/
+.envrc
+.claude/projects/
+
+# NOTE: rfcs/ is deliberately committed here — the RFC corpus is a deliverable.
+
+# Stray warehouse files from local SQLMesh/DuckDB runs — the e2e tier builds
+# its own under tmp_path and never writes into the repo.
+*.duckdb
+*.duckdb.wal

bloomery-0.1.0/CHANGELOG.md

@@ -0,0 +1,154 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [0.1.0] - 2026-08-15
+
+First release. Everything bloomery does is new here, so this section is one `Added` —
+`Changed`, `Deprecated`, `Removed`, `Fixed` and `Security` describe movement away from a
+version somebody could have installed, and there is not one yet. They begin at 0.2.0.
+
+From this tag the [stability promises](https://morzecrew.github.io/bloomery/reference/stability/)
+bind: SemVer over the Python API, per-kind versioning over spec YAML, and emitted
+artifacts explicitly **not** stable across bloomery versions.
+
+### Added
+
+**The compiler**
+
+- `compile_project(project, *, target, dialect, naming=None, catalog=None, steps=EMPTY_REGISTRY)`
+  — declarative specs to target artifacts as one pure function. No filesystem, no
+  network, no clock, no randomness: the same specs produce byte-identical artifacts
+  across machines, processes and `PYTHONHASHSEED` values.
+- **Six spec document kinds**, each strict YAML that self-identifies by its version key:
+  Catalog (`catalog_version`), EntityModel (`spec_version`), Mapping (`mapping_version`),
+  MetricSet (`metrics_version`), MartSet (`marts_version`) and StepSet (`steps_version`).
+  Unknown keys, duplicate YAML keys and grammar violations are refused, batched per
+  document with a source path each. A version bloomery does not implement is refused
+  rather than read as one it does.
+- Deterministic intermediate representation with a `blm1:` content fingerprint
+  (`build_project_ir`, `project_fingerprint`), stamped into every artifact header.
+  `bloomery_ir_version` is **5**; it covers each node's field names and count, so an IR
+  shape change moves every fingerprint by construction.
+- A closed whitelist of 24 typed mapping transforms with a compile-time typecheck of
+  every chain, decimal precision and scale tracked through arithmetic, and
+  `register_transform` for vetted extensions.
+- Resolution (`resolve`): cross-spec reference validation, recorded-recipe validation,
+  cycle detection, and metric reachability naming the specific missing leaf.
+  `UnreachableMetric.via` names the chain when a metric is blocked *through* another one.
+
+**Guardrails**
+
+- Fail-closed unit, tax-basis, currency, grain and additivity checks; mart fan-out and
+  grain protection; `assert:` clauses lowered to target-native audits. Every violation is
+  a typed error with a source path, and stages batch so a spec is fixed in one round trip.
+- Two constructs that used to compile clean and could not be right are refused:
+  `HistoricalFanout` for a mart flattening an `scd: type2` dimension with no validity
+  predicate (each base row multiplied by that key's version count, with every declared
+  cardinality still honest), and `UnsupportedByTarget` for the `convert` transform, which
+  lowered to a `CONVERT_CURRENCY` call no engine defines. `convert` stays registered and
+  typechecked; currency conversion needs a dated rate relation bloomery does not model.
+
+**Data quality**
+
+- Cleansing as spec surface: a closed rule catalogue (`coercible`, `not_null`, `range`,
+  `length`, `pattern`, `in_enum`, `in_set`, `unique`, `normalize`, `charset`), entity row
+  rules (`expression`, `referential`), `dedupe:`, `quarantine:`, document-level
+  `reconcile:`, and cross-entity `coverage:` checks. Every rule carries an explicit
+  `on_fail` — `flag`, `quarantine`, `fail` or `repair` — and rules evaluate under a
+  strict three-valued discipline, so a NULL-involved comparison never fires.
+- `pattern` speaks a portable regex allowlist, refused at parse with the construct named;
+  `range` bounds are exact (int, decimal, or a string carrying an exact decimal or ISO
+  date/timestamp); `charset` declares admissible characters as `U+` codepoints.
+- One replayable `<entity>__reject` table per entity with a `reject_id` recomputable from
+  the row, a replay artifact that re-runs the current mapping under the pipeline's own
+  dedupe order, `retention:` and `redact:`. bloomery emits the artifact and never runs it.
+- `gold.mart_data_quality` — an ordinary mart with one row per rule evaluation plus an
+  accounting row per entity, so quarantine rate is a plain `MetricRequest`. Five reserved
+  metrics come with it.
+- Every silver model projects `_quality_flags` and `_quality_ok`; a mart over a
+  rule-carrying base flattens them into a `has_quality_flags` dimension.
+
+**Steps: referenced implementations**
+
+- A project may wire platform-owned steps through a `steps_version: 1` document —
+  `use: ref@version`, input/output bindings, parameters within the manifest's declared
+  bounds, `expression` quality rules on outputs, and `canonical:` links so metrics and
+  `reconcile` can read a step output. Manifests reach the compiler as a frozen
+  `StepRegistry` passed to `compile_project(..., steps=…)`: bloomery reads no step files
+  and has no dynamic loading path, so a spec can never name code to load.
+- Three tiers emit — `sql_macro` splices into the consuming SELECT, `sql_model` emits an
+  ordinary model, and `python_model` emits one generated wrapper per declared output,
+  each carrying a non-optional `assert_step_contract` call. Step outputs are entities:
+  a mart may reference one exactly as it would any silver entity, and `plan()` diffs them.
+- `bloomery.steps.assert_step_contract` — the run-time contract, and the only bloomery
+  name intended for import outside compilation. It imports nothing but `bloomery.errors`.
+
+**The gold layer and the emitters**
+
+- Wide marts: relationship flattening with mandatory prefixes, role-playing date
+  dimensions (`ordered_month`, `shipped_month`, …), a generated `dim_date` owned by the
+  catalog, and aggregate `assert:` clauses lowering to target-native audits.
+- Emit targets for **SQLMesh** (models, audits, native SCD2, reject/replay, quality
+  audits), **dbt** (models through `ref()`/`source()`, sources, snapshots, schema tests,
+  a self-contained expression-test macro) and **Cube** (cubes and views with additivity
+  metadata, ratios as calculated measures), rendering over **DuckDB**, **Trino** and
+  **PostgreSQL**. `register_emitter` adds extension targets. Where a target cannot express
+  a declaration it raises `UnsupportedByTarget` rather than dropping it silently.
+
+**Request-time planning**
+
+- `MetricFlowPlanner`: a structured `MetricRequest` becomes SQL over a wide mart plus
+  typed columns, warnings, a deterministic explanation and a fingerprint — refusing
+  unknown members, cross-grain requests and ambiguous dimensions instead of guessing.
+  MetricFlow is embedded and render-only, never connected to a database. Bind result rows
+  by `ColumnDescriptor.sql_alias`; display `name`.
+- Filters are typed CNF clauses (`Predicate` / `AnyOf` — implicit AND, one level of OR),
+  with `RowPolicy` for row-level scoping and `parse_filter_json` / `parse_sort_json` /
+  `parse_page_json` as the Mongo-flavoured JSON front door. Unsupported constructs raise
+  `UnsupportedFilter` with a stable reason code from the closed, drift-guarded set
+  exported as `bloomery.planner.KNOWN_UNSUPPORTED`.
+- `LruManifestHydrator` / `HydrationKey`: in-process manifest hydration keyed by spec
+  fingerprint and library versions, with an optional caller-owned byte store.
+
+**Assessing and evolving a spec**
+
+- `evaluate(project) -> SpecEvidence` — everything knowable about a spec without touching
+  data, as one value: reachable metrics, unreachable ones with the missing leaf, batched
+  refusals with source paths, mart shapes, entities, fingerprint. **Refusals are the
+  return value**, and analysis that completed before the refusal comes back with them.
+  `InvariantViolated` and every programming error still propagate.
+- `plan()` — every change between two compiled versions classified as additive, widening,
+  rename, restating or breaking, with backfill scope, replay scope for the reject tables a
+  change invalidates, downstream metric impact and an enforced expand/contract workflow.
+- Structured fix suggestions on five refusals: `UnknownMember.did_you_mean`,
+  `UnreachableAtGrain.covering_marts`, `GrainViolation.offending_measures`,
+  `UnknownStep.available_versions`, `UnsupportedFilter.nearest_supported`. Always present
+  — `()` or `None` when there is nothing to suggest, never absent and never fabricated.
+
+**Surfaces**
+
+- A total error hierarchy rooted at `BloomeryError`: every failure is typed, carries a
+  source path into the offending spec node, and is documented in the errors reference.
+- **A command line** — `bloomery compile|plan|resolve|explain|schema|fingerprint`, plus
+  `bloomery --version`. Each command is a thin argument shell over one public function;
+  `--format json` emits the same values the Python API returns. A refusal exits `1` and a
+  usage error `2`, so a pipeline can tell "your spec is wrong" from "your command is
+  wrong". Nothing is executed: `bloomery run` does not exist.
+- **JSON Schema per spec kind** — `spec_json_schema(kind)`, `all_spec_schemas()`, and
+  `bloomery schema --out DIR`. Generated from the Pydantic models so they cannot drift
+  from the parser, with every closed set enumerated. Also published at
+  `https://morzecrew.github.io/bloomery/schemas/v1/<kind>.json`.
+- `bloomery.__all__` is **closed over its own signatures**: every type named in a public
+  signature is importable from the root, enforced by a test that walks the whole surface.
+  `bloomery.__version__` reports the installed release.
+- Documentation: get-started, concepts, how-to guides for every target and the planner,
+  full spec/transform/error/API/stability references, and a runnable `examples/quickstart/`.
+
+[Unreleased]: https://github.com/morzecrew/bloomery/compare/v0.1.0...HEAD
+[0.1.0]: https://github.com/morzecrew/bloomery/releases/tag/v0.1.0

bloomery-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Morze Technologies
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

bloomery-0.1.0/PKG-INFO

@@ -0,0 +1,224 @@
+Metadata-Version: 2.5
+Name: bloomery
+Version: 0.1.0
+Summary: Entity-first spec compiler: declarative entity/mapping/metric specs → SQLMesh, dbt, and Cube artifacts
+Project-URL: homepage, https://github.com/morzecrew/bloomery
+Project-URL: documentation, https://morzecrew.github.io/bloomery/
+Project-URL: changelog, https://github.com/morzecrew/bloomery/blob/main/CHANGELOG.md
+Project-URL: issues, https://github.com/morzecrew/bloomery/issues
+Author-email: Lev Litvinov <misery7100@gmail.com>
+Maintainer-email: Lev Litvinov <misery7100@gmail.com>
+License: MIT License
+        
+        Copyright (c) 2026 Morze Technologies
+        
+        Permission is hereby granted, free of charge, to any person obtaining a copy
+        of this software and associated documentation files (the "Software"), to deal
+        in the Software without restriction, including without limitation the rights
+        to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+        copies of the Software, and to permit persons to whom the Software is
+        furnished to do so, subject to the following conditions:
+        
+        The above copyright notice and this permission notice shall be included in all
+        copies or substantial portions of the Software.
+        
+        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+        IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+        FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+        AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+        LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+        OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+        SOFTWARE.
+License-File: LICENSE
+Keywords: analytics,compiler,cube,data-engineering,dbt,semantic-layer,sqlglot,sqlmesh
+Classifier: Development Status :: 3 - Alpha
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Software Development :: Code Generators
+Classifier: Topic :: Software Development :: Libraries
+Classifier: Typing :: Typed
+Requires-Python: <3.15,>=3.12
+Requires-Dist: jinja2>=3.1
+Requires-Dist: metricflow==0.211.*
+Requires-Dist: pydantic>=2.9
+Requires-Dist: pyyaml>=6
+Requires-Dist: sqlglot<31,>=30.8.0
+Description-Content-Type: text/markdown
+
+# bloomery
+
+**Entity-first spec compiler: declarative entity/mapping/metric specs, compiled deterministically into SQLMesh, dbt, and Cube artifacts.**
+
+## What it is
+
+bloomery is a pure function library. You hand it declarative specs — a catalog, entities,
+mappings, metrics, marts, and optionally steps — and it compiles them into ready-to-run
+artifacts for SQLMesh, dbt, and Cube: models, audits, and semantic-layer definitions.
+The same specs also serve metric queries at request time: a structured `MetricRequest`
+becomes SQL over a wide mart, planned by an embedded, render-only MetricFlow.
+
+- **Deterministic** — same specs in, byte-identical artifacts out, across machines,
+  processes, and hash seeds. No clocks, no randomness, no environment reads.
+- **Fail-closed guardrails** — grain fan-out, additivity violations, and contract breaks
+  are compile errors with named reasons, not silent wrong numbers downstream.
+- **Reviewable** — emitted artifacts are stable-sorted, pretty-printed text, so a diff of
+  the output is a faithful diff of the semantic change.
+
+## What it is not
+
+- It does **not execute SQL** — it emits artifacts and plans for engines and frameworks
+  that do.
+- It does **no orchestration** — scheduling, backfills, and deployment belong to SQLMesh,
+  dbt, or whatever runs the artifacts.
+- It contains **no LLM** — specs are authored by people (or by tools upstream of this
+  library); compilation is deterministic all the way down.
+
+## Quick start
+
+```bash
+uv add bloomery
+```
+
+Compile specs into SQLMesh artifacts (the library never touches the filesystem —
+writing is your loop):
+
+```python
+from bloomery import Target, compile_project, load_catalog, load_project
+
+catalog = load_catalog(catalog_yaml)
+project = load_project(
+    {
+        "entity_model.yaml": entities_yaml,
+        "mapping_orders.yaml": mapping_yaml,
+        "metrics.yaml": metrics_yaml,
+        "marts.yaml": marts_yaml,
+    }
+)
+
+artifacts = compile_project(project, target=Target.SQLMESH, dialect="duckdb", catalog=catalog)
+for artifact in artifacts:
+    print(artifact.path)  # write artifact.content wherever your repo keeps models
+```
+
+Or from a shell — the CLI is a thin argument shell over exactly these functions, and the
+only part of the package that touches a filesystem:
+
+```bash
+bloomery compile specs/ --target sqlmesh --dialect duckdb --out out/
+bloomery resolve specs/          # what is computable, what is missing, what was refused
+bloomery schema --out schemas/   # JSON Schema per spec kind, for editors and validators
+```
+
+A refusal exits `1` and a bad invocation exits `2`, so a pipeline can tell "your spec is
+wrong" from "your command is wrong". Nothing is executed: `bloomery run` does not exist.
+
+Assess a spec before it compiles — refusals come back as a **value**, alongside whatever
+analysis completed before them, so a draft mid-edit still reports what it would give you:
+
+```python
+from bloomery import Stage, evaluate
+
+evidence = evaluate(project, catalog=catalog)
+evidence.stage_reached   # read this first: at any stage but COMPLETE the rest is a prefix
+evidence.reachable       # ('gross_revenue', 'order_count', …)
+evidence.unreachable     # margin, blocked on 'cogs' — the specific leaf, not a summary
+evidence.refusals        # each with its own source path into the spec that caused it
+```
+
+Plan a metric request over the mart those specs declared — SQL out, nothing executed:
+
+```python
+from bloomery import LruManifestHydrator, MetricFlowPlanner, MetricRequest, build_project_ir
+from bloomery.naming import DefaultNaming
+
+naming = DefaultNaming()
+planner = MetricFlowPlanner(LruManifestHydrator(naming), naming=naming)
+plan = planner.plan(
+    build_project_ir(project, catalog=catalog),
+    MetricRequest(metrics=("revenue",), dimensions=("ordered_month",)),
+    dialect="duckdb",
+)
+print(plan.sql)
+print(plan.explanation.render())
+```
+
+Filters are typed CNF clauses (`Predicate` / `AnyOf` — implicit AND, one level of OR), and
+`bloomery.planner.parse_filter_json` is a public front door for the Mongo-flavoured JSON
+grammar (`$and`/`$or`/`$not`, field maps): it normalizes (De Morgan → complement inversion
+→ capped CNF) before refusing, and refuses only from the closed, drift-guarded list
+exported as `bloomery.planner.KNOWN_UNSUPPORTED`:
+
+```python
+from bloomery.planner import parse_filter_json
+
+filters = parse_filter_json(
+    {
+        "customer_id": {"$neq": "internal"},
+        "$or": [{"ordered_month": {"$gte": "2024-01-01"}}, {"ordered_month": "2023-12-01"}],
+    }
+)  # → (Predicate(…), AnyOf(…)) — pass straight to MetricRequest(filters=…)
+```
+
+The runnable version of both snippets lives in
+[`examples/quickstart/`](examples/quickstart/):
+
+```bash
+uv run python examples/quickstart/run.py
+```
+
+## Status
+
+**0.1.0** — the first release. Everything the library does ships behind the quality gate:
+the spec layer over six document kinds, the deterministic IR, transforms and typecheck,
+resolution, fail-closed guardrails, declarative data quality with quarantine and replay,
+steps as referenced implementations, wide marts with role-playing dates, the
+SQLMesh/dbt/Cube emitters over DuckDB/Trino/Postgres, the MetricFlow-backed planner with
+manifest hydration, spec-diff planning, spec assessment, the CLI and the JSON Schema
+export. Every test tier runs, including the Docker-backed engine matrix, the target e2e
+tiers and the three-way equivalence tier.
+
+From this release the promises in
+[Stability](https://morzecrew.github.io/bloomery/reference/stability/) bind: per-kind
+versioning over spec YAML (fully), SemVer over the Python API (breaking changes are
+allowed in a minor below 1.0, but never silent), and emitted artifacts explicitly **not**
+stable across versions — byte-reproducible for fixed inputs, which is determinism rather
+than a cross-version promise. Pin the minor if you want the API to hold still.
+
+Designs that have not yet landed live as RFCs in [`rfcs/`](rfcs/INDEX.md); code that
+contradicts a live RFC is the bug, not the RFC. An RFC is retired once it ships — the
+code, the tests and the documentation are the account of what bloomery already does.
+
+## Documentation
+
+Full documentation is available at
+[https://morzecrew.github.io/bloomery/](https://morzecrew.github.io/bloomery/):
+
+- [Quickstart](https://morzecrew.github.io/bloomery/get-started/quickstart/) — specs to
+  compiled artifacts to a planned query.
+- [Concepts](https://morzecrew.github.io/bloomery/concepts/specs-and-catalog/) — the
+  domain model, the compile pipeline, determinism, guardrails, wide marts.
+- How-to guides — emit
+  [SQLMesh](https://morzecrew.github.io/bloomery/how-to/emit-sqlmesh/),
+  [Cube](https://morzecrew.github.io/bloomery/how-to/emit-cube/), or
+  [dbt](https://morzecrew.github.io/bloomery/how-to/emit-dbt/);
+  [plan a metric request](https://morzecrew.github.io/bloomery/how-to/plan-a-metric-request/);
+  [evolve a spec safely](https://morzecrew.github.io/bloomery/how-to/evolve-a-spec/).
+- Reference —
+  [spec schemas](https://morzecrew.github.io/bloomery/reference/spec-schemas/),
+  [transforms](https://morzecrew.github.io/bloomery/reference/transforms/),
+  [errors](https://morzecrew.github.io/bloomery/reference/errors/),
+  [API](https://morzecrew.github.io/bloomery/reference/api/),
+  [stability](https://morzecrew.github.io/bloomery/reference/stability/).
+
+## Contributing
+
+Contributions, issues, and feature requests are welcome.
+See [CONTRIBUTING.md](CONTRIBUTING.md) for details — including the RFC process for larger
+changes.
+
+## Licence
+
+bloomery is licensed under the MIT License — see [LICENSE](LICENSE) for details.