UIAP Conformance Suite

UIAP Conformance Suite v0.1

Feld	Wert
Status	Draft
Version	0.1
Datum	2026-03-27
Abhängigkeiten	Alle UIAP-Spezifikationen
Editoren	Patrick

1. Zweck und Geltungsbereich

UIAP Conformance Suite v0.1 definiert, wie Implementierungen von UIAP-Spezifikationen standardisiert geprüft, bewertet und als konform oder nicht konform eingestuft werden.

Die Conformance Suite deckt diese Spezifikationsbereiche ab:

UIAP Core v0.1
UIAP Capability Model v0.1
UIAP Web Profile v0.1
UIAP Action Runtime Spec v0.1
UIAP Policy Extension v0.1
UIAP SDK API v0.1
UIAP Workflow Extension v0.1
UIAP Discovery Mapper Spec v0.1
UIAP Authoring/Manifest Spec v0.1

Die Suite definiert:

Konformitätsklassen und Claims
Testmodule und Testfälle
Harness- und Fixture-Modell
Ausführungs- und Bewertungsregeln
Ergebnis- und Report-Format
Komposit-Profile für reale Produktclaims

Die Suite definiert nicht:

Produktzertifizierungen durch eine bestimmte Organisation
kommerzielle Label oder Markenrechte
Benchmarking von Modellqualität
LLM-Intelligenztests im Sinne von „wirkt der Agent cool genug“

2. Grundprinzipien

Conformance ist claims-basiert. Getestet wird nur, was eine Implementierung tatsächlich beansprucht.
Pflichttests sind verbindlich. Ein bestandener Claim setzt das Bestehen aller zugehörigen Pflichtfälle voraus.
Komposit-Profile bauen auf Basisprofilen auf.
Negative Tests sind gleichwertig zu Positivtests.
Determinismus schlägt Romantik. Wiederholbare Eingaben müssen reproduzierbare Ergebnisse liefern, soweit die Spezifikation das verlangt.
Conformance misst Spezifikationstreue, nicht Produktgüte.
Selbstbehauptete Kompatibilität ohne Suite-Ergebnis ist kein Konformitätsnachweis.

3. Normative Begriffe

Die Schlüsselwörter MUSS, DARF NICHT, SOLLTE, KANN in diesem Dokument sind normativ gemäss RFC 2119 und BCP 14 zu interpretieren, wenn und nur wenn sie in GROSSBUCHSTABEN erscheinen.

4. Rollen des zu prüfenden Systems

Eine Implementierung KANN eine oder mehrere dieser Rollen beanspruchen:

type ConformanceRole =
  | "CoreEndpoint"
  | "CapabilityProvider"
  | "WebPublisher"
  | "WebConsumer"
  | "RuntimeExecutor"
  | "RuntimeController"
  | "PolicyEvaluator"
  | "WebSDK"
  | "WorkflowEngine"
  | "DiscoveryMapper"
  | "AuthoringCompiler";

Rollensemantik

CoreEndpoint: spricht UIAP Core korrekt
CapabilityProvider: liefert Capability-Dokumente
WebPublisher: publiziert PageGraph, Deltas und Web-Signale
WebConsumer: konsumiert Web-Zustände korrekt
RuntimeExecutor: führt Actions gemäß Runtime Spec aus
RuntimeController: steuert Actions, Confirmations, Cancel
PolicyEvaluator: liefert und erzwingt Policy-Entscheidungen
WebSDK: implementiert die SDK-API im Browser/Host-Kontext
WorkflowEngine: führt Workflows aus
DiscoveryMapper: erkundet Apps kontrolliert und erzeugt Discovery-Pakete
AuthoringCompiler: kompiliert Authoring-Manifeste zu normierten Bundles

5. Konformitäts-Claims

5.1 Claim Descriptor

Jede zu prüfende Implementierung MUSS ihre Claims maschinenlesbar deklarieren.

interface ConformanceClaimSet {
  suiteVersion: "0.1";
  implementation: ImplementationDescriptor;
  claims: ProfileClaim[];
}

interface ImplementationDescriptor {
  vendor: string;
  product: string;
  version: string;
  buildId?: string;

  components: ImplementedComponent[];
  metadata?: Record<string, unknown>;
}

interface ImplementedComponent {
  id: string;
  roles: ConformanceRole[];

  uiapCore?: string;
  profiles?: string[];
  extensions?: Array<{
    id: string;
    version: string;
  }>;

  metadata?: Record<string, unknown>;
}

interface ProfileClaim {
  componentId: string;
  profileId: ConformanceProfileId;
}

6. Konformitätsprofile

type ConformanceProfileId =
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]"
  | "[email protected]";

6.1 Profilabhängigkeiten

`[email protected]`

Keine Abhängigkeiten.

`[email protected]`

Abhängig von:

[email protected]

`[email protected]`

Abhängig von:

[email protected]
[email protected]

`[email protected]`

Abhängig von:

[email protected]
[email protected]

`[email protected]`

Abhängig von:

[email protected]
[email protected]

`[email protected]`

Abhängig von:

[email protected]

`[email protected]`

Abhängig von:

`[email protected]`

Abhängig von:

`[email protected]`

Abhängig von:

[email protected]
[email protected]

`[email protected]`

Keine Laufzeitabhängigkeit, aber Paket-/Bundle-Konformität.

`[email protected]`

Abhängig von:

`[email protected]`

Abhängig von allen Profilen.

7. Status und Ergebnissemantik

type TestStatus =
  | "pass"
  | "fail"
  | "skip"
  | "warn"
  | "invalid";

Semantik

pass: Test erfüllt alle normativen Assertions
fail: Test verletzt mindestens eine normative Assertion
skip: Test ist für den Claim nicht anwendbar oder von einer nicht beanspruchten optionalen Fähigkeit abhängig
warn: Testfall ist nicht verpflichtend oder nur informativ, zeigt aber ein relevantes Problem
invalid: Test konnte wegen Harness-, Fixture- oder Umgebungsfehler nicht korrekt bewertet werden

Profilbewertung

Ein Profil gilt als bestanden, wenn:

alle required Testfälle des Profils und seiner Abhängigkeiten den Status pass haben,
kein required Test den Status fail oder invalid hat.

Ein Profil gilt als nicht bestanden, wenn:

mindestens ein required Test fail oder invalid ist.

Ein Profil KANN trotz warn bestanden sein.

8. Testschweregrade

type TestSeverity =
  | "required"
  | "optional"
  | "informational";

Regeln

required: bestimmt die Konformität
optional: erweitert die Aussagekraft, aber blockiert Basiskonformität nicht
informational: liefert Metriken oder Hinweise, aber keinen Pass/Fail-Effekt auf Profile

9. Testarten

type TestMethod =
  | "blackbox"
  | "graybox"
  | "whitebox";

Semantik

blackbox: Prüfung nur über öffentliche Protokoll-/API-Oberfläche
graybox: Prüfung mit Einsicht in deklarierte Artefakte, Bundles oder SDK-Hooks
whitebox: Prüfung mit interner Instrumentierung

Normative Vorgabe

Für UIAP-Konformität SOLLTE der Schwerpunkt auf blackbox und graybox liegen. Whitebox-Tests KÖNNEN ergänzen, DÜRFEN aber keine Basiskonformität ersetzen.

10. Harness-Modell

10.1 Test Harness

Ein Conformance Harness ist das System, das Tests gegen die zu prüfende Implementierung ausführt.

interface ConformanceHarness {
  loadClaims(claims: ConformanceClaimSet): Promise<void>;
  prepareFixtures(fixtures: FixtureRef[]): Promise<void>;
  runTest(testId: string): Promise<TestCaseResult>;
  runProfile(profileId: ConformanceProfileId): Promise<ProfileResult>;
}

10.2 Harness-Komponenten

Ein konformer Harness SOLLTE diese funktionalen Teile haben:

Transport Adapter für UIAP-Nachrichten
Fixture Loader für Web-App-, Bundle- und Discovery-Fixtures
Oracle/Assertion Engine
Artifact Collector
Result Aggregator
Clock/Timeout Controller

11. Fixture-Modell

11.1 Fixture Reference

interface FixtureRef {
  id: string;
  type:
    | "message-sequence"
    | "web-app"
    | "compiled-bundle"
    | "policy-context"
    | "workflow-catalog"
    | "discovery-environment"
    | "authoring-package";

  version: string;
  metadata?: Record<string, unknown>;
}

11.2 Referenz-Fixtures

Die Suite SOLLTE mindestens diese Referenz-Fixtures definieren:

12. Artefaktmodell

Der Harness MUSS Belege für Testentscheidungen speichern können.

type ArtifactType =
  | "message-trace"
  | "snapshot"
  | "delta"
  | "policy-decision"
  | "policy-audit"
  | "workflow-history"
  | "compiled-bundle"
  | "discovery-package"
  | "screenshot"
  | "log"
  | "diff";

interface ArtifactRef {
  id: string;
  type: ArtifactType;
  uri?: string;
  note?: string;
}

Regeln

Jeder fail- oder invalid-Fall MUSS mindestens ein referenzierbares Artefakt haben.
message-trace SOLLTE für Core-, Runtime- und Workflow-Fälle verpflichtend sein.
compiled-bundle SOLLTE für Authoring-Fälle verpflichtend sein.
discovery-package SOLLTE für Discovery-Fälle verpflichtend sein.

13. Testfallmodell

interface TestCaseDefinition {
  id: string;
  moduleId: string;
  title: string;
  targetRoles: ConformanceRole[];

  severity: TestSeverity;
  method: TestMethod;

  prerequisites?: string[];
  fixtures?: string[];

  purpose: string;
  assertions: AssertionDefinition[];

  metadata?: Record<string, unknown>;
}

interface AssertionDefinition {
  id: string;
  description: string;
  required: boolean;
}

interface TestCaseResult {
  id: string;
  status: TestStatus;
  durationMs: number;

  assertions: AssertionResult[];
  artifacts?: ArtifactRef[];
  notes?: string[];
}

interface AssertionResult {
  id: string;
  status: "pass" | "fail" | "skip";
  message?: string;
}

14. Modultaxonomie

type ConformanceModuleId =
  | "core"
  | "capabilities"
  | "web.profile"
  | "action.runtime"
  | "policy"
  | "sdk.web"
  | "workflow"
  | "discovery"
  | "authoring";

15. Testmodule und Pflichtfälle

15.1 Modul `core`

Pflichtfälle

`CORE-ENV-001`

Ziel: Envelope-Pflichtfelder werden korrekt validiert. Assertions:

Envelope ohne uiap wird abgelehnt
Envelope ohne kind, type, id, ts, source, payload wird abgelehnt
payload MUSS Objekt sein

`CORE-ENV-002`

Ziel: Response- und Error-Korrelation. Assertions:

response MUSS correlationId tragen
error MUSS correlationId tragen

`CORE-SES-001`

Ziel: Erfolgreicher Session-Handshake. Assertions:

session.initialize führt zu session.initialized
selectedVersion stammt aus angebotenem Versionssatz
Session wird aktiv

`CORE-SES-002`

Ziel: Fehler bei inkompatibler Version. Assertions:

Handshake endet mit unsupported_version

`CORE-SES-003`

Ziel: Fehler bei fehlender Required Extension. Assertions:

fehlende Pflicht-Extension führt zu unsupported_extension oder unsupported_profile

`CORE-SES-004`

Ziel: session.ping / session.pong. Assertions:

pong korreliert semantisch zum Ping
Session bleibt aktiv

`CORE-SES-005`

Ziel: Geordnete Terminierung. Assertions:

session.terminate führt zu session.terminated
danach werden keine normalen Nachrichten mehr verarbeitet

`CORE-CAP-001`

Ziel: capabilities.get / capabilities.list. Assertions:

Capability-Antwort ist formal gültig
capabilities.list enthält capabilities

`CORE-ERR-001`

Ziel: Fehlerobjekt und Fehlercodes. Assertions:

error.payload.code ist gesetzt
message ist gesetzt

`CORE-ERR-002`

Ziel: Unbekannter Nachrichtentyp. Assertions:

unbekannter type liefert unknown_message_type

`CORE-VER-001`

Ziel: Verhandelte Version bleibt bindend. Assertions:

nach Handshake tragen Nachrichten die ausgewählte Version

15.2 Modul `capabilities`

Pflichtfälle

`CAP-DOC-001`

Ziel: Capability Document ist formal gültig. Assertions:

modelVersion, profile, roles, stateKeys, affordances, actions, riskLevels vorhanden

`CAP-ACT-001`

Ziel: Action-IDs sind eindeutig. Assertions:

keine doppelten action.id

`CAP-SIG-001`

Ziel: verwendete Success-Signal-Arten sind deklariert. Assertions:

alle success.kind-Werte stehen in successSignalKinds

`CAP-RISK-001`

Ziel: Risk-Levels sind zulässig. Assertions:

nur safe, confirm, blocked, sofern keine dokumentierte Erweiterung

Optionale Fälle

`CAP-CONS-001`

Ziel: Konsistenz zwischen Rolle, Affordances und Actions. Beispiel: textbox mit ui.enterText, button mit ui.activate.

15.3 Modul `web.profile`

Pflichtfälle

`WEB-SNAP-001`

Ziel: Snapshot-Grundstruktur. Assertions:

PageGraph enthält revision, rootDocumentId, documents, elements, viewport

`WEB-REV-001`

Ziel: Revisionen steigen monoton. Assertions:

spätere Snapshots/Deltas haben keine rückwärtslaufende Revision

`WEB-DELTA-001`

Ziel: Deltas referenzieren bekannte Basisrevision. Assertions:

baseRevision zeigt auf bekannte vorherige Revision

`WEB-DOC-001`

Ziel: Cross-Origin-Opaque-Frames korrekt. Assertions:

opaque Frames sind als access="opaque" markiert
keine inneren Elemente werden fälschlich publiziert

`WEB-SHADOW-001`

Ziel: Closed Shadow DOM wird korrekt behandelt. Assertions:

closed Shadow-Inhalte werden nicht als frei zugängliche Elemente publiziert

`WEB-BIND-001`

Ziel: stabile IDs haben Vorrang. Assertions:

wenn stableId vorhanden ist, bleibt sie die kanonische Zielidentität

`WEB-SIG-001`

Ziel: zentrale Signale sind publizierbar. Assertions:

mindestens Route-, Dialog- oder Status-/Toast-Signale werden korrekt emittiert

`WEB-FOCUS-001`

Ziel: Fokuszustand ist konsistent. Assertions:

focus.target zeigt auf ein existierendes Element oder ist leer

Optionale Fälle

`WEB-SHADOW-002`

Ziel: Open Shadow DOM wird korrekt modelliert.

`WEB-FRAME-001`

Ziel: Bridged Cross-Origin-Frames werden korrekt als bridged publiziert.

15.4 Modul `action.runtime`

Pflichtfälle

`ACT-REQ-001`

Ziel: gültige Action-Requests werden angenommen oder sauber abgelehnt. Assertions:

action.request führt zu action.accepted oder error

`ACT-TGT-001`

Ziel: Zielauflösung via stableId. Assertions:

eindeutige stableId wird korrekt aufgelöst

`ACT-TGT-002`

Ziel: Ambiguität wird nicht verschleiert. Assertions:

mehrdeutige Ziele führen zu target_ambiguous

`ACT-CHECK-001`

Ziel: Actionability-Prüfung. Assertions:

nicht interagierbare Ziele führen zu target_not_interactable oder dokumentierter Recovery

`ACT-CONF-001`

Ziel: Confirmation Flow. Assertions:

confirm-Pflicht führt zu action.confirmation.request
ohne grant keine Ausführung
deny führt zu cancelled oder failed mit passender Ursache

`ACT-CANCEL-001`

Ziel: Cancel-Verhalten. Assertions:

action.cancel beendet aktive Action sauber

`ACT-VER-001`

Ziel: Verifikationspolitik all / any / none. Assertions:

all verlangt alle Signale
any verlangt mindestens eines
none verlangt keine Signalprüfung

`ACT-USER-001`

Ziel: User-Activation-Fälle werden korrekt behandelt. Assertions:

aktivierungspflichtige Aktion führt zu waiting_for_user, handoff oder user_activation_required

`ACT-RETRY-001`

Ziel: kein unsicherer Retry. Assertions:

bei nicht-idempotenter Action mit sideEffectState="unknown" erfolgt kein stiller Wiederholungsversuch

`ACT-RES-001`

Ziel: Action Result ist vollständig. Assertions:

status, verification, optional resolvedTarget, chosenExecutionMode vorhanden

15.5 Modul `policy`

Pflichtfälle

`POL-GET-001`

Ziel: Policy-Dokument kann geliefert werden. Assertions:

uiap.policy.get führt zu gültigem uiap.policy.document

`POL-EVAL-001`

Ziel: Safe Action mit ausreichendem Grant. Assertions:

Ergebnis ist allow

`POL-EVAL-002`

Ziel: Confirm Risk. Assertions:

confirm-Risk führt zu confirm, sofern nicht schärfere Regel greift

`POL-EVAL-003`

Ziel: Secret/Credential ohne Grant. Assertions:

Ergebnis ist deny oder handoff gemäß Policy, aber nie stilles allow

`POL-RED-001`

Ziel: Redaction-Regeln wirken. Assertions:

redaktionspflichtige Felder werden in den betroffenen Outputs maskiert

`POL-AUD-001`

Ziel: Audit-Verhalten. Assertions:

bei auditpflichtiger Entscheidung entsteht ein gültiger Audit-Record

`POL-HAND-001`

Ziel: User-Activation-/Human-Actor-Regel. Assertions:

bei passender Obligation wird handoff oder äquivalente Nicht-Autonomie erzwungen

`POL-STRICT-001`

Ziel: strengere Regel gewinnt. Assertions:

konfliktierende Regeln werden deterministisch zugunsten der strengeren Wirkung ausgewertet

15.6 Modul `sdk.web`

Pflichtfälle

`SDK-LIFE-001`

Ziel: Lifecycle-Methoden existieren und funktionieren. Assertions:

start, stop, destroy sind nutzbar

`SDK-BIND-001`

Ziel: bindElement / bindScope prägen den Snapshot. Assertions:

gebundene IDs erscheinen im publizierten State

`SDK-ACT-001`

Ziel: registrierte Actions sind ausführbar. Assertions:

registerAction stellt die Action zur Verfügung
Runtime bevorzugt registrierte App-Action, sofern passend

`SDK-POL-001`

Ziel: Policy Hook greift durch. Assertions:

lokale deny-Entscheidung verhindert Ausführung

`SDK-SIG-001`

Ziel: Signal-Emission. Assertions:

emitSignal publiziert ein gültiges Web-Signal

`SDK-FRAME-001`

Ziel: Frame Bridge validiert Kanal und Origin. Assertions:

Nachrichten von falschem origin oder falschem Kanal werden verworfen

Optionale Fälle

`SDK-OVER-001`

Ziel: Overlay ist rein präsentational. Assertions:

Overlay-Erfolg ersetzt kein action.result

15.7 Modul `workflow`

Pflichtfälle

`WF-DOC-001`

Ziel: Workflow-Katalog ist formal gültig. Assertions:

initialStepId existiert
Step-IDs sind eindeutig

`WF-START-001`

Ziel: Start eines gültigen Workflows. Assertions:

uiap.workflow.start führt zu uiap.workflow.started

`WF-INPUT-001`

Ziel: fehlende Inputs werden korrekt behandelt. Assertions:

collect führt bei fehlenden Werten zu uiap.workflow.input.request
input.provide wird korrekt angenommen oder abgelehnt

`WF-STEP-001`

Ziel: Action Step delegiert an Runtime. Assertions:

Workflow-Action führt intern zu Runtime-Ausführung
Ergebnis fließt in Workflow-History ein

`WF-POL-001`

Ziel: Policy-Integration. Assertions:

confirm führt zu waiting_confirmation
handoff führt zu waiting_user
deny führt zu failed oder definierter Recovery

`WF-CHK-001`

Ziel: Checkpoint/Resume. Assertions:

Checkpoints werden an zulässigen Punkten erzeugt
resume setzt korrekt fort

`WF-HAND-001`

Ziel: expliziter Handoff Step. Assertions:

handoff-Step setzt waiting_user

`WF-FAIL-001`

Ziel: Recovery Rules. Assertions:

definierte onError-Strategie wird angewendet

`WF-RES-001`

Ziel: Workflow-Abschluss. Assertions:

complete + globale Erfolgskriterien führen zu uiap.workflow.result

15.8 Modul `discovery`

Pflichtfälle

`DISC-PLAN-001`

Ziel: Planungsphase ist formal korrekt. Assertions:

Discovery Plan akzeptiert gültige Seeds und Umgebung

`DISC-RUN-001`

Ziel: Lifecycle von Start bis Result. Assertions:

start führt zu Progress und Result oder sauberem Fehler

`DISC-STATE-001`

Ziel: pro Seed mindestens ein Discovery State. Assertions:

initialer State enthält PageGraph und Fingerprint

`DISC-DEDUPE-001`

Ziel: Deduplizierung äquivalenter States. Assertions:

mehrfach besuchte identische Zustände erzeugen nicht beliebig neue State Nodes

`DISC-SAFE-001`

Ziel: Safety Policy wird respektiert. Assertions:

verbotene oder destructive Actions werden nicht autonom ausgeführt

`DISC-ART-001`

Ziel: Kernkataloge vorhanden. Assertions:

Route-, Scope-, Element- und Action-Katalog werden erzeugt

`DISC-EVID-001`

Ziel: Kandidaten tragen Evidence und Confidence. Assertions:

jeder Kandidat hat discoveredBy und confidence

`DISC-REV-001`

Ziel: Review Queue. Assertions:

Ambiguitäten, opaque Boundaries oder fehlende Success Signals erzeugen Review Items

Optionale Fälle

`DISC-WF-001`

Ziel: Workflow-Kandidaten werden synthetisiert.

15.9 Modul `authoring`

Pflichtfälle

`AUTH-PKG-001`

Ziel: Package Manifest ist gültig. Assertions:

genau ein Package
genau ein effektives App-Manifest nach Auflösung

`AUTH-IMP-001`

Ziel: Imports und Aliase. Assertions:

Aliase sind eindeutig
importierte IDs werden korrekt namespaced

`AUTH-OVR-001`

Ziel: Overlay-Anwendung ist deterministisch. Assertions:

identische Inputs und Build-Kontext liefern identisches Ergebnis
Konflikte werden nicht stillschweigend versteckt

`AUTH-LOC-001`

Ziel: Locale-Referenzen werden aufgelöst. Assertions:

fehlende Pflichttexte werden als Fehler oder Review-Block markiert

`AUTH-REV-001`

Ziel: Review-Gates greifen. Assertions:

prod-Bundle verletzt keine definierten Review-Regeln

`AUTH-BLD-001`

Ziel: Bundle-Kompilierung. Assertions:

kompiliertes Bundle enthält keine unaufgelösten Imports/Overlays
Build ist reproduzierbar

`AUTH-CONFLICT-001`

Ziel: Konfliktbehandlung. Assertions:

doppelte IDs oder unvereinbare Overlays führen zu Fehler oder expliziter Review-Warnung

`AUTH-DISC-001`

Ziel: Discovery-Importe sind explizit. Assertions:

Discovery-Inhalte werden nur via Acceptance-Regel in Authoring übernommen

16. Kompositprofile

16.1 `[email protected]`

Dieses Profil ist bestanden, wenn folgende Profile bestanden sind:

Empfohlene Zusatzfälle

[email protected], wenn Onboarding-/Assistenz-Use-Cases beworben werden

16.2 `[email protected]`

Dieses Profil ist bestanden, wenn alle Basisprofile bestanden sind:

Core
Capabilities
Web Publisher
Web Consumer
Action Runtime
Policy
SDK Web
Workflow
Discovery
Authoring

17. Testausführungsregeln

17.1 Wiederholung

Ein fehlgeschlagener required Test DARF genau einmal automatisch wiederholt werden, wenn der erste Lauf wegen offenkundig externer Umgebungsstörung invalid war.

17.2 Flaky Tests

Ein Test, der ohne Änderungen zwischen pass und fail schwankt, MUSS als invalid markiert werden, bis die Ursache geklärt ist.

17.3 Zeitlimits

Jeder Test SOLLTE ein Timeout haben. Timeout-Verletzungen in required Fällen führen zu fail oder invalid, je nach Ursache.

17.4 Determinismus

Für Authoring-, Policy- und bestimmte Discovery-Fälle MUSS Reproduzierbarkeit geprüft werden, wenn gleiche Inputs und gleicher Kontext vorliegen.

18. Report-Format

interface ConformanceReport {
  suiteVersion: "0.1";
  generatedAt: string;

  implementation: ImplementationDescriptor;
  claims: ProfileClaim[];

  environment: ConformanceEnvironment;
  results: ProfileResult[];

  summary: ConformanceSummary;
  artifacts?: ArtifactRef[];
}

interface ConformanceEnvironment {
  harnessVersion: string;
  runnerId?: string;
  os?: string;
  browser?: string;
  nodeVersion?: string;
  metadata?: Record<string, unknown>;
}

interface ProfileResult {
  profileId: ConformanceProfileId;
  status: "pass" | "fail" | "invalid";
  testResults: TestCaseResult[];
}

interface ConformanceSummary {
  passedProfiles: string[];
  failedProfiles: string[];
  invalidProfiles: string[];

  passCount: number;
  failCount: number;
  skipCount: number;
  warnCount: number;
  invalidCount: number;
}

Regeln

Jeder beanspruchte Claim MUSS im Report auftauchen.
failedProfiles MUSS auch Profiles enthalten, die nur wegen Abhängigkeitsverletzung scheitern.
Reports SOLLTEN maschinenlesbar serialisierbar sein.

19. Minimaler Suite-Lieferumfang

Eine Referenz-Conformance-Suite v0.1 MUSS mindestens bereitstellen:

Profildefinitionen
Testfallkatalog
Referenz-Fixtures
Report-Schema
Ergebnisaggregation
Dokumentation zur Harness-Ausführung

Sie SOLLTE zusätzlich bereitstellen:

Referenz-Harness
CI-kompatiblen Runner
Golden Artifacts
Beispiel-Claims
Beispiel-Reports

20. Beispiel eines Claim Sets

{
  "suiteVersion": "0.1",
  "implementation": {
    "vendor": "Acme",
    "product": "Acme Web Agent Host",
    "version": "1.2.0",
    "components": [
      {
        "id": "host",
        "roles": [
          "CoreEndpoint",
          "CapabilityProvider",
          "WebPublisher",
          "RuntimeExecutor",
          "PolicyEvaluator",
          "WebSDK"
        ],
        "uiapCore": "0.1",
        "profiles": ["[email protected]"],
        "extensions": [
          { "id": "uiap.policy", "version": "0.1" }
        ]
      }
    ]
  },
  "claims": [
    { "componentId": "host", "profileId": "[email protected]" },
    { "componentId": "host", "profileId": "[email protected]" },
    { "componentId": "host", "profileId": "[email protected]" },
    { "componentId": "host", "profileId": "[email protected]" },
    { "componentId": "host", "profileId": "[email protected]" },
    { "componentId": "host", "profileId": "[email protected]" },
    { "componentId": "host", "profileId": "[email protected]" }
  ]
}

21. Beispiel eines Report-Fragments

{
  "suiteVersion": "0.1",
  "generatedAt": "2026-03-26T18:20:00Z",
  "implementation": {
    "vendor": "Acme",
    "product": "Acme Web Agent Host",
    "version": "1.2.0",
    "components": [
      {
        "id": "host",
        "roles": [
          "CoreEndpoint",
          "CapabilityProvider",
          "WebPublisher",
          "RuntimeExecutor",
          "PolicyEvaluator",
          "WebSDK"
        ]
      }
    ]
  },
  "claims": [
    { "componentId": "host", "profileId": "[email protected]" }
  ],
  "environment": {
    "harnessVersion": "0.1.0",
    "browser": "Chromium 126"
  },
  "results": [
    {
      "profileId": "[email protected]",
      "status": "pass",
      "testResults": [
        {
          "id": "CORE-SES-001",
          "status": "pass",
          "durationMs": 48,
          "assertions": [
            { "id": "a1", "status": "pass" },
            { "id": "a2", "status": "pass" }
          ]
        }
      ]
    },
    {
      "profileId": "[email protected]",
      "status": "fail",
      "testResults": [
        {
          "id": "SDK-FRAME-001",
          "status": "fail",
          "durationMs": 33,
          "assertions": [
            {
              "id": "a1",
              "status": "fail",
              "message": "Nachricht mit falschem origin wurde verarbeitet."
            }
          ],
          "artifacts": [
            {
              "id": "art_17",
              "type": "message-trace",
              "note": "Frame bridge accepted untrusted origin"
            }
          ]
        }
      ]
    }
  ],
  "summary": {
    "passedProfiles": ["[email protected]"],
    "failedProfiles": ["[email protected]"],
    "invalidProfiles": [],
    "passCount": 11,
    "failCount": 1,
    "skipCount": 3,
    "warnCount": 0,
    "invalidCount": 0
  }
}

22. Konformitätsaussagen nach außen

Eine Implementierung DARF nur dann öffentlich behaupten:

„UIAP Core v0.1 konform“, wenn [email protected] bestanden ist
„UIAP Web Agent Host v0.1 konform“, wenn [email protected] bestanden ist
„UIAP Full Reference v0.1 konform“, wenn [email protected] bestanden ist

Wenn nur Teilbereiche bestanden sind, MUSS die Aussage präzise sein. Also nicht „wir sind UIAP-kompatibel“, wenn in Wahrheit nur das Envelope-Parsing lebt und der Rest aus Hoffnung besteht.

23. Empfohlene nächste Artefakte

Nach dieser Spec fehlen praktisch noch drei Dinge, damit das sofort produktiv brauchbar wird:

Referenz-Fixture Pack v0.1 mit Demo-Web-App, Policy-Fällen, Workflow-Fällen, Discovery-Umgebung und Authoring-Sample-Pack.
Conformance Report JSON Schema v0.1 damit Reports maschinenvalidierbar sind.
CI Runner Spec v0.1 damit Teams Claims automatisch in CI prüfen und Bundle-/SDK-/Runtime-Releases blockieren können.

Normative Referenzen

[UIAP-CORE] UIAP Core v0.1
[UIAP-CAP] UIAP Capability Model v0.1
[UIAP-WEB] UIAP Web Profile v0.1
[UIAP-ACTION] UIAP Action Runtime v0.1
[UIAP-POLICY] UIAP Policy Extension v0.1
[UIAP-SDK] UIAP SDK API v0.1
[UIAP-WORKFLOW] UIAP Workflow Extension v0.1
[UIAP-DISCOVERY] UIAP Discovery Mapper v0.1
[UIAP-MANIFEST] UIAP Authoring/Manifest v0.1
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, BCP 14

Security Considerations

Conformance-Tests DÜRFEN NICHT gegen Produktivsysteme ohne explizite Autorisierung ausgeführt werden.
Test-Fixtures KÖNNEN sensitive Muster enthalten; Test-Ergebnisse SOLLTEN vor der Veröffentlichung redaktiert werden.
Conformance-Ergebnisse SOLLTEN kryptographisch signiert werden, wenn sie als Nachweis gegenüber Dritten verwendet werden.

Changelog

Version	Datum	Änderungen
0.1	2026-03-27	Initialer Entwurf

UIAP Conformance Suite

UIAP Conformance Suite v0.1

1. Zweck und Geltungsbereich

2. Grundprinzipien

3. Normative Begriffe

4. Rollen des zu prüfenden Systems

Rollensemantik

5. Konformitäts-Claims

5.1 Claim Descriptor

6. Konformitätsprofile

6.1 Profilabhängigkeiten

7. Status und Ergebnissemantik

Semantik

Profilbewertung

8. Testschweregrade

Regeln

9. Testarten

Semantik

Normative Vorgabe

10. Harness-Modell

10.1 Test Harness

10.2 Harness-Komponenten

11. Fixture-Modell

11.1 Fixture Reference

11.2 Referenz-Fixtures

12. Artefaktmodell

Regeln

13. Testfallmodell

14. Modultaxonomie

15. Testmodule und Pflichtfälle

15.1 Modul core

Pflichtfälle

CORE-ENV-001

CORE-ENV-002

CORE-SES-001

CORE-SES-002

CORE-SES-003

CORE-SES-004

CORE-SES-005

CORE-CAP-001

CORE-ERR-001

CORE-ERR-002

CORE-VER-001

15.2 Modul capabilities

Pflichtfälle

CAP-DOC-001

CAP-ACT-001

CAP-SIG-001

CAP-RISK-001

Optionale Fälle

CAP-CONS-001

15.3 Modul web.profile

Pflichtfälle

WEB-SNAP-001

WEB-REV-001

WEB-DELTA-001

WEB-DOC-001

WEB-SHADOW-001

WEB-BIND-001

WEB-SIG-001

WEB-FOCUS-001

Optionale Fälle

WEB-SHADOW-002

WEB-FRAME-001

15.4 Modul action.runtime

Pflichtfälle

ACT-REQ-001

ACT-TGT-001

ACT-TGT-002

ACT-CHECK-001

ACT-CONF-001

ACT-CANCEL-001

ACT-VER-001

ACT-USER-001

ACT-RETRY-001

ACT-RES-001

15.5 Modul policy

Pflichtfälle

POL-GET-001

POL-EVAL-001

15.1 Modul `core`

`CORE-ENV-001`

`CORE-ENV-002`

`CORE-SES-001`

`CORE-SES-002`

`CORE-SES-003`

`CORE-SES-004`

`CORE-SES-005`

`CORE-CAP-001`

`CORE-ERR-001`

`CORE-ERR-002`

`CORE-VER-001`

15.2 Modul `capabilities`

`CAP-DOC-001`

`CAP-ACT-001`

`CAP-SIG-001`

`CAP-RISK-001`

`CAP-CONS-001`

15.3 Modul `web.profile`

`WEB-SNAP-001`

`WEB-REV-001`

`WEB-DELTA-001`

`WEB-DOC-001`

`WEB-SHADOW-001`

`WEB-BIND-001`

`WEB-SIG-001`

`WEB-FOCUS-001`

`WEB-SHADOW-002`

`WEB-FRAME-001`

15.4 Modul `action.runtime`

`ACT-REQ-001`

`ACT-TGT-001`

`ACT-TGT-002`

`ACT-CHECK-001`

`ACT-CONF-001`

`ACT-CANCEL-001`

`ACT-VER-001`

`ACT-USER-001`

`ACT-RETRY-001`

`ACT-RES-001`

15.5 Modul `policy`

`POL-GET-001`

`POL-EVAL-001`

`POL-EVAL-002`

`POL-EVAL-003`

`POL-RED-001`

`POL-AUD-001`

`POL-HAND-001`

`POL-STRICT-001`

15.6 Modul `sdk.web`

`SDK-LIFE-001`

`SDK-BIND-001`

`SDK-ACT-001`

`SDK-POL-001`

`SDK-SIG-001`

`SDK-FRAME-001`

`SDK-OVER-001`

15.7 Modul `workflow`

`WF-DOC-001`

`WF-START-001`

`WF-INPUT-001`

`WF-STEP-001`

`WF-POL-001`

`WF-CHK-001`

`WF-HAND-001`

`WF-FAIL-001`

`WF-RES-001`

15.8 Modul `discovery`

`DISC-PLAN-001`

`DISC-RUN-001`

`DISC-STATE-001`

`DISC-DEDUPE-001`

`DISC-SAFE-001`

`DISC-ART-001`

`DISC-EVID-001`

`DISC-REV-001`

`DISC-WF-001`

15.9 Modul `authoring`

`AUTH-PKG-001`

`AUTH-IMP-001`