Premises-Katalog

Alle Governance-Premises des IIO-Systems — von P-CORE-001 bis P-OPS-005. Jede Premise ist verbindlich und vererbt sich auf alle Subnodes.

Kategorien (15)

P-CORE — Ontologie (6) P-ARCH — Architektur (3) P-PROJ — Projektion (8) P-SAFE — Sicherheit (3) P-EXEC — Determinismus (3) P-STORY — Story (4) P-ROLE — Rollen (5) P-COMP — Composition (7) P-TXN — Transaction (5) P-BOUND — Boundary (9) P-SKILL — Skills (7) P-DIAG — Diagramme (7) P-ADPT — Adapter (5) P-CAP — Capability (3) P-OPS — Operator (5)

P-CORE — Ontologie-Kern

ID	Premise	Fail-Closed?
P-CORE-001	Alle Wesen und Artefakte im Space sind Actors. Es gibt keine passiven Entities.
P-CORE-002	Jeder Actor besitzt genau einen owned content path — sein kanonisches Zuhause im Space.
P-CORE-003	Entity → Actor Refactoring: Passiv/aktiv ist eine Role, keine ontologische Kategorie.	FC
P-CORE-004	Agent/Human → Intelligent Actor + Communication Mode: Beide haben Perception, Skill, Discovery, Agency. Unterschied = Präsentationsformat.
P-CORE-005	Composition → Composite Actor: Eine Composition mit definierten Roles, Boundary und Shared Plan wird selbst zum Actor.	FC
P-CORE-006	Communication als universeller Mechanismus: Alle Actor-Interaktionen sind Communication Events — intern via TX, extern via Interface.

P-ARCH — Architektur-Schichten

ID	Premise	Fail-Closed?
P-ARCH-001	Schichten-Reihenfolge ist kanonisch und nicht-verhandelbar: Guardrails → Foundation → Core → ... → Interface → Operations.	FC
P-ARCH-002	Vertical Separation: Jede Schicht kommuniziert nur mit adjacent layers. Keine Schicht überspringt eine andere.	FC
P-ARCH-003	Core Stays Dry: Keine geschäftliche oder Node-spezifische Logik in Core-Schichten. Core bleibt universell.

P-PROJ — Projektion / Seed-Node

ID	Premise	Fail-Closed?
P-PROJ-001	Seed Minimal: Seed enthält nur das Nötigste — kein Node-spezifischer Inhalt im Seed.
P-PROJ-002	Node Formula: Node = Seed + local_context + classification_map + configuration.	FC
P-PROJ-003	Object Classification: Jedes Objekt in einem Node ist einem Classification-Typ zugeordnet (own/reference/generated/imported/archive). Unklassifiziert = verboten.	FC
P-PROJ-004	Determinism: Identische Inputs (Seed + local_context + classification_map) produzieren immer identischen Output-Node.	FC
P-PROJ-005	Source-Lane Discovery: Alle Quellen werden vor der Projektion explizit entdeckt und klassifiziert. Keine impliziten Includes.
P-PROJ-006	Explicit Path Authority: Kein Pfad wird ohne explizite selected_paths-Deklaration projiziert.	FC
P-PROJ-007	Manifest Required: Jede Projektion muss ein vollständiges Projection Manifest produzieren (alle 15 Pflichtfelder).	FC
P-PROJ-008	State Hash: SHA-256 Hash über (master_ref + profile + local_context + classification_map + selected_paths) wird im Manifest gespeichert. Abweichung = Manipulation.	FC

P-SAFE — Sicherheit & Review

ID	Premise	Fail-Closed?
P-SAFE-001	Protected Domains: Security, Legal und Finance sind Hochrisiko-Domains. Alle Änderungen erfordern explizite Review Gate.	FC
P-SAFE-002	Gated Domains: Jede Interaktion mit Security/Legal/Finance-Domain ohne Gate-Freigabe = automatischer Block.	FC
P-SAFE-003	Fail-Closed Default: Bei unbekanntem Zustand, fehlenden Artefakten oder mehrdeutigem Kontext: System stoppt, nicht fortfährt.	FC

P-EXEC — Determinismus & Ausführung

ID	Premise	Fail-Closed?
P-EXEC-001	Deterministic Execution: Scripts und Prozesse liefern bei gleichen Inputs gleiche Outputs. Kein zufälliges Verhalten ohne explizite Dokumentation.	FC
P-EXEC-002	No Hidden State: Kein Prozess darf auf undeklariertem Zustand basieren. Jeder Zustand muss im TX-Log oder State-File sichtbar sein.	FC
P-EXEC-003	Dry-Run Before Real Run: Alle destruktiven oder irreversiblen Operationen erfordern ein Dry-Run-Protokoll vor der tatsächlichen Ausführung.

P-STORY — Story-Schicht

ID	Premise	Fail-Closed?
P-STORY-001	Jede Story enthält die kanonischen Elemente: Actor, Plan, Work, Interface, State, Role, Boundary. Fehlende Pflicht-Elemente = invalid Story.	FC
P-STORY-002	Layer Consistency: Story-Elemente müssen mit der Layer-Architektur konsistent sein. Story kann keine Layer-Regeln überschreiben.
P-STORY-003	Member Compatibility: Alle Actors in einer Composition müssen kompatible Stories haben (keine widersprüchlichen Constraints werden zusammengefügt).	FC
P-STORY-004	Deterministic Transformation: Story-zu-Node Transformation ist deterministisch und versioniert. Gleicher Story Input = gleicher Node Output.	FC

P-ROLE — Rollen

ID	Premise	Fail-Closed?
P-ROLE-001	Jeder Actor im Space hat mindestens eine aktive Role. Kein Actor ist rolle-los.	FC
P-ROLE-002	Role-Agnostic Core: Core-Schichten sind universell und rollen-unabhängig. Role-spezifische Logik gehört nicht in Core.
P-ROLE-003	Multi-Homing: Ein Actor kann gleichzeitig mehrere Roles in verschiedenen Compositions haben. Kein Widerspruch per se.
P-ROLE-004	Conflict Resolution: Bei Role-Konflikten (z.B. reviewer + author im gleichen Gate) entscheidet der Conflict-Check. Automatische Eskalation bei Unauflösbarkeit.	FC
P-ROLE-005	Skill Requirements: Roles haben deklarierte Skill-Anforderungen. Kein Actor kann eine Role dauerhaft übernehmen, ohne die Mindest-Skills zu erfüllen.

P-COMP — Composition & Composite Actor

ID	Premise	Fail-Closed?
P-COMP-001	Composition Preconditions: Alle 6 Felder (actors, shared_plan, shared_work, shared_artifacts, shared_state, boundary) müssen definiert sein, bevor Composite Actor Status erlangt wird.	FC
P-COMP-002	Member Requirements: Alle Members einer Composition müssen die für ihre Role nötigen Skills besitzen.
P-COMP-003	Story Consistency: Member-Stories müssen kompatibel sein. Widersprüchliche Constraints = Composition ungültig bis aufgelöst.	FC
P-COMP-004	TX Attribution: Transactions werden dem Composite Actor zugerechnet. Member-Detail ist sekundäres Log-Datum.
P-COMP-005	Boundary Enforcement: Alle Composite-Actor-Interactions laufen durch die Composition-Boundary. Kein Member-Direktzugriff außerhalb der Boundary.	FC
P-COMP-006	Member Change: Members können hinzukefügt oder entfernt werden. Jede Änderung erfordert Aktualisierung aller betroffenen Felder und TX-Record.
P-COMP-007	Fractal Nesting: Composite Actors können Members anderer Composite Actors sein. Keine Tiefenbegrenzung, aber Boundary immer explizit.

P-TXN — Transactions

ID	Premise	Fail-Closed?
P-TXN-003	Uniform Format: Alle Transactions folgen demselben kanonischen Format (10 Pflichtfelder). Kein TX ohne operation, actor, timestamp, state_before, state_after.	FC
P-TXN-004	Composite Attribution: In Composite Actors wird die Composition als primärer Actor gelistet. Member als sekundäre Attribution.
P-TXN-005	All Gates TX'd: Jede Gate-Entscheidung (GO, NO-GO, OVERRIDE) wird als TX geloggt.	FC
P-TXN-006	Append-Only: TX-Logs sind append-only. Keine Löschung, keine Modifikation. Korrektur = neues TX mit Verweis auf korrigiertes TX.	FC
P-TXN-007	Determinism Flag: Non-deterministische Operationen werden explizit als `determinism: false` geloggt.

P-BOUND — Boundaries & Federation

ID	Premise	Fail-Closed?
P-BOUND-001	4 Boundary-Typen: `personal`, `workspace`, `composition`, `federation`. Jede Boundary hat explizite allow/deny-Regeln.	FC
P-BOUND-002	Role-Based Access: Boundary-Crossing nur für Actors mit explizit gewährter Role. Default = deny.	FC
P-BOUND-003	Audit Denied Attempts: Alle abgelehnten Boundary-Crossing-Versuche werden geloggt.	FC
P-BOUND-004	Explicit Grants: Boundary-Grants werden explizit ausgestellt (kein implicit inheritance). Grant = TX.	FC
P-BOUND-005	Boundary Transitions: Wechsel des Boundary-Typs (z.B. workspace → composition) erfordert expliziten Transition-TX.
P-BOUND-006	Dissolution: Boundary-Auflösung erfordert TX + alle Members müssen benachrichtigt werden.
P-BOUND-007	Federated Autonomy: Federation-Boundaries bewahren Autonomie beider Seiten. Keine Seite kann die andere über die Federation hinaus kontrollieren.
P-FED-001	Mutual Consent TX: Jede Federation-Öffnung erfordert TX beider Seiten (mutual consent). Einseitige Öffnung = invalid.	FC
P-FED-002	Federation Review Gate: Cross-Org Federation benötigt immer RG-003. Keine Ausnahmen.	FC

P-SKILL — Skills

ID	Premise	Fail-Closed?
P-SKILL-001	Universal Skills: Skills gelten für alle Actor-Typen gleichermaßen (Human + Agent). Kein skill-Set exklusiv für einen Typ.
P-SKILL-002	Evidence Required: Jede Skill-Zuweisung erfordert ein Evidence-Artefakt (Minimum: workspace-verified).	FC
P-SKILL-003	Model-Only Needs Review: Skills mit Evidenz-Klasse `model-only` erfordern explizite menschliche Review-Freigabe.	FC
P-SKILL-004	Proficiency Levels: 3 Stufen: `foundation`, `practitioner`, `expert`. Role-Anforderungen referenzieren immer eine minimale Stufe.
P-SKILL-005	Prerequisites: Skills können Voraussetzungen haben. Ohne erfüllte Prerequisites ist der Skill nicht aktivierbar.	FC
P-SKILL-006	Conflict Manual Review: Widersprüchliche Skill-Zuweisungen (z.B. inkonsistente Evidence) → manuelles Review, kein Autofix.
P-SKILL-007	TX Logging: Alle Skill-Zuweisung, -änderungen und -entfernungen werden als TX geloggt.

P-DIAG — Diagramme & Visualisierungen

ID	Premise	Fail-Closed?
P-DIAG-001	Uniform Notation: Alle Diagramme verwenden die kanonische IIO-Notation. Keine eigene Symbolik ohne Legende.
P-DIAG-002	Legend Required: Jedes Diagramm enthält eine Legende. Kein Diagramm ohne Erl. der verwendeten Symbole.
P-DIAG-003	Role-Dispatch Diagram: Jede Composition hat ein Role-Dispatch-Diagramm, das zeigt, wer was entscheidet.
P-DIAG-004	Audit Trail Sequence: Kritische Prozesse haben ein Audit-Trail-Sequenzdiagramm.
P-DIAG-005	Story Diagram: Jede komplexe Story hat ein zugehöriges Diagramm.
P-DIAG-006	Mermaid: Standard-Diagramm-Format ist Mermaid. Andere Formate erfordern Begründung.
P-DIAG-007	Boundary Rendering Types: Boundaries werden mit spezifischen Rendering-Typen dargestellt (dashed = temporary, solid = permanent, etc.).

P-ADPT — Adapter & Integration

ID	Premise	Fail-Closed?
P-ADPT-001	Registry Required: Alle Integrationen müssen in der Adapter Registry gelistet sein. Unregistrierte = verboten.	FC
P-ADPT-002	Human Approval: Neue Adapters und Endpoint-Änderungen erfordern Review Gate + TX.	FC
P-ADPT-003	Role-Constrained Capability: Adapter können nur Role-erlaubte Capabilities aufrufen. Adapter ≠ Privilege Escalation.	FC
P-ADPT-004	No Secrets in Contract: Kein Secret-Material in Adapter-Contract-Dateien.	FC
P-ADPT-005	Prompt Injection Guard: Alle Adapter mit externen Payloads müssen Prompt-Injection-Guard haben.	FC

P-CAP — Capability Profiles

ID	Premise	Fail-Closed?
P-CAP-001	One Profile Per Node: Jeder Node hat genau ein aktives Capability Profile. Kein Mischbetrieb.	FC
P-CAP-002	Upgrade Requires Signoff: Jedes Profile-Upgrade (auch Research→Base) erfordert menschlichen Signoff (RG-001).	FC
P-CAP-003	Cosmic Features Require Gate + Signoff: Cosmic-Tier-Features erfordern zusätzlich zum Signoff auch das Review Gate RG-002.	FC

P-OPS — Operator Governance

ID	Premise	Fail-Closed?
P-OPS-001	Operator Scope: HITL Operator hat PRIMARY-Scope über guardrails, runtime, operations, transaction, integration. Read-Only für architecture, projection, learning, publishing, migration.	FC
P-OPS-002	Escalation Chain: 3-Level Eskalationskette: Responsible Owner (same day) → Space Lead (next day + escalation TX) → Emergency Freeze (immediate).	FC
P-OPS-003	Emergency Freeze: Jeder aktive HITL Operator kann einfrieren. Aufhebung nur durch human_owner oder space_lead.	FC
P-OPS-004	Manual Gate Override: Letztes Mittel — nur wenn: (1) auto-Gate fehlgeschlagen im No-AI-Mode + (2) vollständige Eskalation dokumentiert + (3) zeitkritisch. Keine silent overrides.	FC
P-OPS-005	No-AI Vollständigkeit: Alle Operator-Prozesse sind ohne LLM ausführbar. Kein kritischer Prozess ist von AI-Verfügbarkeit abhängig.	FC

Vererbungs-Contract & Quality Gates

Inheritance Contract

Alle Subnodes und abgeleitete Systeme erben automatisch alle Premises dieser Katalog-Seite. Premises können eingeschränkt (nicht ausgeweitet) werden, aber nie durch Node-lokale Specs überschrieben werden. Widerspruch zwischen Node-Spec und dieser Seite = Fail-Closed: die strengere Regel gilt.

Die 4 Quality Gates

Layer Consistency

Alle Artefakte referenzieren Schichten korrekt (P-ARCH-001/P-ARCH-002). Quer-Schicht-Verletzungen = Fail.

Source Traceability

Jedes Objekt hat eine nachvollziehbare, klassifizierte Quelle (P-PROJ-003/P-PROJ-005). Unklassifiziert = Fail.

Non-Drift

Alle Drift-Reports sind resolved oder monitoring. Unresolved Drift mit Deadline → Review Gate automatisch (P-EXEC-001).

Fail-Closed

System stoppt bei Ambiguität, fehlenden Artefakten oder unerfüllten Preconditions (P-SAFE-003). Kein Fallback ohne explizite Freigabe.