Bourdon is at 0.25.0 and pre-1.0. A version number alone cannot tell you what is safe to build on, so this page says it plainly: what you may depend on, what may still move, and what happens when something has to break.
The canonical statement is docs/STABILITY.md in the repository. It ships with the code it describes, so if that file and this page ever disagree, the file is correct. This page carries the same contract in prose, plus the current release, the release history, and the gates every change passes before it ships.
Bourdon is federated memory. Other programs read and write through it, and a store written today is expected to be readable years from now. That is why these promises are written down rather than implied by a version number.
What you may depend on#
Anything not listed here is internal, however visible it happens to be.
| Surface | Versioned as | Where it lives |
|---|---|---|
| L5 manifest schema | 0.1 | L5_manifest_v0.1.json, byte-checked against the repository on every site build |
| Agent roster contract | bourdon.agents/v1 | bourdon agents --json, and the export_agents MCP tool |
| Roster listing contract | bourdon.roster/v1 | bourdon agents list --json |
| Codex turn brief | codex-turn-brief/v1 | the compile_codex_turn MCP tool |
| Participant contract | unversioned, additive | spec/PARTICIPANT_CONTRACT.md |
| MCP tool names | tied to the major version | bourdon serve |
| CLI subcommand names | tied to the major version | bourdon --help |
| Conformance fixtures | conformance_version in conformance/manifest.json | conformance/, regenerated and diffed in CI so a behaviour change cannot land silently |
The conformance suite is the enforcement mechanism for most of the above. It is not documentation of the contract, it is the contract in executable form: a change that alters behaviour fails CI unless the fixtures are regenerated in the same commit, which makes the change visible in review. The current suite is conformance_version 2.6.0, 89 fixtures, produced against 0.24.0.
What may still move#
Being honest about this is the point of having a contract at all.
- MCP tool parameter names and response fields, other than the versioned contracts above. The tool names are stable; the shape of what they return is not yet.
- CLI flags. Subcommand names are stable and have only ever been added to. Flags on an existing subcommand may change.
- The peer federation wire protocol (HTTP, bearer tokens, depth one). The semantics are settled; the transport details are not frozen.
- Hooks, live evaluation tooling, and the recognition string shape. These are the newest surfaces and the ones still learning what they are.
- Anything marked experimental in its own documentation.
When something has to break#
A deprecation is announced before it happens, and the announcement is in the artifact itself, not only in a release note:
- The old form keeps working and is marked deprecated in the changelog under the version that deprecated it, and at the point of use where there is one: a CLI warning on stderr, a field left in place, a documented note.
- It keeps working for at least two minor versions after that.
- It is removed only in a major version, and the release notes for that major version list every removal in one place.
Two things override this order, and both are stated when used. A security fix may break a contract immediately, because leaving a hole open to preserve a field name is the wrong trade. And a contract that was never usable may be corrected immediately: a documented shape nothing could successfully depend on is a bug, not a promise. The claude.ai connector path shipped in 0.16.0 and could not complete until 0.24.0; correcting that was a fix, not a break.
What a version number means here#
- Patch (0.24.0 to 0.24.1): a fix. No surface changes.
- Minor (0.24.0 to 0.25.0): additions, and changes to anything in What may still move. Safe to take if you depend only on the surfaces above.
- Major: a change to the public surface, or a removal that finished its deprecation period. Migration notes ship with it.
The engine is 0.x today. Until 1.0.0 the deprecation windows above are honoured in practice but not yet guaranteed, and the distinction matters: after 1.0.0 a break outside this process is a defect rather than a judgement call.
It runs in production for its authors. Every agent used to build Bourdon federates through it, on several machines, every day. That is not a claim that it is production-ready for you; it means the failure modes you hit are ones we hit first.
What is not a stability promise#
- Performance numbers. Recognition latency, hydration timing and memory sizes are measured in dated field tests with their methods and limits recorded. They are evidence of what happened on a machine, not a guarantee about yours.
- The licence split is a legal matter, not a technical one. The wire and interop surface is Apache-2.0; the engine is BUSL-1.1 and converts to Apache-2.0 four years after each version publishes.
- Hosted service behaviour. app.bourdon.ai is a product built on this engine; its availability, pricing and console are governed by its own terms, not by this page.
Current release#
| Python package | bourdon 0.24.0 on PyPI, released 2026-09-18 |
| npm packages | bourdon 0.23.0 (the CLI), @getbourdon/mcp-server 0.7.0, @getbourdon/federation 0.6.0, @getbourdon/conformance 0.7.0, @getbourdon/recognition 0.3.0 |
| Container | bourdonai/bourdon:0.24.0 (also latest) on Docker Hub and the GitLab registry, same digest |
| Homebrew | bourdonai/bourdon/bourdon 0.24.0, bottles for Apple silicon macOS 26 and ARM64 Ubuntu 24.04 |
| Conformance suite | conformance_version 2.6.0, 89 fixtures |
| Python | 3.10 or newer |
| Platforms | macOS, Linux, Windows (WSL recommended) |
How to check rather than trust this page#
bourdon --version # what you are running
bourdon doctor # every participant reports, with a fix line where it can
Release history#
| Version | Date | Headline |
|---|---|---|
| 0.25.0 | 2026-09-21 | Eight new participants (Gemini and Google Antigravity, Grok Bot family, Cline and Roo Code, Aider, Continue, Supermaven, v0, Bolt), four new L6 tools (search_federation, propose_consensus, vote_consensus, capture_clip), and the review campaign: 29 PRs putting every new surface through the old rules; conformance 5.1.0 on both implementations |
| 0.24.0 | 2026-09-18 | bourdon oauth reset-passphrase: a managed control plane can open the browser-connector door, because the interactive verb needs a terminal that an exec API does not have |
| 0.23.0 | 2026-09-18 | Every hook adapter on one core (Copilot CLI, Hermes, Cascade, Cursor, and Codex with a Stop hook), duplicate rows fold at the participant boundary, and bourdon doctor --which says which Bourdon answered |
| 0.22.0 | 2026-09-17 | The hooks close their own loop (usefulness signal wired, hook stop), L1 stays fresh from per-agent exports, doctor staleness fixes, and the container image ships Debian's security fixes: 43 fixable HIGH/CRITICAL OS findings in 0.21.0, none in 0.22.0 |
| 0.21.0 | 2026-09-17 | Recognition judged by its first sentence: entity hygiene, fuzzy tier, clustering and ranking, a gloss in the recognition string, one hydration door, Claude Code hooks as product, live evaluation and a usefulness signal |
| 0.20.0 | 2026-09-17 | Lovable participant (tenth surface, first cloud-native); stable member identities, library enrollment, describe_caller; Homebrew and GitLab Releases as gated publish channels |
| 0.19.0 | 2026-08-24 | Consent-based federation roster, bourdon agents, bourdon console, bourdon sync stage |
| 0.18.0 | 2026-08-17 | Schema-driven clamping so readers can never emit an invalid row; store can no longer be bricked by a tightened filename policy |
| 0.17.0 | 2026-08-17 | Version history and rollback: list_memory_versions, explain_memory_change, rollback_agent_memory |
| 0.16.0, 0.16.1 | 2026-08-09 | OAuth front door for claude.ai and ChatGPT connectors |
| 0.15.0 to 0.15.2 | 2026-08-04 | Homebrew bottles, release hardening |
| 0.14.0 | 2026-08-04 | Drift surfacing: a vendor format change is reported at turn start |
| 0.13.0 | 2026-08-03 | Reproducible CI resolution, pinned constraint set |
| 0.12.5 | 2026-07-27 | Hermes Agent participant |
Every release before these, back to 0.0.1 in April 2026, is on the GitLab releases page with notes. The full change list is CHANGELOG.md.
What every change passes before it ships#
A change reaches main only through a pull request whose checks are green, and the checks are required by branch protection rather than convention:
| Gate | What it catches |
|---|---|
pytest, over 2,800 tests | behaviour, including negative tests for every security control on the Security page |
| Python 3.10 and 3.11 matrix | the supported-version claim is executed, not written |
ruff, mypy, bandit | style, types, and common Python security mistakes |
pip-audit against a pinned constraint set | known-vulnerable dependencies; resolution is reproducible |
| contamination gate | operator-specific paths or identifiers leaking into a public tree |
gitleaks (pinned, checksummed) | secrets in the tree |
| leak-audit fixture | bourdon audit-leaks runs against a real manifest so it cannot pass by scanning nothing |
| conformance regeneration | the cross-implementation fixtures are rebuilt and diffed |
wheel build, twine check, fresh-venv smoke install | the artifact that ships is the artifact that was tested |
On a tag, the pipeline additionally verifies the tag matches pyproject.toml, then publishes to PyPI through trusted publishing and to the container registries.
Evidence rather than claims#
Performance and behaviour numbers on this site come from dated, reproducible field tests, each with its method and its limits written down: recognition latency on a local model, cross-account recognition on a fresh machine, and cross-machine fallback memory. They are on the Field tests page, and the running log of what did and did not hold is the findings journal.
Where to report things#
- Bugs and questions: GitLab issues, or hello@bourdon.ai if you would rather write.
- Security: the process in
SECURITY.md; please do not open a public issue first. - A new agent adapter:
docs/AUTHORING_A_PARTICIPANT.md, then a pull request. Two shipping adapters arrived this way.