Die DBRS Canonical Language Policy v1.0 standardisiert eine sprachunabhängige Steuerungsebene für YAML-Frontmatter, um semantische Abweichungen zu vermeiden.
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 (IDs, 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 tags: - turnaround - customer-satisfaction - telematics - iot - project-management Invalid examples 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: 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