IIO Guardrail ArchitekturIIO Guardrail Architecture
Ja, das macht Sinn: Diese Seite erklärt explizit, wie Story, Theme, Sprache und Guardrailing zusammenarbeiten. Ziel ist ein gemeinsames Betriebsverständnis für Menschen und Agenten.
1) Systemlogik in Klartext1) System Logic in Plain Text
IIO ist kein klassisches Feature-Frontend. Es ist ein Governance-first Betriebssystem, in dem Änderungen als kontrollierte Transaktionen laufen: Prämissen prüfen, Gates entscheiden, Evidenz sichern, dann projizieren.
Story-KonzeptStory Concept
- Story ist ein Steuerobjekt, nicht nur Text.
- Jede Änderung braucht Zweck, Kontext, Verantwortung.
- Die Story muss in Artefakten sichtbar werden.
Theme-KonzeptTheme Concept
- Theme wird zentral gesteuert, nicht pro Seite improvisiert.
- Manual-Chrome kommt aus der Shell, nicht aus Einzel-Fixes.
- Visuelle Konsistenz ist ein Guardrail gegen UI-Drift.
Sprach- und StilkonzeptLanguage and Style Concept
- Operator-tauglich: präzise, knapp, handlungsorientiert.
- Nachvollziehbar: Behauptung nur mit Evidenzpfad.
- Publikationskanäle getrennt (AGT/EN/DE), kein Mischformat.
2) Guardrail Stack (von oben nach unten)2) Guardrail Stack (top to bottom)
| EbeneLevel | Zentrale QuelleCentral Source | WirkungEffect | Fail-Closed Signal |
|---|---|---|---|
| Premises Codex | iio/specs/governance/layer-premises-catalog.yaml |
Kanonische Wahrheitsgrundlage | BLOCK bei fehlender Premise-Abbildung |
| Agent Contract | iio/specs/agents/contract.yaml |
Determinismus + hidden-state Verbot | BLOCK bei Kontext- oder Input-Lücken |
| Gate Cascade | iio/specs/layers/LAYER-INTEGRATION.md |
8-Gate Entscheidungskette | BLOCK/ESCALATE je Gate-Fail |
| Skill/Transaction | iio/specs/layers/SKILL-REGISTRY-LAYER.md, iio/specs/layers/TRANSACTION-LAYER.md |
Rollenfit, Evidenzklasse, Auditspur | BLOCK bei fehlender Nachweisbarkeit |
| Operator Surface | iio/manual/*.html |
Steuerung, Diagnose, Ausführung | GO nur mit nachvollziehbarer Evidenz |
| Public Projection | iio/public/ |
Externe Lesbarkeit des Zustands | BLOCK bei Drift zwischen docs/specs/public |
3) Entscheidungsmodell3) Decision Model
Entscheidungslogik ist dreistufig und nicht optional: GO, BLOCK, ESCALATE.
A) Intake + Source Registry
Request Scope
Actor ID
Evidence Check
Canonical Sources
Premise Mapping
B) 8 Gates in Folge
Actor
Story
Role
Composition
Skill→Boundary→Transaction→Audit
C) Output
All pass
GO
Recoverable fail
ESCALATE
Unrecoverable fail = BLOCK
4) Sprachstil und Schreibregeln4) Language Style and Writing Rules
| Dimension | RegelRule | WarumWhy |
|---|---|---|
| Ton | klar, operativ, kein Buzzword-Nebel | Operator muss schnell entscheiden können |
| Aussagen | jede starke Behauptung mit Evidenzpfad | Vertrauen durch Nachprüfbarkeit |
| Entscheidungstext | immer GO/BLOCK/ESCALATE explizit | keine impliziten Grenzfälle |
| Sprachebenen | AGT/EN/DE nicht mischen | saubere Publikationsgrenzen |
| Style Drift | zentral in Shell/Theme lösen, nie pro Seite flicken | Wartbarkeit und konsistente UX |
5) Entwickler-Checkliste für konsistente Änderungen5) Developer Checklist for Consistent Changes
Vor ÄnderungBefore Change
- Premise- und Scope-Mapping klar?
- Actor/Role/Reviewer benannt?
- Betroffene Top-Level-Folder definiert?
Während ÄnderungDuring Change
- Zentrale Quelle statt Seitenflick?
- Gate-Konsequenzen sichtbar gemacht?
- Evidenzklasse dokumentiert?
Nach ÄnderungAfter Change
- Docs/Specs/Public synchron?
- GO/BLOCK/ESCALATE klar gesetzt?
- Nächster Owner + Next Step hinterlegt?