#Stability Policy

ByteOr follows a conservative stability posture. The workspace is pre-1.0, but documented contracts matter.

#OSS Stability

#Stable Contracts

The following are the clearest current contracts:

• byteor-abi repr(C) layouts and generated header workflow
• byteor-pipeline-spec v1 data model
• Deterministic KV encode/decode and canonicalization behavior
• IndexBus v1 lane semantics and repr(C) layouts

#Evolving Surfaces

These are useful today but still evolving:

• Executor convenience helper APIs
• SHM file naming/path conventions
• Runtime bring-up helper shapes
• Proc-macro ergonomics
• xtask command surface and gate toggles

#Versioning

• SemVer with pre-1.0 convention
• Breaking changes bump the minor version (0.Y.0)
• Non-breaking additions bump the patch version (0.Y.Z)
• Crates move in lockstep to avoid dependency skew

#Experimental Features

New capabilities not ready for long-term support ship behind unstable- prefixed feature flags. These are explicitly outside the stability contract.

#Enterprise Stability

#Stable Operator Contracts

• Environment and path conventions from byteor-core
• Policy decisions from byteor-policy
• Runtime CLI verbs and artifact outputs
• DataGuard report and incident/replay artifact schemas

#Active Implementation

These surfaces are documented but still evolving:

• Adapter coverage and adapter-loop ergonomics
• Replay execution details and operational limits
• Product app parity between SingleRing and broader LaneGraph paths
• Runtime tuning ergonomics and packaging

#IndexBus Stability

IndexBus follows the same pre-1.0 posture:

• v1 lane semantics are the current contract
• repr(C) layouts and generated headers are stable
• Platform crate APIs are evolving
• Performance characteristics are documented but subject to optimization