Self-Shaping MiniApps + A2UI

Eine auditierbare Pipeline von Intent zu Interaktion

Kontext

In klassischen Verwaltungs- und Enterprise-Architekturen ist Bedeutung über viele Modelle, APIs und UI-Sichten verteilt; Beziehungen sind oft implizit, Regeln stecken im Code, und jede Oberfläche braucht ihr eigenes Modell. Der Concept Graph verschiebt das auf eine gemeinsame semantische Ebene (Konzepte, Beziehungen, Regeln/Constraints) – dadurch wird Self-Shaping UI möglich: Oberflächen entstehen dynamisch aus Intent und Kontext, nicht aus festen Screens. 

A2UI ergänzt genau an der Stelle, an der Self-Shaping UI sonst „beliebig“ wird: als standardisierter, sicherer UI-Ausgabevertrag zwischen Agent/Orchestrierung und Client. A2UI ist deklarativ (Daten, kein ausführbarer Code) und basiert auf einem trusted component catalog im Client: Der Agent kann nur anfordern, was der Client freigibt. 

Für den Public Sector ist das besonders attraktiv, weil es eine digital-souveräne, kontrollierbare UI-Generierung ermöglicht – passend zu „digitale Souveränität“ und „KI-gestützte Mini-Behörden-Apps“. 

 

1) Die Idee

Von „Screens“ zu „Antwortflächen“

Self-Shaping UI bedeutet: Die Oberfläche ist nicht das Primärartefakt. Primär sind Intent, Kontext und Semantik. Der Nutzer formuliert ein Anliegen („Zeig mir alle Anträge mit Risiko > X“, „Vergleiche Fall A und B“). Das System interpretiert Intent und Kontext, traversiert den Concept Graph (Konzepte, Beziehungen, Regeln/Constraints) und erzeugt daraus die passende Sicht (Liste, Akte, Vergleich, Dashboard, …). 

 

Wo A2UI hinzukommt: „UI als auditierbarer Vertrag“

Ohne A2UI landen viele Self-Shaping-Ansätze am Ende bei „LLM generiert HTML/JS“ oder bei schwer prüfbaren, ad-hoc gerenderten UI-Strukturen. A2UI zieht hier eine klare Grenze:

  • Der Agent/Orchestrator beschreibt UI nur deklarativ als strukturierte Nachrichten (JSONL-Stream) – keine Templates, kein fremder Code. 
  • Der Client rendert ausschließlich aus einem freigegebenen Komponenten-Katalog („catalog“) und mappt abstrakte Komponenten auf native Widgets. Damit ist UI-Output „safe like data“. 
  • UI wird in Surfaces organisiert (mehrere unabhängige UI-Regionen, jeweils mit eigenem Data Model, um Key-Kollisionen zu vermeiden). 

 

„Nicht beliebig“ heißt: doppelte Governance

Damit der Ansatz wirklich kontrolliert und wiederholbar bleibt, wird die dynamische UI auf zwei Ebenen begrenzt:

  • Fachliche Pattern-Bibliothek (Self-Shaping-Ebene): Endliche Menge an erlaubten View-Patterns (z. B. CaseList, CaseFile, EligibilityCheck, DocumentExtractReview, Compare, RiskOverview).
  • Technischer A2UI-Katalog (Rendering-Ebene): Endliche Menge an freigegebenen UI-Bausteinen im Client (inkl. optionaler Custom Components, aber nur per Registry unter unserer Kontrolle). 

So „erfindet“ die KI nicht beliebig UI – sie wählt innerhalb von genehmigten Patterns und Bausteinen.

 

 

2) Die Pipeline (auditierbar, end-to-end)

Die 8 Schritte als verbindlicher Ablauf

1. Intent Envelope erstellen
Eingabe + Kontext (Rolle, Akten-/Vorgangs-ID, Mandant, Gerät/Surface-Ziel, Sitzung).
Audit-Artefakt: IntentEnvelope (correlationId, timestamp, principal, contextRefs).

2. Semantik ziehen (Concept Graph)
Concept-Graph-Traversal/Queries inkl. Regeln/Constraints (z. B. Datenminimierung, erlaubte Attribute, Aggregationspflicht, Schwärzungsregeln). 
Audit-Artefakt: SemanticSnapshotRef (graphVersion, query, resultHash, policyContext).

3. View Plan (Pattern-Ebene) erzeugen
Aus Intent+Semantik entsteht ein ViewPlan: gewähltes Pattern, benötigte Datenfelder, Aggregationen, erlaubte Interaktionen (Actions).
Audit-Artefakt: ViewPlan.json (versioniert, deterministisch prüfbar).

4. Policy Gate (harter Kontrollpunkt)
Validierung: Pattern erlaubt? Actions erlaubt? Daten minimiert? Barrierefrei-Pflichten erfüllbar?
Audit-Artefakt: PolicyDecision (allow/deny, ruleIds, Begründung).

5. A2UI Compile (ViewPlan → A2UI Stream)
Der ViewPlan wird in A2UI-Nachrichten übersetzt:

  • surfaceUpdate (Komponentenstruktur)
  • dataModelUpdate (Zustand/Datenmodell)
  • beginRendering (Render-Signal inkl. root)
  • optional deleteSurface (Lifecycle) 
    Audit-Artefakt: A2UIStream.jsonl + catalogId + surfaceId(s).

6. Streaming an den Client
A2UI ist JSONL (line-based), typischerweise über SSE beschrieben; transportneutral möglich. Die Spezifikation beschreibt Client-Buffering und Render-Start erst nach beginRendering, um „flash of incomplete content“ zu vermeiden. 
Audit-Artefakt: Transport-Log (messageHash pro Zeile, timestamps).

7. User Actions zurück (Event-Pfad)
Interaktionen (z. B. Button, Drilldown) führen zu userAction-Events, die laut Spec via A2A-Message an den Server gehen. 
Audit-Artefakt: UserActionLog (surfaceId, componentId, actionName, context, timestamp).

8. Delta-Updates / Surface-Lifecycle
Antworten auf Aktionen kommen als weitere surfaceUpdate/dataModelUpdate-Deltas; ggf. deleteSurface. 

 

3) Für IT-Architekten: Architektur, Verträge, Datenflüsse

3.1 Scope und Leitplanken (Public Sector)

Scope: Intent-getriebene, dynamische Oberflächen für Verwaltungsprozesse (Fallbearbeitung, Antragsprüfung, Dokumenten-Extraktion, Status/Fristen, Bescheidentwurf-Review).
Leitplanken: Nachvollziehbarkeit, Berechtigungen, Datenminimierung, Logging/Revision, kontrollierbare UI-Bausteine, Plattform-Portabilität.

Nicht-Ziel: „LLM generiert frei UI-Code“. A2UI ist ausdrücklich deklarativ und arbeitet über vorab genehmigte Komponenten. 

Reifegrad-Hinweis: A2UI ist v0.8 „stable initial public release“, zugleich „early stage public preview“ – Spezifikation/Implementierungen sind funktional, aber in Bewegung. 

 

3.2 Bausteine (Responsibilities)

(A) Fachanwendungs-Shell / Portal

  • AuthN/AuthZ, Session, Routing, Shell-Layout
  • Hostet A2UI-Renderer als integrierte UI-Region(en) („Surfaces“)

(B) A2UI Renderer (Client) + WidgetRegistry + Catalog

  • JSONL-Parser, Message-Dispatcher, Surface-State, Component-Buffer (Adjacency-List)
  • Rendert ausschließlich Komponenten aus dem Catalog (whitelist); optional Custom Components via Registry. 

(C) Self-Shaping Runtime / UI-Orchestrator (Server)

  • IntentEnvelope → Semantikzugriff → ViewPlan → Policy Gate → A2UI Compile
  • Orchestriert Deltas bei Folgefragen/Actions

(D) Concept Graph Service

  • Semantik/Beziehungen/Regeln/Constraints als „lebende Wahrheit“ der Domäne. 

(E) Policy Engine (ABAC/RBAC + Datenpolitik)

  • Entscheidet über erlaubte Patterns, Actions, Felder, Aggregationen, Redaction
  • Erzwingt „nicht beliebig“ durch harte Verträge (Pattern-Allowlist, Catalog-Allowlist)

(F) Audit/Observability Layer

  • Persistiert ViewPlan, PolicyDecision, A2UI-Hashes, DataSnapshot-Refs, UserActions
  • Ermöglicht Replay, Untersuchung, Revision

 

3.3 Schnittstellen & Protokolle (präzise)

Server → Client (UI-Stream)

  • A2UI Messages als JSON Lines (JSONL): pro Zeile exakt eine Message, und jede Message enthält exakt einender vier Top-Level-Keys: beginRendering | surfaceUpdate | dataModelUpdate | deleteSurface. 
  • Spezifikation beschreibt JSONL-Stream, typischerweise über SSE; Client puffert Updates und rendert erst nach beginRendering. 

Client → Server (Events)

  • Nutzerinteraktionen werden als userAction Payload gebaut (inkl. gebundener Kontextdaten) und via A2A-Message an den Server gesendet (laut Spec-Data-Flow). 

Multi-Surface

  • surfaceId adressiert UI-Regionen; jede Surface hat separates Root und separates Data Model (Key-Isolation). 

 

 

 

3.4 Architekturbild (Textdiagramm)

Die A2UI-Konzepte „Surfaces“, JSONL-Message-Set und Client-Buffer/Render-Start nach beginRendering sind so in Spec/Reference/Renderer-Guide beschrieben.

 

 

3.5 Datenflussdiagramm (Sequenz, auditierbar)

Message-Set, JSONL-Format und der Data-Flow „Stream + events back via userAction“ sind in den offiziellen A2UI-Docs/Spezifikation beschrieben.

 

 

4) Praktische Governance: Wie „nicht beliebig“ technisch garantiert wird

4.1 Pattern-Contract (fachlich)

Allowlist: z. B. 25–40 Patterns mit klaren Eingabeschemata und Ziel-Sichten

Pro Pattern definiert: 

  • benötigte Daten (Feldgruppen), zulässige Aggregationen
  • erlaubte Actions (Drilldown, Compare, Export=nein, …)
  • Barrierefrei-Anforderungen (z. B. tabellarische Alternative zu Charts)

 

4.2 Catalog-Control (A2UI-Ebene)

  • Der Client hält den Catalog (Trusted Components). catalogId kann explizit gesetzt werden; ohne Angabe gilt Standardkatalog. 
  • Renderer-Guide fordert explizit: Message-Dispatcher, Surface-Management, Component-Buffer (Map by id), deleteSurface-Handling. 
  • Custom Components nur über Registry/Smart Wrapper unter eurer Kontrolle (keine „LLM erfindet Widgets“-Dynamik). 

 

4.3 Policy Gate (harter Stop)

Vor dem A2UI-Compile: ViewPlan + Datenzugriff + Rolle + Redaction-Rules

Ergebnis wird als PolicyDecision gespeichert (auditfähig) und bestimmt:

  • ob UI überhaupt gerendert wird
  • welche Daten im Data Model erscheinen dürfen
  • welche Actions zulässig sind

 

4.4 Replay-Fähigkeit (Revision)

  • Persistiere: IntentEnvelope, SemanticSnapshotRef, ViewPlan, PolicyDecision, Hashes des JSONL-Streams, userAction-Events
  • Ergebnis: Jede UI-Antwort ist rekonstruierbar („Warum wurde genau diese Sicht erzeugt?“).

 

5) Einordnung in den Public-Sector-Kontext

Das nogor-eGovernment-Lab zeigt ein Spektrum moderner Verwaltungsarchitektur-Demos inkl. „KI-gestützten Mini-Behörden-Apps“. 


Die Kombination Concept Graph + Self-Shaping UI liefert die semantische Grundlage und die Interaktionslogik („UI entsteht aus Intent+Kontext“). 


A2UI macht daraus eine standardisierte, kontrollierte und client-seitig whitelistbare UI-Ausgabe, die sich besonders gut für Umgebungen eignet, in denen Nachvollziehbarkeit und Sicherheitsgrenzen wichtiger sind als maximale Freiheit im UI-Code.

 

Anhang 1) Minimaler Pattern-Katalog für Behörden

Ziel: ein endlicher, wiederholbarer Satz an „Antwortflächen“, die der Agent auswählen darf. Jedes Pattern ist ein fachlicher Vertrag: Zweck → benötigte Daten → erlaubte Interaktionen → Darstellungsgrenzen.
A2UI ist danach nur noch Transport & Rendering (Komponenten aus freigegebenem Katalog).

 

Datenklassen (einfaches, praxistaugliches Raster)

Damit Patterns und Policies sauber bleiben, hilft ein kleines Klassifizierungsraster (Beispiel, anpassbar):

  • DK0 Öffentlich: keine Schutzbedürftigkeit.
  • DK1 Intern: organisatorisch intern, nicht personenbezogen.
  • DK2 Personenbezogen (Standard): Name, Adresse, Aktenzeichen mit Personenbezug, Kontaktdaten.
  • DK3 Sensibel: Sozial-/Gesundheits-/Steuer-/Sanktions-/Strafverfolgungsbezug, besondere Schutzbedürftigkeit.
  • DK4 Geheim/VS: besondere Amts-/Sicherheitsinteressen (falls zutreffend).

Regel: Patterns definieren, welche Datenklassen maximal zulässig sind und ob nur aggregiert (z. B. DK2 als „Counts“) gerendert werden darf.

 

Pattern 1: Inbox / Aufgabenliste (Task Inbox)

Zweck: Einstieg, Arbeitsvorrat, Priorisierung.
Daten: Vorgänge/Fälle (Metadaten), Status, Fristen, Verantwortlichkeit (typisch DK1–DK2).
Erlaubte Actions: filter/sort, öffnen, übernehmen/zuweisen, „merken“/flaggen.
Darstellung: Liste + Facettenfilter + Fristenindikator.

 

Pattern 2: Fallliste / Ergebnisliste (Case List)

Zweck: Suchergebnisse („zeige alle …“), Triagierung.
Daten: reduzierte Fall-Header (ID, Status, Datum, Kategorie), ggf. Risiko-/Prioritätswert (DK1–DK2; DK3 nur aggregiert oder mit Redaction).
Actions: filter/sort, drilldown in Fallakte, compare (max 2–3 Elemente).
Darstellung: Tabelle/Liste + Spaltensteuerung (aber vordefiniert).

 

Pattern 3: Fallakte (Case File)

Zweck: konsolidierte Sicht auf einen Vorgang/Fall.
Daten: Entitäten/Beziehungen aus Concept Graph (Antrag, Person/Org, Dokumente, Entscheidungen, Zahlungen). DK2–DK3 je nach Domäne, mit strikter Redaction.
Actions: Tabs/Sections, „Details öffnen“, „Notiz hinzufügen“, „Nächster Schritt“ (Workflow), „Anforderung erzeugen“.
Darstellung: Sections + Timeline + Dokumentliste.

 

Pattern 4: Entitätsakte Person (Person Record)

Zweck: Person als Knoten (Bürgerkonto/Adressstamm, Beteiligte).
Daten: Stammdaten, Identifikatoren, Beziehungen zu Fällen/Leistungen (DK2–DK3).
Actions: „Beziehungen anzeigen“, „zu Fall springen“, „Datenqualität melden“.
Darstellung: Card/Sections + Relationship-List.

 

Pattern 5: Entitätsakte Organisation (Organization Record)

Zweck: Unternehmen/Verein/Behörde, Beteiligte, Rollen.
Daten: Registerdaten, Zuständigkeiten, Beziehungen zu Fällen (DK1–DK2).
Actions: drilldown, „Beteiligte anzeigen“, „Historie anzeigen“.
Darstellung: Sections + Relationship-List.

 

Pattern 6: Eligibility/Anspruchsprüfung (Eligibility Check)

Zweck: „Erfüllt Kriterium X?“ – nachvollziehbar, regelbasiert.
Daten: Kriterien, Nachweise, Regelreferenzen (DK1–DK3, aber Ausgabe stark begrenzt).
Actions: „fehlende Nachweise anfordern“, „Regel anzeigen“, „Was-wäre-wenn“ (nur mit erlaubten Parametern).
Darstellung: Checkliste + Begründungs-Panel (keine freien Texte ohne Quellenhinweis).

 

Pattern 7: Dokumentenreview / Extraktionsprüfung (Document Review)

Zweck: KI-Extraktion aus Dokumenten prüfen, nicht blind übernehmen.
Daten: Dokument-Metadaten + extrahierte Felder + Confidence + Fundstelle (DK2–DK3).
Actions: akzeptieren/korrigieren, Feld als „unklar“ markieren, Rückfrage erzeugen.
Darstellung: „Field-Table“ + „Evidence Snippets“ (max. Längen, redacted).

 

Pattern 8: Entscheidungsvorlage (Decision Draft)

Zweck: Entscheidung als Vorschlag mit Begründung/Quellen.
Daten: Ergebnis, Begründung, Regel-/Paragraphen-Refs, verwendete Datenpunkte (DK1–DK3).
Actions: „als Entwurf speichern“, „Begründung prüfen“, „Abweichung dokumentieren“, „zur Freigabe“.
Darstellung: Structured sections („Ergebnis“, „Begründung“, „Grundlagen“, „Offene Punkte“).

 

Pattern 9: Vergleich (Compare 2–3)

Zweck: Vergleich von Fällen/Personen/Anträgen (z. B. „A vs B“).
Daten: definierte Vergleichsattribute (DK1–DK2; DK3 nur wenn Policy erlaubt).
Actions: Attribute ein/aus (vordefinierte Sets), „Differenzen hervorheben“.
Darstellung: Side-by-side Tabelle.

 

Pattern 10: Timeline / Verlauf (Audit Timeline)

Zweck: Ereignisse/Schritte/Kommunikation im Zeitverlauf.
Daten: Event-Metadaten, Statuswechsel, Bescheide, Fristen (DK1–DK2).
Actions: „Event öffnen“, „Zeitraum filtern“, „zu Dokument springen“.
Darstellung: Timeline + Detailpanel.

Pattern 11: Risiko-/Plausibilitäts-Übersicht (Risk / Plausibility Overview)

Zweck: Flagging, Plausibilitätschecks, Anomalien (z. B. Missbrauchsprävention).
Daten: Scores, Gründe (Feature-Refs), Schwellenwerte, keine unnötigen Rohdaten (DK1–DK3).
Actions: Drilldown in Begründung, „Fall markieren“, „Zweitprüfung anstoßen“.
Darstellung: Cards + Begründungsdetails.

 

Pattern 12: Aggregationsdashboard (Portfolio Dashboard – nur aggregiert)

Zweck: Lagebild (Durchlaufzeiten, Backlog, Quote, SLA), ohne Personenbezug.
Daten: Aggregationen (Counts, Mediane, Trends) → ideal DK0–DK1.
Actions: Zeitraum/Organisationseinheit filtern, Drilldown in Case List (mit Policy Gate).
Darstellung: KPI Cards + einfache Charts (nur wenn im Katalog freigegeben).

Optional (wenn benötigt, aber bewusst „nicht default“)

  • Relationship Graph / Constellation View (Netzwerk/Graph): nur als Custom Component im A2UI-Catalog, streng geprüft (Performance, A11y, Datenschutz).
  • Geo/Map View: ebenfalls Custom Component; im Public Sector oft sensibel.

 

 

Zuordnung: Pattern → A2UI-Komponenten (Prinzip)

Wichtig ist der Governance-Satz:

"Patterns bestimmen die fachliche Form (Liste, Akte, Vergleich, Review). A2UI kompiliert Patterns in einen freigegebenen Komponentenbaum (Catalog/Registry im Client). Der Agent darf nur (a) erlaubte Patterns wählen und (b) erlaubte Komponenten nutzen."

 

 

Anhang 1)  Audit-Schema (Minimalanforderungen, „prüfersicher“)

Ziel: Jede generierte Oberfläche ist rekonstruierbar und begründbar:

  • Wer hat was gefragt? (Intent + Kontext)
  • Auf welcher Datenbasis? (Snapshot/Refs)
  • Welche Regeln/Policies haben erlaubt/abgelehnt?
  • Welche View (Pattern) wurde gewählt?
  • Welche UI (A2UI Stream) wurde ausgeliefert?
  • Welche Interaktionen (userAction) folgten?

 

2.1 Core-Prinzipien (Public Sector)

Append-only Audit Log (WORM/immutable storage), signiert.

  1. Korrelation über IDs (end-to-end trace).
  2. Datenminimierung auch im Audit: keine unnötigen PII im Log; stattdessen Hashes/Refs.
  3. Versionierung: Graph-Version, Policy-Bundle-Version, Catalog-Version, Prompt/Template-Version, Runtime-Build.
  4. Replay-Fähigkeit: mindestens ViewPlan + A2UIStream müssen als Beweis gespeichert werden, weil LLM-Ausgaben nicht deterministisch sind.

 

2.2 Minimalfelder je Artefakt

A) IntentEnvelope (Eingang)

Wichtig: Inhalt kann redacted gespeichert werden (oder gar nicht), aber Hash sollte existieren.

 

 

B) SemanticSnapshotRef (Datenbasis + Semantik)

ResultRef zeigt auf einen Snapshot (z. B. in einem Data Vault oder revisionssicheren Store).

 

 

 

C) ViewPlan (Pattern-Entscheidung, fachlicher Vertrag)

 

 

D) PolicyDecision (Gatekeeper-Entscheid)

 

 

E) A2UI Delivery Record (Beweis der ausgelieferten Oberfläche)

Speichere nicht nur „es wurde gerendert“, sondern die ausgelieferte Struktur auditierbar:

Warum lineHashes/MerkleRoot?
Damit du beweisen kannst, dass der Stream später nicht verändert wurde, ohne ihn komplett in jedem Report auszudrucken.

 

 

F) UserActionLog (Interaktionen, revisionsfähig)

 

 

2.3 Minimaler „Audit Trace“ als Kette

Im Betrieb willst du genau diese Trace-Kette zuverlässig erzeugen:

2.4 Empfohlene technische Kontrollen 

  • Immutable/WORM Storage für Audit (mit Signatur/Key-Management).
  • Trennung von Nutzdaten und Audit: Audit speichert vorzugsweise Hash/Refs, nicht PII.
  • Catalog/Pattern Version Lock: jede UI ist an patternVersion + catalogId gebunden.
  • Policy-as-Code: PolicyDecision muss Rule-IDs und Bundle-Version tragen (prüfbar).
  • Rate/Size Limits: Schutz gegen „UI-Spam“ (max components, max depth, max rows).

 

2.5 Startpunkt: Minimal, aber belastbar

  • ViewPlan speichern (Pattern + Transformations + allowedActions)
  • PolicyDecision speichern (Rule-IDs + redactionSpec + catalogIdAllowed)
  • A2UI-Stream beweissicher speichern (jsonl ref + hashes)

 

Wir benötigen Ihre Zustimmung zum Laden der Übersetzungen

Wir nutzen einen Drittanbieter-Service, um den Inhalt der Website zu übersetzen, der möglicherweise Daten über Ihre Aktivitäten sammelt. Bitte überprüfen Sie die Details in der Datenschutzerklärung und akzeptieren Sie den Dienst, um die Übersetzungen zu sehen.