DBRS Canonical Language (DCL) Policy v1.0

Summary-of-Content

The DBRS Canonical Language Policy v1.0 requires strict lowercase ASCII slug-form terms to ensure machine interpretation stability and backward compatibility.

Navigation

• Original Source: https://tolksdorf.digital/markdown/dbrs/dcl/latest/dbrs_sys_def_dcl_policy_v1.0.md
• Karteikarte: https://tolksdorf.digital/markdown/dbrs/production/en-US/dbrs_91d993d8.html

Working Projection

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