Beitragsarten, Elemente und Checklisten im Zusammenhang

Ein langlebiges Contentsystem trennt Entscheidungen nach ihrem Geltungsbereich. Der Workflow legt fest, was die Website erstellen und prüfen soll. Die Beitragsart legt fest, welche Aufgabe eine Seite erfüllen muss. Das Element legt fest, was ein Block bedeutet und wie er sich verhält. Wenn diese Verantwortlichkeiten getrennt bleiben, kann ein Team eine Definition verbessern und überall wiederverwenden, ohne das gesamte System neu schreiben zu müssen.

Diese Seite erklärt diese Architektur. Sie erweitert das im Playbook-Hub vorgestellte Modell, zeigt die einseitige Abhängigkeit zwischen den drei Produktionsebenen und verfolgt eine reale AmICited-Academy-Seite von der Chancenauswahl bis zur Messung.

Das erweiterte Systemdiagramm

Der Playbook-Hub fasst das System als Planen → Bauen → Anpassen → Verbessern zusammen. Er identifiziert außerdem das Dokument, die Komponente, die Priorität und den Kreislauf, die durch die verbundenen Säulen dargestellt werden. Die erweiterte Ansicht unten macht die Abhängigkeitsrichtung explizit.

GRUNDLAGEN: gemeinsame Überlegungen zu Absicht, Belegen, Struktur und Vertrauen
                                │
GESCHÄFTSTYP: übergreifende Priorisierungslinse
                                │ beeinflusst die Reihenfolge der Chancen
                                ▼
┌──────────────────────────────────────────────────────────────────┐
│ PROZESS / CHECKLISTEN – wirken auf die Website                   │
│ Chance auswählen → Arbeit sequenzieren → genehmigen → veröffentlichen → überprüfen │
└──────────────────────────────┬───────────────────────────────────┘
                                 │ wählt aus
                                 ▼
┌──────────────────────────────────────────────────────────────────┐
│ BEITRAGSART – wirkt auf eine Seite                               │
│ Definiert den Seitenauftrag, Beleglast, Form und Abschnittsreihenfolge │
└──────────────────────────────┬───────────────────────────────────┘
                                 │ wählt aus und ordnet
                                 ▼
┌──────────────────────────────────────────────────────────────────┐
│ ELEMENTE – wirken auf einzelne Blöcke                            │
│ Definieren Zweck, Felder, Inhaltsregeln, Darstellung und Varianten │
└──────────────────────────────────────────────────────────────────┘
                                 │
                                 ▼
                           VERÖFFENTLICHTE SEITE
                                 │ beobachtet durch
                                 ▼
                 ERGEBNISSE: Belege für die nächste Prozessentscheidung

Der Ergebnis-Pfeil schließt einen Betriebskreislauf; er kehrt die Definitionsabhängigkeit nicht um. Ein schwaches Ergebnis kann dazu führen, dass der Prozess beim nächsten Mal eine andere Beitragsart auswählt, aber es erlaubt keinem Bericht, die Bedeutung eines Schrittlistenelements zu ändern. Ebenso informieren die Grundlagen jede Entscheidung, ohne selbst zu einer weiteren Produktionsebene zu werden.

Die sechs Säulen-Hubs sind verschiedene Zugänge zu diesem selben System. Nutzen Sie SEO-Grundlagen für die Überlegungen, SEO-Beitragsarten für Dokumentenformen, SEO-Inhaltselemente für Blöcke, SEO-Strategien nach Geschäftstyp für die Priorisierung, den SEO-Prozess für Produktionskontrollen und SEO-Ergebnisse für Messung und Folgeentscheidungen.

1. Die drei Ebenen, präzise definiert

1. Prozess und Checklisten wirken auf die Website

Ein Prozess ist das geordnete System von Entscheidungen, das die Website vom Beleg zur Aktion führt. Eine Checkliste ist ein begrenztes Prüfinstrument innerhalb dieses Prozesses. Zusammen entscheiden sie, welche Seiten existieren sollen, welche Abhängigkeit zuerst kommt, wer die Arbeit genehmigt, ob die Seite veröffentlicht werden kann und wann das Ergebnis überprüft wird.

Diese Ebene benötigt eine websiteweite Sicht, weil Seitenchancen um dasselbe Budget, dieselbe Expertise, Entwicklungskapazität und Crawl-Aufmerksamkeit konkurrieren. Eine technisch blockierte Website sollte die Produktion nicht einfach beschleunigen, nur weil zehn Briefings fertig sind. Ein Prozess kann sagen: „Schließen Sie die technische Basislinie ab, bevor Sie ein weiteres Cluster veröffentlichen“, weil er die Sequenzierung über Seiten hinweg besitzt. Er kann auch sagen: „Überprüfen Sie die Leistung nach dem vereinbarten Beobachtungszeitraum“, weil er den Kreislauf nach der Veröffentlichung besitzt.

Prozessregeln haben beobachtbare Eingaben und Entscheidungen. Ein nützlicher Checklistenpunkt benennt die zu prüfenden Belege, die Bestehensbedingung und was nach einem Fehlschlag passiert. „Links prüfen“ ist vage. „Bestätigen, dass jedes interne Ziel auflöst und jeder Anker es korrekt beschreibt; Veröffentlichung blockieren, wenn einer der Tests fehlschlägt“ kann ausgeführt und geprüft werden.

2. Eine Beitragsart wirkt auf eine Seite

Eine Beitragsart ist ein Vertrag für die Aufgabe, die eine einzelne Seite für einen Leser erfüllt. Die Aufgabe bestimmt die Form der Seite. Eine Anleitung ermöglicht eine Aufgabe; ein Glossarbegriff stiftet Bedeutung; ein Vergleich unterstützt eine Entscheidung; eine Fallstudie zeigt, was in einer bestimmten Situation passiert ist. Dies sind keine Etiketten, die nach dem Verfassen vergeben werden. Sie implizieren unterschiedliche Fragen, Beleglasten, Abschnittsreihenfolgen und Folgeaktionen.

Die Spezifikation der Beitragsart beantwortet Fragen wie:

• Welche Absicht muss diese Seite erfüllen?
• Warum passt dieses Format besser als benachbarte Formate?
• Welche Elemente sind erforderlich, empfohlen, bedingt oder verboten?
• In welcher Reihenfolge erscheinen diese Elemente, und welche Ausnahme erlaubt eine andere Reihenfolge?
• Welche Belege sind für die Behauptungen der Seite ausreichend?
• Welche Leseraktion folgt natürlicherweise auf die Erfüllung des Seitenauftrags?

Eine Beitragsart kann eine Warnung vor einem irreversiblen Schritt verlangen oder einen Quellenblock nach der letzten beleggestützten Behauptung platzieren. Sie besitzt diese Positionsregeln, weil die Position die Logik des gesamten Dokuments ausdrückt. Sie besitzt nicht die internen Felder oder die visuelle Gestaltung der jeweiligen Elemente.

3. Ein Element wirkt auf einen Block

Ein Element ist ein typisierter, wiederverwendbarer Inhaltsblock mit einem primären Zweck. Ein Direktantwort-Block beantwortet die Hauptfrage kompakt. Eine Vergleichstabelle organisiert konsistente Dimensionen. Ein Warnhinweis unterbricht den Fluss, weil das Übersehen des Risikos Schaden oder Misserfolg verursachen könnte. Ein Quellenblock macht Belege überprüfbar. Der Elementvertrag legt fest, was der Block enthält, welche Felder erforderlich sind, welche gültigen Variationen es gibt und wie Renderer seine Bedeutung bewahren.

Der Geltungsbereich endet an der Blockgrenze. Ein Warnhinweis kann ein Schweregradfeld definieren und verlangen, dass die Konsequenz explizit ist. Er kann nicht sagen, dass jede Anleitung nach Schritt drei einen braucht; das ist Seitenlogik. Ebenso kann ein Quellenblock ausreichende Veröffentlichungsdetails verlangen, um jede Quelle zu identifizieren. Er kann nicht entscheiden, welche Seitenchance als Nächstes recherchiert wird.

2. Abhängigkeit verläuft in eine Richtung

Die Abhängigkeitskette ist Prozess → Beitragsart → Elemente. Der Prozess wählt einen Seitenauftrag aus. Die gewählte Beitragsart wählt Blöcke aus und ordnet sie. Elemente sind die Atome, aus denen die Seite zusammengesetzt ist. Nichts in der Definitionskette zeigt nach oben.

Diese Richtung verhindert zirkuläre Zuständigkeiten. Wenn ein Element eine Bedingung wie „nur auf Alternativseiten anzeigen“ enthält, muss die Komponente nun wissen, welches Dokument sie enthält. Sie wird nicht mehr wiederverwendbar, Tests benötigen Seitenkontext, und ein Renderer muss die redaktionellen Richtlinien duplizieren. Die korrekte Regel ist entweder „Alternativseiten benötigen dieses Element an dieser Position“ in der Spezifikation der Beitragsart oder „dieser Block hat einen eigenständigen Zweck“ in einem separat definierten Element.

Der umgekehrte Fehler ist ebenso schädlich. Eine Beitragsart darf ein gemeinsames Element nicht neu definieren, indem sie ihm andere Pflichtfelder, Überschriftenverhalten oder Barrierefreiheitsregeln gibt. Sie kann eine unterstützte Variante auswählen, aber die Variante gehört immer noch zum Elementvertrag. Sonst können zwei Seiten behaupten, dasselbe Element zu verwenden, aber inkompatibles Markup und unterschiedliche Bedeutung ausliefern.

Betrachten Sie Auswahl und Definition als getrennte Befugnisse. Die obere Ebene wählt aus Verträgen aus, die darunter gepflegt werden. Sie bearbeitet diese Verträge niemals lokal.

3. Die Ebenenregel: Platziere jede Regel im engsten wiederverwendbaren Geltungsbereich

Regeln wandern nach oben oder unten, wenn Teams Anleitungen nach der zu bearbeitenden Datei statt nach dem zu steuernden Verhalten organisieren. Das Gegenmittel ist ein Drei-Fragen-Test:

1. Steuert die Regel die Bedeutung, Felder oder Darstellung eines Blocks? Platziere sie in der Element-Definition.
2. Steuert sie den Auftrag, das Belegmuster, das Vorhandensein von Abschnitten oder die Abschnittsreihenfolge einer Seite? Platziere sie in der Spezifikation der Beitragsart.
3. Steuert sie die Chancenauswahl, Arbeitsreihenfolge, Genehmigung, Veröffentlichung oder spätere Bewertung über Seiten hinweg? Platziere sie im Prozess oder in der Checkliste.

„Quellen immer angeben“ ist zu weit gefasst, um es wörtlich umzusetzen: Nicht jeder Satz benötigt eine Quellenangabe. Die wiederverwendbare Regel ist, dass beleggestützte Behauptungen mit identifizierbaren Quellen verbunden sein müssen, und das Quellenelement definiert die Darstellung und die Mindestfelder. Eine Beitragsart kann dieses Element dann verlangen, wenn ihre üblichen Behauptungen externe Belege erfordern.

„Dieser Typ endet immer mit einem Abschnitt zu Alarmzeichen“ gehört zur Beitragsart. Die Regel existiert, weil ein Leser, der diese Dokumentenform nutzt, vor einer Handlung Ausschlussbedingungen benötigt. Der Block kann ein Warnhinweis-Element verwenden, aber der Seitenvertrag besitzt dessen Vorhandensein und endgültige Position.

„Vor bestandener technischer Basislinienprüfung niemals veröffentlichen“ gehört zum Prozess. Er steuert die Reihenfolge und den Freigabestatus von Arbeiten auf der gesamten Website; weder die Seite noch ein Block kann die technische Bereitschaft der Website überprüfen.

Eine falsch platzierte Regel mag auf der ersten Seite harmlos erscheinen. Die Kosten zeigen sich bei der zehnten. Autoren kopieren lokale Ausnahmen, Komponenten erhalten versteckte Kontexte, Checklisten sammeln Stilhinweise, und niemand weiß, welche Definition maßgeblich ist. Die Wiederverwendbarkeit verschwindet, selbst wenn dieselben Namen erhalten bleiben.

4. Beispielhafter Ablauf: Eine Core-Web-Vitals-Academy-Seite

Betrachten Sie die veröffentlichte Seite So überprüfen Sie Ihre Core Web Vitals in AmICited . Sie ist ein nützlicher Ablauf, weil sie eine abgegrenzte Aufgabe vermittelt, einen echten Produktbildschirm zeigt, unbekannte Metriken erklärt und zu wiederholbaren Aktionen führt. So sollte das System diese Seite von oben nach unten produzieren.

1. Der Prozess wählt die Chance aus

Während der technischen Basislinienprüfung stellt das Team fest, dass Nutzer das Web-Vitals-Audit interpretieren müssen, anstatt nur fünf Abkürzungen und farbige Werte zu sehen. Das Belegpaket dokumentiert die Leserfrage – „Wie überprüfe und handle ich auf Basis von Core Web Vitals in AmICited?“ – die betroffene Produktoberfläche, die bestehenden Suchergebnis-Muster, verfügbare Produktbelege und das gewünschte Ergebnis: Ein Nutzer kann das Audit öffnen, jede Metrik interpretieren, eine Korrektur priorisieren und wissen, wann er erneut prüfen muss.

Die Phase wählt eine Seite aus, weil der Bedarf dauerhaft ist, aus verifiziertem Produktverhalten beantwortet werden kann und eine echte Aufgabe unterstützt. Sie legt auch Abhängigkeiten fest: Produkt-Workflow und Terminologie vor dem Verfassen bestätigen; keine Schwellenwerte erfinden oder behaupten, dass Performance allein KI-Zitate verursacht.

2. Der Prozess wählt eine Beitragsart

Die gewählte Beitragsart ist Anleitung, weil der Leser eine Abfolge in einem Produkt durchführen möchte. Eine Was-ist-X-Seite würde Core Web Vitals erklären, aber den Leser nicht durch die Benutzeroberfläche führen. Ein ultimativer Leitfaden würde den Umfang auf Testmethoden, technische Korrekturen und umfassendere Performancestrategie ausweiten und die unmittelbare Aufgabe verzögern. Eine Listen-Anleitung würde eine bewertete oder nummerierte Aufzählung versprechen, statt eines zusammenhängenden Workflows.

Diese Wahl begründet das Seitenversprechen: Am Ende kann der Leser das Audit finden, seine Ausgabe verstehen, entscheiden, was zuerst zu korrigieren ist, und eine erneute Prüfung planen.

3. Die Beitragsart wählt Elemente aus und ordnet sie

Der Anleitungsvertrag setzt die Seite in dieser Reihenfolge zusammen:

Positionsregeln sind wichtig. Die Definition geht der Metrik-Interpretation voraus, weil Anleitungen nicht von undefinierten Begriffen abhängen können. Der Screenshot steht neben der Navigation und nicht am Ende, weil visuelle Belege am Orientierungspunkt am nützlichsten sind. Der Hinweis zu fehlenden Daten bleibt neben dem Bildschirmzustand, den er erklärt, damit Leser einen nicht verfügbaren Wert nicht für ein defektes Audit halten.

Jeder Block folgt weiterhin seiner eigenen Elementdefinition. Der Seitentyp entscheidet, dass der Hinweis in der Nähe des Produktbildschirms gehört; das Hinweis-Element entscheidet über seine Semantik und Darstellung. Der Seitentyp entscheidet, dass eine geordnete Aktionssequenz erforderlich ist; das Schrittlisten-Element entscheidet, wie ein Schritt dargestellt wird. Dies ist die Abhängigkeitsgrenze in der Praxis.

4. Die Seite durchläuft das QA-Gate

Die QA-Checkliste vor der Veröffentlichung bewertet die zusammengestellte Seite, ohne ihre Verträge neu zu schreiben. Sie bestätigt, dass der Produktpfad mit der aktuellen Oberfläche übereinstimmt, der Screenshot den genannten Bildschirm zeigt, Akronyme bei erster Verwendung ausgeschrieben werden, Ratschläge aus verfügbaren Belegen folgen, interne Ziele auflösen, die Überschriftenstruktur stimmig ist und die Seite die Aufgabe auch beim Überfliegen erfüllt.

Ein Fehlschlag geht an den Eigentümer des Problems zurück. Ein falscher Produktpfad geht zurück zur Inhaltsverifizierung. Ein fehlender erforderlicher Abschnitt geht zurück zur Umsetzung der Beitragsart. Ein nicht zugänglicher Hinweisstil geht zurück zum Element-Renderer. Die Checkliste meldet den Fehlschlag; sie absorbiert nicht die Qualitätsregel und wird nicht zur dauerhaften Definition eines guten Hinweises oder einer guten Anleitung.

5. Der Ergebnisbericht misst den Seitenauftrag

Der Messdatensatz beginnt mit einer Veröffentlichungsbasislinie und einem Beobachtungszeitraum. Er verfolgt, ob die Seite für ihre beabsichtigte Frage sichtbar wird, ob Such- oder Antwortsysteme sie auswählen, ob Leser sich mit den Anleitungen beschäftigen und ob sie zum relevanten Produkt-Workflow übergehen. Dies sind getrennte Belegebenen: Sichtbarkeit ist nicht Aufgabenabschluss, und ein Produktbesuch ist kein Beleg dafür, dass der Artikel ein kommerzielles Ergebnis verursacht hat.

Zum Überprüfungszeitpunkt unterstützt der Bericht eine Prozessentscheidung: Seite behalten, unklare Abschnitte überarbeiten, geänderte Oberflächendetails aktualisieren, nur erweitern, wenn neue Leserbedürfnisse verifiziert sind, Überschneidungen konsolidieren oder einstellen. Die Messung schließt den Betriebskreislauf, indem sie die nächste Prozessentscheidung informiert, ohne einen Vertrag auf niedrigerer Ebene zu ändern.

5. Der Geschäftstyp ist eine Facette, keine vierte Ebene

Ein Geschäftstyp beschreibt den kommerziellen Kontext: wie die Organisation Wert schafft, was Kunden vor dem Kauf verstehen müssen und welche Journeys Content-Investitionen verdienen. Er durchzieht die Architektur, weil dieser Kontext die Priorisierung an mehreren Entscheidungspunkten beeinflusst. Er fügt keine weitere Ebene zwischen einer Beitragsart und einem Element hinzu.

Bei einem SaaS-Produkt können Vergleichs-, Anwendungsfall-, Produkt- und Anleitungsseiten frühe Aufmerksamkeit verdienen, weil Evaluierung, Adoption und Bindung wichtig sind. Ein E-Commerce-Unternehmen priorisiert möglicherweise Kategorie-, Produkt-, Vergleichs- und Best-für-Anwendungsfall-Seiten, weil Entdeckung und Produktauswahl anders funktionieren. Dies sind Priorisierungshypothesen, die die Forschung validieren muss, keine neuen Definitionen der Formate.

Die gleiche Vergleichstabelle bleibt in beiden Kontexten dasselbe Element. Die gleiche Anleitungs-Beitragsart behält denselben Seitenauftrag. Der Geschäftskontext ändert, welche Seiten in die Roadmap aufgenommen werden, welche kommerziellen Belege sie benötigen und ihre Priorität gegenüber anderen Chancen. Wenn eine „SaaS-Vergleichstabelle“ nur deshalb andere Semantiken erhält, weil sie auf einer SaaS-Website erscheint, ist Geschäftslogik in ein Element durchgesickert.

6. Versionierung ohne stille Neuinterpretation

Veröffentlichte Seiten wurden gegen bestimmte Verträge genehmigt. Eine spätere Verbesserung muss diese Historie bewahren, anstatt so zu tun, als ob jede alte Seite bereits konform wäre.

Wenn sich eine Elementdefinition ändert, klassifizieren Sie die Änderung zunächst. Eine kompatible Darstellungskorrektur – wie korrigierter Abstand oder verbessertes barrierefreies Markup mit derselben Bedeutung und denselben Feldern – kann alle Instanzen über den gemeinsamen Renderer aktualisieren. Eine semantische oder strukturelle Änderung – wie die Einführung verpflichtender Quellendaten oder eine Änderung der Bedeutung von Schweregrad – erzeugt eine neue Version. Bestehende Seiten werden weiterhin unter dem Vertrag dargestellt, den sie verwendet haben, bis sie eine validierte Migration durchlaufen.

Der Migrationsdatensatz sollte betroffene Instanzen identifizieren, alte Felder auf neue abbilden, Inhalte kennzeichnen, die redaktionelles Urteil erfordern, jede unterstützte Ausgabe testen und den Abschluss dokumentieren. Wenn eine zuverlässige Abbildung unmöglich ist, fabrizieren Sie keine fehlenden Belege. Stellen Sie die Instanz in eine Überprüfungswarteschlange.

Wenn eine Beitragsart einen erforderlichen Abschnitt erhält, übernehmen neue Entwürfe sofort die überarbeitete Spezifikation. Bereits veröffentlichte Seiten kommen in eine Nachrüstungs-Rückliste. Erfassen Sie sie nach Beitragsarten-Version, bewerten Sie, ob der neue Abschnitt relevant und unterstützbar ist, priorisieren Sie nach Risiko und Wert, aktualisieren Sie die Quelle, führen Sie QA durch und dokumentieren Sie die neue Version. Bis die Migration abgeschlossen ist, sollten Dashboards zwischen „veröffentlicht unter Version 1“ und „konform mit Version 2“ unterscheiden.

Prozess-Checklisten benötigen ebenfalls Versionen, aber ihre Änderung betrifft zukünftige Ausführungen, anstatt das historische Ergebnis einer abgeschlossenen Überprüfung stillschweigend zu ändern. Bewahren Sie die Belege, die zeigen, welche Checklisten-Version jede Freigabe genehmigt hat.

7. Anti-Patterns, die eine gebrochene Grenze aufdecken

Eine Beitragsart, die in Wirklichkeit ein Element ist

„FAQ-Beitrag“ benennt oft ein einzelnes Akkordeon statt eines Dokumentenauftrags. Die eigentliche Aufgabe des Lesers kann das Erlernen eines Konzepts, die Bewertung eines Produkts oder die Lösung eines Problems sein. FAQ ist dann ein Element, das gewählt wird, weil mehrere einzelne Fragen offen sind, nicht der bestimmende Typ der Seite. Erheben Sie etwas nur dann zu einer Beitragsart, wenn es eine eigenständige Absicht, Dokumentenform, Beleglast und Folgeaktion definiert.

Ein Element, das nur von einer Beitragsart verwendet wird

Einmalige Nutzung ist kein automatischer Beleg für einen Fehler, aber ein starkes Überprüfungssignal. Wenn der Block keinen eigenständigen Zweck außerhalb eines Seitenvertrags hat, ist er möglicherweise einfach ein erforderlicher Abschnitt in der Spezifikation dieser Beitragsart. Ein zu frühes Erstellen eines Elements fügt Renderer, Schema, Dokumentation und Versionierungsaufwand ohne Wiederverwendung hinzu. Behalten Sie es in der Beitragsart, bis eine zweite echte Nutzung einen stabilen, gemeinsamen Zweck demonstriert.

Ein Checklisten-Schritt, der eigentlich eine Qualitätsregel ist

„Klare Warnungen schreiben“ ist kein ausführbarer Prüfpunkt, weil „klar“ kein definiertes Akzeptanzkriterium hat. Das Warnungs-Element sollte das Risiko, die auslösende Bedingung und die Konsequenz verlangen. QA kann dann überprüfen, ob diese Felder vorhanden und unterstützt sind. Die Checkliste beobachtet die Einhaltung; sie sollte nicht der einzige Ort sein, an dem der Qualitätsstandard existiert.

Lokale Neudefinitionen mit vertrauten Namen

Eine benutzerdefinierte Box „Quellen“ zu nennen, macht sie nicht zum Quellen-Element. Wenn eine Vorlage einer Beitragsart deren Felder oder Bedeutung lokal ändert, können Autoren nicht wissen, welcher Vertrag gewinnt. Verwenden Sie das kanonische Element, schlagen Sie eine unterstützte Variante vor oder behalten Sie wirklich seiten-spezifischen Text unter einem anderen Namen in der Spezifikation der Beitragsart.

Prozesslogik in Seitenkopien eingebettet

Redaktionelle Anweisungen wie „erst veröffentlichen, wenn die Technik freigegeben hat“ sollten nicht in der öffentlichen Seite oder im verfassten Inhalt eines Elements verbleiben. Die Genehmigung gehört in den Workflow-Status und Checklisten-Belege. Die Vermischung von Produktionssteuerung mit lesersichtbarem Text macht Exporte unsicher und macht das eigentliche Gate davon abhängig, dass jemand einen Satz bemerkt.

Ein praktischer Zuständigkeitstest

Wenn eine neue Regel auftaucht, schreiben Sie sie als vollständigen Satz und unterstreichen Sie ihr Subjekt. Wenn das Subjekt dieser Block ist, entscheidet der Element-Eigentümer. Wenn es diese Art von Seite ist, entscheidet der Beitragsarten-Eigentümer. Wenn es diese Website, dieses Release, diese Kampagne oder diesen Produktionsdurchlauf ist, entscheidet der Prozess-Eigentümer. Fragen Sie dann, ob die obere Ebene einen niedrigeren Vertrag auswählt oder ihn heimlich neu definiert.

Diese kleine Disziplin hält das System lesbar. Prozess und Checklisten steuern die Website-Arbeit. Beitragsarten steuern Dokumente. Elemente steuern Blöcke. Geschäftstypen bewerten Chancen im gesamten System, und Ergebnisse senden Belege zurück zur nächsten Prozessentscheidung. Jede Ebene kann sich weiterentwickeln, weil jede Regel ein Zuhause hat und jede Abhängigkeit in eine Richtung verläuft.