Terminology and Language Policy
Verbindliche Sprachregel fuer die IIO-Dokumentation: Informatik- und IT-Fachsprache zuerst, IIO-Wording als klares Mapping. Business- und Team-Sprache wird ueber Uebersetzung und Sprachstile angebunden.
0. Top-20 Begriffe fuer den schnellen Einstieg
| Begriff | 1-Satz-Erklaerung |
|---|---|
| Actor | Identifizierbare Einheit, die im System handelt (Mensch oder Agent). |
| Role | Kontext, der festlegt, welche Aufgaben ein Actor ausfuehren darf. |
| Skill | Nachgewiesene Faehigkeit, die fuer bestimmte Rollen/Operationen gebraucht wird. |
| Evidence | Pruefbarer Nachweis fuer die Gueltigkeit eines Skills oder einer Entscheidung. |
| Proficiency | Reifegrad eines Skills (novice, practitioner, expert). |
| Story | Zweck- und Wirkungspfad einer Aenderung im Betrieb. |
| Transaction | Append-only Zustandswechsel mit nachvollziehbaren Metadaten. |
| Audit Trail | Lueckenlose Nachweiskette aller relevanten Aktionen und Freigaben. |
| Gate Cascade | Feste Reihenfolge von Pruefungen vor einer GO-Entscheidung. |
| GO/BLOCK/ESCALATE | Standardisierte Entscheidungsresultate im IIO-Betrieb. |
| Fail-Closed | Bei Unsicherheit oder fehlendem Input wird sicherheitshalber blockiert. |
| HITL | Menschliche Freigabe fuer risikoreiche oder unklare Entscheidungen. |
| Seed | Referenzmodell mit Regeln und Struktur fuer neue Ableitungen. |
| Node (tenant) | Konkrete Betriebsinstanz fuer Kunde/Organisation im Alltag. |
| Projection | Kontrollierte Ableitung eines Nodes aus dem Seed. |
| Composition | Koordinierter Verbund mehrerer Actors mit gemeinsamer Story. |
| Boundary | Definierte Grenze fuer Zugriff, Sichtbarkeit und Verantwortung. |
| Dispatch | Zuordnung einer Operation zu passendem Actor, Role und Skill. |
| Guardrail | Operative Leitplanke zur Vermeidung von Fehlverhalten unter Last. |
| Traceability | Rueckverfolgbarkeit von Entscheidung bis Artefakt und Quelle. |
Operator-Hinweis
- Diese Top-20 zuerst lesen, dann in die Cluster und A-Z-Ansicht springen.
- Bei Governance-Fragen immer die Begriffe Actor, Role, Skill, Evidence gemeinsam betrachten.
- Bei Incident/Review zuerst Transaction, Audit Trail, Gate Cascade und Fail-Closed pruefen.
0.1 Visuelle Begriffslandkarte
Mindmap: IIO Begriffswelt auf einen Blick
mindmap
root((IIO Begriffswelt))
Governance
Actor
Role
Skill
Evidence
Gate Cascade
GO/BLOCK/ESCALATE
HITL
Operations
Transaction
Audit Trail
Dispatch
Operator Runbook
Rollback
Drift
Architektur
Seed
Node (tenant)
Projection
Composition
Boundary
Federation
Runtime Contract
Publishing
Language Channel
Canonical Source
Traceability
Flow: Von Begriff zu operativer Entscheidung
flowchart LR
A[Actor + Role] --> B[Skill + Proficiency]
B --> C[Evidence Class]
C --> D[Gate Cascade]
D --> E{Decision}
E -->|GO| F[Transaction Write]
E -->|BLOCK| G[Fail-Closed Stop]
E -->|ESCALATE| H[HITL Review]
F --> I[Audit Trail + Traceability]
H --> I
Interpretation
- Ein Begriff ist nie isoliert, sondern Teil eines Entscheidungsflusses.
- Governance-Begriffe bestimmen, wer handeln darf; Operations-Begriffe beweisen, was passiert ist.
- Architektur- und Publishing-Begriffe sichern Skalierung und konsistente Kommunikation.
0.2 Entscheidungs-Checkkarte (1-Screen, druckbar)
Nutzung: Diese Karte vor jeder riskanten Aenderung einmal vollstaendig durchlaufen.
| Check | Frage | Wenn "Nein" |
|---|---|---|
| Actor | Ist ein eindeutiger Actor fuer die Operation gesetzt? | BLOCK |
| Role | Hat der Actor die erforderliche Rolle? | BLOCK |
| Skill | Ist der benoetigte Skill vorhanden und passend? | BLOCK |
| Evidence | Reicht die Evidence-Klasse fuer das Risiko? | ESCALATE oder BLOCK |
| Gate | Wurden alle relevanten Gates geprueft? | BLOCK |
| HITL | Ist HITL erforderlich und erfolgt? | ESCALATE |
| Transaction | Ist die TX append-only und vollstaendig dokumentiert? | BLOCK |
| Audit | Ist der Nachweispfad reproduzierbar (Traceability)? | BLOCK |
Decision-Mini-Flow
flowchart TD
A[Actor gesetzt?] -->|Nein| B[BLOCK]
A -->|Ja| C[Role + Skill passend?]
C -->|Nein| B
C -->|Ja| D[Evidence ausreichend?]
D -->|Nein| E[ESCALATE/HITL]
D -->|Ja| F[Gate + TX + Audit vollstaendig?]
F -->|Nein| B
F -->|Ja| G[GO]
Print-Kurzmodus
- Actor, Role, Skill, Evidence.
- Gate-Cascade und HITL.
- Transaction + Audit Trail.
- Ergebnis nur GO/BLOCK/ESCALATE.
1. Grundregel
Primaersprache: Standardisierte Informatik- und IT-Fachbegriffe. Sekundaersprache: IIO-Begriffe als Mapping in Klammern oder Glossarspalte. Stilvarianten: Management-, Team- und Kundensprache werden als Uebersetzungsschicht aus der Primaersprache abgeleitet.
2. Kern-Glossar (Fachwort -> IIO)
| Fachwort | IIO-Wort | Praktischer Einsatz |
|---|---|---|
| Referenztemplate / Kernmodell | Seed | Zentrale Regeln, Methoden, Governance-Rails |
| Mandant / Kundeninstanz | Node (tenant) | Konkreter Client-Betrieb, lokale Teams und Prozesse |
| Ableitung / Initialisierung | Projection | Erzeugung einer neuen Node aus dem Seed |
| Rollenpaket | Role Package | Betriebliche Aufgaben- und Berechtigungsbündel |
| Betriebsnachweis | Evidence | Prüfbare Nachweise fuer Gates und Audits |
| Zustandswechselprotokoll | Transaction | Append-only Dokumentation von Zustandswechseln |
| Freigabeentscheidung | GO/BLOCK/ESCALATE | Review- und Release-Entscheidung |
2.1 Anschlussfaehigkeit zu IT- und Uni-Standards
Damit externe IT-Teams und Informatik-Kontexte sofort anschlussfaehig sind, wird IIO-Wording auf gaengige Fachsprache abgebildet. Das ist kein Bruch, sondern ein kontrolliertes Mapping mit anschliessender Stil-Uebersetzung fuer unterschiedliche Zielgruppen.
| IIO-Begriff | Gaengiger IT-/Uni-Begriff | Kontext |
|---|---|---|
| Seed | Reference Template / Baseline Architecture | Referenzmodell, von dem Instanzen abgeleitet werden |
| Node (tenant) | Tenant / Instance / Deployment Unit | Konkrete mandantenbezogene Betriebsinstanz |
| Projection | Instantiation / Provisioning from Template | Ableitung einer Instanz aus der Baseline |
| Transaction | Change Record / Audit Trail Entry | Nachvollziehbarer, append-only Zustandswechsel |
| Evidence | Verification Evidence / Trace Artifact | Pruefbare Nachweise fuer Reviews und Audits |
| GO/BLOCK/ESCALATE | Decision Gate / Approval Outcome | Steuerentscheidung im Change- und Release-Prozess |
2.2 Verbindliche Begriffe fuer Intelego, Kunden und Kundenprojekte
Diese Matrix ist die kanonische Benennung fuer euren Betrieb. Sie soll als Source-of-Truth fuer DE/EN-Uebersetzungen dienen.
| Betriebsfall | Kanonischer IT/CS-Begriff (DE) | EN | IIO-Mapping | Nicht verwenden als Default |
|---|---|---|---|---|
| Intelego als konkrete Zielinfra | Tenant-Instanz Intelego | Intelego tenant instance | Node (tenant) | Hub (nur wenn echte Hub-Funktion vorliegt) |
| Weitere Kunden neben Intelego | Weitere Tenant-Instanzen | Additional tenant instances | Weitere Nodes | Sub-Node, Mini-Seed |
| Kunde als Organisation | Kundenorganisation / Mandant | Customer organization / tenant | Node-Kontext | Node selbst als Firmenname ohne Klartext |
| Projekt bei einem Kunden | Kundenprojekt | Customer project | Projekt im Node-Kontext | Eigener Seed, eigener Tenant (wenn es nur ein Projekt ist) |
| Aus Seed abgeleitete neue Instanz | Instanziierung / Ableitung | Instantiation / projection | Projection | Seeding als Hauptbegriff in formaler Doku |
| Gesamtheit mehrerer Kundeninstanzen | Kundenportfolio von Tenant-Instanzen | Tenant instance portfolio | Node-Portfolio | Einzelner Hub (wenn nicht zentral orchestriert) |
2.3 Ausfuehrliches IIO-Fachglossar (modern + praxisnah)
Cluster-Sprungmarken
A-Z Sprungmarken
Cluster: Governance
Actor, Role, Policy as Code, Premise, Gate Cascade, GO/BLOCK/ESCALATE, HITL, Audit Trail, Traceability
Cluster: Operations
Operator Runbook, Dispatch, Transaction, Revision, Rollback, Drift, Evidence Class, Proficiency
Cluster: Architektur
Seed, Node (tenant), Projection, Composition, Federation, Boundary, Semi-permeable Boundary, Root Placement, Layer Integration, Runtime Contract
Cluster: Language & Publishing
Language Channel, Canonical Source, Deterministic Processing
A-Z Index A-F
- A: Actor, Audit Trail
- B: Boundary
- C: Canonical Source, Composition
- D: Deterministic Processing, Dispatch, Drift
- E: Evidence Class
- F: Fail-Closed, Federation
A-Z Index G-L
- G: Gate Cascade, GO/BLOCK/ESCALATE, Guardrail
- H: HITL
- L: Language Channel, Layer Integration
A-Z Index M-R
- N: Node (tenant)
- O: Operator Runbook
- P: Policy as Code, Premise, Proficiency, Projection
- R: Revision, Role, Rollback, Root Placement, Runtime Contract
A-Z Index S-Z
- S: Seed, Semi-permeable Boundary, Skill, Skill Registry, Story
- T: Traceability, Transaction
| Begriff | Kurzdefinition | Warum relevant im IIO-Betrieb |
|---|---|---|
| Actor | Handlungsfaehige Einheit (Mensch oder Agent) mit eindeutiger ID. | Ohne klaren Actor keine gueltige Transaktion und kein Audit-Anker. |
| Role | Berechtigter Aufgabenkontext eines Actors. | Steuert, wer welche Operationen ausfuehren oder freigeben darf. |
| Skill | Nachweisbare Faehigkeit mit Evidence und Proficiency. | Verhindert implizite Kompetenzannahmen bei kritischen Ops. |
| Skill Registry | Kanonisches Verzeichnis aller Skills, Prerequisites und Konflikte. | Basis fuer deterministischen Dispatch und Reliance-Entscheidungen. |
| Evidence Class | Qualitaetsstufe eines Nachweises (mcp/workspace/model/attestation). | Definiert HITL-Pflicht und Vertrauensniveau. |
| Proficiency | Reifegrad eines Skills (novice/practitioner/expert). | Regelt, ob ein Actor nur assistiert oder eigenstaendig handeln darf. |
| Composition | Koordinierter Verbund mehrerer Actors mit gemeinsamer Story. | Wichtig fuer teamuebergreifende Ausfuehrung und Konfliktsteuerung. |
| Boundary | Definierte Zugriffs- und Sichtgrenze einer Composition oder eines Layers. | Schuetzt vor Scope-Leaks und unkontrollierter Kopplung. |
| Semi-permeable Boundary | Selektiv oeffnende Grenze mit expliziter Freigabe. | Erlaubt kontrollierte Zusammenarbeit ohne Vollzugriff. |
| Federation | Geregelte Kopplung mehrerer Compositions/Nodes. | Ermoeglicht Skalierung ueber Organisationseinheiten hinweg. |
| Story | Nachvollziehbarer Zweckpfad einer Aenderung (Warum + Wirkung). | Verhindert kontextlose Technik-Aenderungen ohne Betriebsbezug. |
| Transaction | Append-only Zustandswechsel mit Actor, Evidence und Zeitbezug. | Kern fuer Revisionssicherheit und forensische Rekonstruktion. |
| Audit Trail | Lueckenlose Kette aller relevanten Entscheidungen und Aktionen. | Noetig fuer Governance, Compliance und Incident-Aufarbeitung. |
| Gate Cascade | Feste Reihenfolge von Pruef-Gates vor GO-Entscheidungen. | Erzwingt systematische Qualitaet statt Ad-hoc-Freigaben. |
| Fail-Closed | Bei fehlendem Input oder unklarer Lage wird BLOCK statt GO erzeugt. | Reduziert Risiko stiller Fehler in kritischen Betriebswegen. |
| Deterministic Processing | Gleiches Input-Set erzeugt gleiches Ergebnis. | Voraussetzung fuer reproduzierbare Automation und Audits. |
| HITL (Human in the Loop) | Verbindliche menschliche Freigabe bei Risiko- oder Unsicherheitslagen. | Sicherheitsnetz fuer Entscheidungen mit hoher Tragweite. |
| GO/BLOCK/ESCALATE | Standardisierter Dreiklang der Entscheidungslogik. | Macht Entscheidungen vergleichbar und operativ steuerbar. |
| Seed | Referenzmodell mit Basisregeln, Guardrails und Struktur. | Startpunkt fuer kontrollierte Ableitungen neuer Betriebsinstanzen. |
| Node (tenant) | Konkrete Kunden- oder Bereichsinstanz im Betrieb. | Ort der realen Ausfuehrung, Teams, Projekte und Daten. |
| Projection | Instanziierung eines Nodes aus dem Seed. | Standardisiert Rollout und minimiert Wildwuchs in Setups. |
| Root Placement | Regelwerk zur korrekten Ablage von Artefakten im Workspace. | Verhindert Strukturdrift und inkonsistente Ownership. |
| Guardrail | Operative Leitplanke mit klaren Verboten/Erlaubnissen. | Stabilisiert Ausfuehrung auch unter Zeitdruck. |
| Policy as Code | Formale Regeln als versioniertes Artefakt. | Pruefbar, reviewbar und automatisierbar statt implizit. |
| Drift | Abweichung zwischen Soll-Kontrakt und Ist-Zustand. | Fruehindikator fuer Sicherheits- und Qualitaetsverlust. |
| Rollback | Rueckkehr auf vorherigen, validierten Zustand. | Sicherheitsmechanismus bei regressiven Aenderungen. |
| Revision | Versionierter, nachvollziehbarer Aenderungszustand. | Bindeglied zwischen Ausfuehrung, Dokumentation und Audit. |
| Runtime Contract | Laufzeitregeln fuer Inputs, Outputs und Verhaltenspflichten. | Sichert stabile Schnittstellen zwischen Komponenten. |
| Dispatch | Zuweisung einer Operation an Actor + Role + Skill. | Zentral fuer planbare Ausfuehrung in Multi-Actor-Systemen. |
| Operator Runbook | Schrittfolge fuer wiederkehrende Betriebsoperationen. | Macht kritische Prozesse reproduzierbar und trainierbar. |
| Canonical Source | Autoritative Quelle fuer eine Regel oder Information. | Verhindert konkurrierende Wahrheiten im System. |
| Premise | Grundannahme/Leitregel, auf der Entscheidungen beruhen. | Definiert den Governance-Rahmen fuer alle Layer. |
| Layer Integration | Verbindungslogik zwischen Architektur-, Skill-, TX- und Audit-Layern. | Stellt sicher, dass lokale Entscheidungen global konsistent bleiben. |
| Language Channel | Kanaele fuer AGT/DE/EN mit klarer Trennung. | Verhindert Sprachmischung und Publikationsdrift. |
| Traceability | Rueckverfolgbarkeit von Entscheidung bis Artefakt. | Entscheidend fuer Incident-Analyse und Compliance-Nachweis. |
Operator-Merksatz fuer den Alltag
- Erst Actor/Role/Skill klaeren, dann ausfuehren.
- Ohne Evidence kein GO.
- Bei Unsicherheit immer fail-closed und HITL aktivieren.
3. Schreibmuster nach Zielgruppe
| Zielgruppe | Empfohlenes Muster | Beispiel |
|---|---|---|
| Management | IT/CS-Begriff + einmaliges Klammermapping | Tenant-Instanz (Node) wird aus einem Referenztemplate (Seed) instanziiert. |
| Fachabteilung | Uebersetzter Stil aus IT/CS-Praezisionsbegriffen | Kundeninstanz wird initialisiert; Details siehe Glossar. |
| Delivery und Ops | IT/CS-Praezisionsstil mit IIO-Mapping bei Bedarf | Zustandswechsel als Transaktion dokumentieren. |
| Architektur und Governance | IT/CS-Sprache als Default, IIO als internes Mapping | Reference Template (Seed) bleibt universell. |
4. Do und Don't
| Do | Don't |
|---|---|
| Tenant-Instanz (Node) einmal definieren und danach konsistent nutzen. | Zwischen Tenant, Node, Client ohne Mapping wechseln. |
| Fachtexte mit Glossar-Hinweis abschliessen. | Nur interne IIO-Kurzformen verwenden. |
| In Schulungen IT/CS-Begriffe zuerst nutzen und teamgerecht uebersetzen. | Abstrakte Begriffe ohne Kontext bringen. |
5. Mini-Template fuer neue Dokumente
| Abschnitt | Pflichtinhalt |
|---|---|
| Begriffsrahmen | 3-6 zentrale Fachbegriffe mit IIO-Mapping |
| Prozessbeschreibung | Fachsprache in Schritten, IIO nur wenn notwendig |
| Verweis | Link auf diese Terminologie-Policy und das Seed-Node-Modell |