# 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 (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

```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**