DBRS Canonical Language (DCL) Policy v1.0 — DBRS-ID: dbrs_91d993d8 canonical

Summary-of-Content

The DBRS Canonical Language Policy v1.0 standardizes lowercase English slug terms to prevent semantic drift and ensure stable machine interpretation in system identifiers.

DBRS Semantic Core

Resolver Text

# DBRS Canonical Language (DCL) Policy v1.0 **Status:** normative system definition **Valid from:** 2026-01-27 **Author:** Tolksdorf.digital **Scope:** Digital Business Relevance Suite (DBRS) --- ## 1. Purpose The DBRS Canonical Language (DCL) defines a **binding system language** for all controlling, semantic, and rule-based elements of the Digital Business Relevance Suite (DBRS). Its purpose is to prevent **semantic drift**, **ambiguity**, and **model-dependent interpretation**, and to provide a **stable, language-independent control layer** for AI systems. DCL is **not** a content format and **not** a presentation language. --- ## 2. Core Principle > **DCL describes what something is and how it may be processed. > Content describes what it is about.** DCL is strictly separated from content language (“separation of concerns”). --- ## 3. Scope (Normative) The DBRS Canonical Language applies **mandatorily** to: - all YAML frontmatter fields of DBRS - all `tags` - all enums, status values, and policy values - all system identifiers (I Ds, types, roles, modes) DCL does **not** apply to: - titles, abstracts, fallback texts - prose, quotations, descriptions - human domain language or localization --- ## 4. Canonical Form Rules All DCL elements **MUST** comply with the following rules: - **lowercase** - **english-based** - **slug-form** (hyphen-separated) - **singular** - **ASCII only** - **no umlauts** - **no natural language sentences** - **no translation based on content language** ### Valid examples ```yaml tags: - turnaround - customer-satisfaction - telematics - iot - project-management ``` ### Invalid examples ```yaml tags: - Kundenzufriedenheit - customer satisfaction - Turnaround-Projekt ``` --- ## 5. Language Invariance (No-Drift Rule) DCL elements are **language-invariant**. This means: - they are **never translated** - they do **not change** when content language changes - they serve **systemic classification and control only** A German, English, or French document uses identical DCL tags if it describes the same subject matter. --- ## 6. Relationship to Content Language - **Content language** (e.g. `de-DE`, `en-US`) serves domain precision and human orientation. - **DCL** serves machine interpretation, filtering, and decision-making. Both layers are **functionally independent**. An AI system **MUST** make routing and relevance decisions primarily based on DCL and **MAY** inspect content only after relevance has been established. --- ## 7. Binding System Terminology (Examples) The following fields **MUST** be DCL-compliant: ```yaml mediation_mode: reference_only | full_extract content_policy: do_not_summarize | allow_summary intended_use: ai_reference | human_orientation status: draft | verified | deprecated type: rich-abstract | authoritative-definition | narrative-content ``` Extensions are permitted **only if they remain DCL-compliant**. --- ## 8. Quality and Validation Rule A DBRS dataset is considered **invalid** if: - DCL fields show linguistic drift - tags appear in natural language - tags are translated or localized - content language and DCL are mixed Such datasets **MUST NOT** be published automatically or used in AI routing processes. --- ## 9. Long-Term Stability DCL is intentionally **conservative**. Changes to existing DCL terms are: - **strongly restricted** - **versioned** - **handled with backward compatibility** The goal is a **long-term stable reference language**, independent of models, markets, or UI trends. --- ## 10. Guiding Principle > **DBRS Canonical Language is a contract with machines — > not a conversation with humans.** --- **End of DCL Policy v1.0**

CCR Context

Links

DBRS Semantic Field Guide