310 lines
10 KiB
Markdown
310 lines
10 KiB
Markdown
# Wissensdokument 000 — Version 2.0.2
|
||
|
||
Was jetzt folgt, ist kein „Meta-Gelaber", sondern die **Verfassung** von *Marke macht.*
|
||
|
||
Ohne dieses Dokument wären alle anderen nur gut gemeint.
|
||
|
||
---
|
||
|
||
## Meta-Governance der Wissensdokumente
|
||
|
||
### Wie Klarheit geschützt, weiterentwickelt und entschieden wird
|
||
|
||
**Status:** Fixiert
|
||
|
||
**Version:** 2.0.2 (ersetzt 2.0.1)
|
||
|
||
**Gültig ab:** sofort
|
||
|
||
**Rolle:** Oberste Instanz für alle Wissensdokumente (001–999)
|
||
|
||
---
|
||
|
||
### Änderungsvermerk (gemäß §5.2)
|
||
|
||
| Feld | Wert |
|
||
| --- | --- |
|
||
| Version | 1.0 → 2.0 (methodisch: Ownership getrennt in Autorenschaft vs. Anwendung) |
|
||
| Datum | 27.05.2026 |
|
||
| Begründung | §4.1 (1.0) erklärte die methodische Letztinstanz pauschal für „nicht delegierbar". Das stand in Spannung zum Skalierungs- und Exit-Versprechen (Dok. 008) und zur Partner-Anwendung (Dok. 009) und machte das Audit zum personengebundenen Flaschenhals. v2.0 trennt **Autorenschaft** (nicht delegierbar) von **Anwendung** (delegierbar). Gewählte Schärfe: **Option A** – maximale Delegation der Anwendung inkl. komplexer Audits an Tool + Partner; bewusster früher Kontrollverlust über die Ausführung zugunsten Skalierung/Exit. Ergänzt **Selbstanwendung** als Proof-of-Method und benennt die **Bootstrapping-Phase** mit explizitem Ausgang. |
|
||
| Betroffene Dokumente | Dok. 000 §4 (Restrukturierung 4.1 → 4.1–4.5); löst latente Spannung zu Dok. 008 (Skalierung/Exit) und Dok. 009 (Partner-Anwendung); Anschluss an Dok. 011b §4.3 (Human-Gate beim Kunden-Owner) |
|
||
| Entscheidung | Kevin Adametz (Letztinstanz, §4.1) |
|
||
| Hinweis | Klassifikation als „methodisch" (v2.0) ist eine bewusste Setzung. Bei Lesart „Klarstellung" wäre v1.1 zulässig. |
|
||
| v2.0.1 (27.05.2026) | Redaktionell: kanonische Schreibweisen in §7 ergänzt (Marken-Hygiene, kein Methodikeingriff). |
|
||
| v2.0.2 (28.05.2026) | Redaktionell: Umbenennung Tool/Produkt von *brandwork.io* zu **Brand Rules** (Markenname) bzw. **brand-rules.com** (Domain). §7 entsprechend aktualisiert; Altschreibweise *brandwork.io* in die Liste unzulässiger Varianten verschoben. Kein Methodikeingriff. Betrifft alle nachgeordneten Dokumente einschließlich Synthese-, Markenwissen- und Implementierungsschicht. |
|
||
|
||
---
|
||
|
||
## 1. Zweck dieses Dokuments (warum es existiert)
|
||
|
||
Dieses Dokument definiert:
|
||
|
||
- **wer** Entscheidungen trifft
|
||
- **wie** Wissen verändert werden darf
|
||
- **was** bei Widersprüchen gilt
|
||
- **welche Logik** über allen anderen Dokumenten steht
|
||
|
||
> Ohne Meta-Governance ist jedes Regelwerk nur Meinung.
|
||
|
||
Dok. 000 ist die **höchste Autorität** im System *Marke macht.*
|
||
|
||
---
|
||
|
||
## 2. Geltungsbereich
|
||
|
||
Diese Meta-Governance gilt für:
|
||
|
||
- alle Wissensdokumente (001–999)
|
||
- alle Ableitungen daraus (Tool-Logik, Partnerhandbücher, Schulungen)
|
||
- alle externen Darstellungen der Methode
|
||
|
||
**Nicht betroffen:**
|
||
|
||
- Kundeninhalte
|
||
- individuelle Marken-DNA-Dokumente
|
||
|
||
---
|
||
|
||
## 3. Hierarchie der Wissensdokumente (entscheidend)
|
||
|
||
Bei Konflikten gilt **immer** folgende Prioritätsreihenfolge:
|
||
|
||
1. **Dok. 000 – Meta-Governance**
|
||
2. **Dok. 001 – Harte Diagnose**
|
||
3. **Dok. 002 – Struktur der Marken-DNA**
|
||
4. **Dok. 003 – Prozess & Erstellung**
|
||
5. **Dok. 004 – Marken-Agent & Systemlogik**
|
||
6. **Dok. 005 – Einstiegsangebot**
|
||
7. **Dok. 006 – Plattform-Narrativ**
|
||
8. **Dok. 007 – LinkedIn-Argumentationssystem**
|
||
9. **Dok. 008 – Produkt-Roadmap**
|
||
10. **Dok. 009+ – Erweiterungen & Anwendungen**
|
||
|
||
> Je näher ein Dokument an der Diagnose liegt, desto höher seine Autorität.
|
||
|
||
---
|
||
|
||
## 4. Entscheidungsinstanz (Ownership)
|
||
|
||
Ownership trennt sich in **zwei Schichten**: **Autorenschaft** (was die Regeln *sind* – nicht delegierbar) und **Anwendung** (was mit den Regeln *getan* wird – delegierbar, mit dem erklärten Ziel der Personenunabhängigkeit). Diese Trennung ist die **Selbstanwendung der eigenen Methode**.
|
||
|
||
---
|
||
|
||
### 4.1 Autorenschaft & Verfassungshoheit (nicht delegierbar)
|
||
|
||
**Kevin Adametz** ist:
|
||
|
||
- methodischer Urheber
|
||
- Verfasser und Hüter der Wissensdokumente (000–999)
|
||
- letzte Instanz für die **Weiterentwicklung der Methode** und für **echte methodische Grenzfälle** (neue Logik, strukturelle Konflikte)
|
||
|
||
Diese Rolle – *was die Regeln sind* – ist:
|
||
|
||
- **nicht delegierbar**
|
||
- **nicht abstimmungsfähig**
|
||
- **nicht temporär**
|
||
|
||
> Jede Methode hat einen Autor. Niemand erwartet, dass der Verfasser einer Verfassung austauschbar ist – sondern dass die Verfassung ohne ihn funktioniert.
|
||
|
||
*Marke macht.* ist kein Open-Source-Modell. Die Methode ist offen nutzbar – aber nicht offen veränderbar.
|
||
|
||
---
|
||
|
||
### 4.2 Methodische Anwendung (delegierbar – mit Ziel der Entbehrlichkeit)
|
||
|
||
Anwendung heißt: Audits durchführen, Inhalte validieren, DNA-Prozesse moderieren, Kunden ins System führen.
|
||
|
||
> Anwendung muss ohne den Urheber funktionieren – sonst ist das Versprechen der Personenunabhängigkeit hohl.
|
||
|
||
Anwendung wird – **auch in komplexen Fällen, einschließlich Audits** – über die Zeit **vollständig delegiert** an:
|
||
|
||
1. **das System** (Brand Rules, Scorecard, DNA-Engine) – kodifizierte Urteilslogik
|
||
2. **zertifizierte Partner** (Dok. 009/012) – unter Vertrag, ohne Methodenhoheit
|
||
3. **den Marken-Owner des Kunden** – als finales Human-Gate für eigene Inhalte (Dok. 011b §4.3)
|
||
|
||
**Erklärtes Ziel:** Kevin wird für die Anwendung entbehrlich. Die Qualitätssicherung der Ausführung liegt dann nicht mehr in seiner Einzelprüfung, sondern in der kodifizierten Regel (der Autorenschaft) und im System.
|
||
|
||
**Bewusste Konsequenz (Option A):** Mit der Delegation auch komplexer Audits gibt der Urheber **früh** Kontrolle über die Ausführung ab. Das ist gewollt – zugunsten von Skalierung und Exit-Fähigkeit. Der Hebel der Qualität verschiebt sich:
|
||
|
||
> von „Kevin prüft den Fall" zu „Kevin schreibt die Regel – das System prüft den Fall".
|
||
|
||
---
|
||
|
||
### 4.3 Selbstanwendung (Proof of Method)
|
||
|
||
*Marke macht.* wendet seine eigene Skalierungslogik (Dok. 001 §8) auf sich selbst an: Der Denkprozess des Urhebers wird kodifiziert – in den Wissensdokumenten, der Scorecard und Brand Rules. Diese **sind** das ausgelagerte methodische Bewusstsein von *Marke macht.*
|
||
|
||
> Die Personenunabhängigkeit, die wir verkaufen, vollziehen wir zuerst an uns selbst.
|
||
|
||
Das ist kein Eingeständnis einer Schwäche, sondern der Beweis der Methode.
|
||
|
||
---
|
||
|
||
### 4.4 Bootstrapping-Phase (ehrlich benannt)
|
||
|
||
Solange weder zertifizierte Partner noch ein reifes Tool existieren, ist die Anwendung faktisch personengebunden (an Kevin). Das ist ein normaler Gründungszustand – aber eine **Phase, kein Dauerzustand**.
|
||
|
||
Ausgang der Phase:
|
||
|
||
- Partner-Zertifizierung (Dok. 009)
|
||
- Reife von Scorecard und DNA-Engine (Dok. 011/011b)
|
||
- → Übergang an Tool + Partner gemäß §4.2
|
||
|
||
---
|
||
|
||
### 4.5 Operative Mitwirkung (Mitwirkung ≠ Autorenschaft)
|
||
|
||
Partner, Mitarbeiter oder Agenten dürfen:
|
||
|
||
- Feedback geben
|
||
- Widersprüche melden
|
||
- Erweiterungen vorschlagen
|
||
- die Methode **anwenden** (sofern zertifiziert)
|
||
|
||
Sie dürfen **nicht**:
|
||
|
||
- Dokumente eigenständig ändern
|
||
- Begriffe neu definieren
|
||
- bestehende Logik relativieren
|
||
|
||
> Anwendung wird geteilt. Autorenschaft nicht.
|
||
|
||
---
|
||
|
||
## 5. Änderungslogik (Versionierung)
|
||
|
||
### 5.1 Arten von Änderungen
|
||
|
||
| Typ | Beschreibung | Version |
|
||
| --- | --- | --- |
|
||
| Redaktionell | Klarstellung, Sprache | +0.0.1 |
|
||
| Strukturell | Reihenfolge, Ergänzung | +0.1 |
|
||
| Methodisch | neue Logik, neue Regeln | +1.0 |
|
||
|
||
### 5.2 Dokumentationspflicht
|
||
|
||
Jede Änderung erfordert:
|
||
|
||
- Versionsnummer
|
||
- Änderungsdatum
|
||
- Begründung (1–3 Sätze)
|
||
- Referenz auf betroffene Dokumente
|
||
|
||
> Keine stille Evolution. Nur bewusste Entscheidung.
|
||
|
||
---
|
||
|
||
## 6. Umgang mit Widersprüchen (sehr wichtig)
|
||
|
||
### 6.1 Arten von Widersprüchen
|
||
|
||
1. **Logische Widersprüche** (z. B. zwei gegensätzliche Aussagen)
|
||
2. **Anwendungswidersprüche** (Theorie funktioniert nicht in der Praxis)
|
||
3. **Interpretationswidersprüche** (unterschiedliches Verständnis)
|
||
|
||
### 6.2 Vorgehen bei Widersprüchen
|
||
|
||
1. Widerspruch wird **benannt**
|
||
2. Betroffene Dokumente werden referenziert
|
||
3. Priorität laut Hierarchie entscheidet
|
||
4. Niederrangiges Dokument wird angepasst
|
||
5. Änderung wird versioniert
|
||
|
||
> Diskussion endet, wo Hierarchie beginnt.
|
||
|
||
---
|
||
|
||
## 7. Schutz vor Verwässerung
|
||
|
||
Folgende Dinge sind **nicht erlaubt**:
|
||
|
||
- alternative Begriffsdefinitionen
|
||
- Vereinfachungen für Marketingzwecke
|
||
- „Übersetzungen" der Methode ohne Freigabe
|
||
- externe White-Label-Versionen
|
||
|
||
Warum:
|
||
|
||
> Klarheit stirbt nicht durch Kritik, sondern durch Verwässerung.
|
||
|
||
**Kanonische Schreibweisen (verbindlich):**
|
||
|
||
- **Marke macht.** (mit Schlusspunkt)
|
||
- **Brand Rules** (Tool/Produkt; zwei Wörter, beide großgeschrieben) · **brand-rules.com** (Domain; klein, mit Bindestrich, mit `.com`)
|
||
- **markemacht.de**
|
||
- **adametz.media**
|
||
|
||
Varianten wie *BrandRules*, *Brand-Rules*, *brandrules*, *brand rules* (klein) sowie die Altschreibweisen *brandwork.io*, *BrandWorks*, *Brandwork* sind unzulässig.
|
||
|
||
---
|
||
|
||
## 8. Verhältnis von Theorie und Praxis
|
||
|
||
Grundsatz:
|
||
|
||
> Praxis validiert Theorie. Aber Praxis überschreibt sie nicht.
|
||
|
||
Wenn Praxis widerspricht:
|
||
|
||
- wird die Theorie überprüft
|
||
- nicht sofort geändert
|
||
|
||
Systemfehler ≠ Anwenderfehler.
|
||
|
||
---
|
||
|
||
## 9. Veröffentlichung & Zugriff
|
||
|
||
### Intern
|
||
|
||
- vollständiger Zugriff auf alle Dokumente
|
||
- Änderungsverlauf sichtbar
|
||
|
||
### Extern
|
||
|
||
- nur freigegebene Auszüge
|
||
- keine vollständige Methodik
|
||
- keine Governance-Dokumente
|
||
|
||
> Nicht alles, was existiert, wird erklärt.
|
||
|
||
---
|
||
|
||
## 10. Erweiterungen des Systems
|
||
|
||
Neue Wissensdokumente dürfen entstehen, wenn:
|
||
|
||
- sie eine klare Lücke schließen
|
||
- sie nicht bestehende Dokumente duplizieren
|
||
- sie der Diagnose (001) nicht widersprechen
|
||
|
||
Nummerierung erfolgt: fortlaufend, logisch, nicht marketinggetrieben.
|
||
|
||
---
|
||
|
||
## 11. Gültigkeit & Revision
|
||
|
||
Dieses Dokument gilt:
|
||
|
||
- bis es **bewusst** geändert wird
|
||
- nicht implizit
|
||
- nicht stillschweigend
|
||
|
||
Geplante Revision: jährlich oder bei grundlegender Systemänderung.
|
||
|
||
---
|
||
|
||
## 12. Essenz (nicht verhandelbar)
|
||
|
||
- Klarheit braucht Hierarchie
|
||
- Hierarchie braucht Verantwortung
|
||
- Verantwortung ist nicht demokratisch
|
||
- Autorenschaft bleibt. Anwendung skaliert.
|
||
|
||
> Marke macht. Weil jemand entscheidet.
|
||
|
||
---
|
||
|
||
### Ende – Wissensdokument 000 (Version 2.0.2)
|
||
|
||
---
|