08 — Versioning & Governance

Status: Draft, v0.1. License: CC-BY-4.0 — see LICENSE-DOCS.

Overview

This chapter defines what this document's own version number means, how changes to it are expected to happen, and who currently holds, and is expected to hold in the future, authority over its content.

Spec versioning

This document is versioned independently of any implementation. A spec version change does not imply a release of those packages, and vice versa.

The version follows SemVer, currently at v0.1. A pre-1.0 version number is used deliberately here, not as a placeholder for an eventual v1.0 "real" release. It signals that this spec has not yet accepted public, external input (02-connections.md's router federation and this spec's own Change process below are both part of changing that) and that breaking changes remain possible without the stronger compatibility guarantee a 1.x line implies.

A 1.0 release is expected once this spec has gone through at least one full cycle of the Change process below with genuine external participation, not on a fixed date.

Change process

As of this writing, this spec has been developed entirely internally at Bonafide Technologies Inc. — there has been no public visibility into it and no external contribution path. This section describes the process going forward, not the process that produced chapters 00 through 07.

Going forward, changes to this spec are proposed and tracked as GitHub issues (or pull requests directly against the affected file) on the spec's repository. Anyone — inside or outside the company — can open an issue proposing a change, reporting a gap, or asking a question about intent.

To keep that door open without being overwhelmed by low-effort or AI-generated volume, a submission is expected to demonstrate concrete engagement with the spec, not just assert that something should change. A proposal MUST state: which chapter and section it concerns; the specific interoperability failure or ambiguity it causes — a concrete scenario where two compliant implementations would disagree, or where a reader can't tell what's required, not a general preference; and what, if anything, already addresses this elsewhere in the spec that the proposal is aware of and distinguishing itself from. A submission that doesn't address these is closed with a request to resubmit in that shape, rather than reviewed in depth. This bar exists to filter for people who have actually hit the problem, not to exclude AI-assisted submissions as such — how a submission was drafted is not what's evaluated, only whether it demonstrates this engagement.

Review and the final decision stay internal to Bonafide Technologies Inc. for now: the company does not have the resources to run a formal external review board or working-group process at this stage. What the company commits to instead is full transparency of that internal process rather than its delegation — every submission, the internal discussion of it, the decision, and the rationale for that decision are posted in the same public issue thread, so the reasoning behind a change (or a rejection) is visible even though the decision itself isn't made by a vote outside the company.

This is expected to change as the Stewardship section below describes: broader, more formal participation is a function of the resources a Foundation transition would bring, not a permanent limitation of the process itself.

Stewardship

Bonafide Technologies Inc. is the sole steward of this spec today, and continues to hold that role unless and until it can transition stewardship to a Foundation. That transition depends on finding sponsors or donors to fund it — the Foundation model is how this spec's maintenance and evolution scale past what a single small company can sustain on its own, not a change made for its own sake.

Until that transition happens, Bonafide Technologies Inc. remains responsible for the Change process above, including the final decision on every proposed change, and for the two public commitments already made elsewhere in this spec: router federation (02-connections.md) and the handshake bootstrap key fix (07-security.md) both ship by the end of 2026.