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 happen, and who holds authority over its content now and in the future.

Spec versioning

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

A 1.0 release is expected once this spec completes 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., with no public visibility or external contribution path. This section describes the process going forward, not the one 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 a reader can't tell what's required, not a general preference.
• What, if anything, already addresses this elsewhere in the spec, and how the proposal differs from it.

A submission that doesn't address these is closed with a request to resubmit in that shape, rather than reviewed in depth. This bar isn't about excluding AI-assisted submissions: how a submission was drafted isn't evaluated, only whether it demonstrates this engagement.

Review and the final decision stay internal to Bonafide Technologies Inc. for now: the company doesn't have the resources to run a formal external review board or working-group process. What the company commits to instead is full transparency of that internal process rather than its delegation: every submission, the internal discussion, the decision, and its rationale are posted in the same public issue thread.

This is expected to change, as Stewardship below describes: broader, more formal participation depends on the resources a Foundation transition would bring.

Stewardship

Bonafide Technologies Inc. is the sole steward of this spec today and continues to hold that role 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.

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.