Proposed vs Standard

Informative guide. This Book page explains Beskid but does not define the standard. For normative requirements, use the Beskid Standard.

Spec pages carry status metadata. Treat it like a fire rating on a door, not decoration.

status	Meaning
Proposed	Incomplete or unstable; do not cite as enforceable language law
Standard	Enforceable contract at this Git revision; needs decisions + verification anchors

stateDiagram-v2
  accTitle: Spec maturity status
  accDescr: A page starts as Proposed and becomes Standard when the gates are met. A Standard bundle that loses its normative prose, anchors or decisions is downgraded to Proposed.
  [*] --> Proposed
  Proposed --> Standard: gates met
  Standard --> Proposed: placeholder-only or circular stub found

Text equivalent: New material is Proposed. It becomes Standard once it has normative prose, verification anchors and decisions. Placeholder-only or circular bundles must return to Proposed.

From Specification authority.

Standard gates

A Standard feature hub must have:

• Normative MUST/SHOULD/MAY prose
• Verification anchors (tests, crates, registry links)
• ## Decisions on the hub and/or adr/ per decision

Placeholder-only bundles or circular canon stubs must downgrade to Proposed until fixed (Feature hub template).

v0.x bands

Roadmap labels like v0.2 describe delivery scope, not alternate spec URLs. See Release and versioning policy.

For readers

When building on Beskid for production, prefer Standard language-meta articles. When experimenting, read Proposed pages, but do not blame the compiler when the spec said “still forming.”

Next

Git as version axis