DBRS Canonical Language (DCL) Policy v1.0

DBRS Canonical Language (DCL) Policy v1.0

Status: normative system definitionValid from: 2026-01-27Author: Tolksdorf.digitalScope: 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