BPlatform specification
Login
featureStandard

Non-normative bridge docs policy

Policy for migration and bridge documents, including mandatory canonical destination links for non-normative mapping pages.

Document layout: Feature capability layoutconforms
  • ## Purpose
  • ## Requirements

Non-normative bridge docs policy Specification

Purpose

Policy for migration and bridge documents, including mandatory canonical destination links for non-normative mapping pages.

Requirements

Requirement: Bridge documents are non-normative by default: Decision [D-COMM-BRIDGE-0001]

The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.

Bridge documents (migration guides, mapping tables, terminology crosswalks) are non-normative by default unless a Standard platform-spec feature page explicitly declares normative status. Migration mapping pages must not be the final authority for platform behavior.

Stable ID: BSP-REQ-D2BBAD9AFEA2
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0001-bridge-docs-non-normative/content.md
Source SHA-256: cbfad0aa63cb939a3fa9c1226b0b61856167607a238131907affc2d3534cebad

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: Bridge pages must link canonical destinations: Decision [D-COMM-BRIDGE-0002]

The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.

Every non-normative bridge page must link to one or more canonical normative destinations and label those links as canonical. Near the top each bridge must state: non-normative status, why the page exists, and which normative page(s) own the behavior. Canonical links must be direct platform-spec URLs with human-readable relation labels; bi-directional discoverability is required during active migration windows when practical.

Stable ID: BSP-REQ-DC48F1CEB81A
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0002-canonical-destination-links/content.md
Source SHA-256: d5b285026f3cb2646819b16870d78f73bda2430de005ace39b94138629c17bf7

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: Migration mapping page required sections: Decision [D-COMM-BRIDGE-0003]

The Beskid standard SHALL enforce the following migrated contract section. Accepted ADR decisions are binding; uppercase requirement keywords retain their BCP-14 meaning.

Migration mapping pages must include: (1) a one-sentence non-normative notice; (2) a Canonical destinations section linking target feature hubs; (3) a Mapping scope section stating coverage and exclusions; (4) a maintenance note for retirement timing. Multi-domain mappings must group links by destination domain/area.

Stable ID: BSP-REQ-BB349DD12BEB
Legacy source: site/spec-content/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0003-migration-mapping-page-shape/content.md
Source SHA-256: 55d47c5fcd79c27b2018a6ed5f4af2f58236394cca52def70436e12587b36948

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: Non-normative bridge docs policy

Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/
Source: site/spec-content/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/content.md
SHA-256: a811b9c5486f84463f1e0f420805889abf628844dc00195577c06048b81c3f17

Migrated source text
## Normative platform contract

1. Bridge documents (migration guides, mapping tables, and terminology crosswalks) are **non-normative** by default unless a page explicitly declares normative status in a canonical platform-spec feature page.
2. Migration mapping pages **must not** be used as the final authority for platform behavior; they are transitional navigation aids.
3. Every non-normative bridge page **must** link to one or more canonical normative destination pages and clearly label those links as canonical.

## Required labeling for bridge docs

Each bridge document **must** state all of the following near the top of the page:

- That the page is non-normative.
- Why the page exists (for example, migration from legacy organization).
- Which canonical normative page(s) supersede or own the described behavior.

## Migration mapping page requirements

Migration mapping pages **must** include:

1. A one-sentence non-normative notice.
2. A "Canonical destinations" section that links to target Feature Hub and/or feature pages.
3. A "Mapping scope" section that states what is covered and what is intentionally excluded.
4. A maintenance note describing when the mapping can be retired.

When mappings span multiple domains or areas, pages **must** group links by destination domain/area so readers can reach canonical sources without interpretation.

## Canonical link quality rules

Canonical destination links **must** satisfy:

- Direct links to canonical platform-spec pages (not only intermediate redirects).
- Human-readable relation labels (for example, "Canonical feature contract").
- Bi-directional discoverability when practical (canonical pages should also link to major migration bridges during active transition windows).

## Decisions
<!-- spec:generate:adr-index -->
No open decisions. Closed choices are normative ADRs under **`adr/`** (`D-COMM-BRIDGE-0001` … `D-COMM-BRIDGE-0003`); use the reader **ADRs** tab for expandable detail.
<!-- /spec:generate:adr-index -->
## Articles
<!-- spec:generate:article-index -->
_No articles in this bundle yet._
<!-- /spec:generate:article-index -->

Source Record: Bridge documents are non-normative by default

Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0001-bridge-docs-non-normative/
Source: site/spec-content/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0001-bridge-docs-non-normative/content.md
SHA-256: cbfad0aa63cb939a3fa9c1226b0b61856167607a238131907affc2d3534cebad

Migrated source text
## Context

Legacy Starlight paths and informal mapping tables were cited in reviews as if they were language law.

## Decision

Bridge documents (migration guides, mapping tables, terminology crosswalks) are **non-normative** by default unless a **Standard** platform-spec feature page explicitly declares normative status. Migration mapping pages **must not** be the final authority for platform behavior.

## Consequences

[Legacy spec mapping](/platform-spec/legacy-spec-mapping/) stays informative; normative fixes land under `platform-spec/`.

## Verification anchors

`PSC005` legacy bridge checks on **Standard** pages linking `/execution/` or `/corelib/`.

Source Record: Bridge pages must link canonical destinations

Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0002-canonical-destination-links/
Source: site/spec-content/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0002-canonical-destination-links/content.md
SHA-256: d5b285026f3cb2646819b16870d78f73bda2430de005ace39b94138629c17bf7

Migrated source text
## Context

Readers stopped at bridge pages without reaching the owning **Standard** feature contract.

## Decision

Every non-normative bridge page **must** link to one or more canonical normative destinations and label those links as canonical. Near the top each bridge **must** state: non-normative status, why the page exists, and which normative page(s) own the behavior. Canonical links **must** be direct platform-spec URLs with human-readable relation labels; bi-directional discoverability is required during active migration windows when practical.

## Consequences

**Standard** pages that link legacy prefixes **must** mark those links non-normative in prose or `relatedTopics`.

## Verification anchors

`checkStaleLegacyBridge` in `platform-spec-content.ts`.

Source Record: Migration mapping page required sections

Authority: informative provenance
Legacy path: /platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0003-migration-mapping-page-shape/
Source: site/spec-content/platform-spec/community/spec-maintenance/non-normative-bridge-docs-policy/adr/0003-migration-mapping-page-shape/content.md
SHA-256: 55d47c5fcd79c27b2018a6ed5f4af2f58236394cca52def70436e12587b36948

Migrated source text
## Context

Ad-hoc mapping tables mixed partial coverage with implied normative scope.

## Decision

Migration mapping pages **must** include: (1) a one-sentence non-normative notice; (2) a **Canonical destinations** section linking target feature hubs; (3) a **Mapping scope** section stating coverage and exclusions; (4) a maintenance note for retirement timing. Multi-domain mappings **must** group links by destination domain/area.

## Consequences

Bridge pages become checklist-complete before merge; retirement removes the bridge when canonical nav suffices.

## Verification anchors

[Legacy spec mapping](/platform-spec/legacy-spec-mapping/) structure review in PR template.