Specification authority and embedded decisions
Normative rules for language law vs implementation domains, maturity (Proposed/Standard), and embedded decision records in feature hubs and articles.
Document layout: Feature capability layoutconforms
## Purpose## Requirements
Specification authority and embedded decisions Specification
Purpose
Normative rules for language law vs implementation domains, maturity (Proposed/Standard), and embedded decision records in feature hubs and articles.
Requirements
Requirement: Specification authority and embedded decisions: Maturity — Proposed vs Standard [community/spec-maintenance/spec-authority-and-decisions]
The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.
statusMeaning Requirements Proposed Incomplete, unstable, or under active design May omit full verification anchors; must not be cited as enforceable language law in conformance arguments Standard Enforceable platform contract Must include normative MUST/SHOULD/MAY prose, verification anchors (tests, crates, or explicit registry links), and ## Decisionson the feature hub (or a linkeddecisions-recordarticle)Any Standard page that fails content gates (circular “canonical chapter” stubs, placeholder-only article bundles, missing decisions) must be downgraded to Proposed until restored.
Stable ID: BSP-REQ-F7D3CBA9D423
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/content.md
Source SHA-256: f8d0f2e321b4883becf6021aa1e6891013e0fbd44520cb458eed9483106f1664
Scenario: Conformance exercises Maturity — Proposed vs Standard
- 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
Requirement: Language law lives only in language-meta: Decision [D-COMM-AUTH-0001]
The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.
Language law — syntax, types, evaluation, contracts, memory, and cross-cutting language rules — must be defined only under Language meta, except where another domain page declares an explicit cross-domain exception and links to the owning language-meta chapter.
Stable ID: BSP-REQ-1E90F18D6DEA
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0001-language-law-in-language-meta/content.md
Source SHA-256: 4534a139944608f7d4919f47424836f15cc073723c439061b1b5e977db141b80
Scenario: Conformance exercises Decision
- 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
Requirement: Implementation domains defer to language-meta: Decision [D-COMM-AUTH-0002]
The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.
Compiler, Execution, Core library, and Tooling specify how the reference platform realizes language-meta. They must not redefine semantics already owned there; they must defer with
relatedTopics(for exampledefers-to,implements) instead of duplicating normative key tables.
Stable ID: BSP-REQ-252EE6F110A4
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0002-implementation-domains-defer/content.md
Source SHA-256: d22ecbcf6fb280298319c555ad0849c72d62af87dc6181b95e38986ac5ba9db5
Scenario: Conformance exercises Decision
- 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
Requirement: Specification leads implementation: Decision [D-COMM-AUTH-0003]
The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.
Implementation that alters observable language or platform behavior must be preceded or accompanied by normative spec updates. The spec is the authority; tests and crates are verification anchors, not substitutes for missing contract text. Cross-cutting inception record: D-INC-0001.
Stable ID: BSP-REQ-093AC7460C8E
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0003-spec-leads-code/content.md
Source SHA-256: 20eaae5415289e997e3a3e2609c87e652d831420e3a3915f9d6c545ff723efd6
Scenario: Conformance exercises Decision
- 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
Requirement: One ADR file per closed decision: Decision [D-COMM-AUTH-0004]
The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.
Each Standard feature must publish closed choices under
adr/as one file per decision (specLevel: adr, stableadrId,adrStatus,adrDate). Body must include## Context,## Decision,## Consequences; add## Verification anchorswhen testable. Legacydecisions-record.mdxand hub## Decisionssummaries remain valid during migration; new work must useadr/. Inception cross-cutting ADRs stay under Project inception.
Stable ID: BSP-REQ-9FE89303AD0F
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0004-adr-per-decision-files/content.md
Source SHA-256: 8710fde0421c9599cef43b08895bbe438b8274e307804751db46d0f7d7744a39
Scenario: Conformance exercises Decision
- 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
Requirement: Proposed vs Standard maturity gates: Decision [D-COMM-AUTH-0005]
The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.
statusMeaning Requirements Proposed Incomplete or unstable May omit full verification anchors; must not be cited as enforceable language law in conformance arguments Standard Enforceable platform contract Must include normative MUST/SHOULD/MAY prose, verification anchors, and hub ## Decisions(or linkeddecisions-record)Any Standard page failing content gates (circular canon stubs, placeholder-only bundles, missing decisions) must downgrade to Proposed until restored.
Stable ID: BSP-REQ-4107C7AE7317
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0005-proposed-vs-standard-maturity/content.md
Source SHA-256: ea05a1548bca873dccaf44637ac14d5db7750b7ce78c2d5f466236c15ecd9f3a
Scenario: Conformance exercises Decision
- 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: Specification authority and embedded decisions
Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/spec-authority-and-decisions/
Source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/content.md
SHA-256: f8d0f2e321b4883becf6021aa1e6891013e0fbd44520cb458eed9483106f1664
Migrated source text
## Normative platform contract
1. **Language law** — User-visible semantics (syntax, types, evaluation, contracts, memory, and cross-cutting language rules) **must** be defined only under the [Language meta](/platform-spec/language-meta/) domain, except where another domain page explicitly declares a **cross-domain exception** and links to the owning language-meta chapter.
2. **Implementation law** — The [Compiler](/platform-spec/compiler/), [Execution](/platform-spec/execution/), [Core library](/platform-spec/core-library/), and [Tooling](/platform-spec/tooling/) domains specify *how the reference platform realizes* language-meta. They **must not** redefine semantics already owned by language-meta; they **must** defer with `relatedTopics` (for example `defers-to`, `implements`) instead of duplicating normative key tables.
3. **Spec leads code** — Implementation changes that alter observable language or platform behavior **must** be preceded or accompanied by normative spec updates. The spec is the authority; tests and crates are verification anchors, not a substitute for missing contract text.
4. **Architecture decision records (ADRs)** — Each **Standard** feature **must** publish closed choices under **`adr/`** as one file per decision (`specLevel: adr`, stable `adrId`). The feature reader exposes an **ADRs** tab with expandable Context / Decision / Consequences detail. Legacy **`decisions-record.mdx`** articles and hub **`## Decisions
<!-- spec:generate:adr-index -->
No open decisions. Closed choices are normative ADRs under **`adr/`** (`D-COMM-AUTH-0001` … `D-COMM-AUTH-0005`); use the reader **ADRs** tab for expandable detail.
<!-- /spec:generate:adr-index -->
No open decisions. Closed choices are normative ADRs under **`adr/`** (`D-COMM-AUTH-0001` … `D-COMM-AUTH-0005`); use the reader **ADRs** tab for expandable detail.
<!-- /spec:generate:adr-index -->`** summaries remain valid during migration but new work **must** use `adr/`. Cross-cutting inception decisions live under [Project inception](/platform-spec/community/project-inception/).
## Language law vs implementation domains
| Concern | Owning surface | Realization surfaces |
| --- | --- | --- |
| What programs mean (types, control flow, contracts) | language-meta | compiler phases, execution runtime |
| Author-facing manifests and CLI | tooling (authoring) | compiler resolution (graph, cycles) |
| Standard library API shape | core-library | execution syscalls, compiler lowering |
| Diagnostics users see | language-meta + compiler registry | tooling/LSP presentation |
When adding a feature, classify the topic **before** writing: if a reader asking “what does valid Beskid code mean?” would need the answer, it belongs in **language-meta** first; pipeline, crate, or host details belong in implementation domains with links back.
## Maturity — Proposed vs Standard
| `status` | Meaning | Requirements |
| --- | --- | --- |
| **Proposed** | Incomplete, unstable, or under active design | May omit full verification anchors; **must not** be cited as enforceable language law in conformance arguments |
| **Standard** | Enforceable platform contract | **Must** include normative MUST/SHOULD/MAY prose, verification anchors (tests, crates, or explicit registry links), and **`## Decisions`** on the feature hub (or a linked `decisions-record` article) |
Any **Standard** page that fails content gates (circular “canonical chapter” stubs, placeholder-only article bundles, missing decisions) **must** be downgraded to **Proposed** until restored.
## ADR file contract
Each ADR file at `platform-spec/<domain>/<area>/<feature>/adr/<slug>.mdx` **must** use:
| Field | Rule |
| --- | --- |
| `specLevel` | `adr` |
| `adrId` | Stable identifier (for example `D-INC-0001`, `D-CORE-CONC-0003`) |
| `adrStatus` | `Accepted`, `Superseded`, or `Proposed` |
| `adrDate` | ISO date when the decision closed (inception ADRs **should** reflect historical dates) |
| Body | **`## Context`**, **`## Decision`**, **`## Consequences`**; **`## Verification anchors`** when testable |
Superseded ADRs **must** set `supersedesAdr` or link the replacement `adrId` in **Consequences** and note the Git revision (not a URL version segment).
## Hub decisions summary
A **Standard** feature hub **must** include **`## Decisions`** that either lists open items or states **no open decisions** and links the **`adr/`** set (reader **ADRs** tab). Hub bullets **must not** duplicate full ADR prose—summarize and link by `adrId`.
## Related maintenance policies
- [Feature Hub + Article Bundle template](/platform-spec/community/spec-maintenance/feature-hub-article-bundle-template/) — Required hub sections, anti-stub rules, and article minimums.
- [Release and versioning policy](/platform-spec/community/spec-maintenance/release-and-versioning-policy/) — Git as version axis; v0.x delivery bands.
- [Non-normative bridge docs policy](/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/) — Legacy doc trees and mapping pages.
## Decisions
## Articles
<!-- spec:generate:article-index -->
_No articles in this bundle yet._
<!-- /spec:generate:article-index -->
Source Record: Language law lives only in language-meta
Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0001-language-law-in-language-meta/
Source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0001-language-law-in-language-meta/content.md
SHA-256: 4534a139944608f7d4919f47424836f15cc073723c439061b1b5e977db141b80
Migrated source text
## Context
Platform-spec domains multiplied without a single place for “what valid Beskid code means,” inviting duplicate type and evaluation tables in compiler and tooling chapters.
## Decision
**Language law** — syntax, types, evaluation, contracts, memory, and cross-cutting language rules — **must** be defined only under [Language meta](/platform-spec/language-meta/), except where another domain page declares an explicit **cross-domain exception** and links to the owning language-meta chapter.
## Consequences
New language semantics start in language-meta; implementation domains link back instead of redefining tables.
## Verification anchors
`packages/trudoc/src/verify/platform-spec-content.ts`; `cd site/website && bun run verify:trudoc -- --preset ci`.
Source Record: Implementation domains defer to language-meta
Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0002-implementation-domains-defer/
Source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0002-implementation-domains-defer/content.md
SHA-256: d22ecbcf6fb280298319c555ad0849c72d62af87dc6181b95e38986ac5ba9db5
Migrated source text
## Context
Pipeline and host details were written as if they owned user-visible meaning, overlapping language-meta chapters.
## Decision
[Compiler](/platform-spec/compiler/), [Execution](/platform-spec/execution/), [Core library](/platform-spec/core-library/), and [Tooling](/platform-spec/tooling/) specify *how the reference platform realizes* language-meta. They **must not** redefine semantics already owned there; they **must** defer with `relatedTopics` (for example `defers-to`, `implements`) instead of duplicating normative key tables.
## Consequences
Classification happens before authoring: “what does valid code mean?” → language-meta first; crates and phases link back.
## Verification anchors
`relatedTopics` frontmatter validation in `verify:trudoc --preset ci`.
Source Record: Specification leads implementation
Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0003-spec-leads-code/
Source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0003-spec-leads-code/content.md
SHA-256: 20eaae5415289e997e3a3e2609c87e652d831420e3a3915f9d6c545ff723efd6
Migrated source text
## Context
README intent and crate behavior diverged when implementation shipped without a matching platform-spec change set.
## Decision
Implementation that alters observable language or platform behavior **must** be preceded or accompanied by normative spec updates. The spec is the authority; tests and crates are verification anchors, not substitutes for missing contract text. Cross-cutting inception record: **D-INC-0001**.
## Consequences
Contributors pair spec and code in one change set; CI content gates block **Standard** stubs.
## Verification anchors
[Project inception ADR 0001](/platform-spec/community/project-inception/adr/0001-spec-leads-code/); `verify:platform-spec-content`.
Source Record: One ADR file per closed decision
Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0004-adr-per-decision-files/
Source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0004-adr-per-decision-files/content.md
SHA-256: 8710fde0421c9599cef43b08895bbe438b8274e307804751db46d0f7d7744a39
Migrated source text
## Context
Monolithic `decisions-record` articles and hub prose duplicated the same choices without a stable identifier or reader **ADRs** tab.
## Decision
Each **Standard** feature **must** publish closed choices under **`adr/`** as one file per decision (`specLevel: adr`, stable `adrId`, `adrStatus`, `adrDate`). Body **must** include **`## Context`**, **`## Decision`**, **`## Consequences`**; add **`## Verification anchors`** when testable. Legacy `decisions-record.mdx` and hub **`## Decisions`** summaries remain valid during migration; new work **must** use `adr/`. Inception cross-cutting ADRs stay under [Project inception](/platform-spec/community/project-inception/).
## Consequences
Superseded ADRs set `supersedesAdr` or link replacements in **Consequences** with a Git revision note. Hub **`## Decisions`** summarizes by `adrId` only—no full ADR prose duplication.
## Verification anchors
`checkAdrSections` and `checkStandardFeatureDecisions` in `packages/trudoc/src/verify/platform-spec-content.ts`.
Source Record: Proposed vs Standard maturity gates
Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0005-proposed-vs-standard-maturity/
Source: site/spec-content/platform-spec/community/spec-maintenance/spec-authority-and-decisions/adr/0005-proposed-vs-standard-maturity/content.md
SHA-256: ea05a1548bca873dccaf44637ac14d5db7750b7ce78c2d5f466236c15ecd9f3a
Migrated source text
## Context
**Standard** pages shipped with circular stubs or without decisions, while readers treated every platform-spec URL as enforceable law.
## Decision
| `status` | Meaning | Requirements |
| --- | --- | --- |
| **Proposed** | Incomplete or unstable | May omit full verification anchors; **must not** be cited as enforceable language law in conformance arguments |
| **Standard** | Enforceable platform contract | **Must** include normative MUST/SHOULD/MAY prose, verification anchors, and hub **`## Decisions`** (or linked `decisions-record`) |
Any **Standard** page failing content gates (circular canon stubs, placeholder-only bundles, missing decisions) **must** downgrade to **Proposed** until restored.
## Consequences
Maturity is explicit in frontmatter; CI strict mode can fail scaffold **Standard** pages.
## Verification anchors
`verify:platform-spec-content` with `--strict`; `LANGUAGE_META_CIRCULAR_CANON_ALLOWLIST` for tracked exceptions.