Glossary and conformance
Defines MUST / SHOULD / MAY usage across all Beskid specifications. Every diagnostic and platform RFC should reference this vocabulary consistently.
Document layout: Feature capability layoutconforms
## Purpose## Requirements
Glossary and conformance Specification
Purpose
Defines MUST / SHOULD / MAY usage across all Beskid specifications. Every diagnostic and platform RFC should reference this vocabulary consistently.
Requirements
Requirement: Glossary and conformance: Normative specification [language-meta/conformance/glossary-and-conformance]
The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.
This chapter is the normative vocabulary for all Beskid platform specifications. Other
language-metaarticles, compiler features, execution contracts, and core-library packages must use these terms and requirement keywords consistently. Informative material (book, guides, workshop notes) must not override text markedStandardhere.Scope
- In scope: requirement keywords (RFC 2119 profile), Beskid conformance levels, maturity of spec pages, diagnostic severity vocabulary, and cross-domain authority boundaries.
- Out of scope: compiler pipeline ordering, manifest schema keys, and runtime ABI details (owned by sibling domains; they must defer to
language-metafor user-visible semantics).Requirement keywords (RFC 2119)
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in normative sections are to be interpreted as described in RFC 2119 and RFC 8174 (BCP 14).
Keyword Meaning in Beskid specs MUST / REQUIRED / SHALL Absolute requirement for conformance at the stated level MUST NOT / SHALL NOT Absolute prohibition SHOULD / RECOMMENDED Strong default; deviation requires explicit rationale in `## Decisions No ADRs published under
adr/yet.No ADRs published under
` |adr/yet.| SHOULD NOT | Strong discouragement; allowed only with documented exception | | MAY / OPTIONAL | Truly optional behavior or surface |
Normative sections must use uppercase keywords. Lowercase must in running prose is informative unless the sentence is inside a quoted normative rule.
Beskid conformance levels
Implementations are evaluated against language-meta (
Standardarticles) plus explicitly linked domain contracts.
Level Definition Verification L0 — Parse Accepts all programs in the v0.1 grammar without internal compiler failure Parser + beskid.pestfixture suiteL1 — Name and module Resolves modules, imports, and visibility per Modules and visibility and Name resolution Resolver tests; E11xx band L2 — Type Assigns types and rejects ill-typed programs per Types and related chapters beskid_analysistype tests; E12xx–E13xxL3 — Semantic Enforces contracts, control flow, events, memory rules, and composition/DI where applicable Semantic + composition tests; E14xx–E17xx L4 — Executable Lowered program behavior matches execution + core-library contracts for the chosen target triple Runtime tests, ABI checks A conforming reference compiler must reach L3 for all
Standardlanguage-meta chapters in this repository snapshot. L4 is claimed per target profile (native, WASM, etc.) in execution and core-library specs.Specification maturity (
status)
statusMeaning Standard Enforceable MUST/SHOULD text; implementation and diagnostics must align or the page must be downgraded Proposed Design in flux; implementations may diverge with tracked gaps A page marked Standard must not consist solely of navigation boilerplate or self-referential “canonical chapter” links. It must include a Normative specification section with testable rules.
Diagnostic vocabulary
Term Rule Error ( E####)Denotes ill-formed or ill-typed program; compilation must fail Warning ( W####)Denotes suspicious but legal program; compilation may succeed Note Informative attachment; never alone changes exit code Stable codes live in the Diagnostic code registry. Language-meta chapters cite bands (for example E11xx resolution); exact messages may evolve while codes remain stable.
Authority boundaries
Domain Owns Must not redefine language-meta User-visible syntax, types, evaluation, contracts, memory, testing surface — compiler Phases, IR, lowering, diagnostic emission mechanics Language semantics execution Schedulers, stacks, channels, runtime services Type rules, spawntyping contractcore-library Host bases, concurrency types, console I/O packages Grammar and name lookup tooling CLI, LSP, manifest authoring UX Resolution graph semantics (defer to compiler) Cross-domain pages must link to the owning
language-metachapter withrelation: defers-toorimplementsinrelatedTopics.Definitions (selected)
Term Definition Program A finite sequence of ItemWithDocsforming a compilation unit per Lexical and syntaxModule A named namespace boundary introduced by modor file-scopedmod path;Type A static description of values; see Types Contract A surface of required members checked structurally; see Contracts Fiber Cooperative task handle produced by spawn; see Fibers and spawnChannel Cross-fiber communication primitive; memory sharing must go through channels per Memory and references Option<T>The sole optional-value surface in v0.1 (corelib Query.Contracts.Option); must not be spelledoptionalor?TnullMust not exist as a type, literal, or implicit default; absence uses Option<T>::Noneor explicit enumsmutPrefix modifier marking a reassignable local or parameter ( mut T name,let mut name)PascalCase Identifier profile for types, enums, contracts, variants, module segments, and callable members; see Code style and naming lowerCamelCase Identifier profile for fields, parameters, locals, and macro names; see Code style and naming GC heap Traced object store with concurrent mark-sweep; runtime details in execution specs; /execution/tree is a non-normative legacy bridge onlyConformance of specifications themselves
Editors must update
lastReviewedwhen normative text changes. Tier-1 language-meta chapters must include## Decisionsfor non-obvious choices. Verification anchors should name crate paths or test directories where the reference compiler enforces the rule.
Stable ID: BSP-REQ-478851A47758
Legacy source: site/spec-content/platform-spec/language-meta/conformance/glossary-and-conformance/content.md
Source SHA-256: 8cbf88bc194357baa5d5ff28e2a05b964220bffcea175b34ddd0cf5616e546ab
Scenario: Conformance exercises Normative specification
- GIVEN an implementation claims conformance with this capability
- WHEN behavior governed by this contract section is exercised
- THEN every MUST, SHALL, REQUIRED, prohibition, and accepted decision in the section is satisfied
Informative Source Provenance
The records below preserve migration history and are not normative except where text was extracted into a requirement above.
Source Record: Glossary and conformance
Authority: informative provenance
Legacy path: /platform-spec/language-meta/conformance/glossary-and-conformance/
Source: site/spec-content/platform-spec/language-meta/conformance/glossary-and-conformance/content.md
SHA-256: 8cbf88bc194357baa5d5ff28e2a05b964220bffcea175b34ddd0cf5616e546ab
Migrated source text
## Normative specification
This chapter is the **normative vocabulary** for all Beskid platform specifications. Other `language-meta` articles, compiler features, execution contracts, and core-library packages **must** use these terms and requirement keywords consistently. Informative material (book, guides, workshop notes) **must not** override text marked `Standard` here.
### Scope
- **In scope:** requirement keywords (RFC 2119 profile), Beskid **conformance levels**, maturity of spec pages, diagnostic severity vocabulary, and cross-domain authority boundaries.
- **Out of scope:** compiler pipeline ordering, manifest schema keys, and runtime ABI details (owned by sibling domains; they **must** defer to `language-meta` for user-visible semantics).
### Requirement keywords (RFC 2119)
The keywords **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** in normative sections are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174) (BCP 14).
| Keyword | Meaning in Beskid specs |
| --- | --- |
| **MUST** / **REQUIRED** / **SHALL** | Absolute requirement for conformance at the stated level |
| **MUST NOT** / **SHALL NOT** | Absolute prohibition |
| **SHOULD** / **RECOMMENDED** | Strong default; deviation requires explicit rationale in `## Decisions
<!-- spec:generate:adr-index -->
No ADRs published under **`adr/`** yet.
<!-- /spec:generate:adr-index -->
No ADRs published under **`adr/`** yet.
<!-- /spec:generate:adr-index -->` |
| **SHOULD NOT** | Strong discouragement; allowed only with documented exception |
| **MAY** / **OPTIONAL** | Truly optional behavior or surface |
Normative sections **must** use uppercase keywords. Lowercase *must* in running prose is informative unless the sentence is inside a quoted normative rule.
### Beskid conformance levels
Implementations are evaluated against **language-meta** (`Standard` articles) plus explicitly linked domain contracts.
| Level | Definition | Verification |
| --- | --- | --- |
| **L0 — Parse** | Accepts all programs in the v0.1 grammar without internal compiler failure | Parser + `beskid.pest` fixture suite |
| **L1 — Name and module** | Resolves modules, imports, and visibility per [Modules and visibility](/platform-spec/language-meta/program-structure/modules-and-visibility/) and [Name resolution](/platform-spec/language-meta/program-structure/name-resolution/) | Resolver tests; E11xx band |
| **L2 — Type** | Assigns types and rejects ill-typed programs per [Types](/platform-spec/language-meta/type-system/types/) and related chapters | `beskid_analysis` type tests; E12xx–E13xx |
| **L3 — Semantic** | Enforces contracts, control flow, events, memory rules, and composition/DI where applicable | Semantic + composition tests; E14xx–E17xx |
| **L4 — Executable** | Lowered program behavior matches execution + core-library contracts for the chosen target triple | Runtime tests, ABI checks |
A conforming **reference compiler** **must** reach **L3** for all `Standard` language-meta chapters in this repository snapshot. **L4** is claimed per target profile (native, WASM, etc.) in execution and core-library specs.
### Specification maturity (`status`)
| `status` | Meaning |
| --- | --- |
| **Standard** | Enforceable MUST/SHOULD text; implementation and diagnostics **must** align or the page **must** be downgraded |
| **Proposed** | Design in flux; implementations **may** diverge with tracked gaps |
A page marked **Standard** **must not** consist solely of navigation boilerplate or self-referential “canonical chapter” links. It **must** include a **Normative specification** section with testable rules.
### Diagnostic vocabulary
| Term | Rule |
| --- | --- |
| **Error** (`E####`) | Denotes ill-formed or ill-typed program; compilation **must** fail |
| **Warning** (`W####`) | Denotes suspicious but legal program; compilation **may** succeed |
| **Note** | Informative attachment; never alone changes exit code |
Stable codes live in the [Diagnostic code registry](/platform-spec/compiler/semantic-pipeline/diagnostic-code-registry/). Language-meta chapters cite **bands** (for example E11xx resolution); exact messages **may** evolve while codes remain stable.
### Authority boundaries
| Domain | Owns | Must not redefine |
| --- | --- | --- |
| **language-meta** | User-visible syntax, types, evaluation, contracts, memory, testing surface | — |
| **compiler** | Phases, IR, lowering, diagnostic emission mechanics | Language semantics |
| **execution** | Schedulers, stacks, channels, runtime services | Type rules, `spawn` typing contract |
| **core-library** | Host bases, concurrency types, console I/O packages | Grammar and name lookup |
| **tooling** | CLI, LSP, manifest authoring UX | Resolution graph semantics (defer to compiler) |
Cross-domain pages **must** link to the owning `language-meta` chapter with `relation: defers-to` or `implements` in `relatedTopics`.
### Definitions (selected)
| Term | Definition |
| --- | --- |
| **Program** | A finite sequence of `ItemWithDocs` forming a compilation unit per [Lexical and syntax](/platform-spec/language-meta/surface-syntax/lexical-and-syntax/) |
| **Module** | A named namespace boundary introduced by `mod` or file-scoped `mod path;` |
| **Type** | A static description of values; see [Types](/platform-spec/language-meta/type-system/types/) |
| **Contract** | A surface of required members checked structurally; see [Contracts](/platform-spec/language-meta/contracts-and-effects/contracts/) |
| **Fiber** | Cooperative task handle produced by `spawn`; see [Fibers and spawn](/platform-spec/language-meta/evaluation/fibers-and-spawn/) |
| **Channel** | Cross-fiber communication primitive; memory sharing **must** go through channels per [Memory and references](/platform-spec/language-meta/memory-model/memory-and-references/) |
| `Option<T>` | The sole optional-value surface in v0.1 (corelib `Query.Contracts.Option`); **must not** be spelled `optional` or `?T` |
| `null` | **Must not** exist as a type, literal, or implicit default; absence uses `Option<T>::None` or explicit enums |
| `mut` | Prefix modifier marking a reassignable local or parameter (`mut T name`, `let mut name`) |
| **PascalCase** | Identifier profile for types, enums, contracts, variants, module segments, and callable members; see [Code style and naming](/platform-spec/language-meta/program-structure/code-style-and-naming/) |
| **lowerCamelCase** | Identifier profile for fields, parameters, locals, and macro names; see [Code style and naming](/platform-spec/language-meta/program-structure/code-style-and-naming/) |
| **GC heap** | Traced object store with concurrent mark-sweep; runtime details in execution specs; `/execution/` tree is a **non-normative legacy bridge** only |
### Conformance of specifications themselves
Editors **must** update `lastReviewed` when normative text changes. Tier-1 language-meta chapters **must** include `## Decisions` for non-obvious choices. Verification anchors **should** name crate paths or test directories where the reference compiler enforces the rule.
## Decisions
## Articles
<!-- spec:generate:article-index -->
_No articles in this bundle yet._
<!-- /spec:generate:article-index -->