UIAP Conformance Suite

UIAP Conformance Suite v0.1

Field	Value
Status	Draft
Version	0.1
Date	2026-03-27
Dependencies	All UIAP specifications
Editors	Patrick

1. Purpose and Scope

UIAP Conformance Suite v0.1 defines how implementations of UIAP specifications are tested, evaluated and classified as conformant or non-conformant in a standardized manner.

The Conformance Suite covers these specification areas:

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

The suite defines:

Conformance classes and claims
Test modules and test cases
Harness and fixture model
Execution and evaluation rules
Result and report format
Composite profiles for real-world product claims

The suite does not define:

Product certifications by a specific organization
Commercial labels or trademarks
Model quality benchmarking
LLM intelligence tests in the sense of “does the agent seem cool enough”

2. Core Principles

Conformance is claims-based. Only what an implementation actually claims is tested.
Required tests are binding. A passed claim requires passing all associated required cases.
Composite profiles build on base profiles.
Negative tests are equal to positive tests.
Determinism beats romance. Repeatable inputs MUST produce reproducible results, insofar as the specification demands it.
Conformance measures specification adherence, not product quality.
Self-asserted compatibility without suite results is not proof of conformance.

3. Normative Keywords

The key words MUST, MUST NOT, SHOULD, MAY in this document are to be interpreted as described in RFC 2119 and BCP 14, when and only when they appear in ALL CAPS.

4. Roles of the System Under Test

An implementation MAY claim one or more of these roles:

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

Role Semantics

CoreEndpoint: speaks UIAP Core correctly
CapabilityProvider: delivers capability documents
WebPublisher: publishes PageGraph, deltas and web signals
WebConsumer: consumes web states correctly
RuntimeExecutor: executes actions according to the Runtime Spec
RuntimeController: controls actions, confirmations, cancel
PolicyEvaluator: delivers and enforces policy decisions
WebSDK: implements the SDK API in a browser/host context
WorkflowEngine: executes workflows
DiscoveryMapper: explores apps in a controlled manner and produces discovery packages
AuthoringCompiler: compiles authoring manifests into normalized bundles

5. Conformance Claims

5.1 Claim Descriptor

Every implementation under test MUST declare its claims in a machine-readable format.

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. Conformance Profiles

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 Profile Dependencies

`[email protected]`

Depends on:

[email protected]
[email protected]

`[email protected]`

Depends on:

[email protected]
[email protected]

`[email protected]`

Depends on:

[email protected]
[email protected]

`[email protected]`

Depends on:

[email protected]
[email protected]

`[email protected]`

No runtime dependency, but package/bundle conformance.

7. Status and Result Semantics

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

Semantics

pass: test fulfills all normative assertions
fail: test violates at least one normative assertion
skip: test is not applicable for the claim or depends on an unclaimed optional capability
warn: test case is not required or is informational only, but indicates a relevant issue
invalid: test could not be correctly evaluated due to a harness, fixture or environment error

Profile Evaluation

A profile is considered passed when:

all required test cases of the profile and its dependencies have status pass,
no required test has status fail or invalid.

A profile is considered failed when:

at least one required test is fail or invalid.

A profile MAY still pass despite warn.

8. Test Severity Levels

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

Rules

required: determines conformance
optional: enhances the expressiveness of results but does not block base conformance
informational: provides metrics or hints but has no pass/fail effect on profiles

9. Test Methods

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

Semantics

blackbox: verification only through the public protocol/API surface
graybox: verification with insight into declared artifacts, bundles or SDK hooks
whitebox: verification with internal instrumentation

Normative Requirement

For UIAP conformance, the emphasis SHOULD be on blackbox and graybox. Whitebox tests MAY supplement but MUST NOT replace base conformance.

10. Harness Model

10.1 Test Harness

A conformance harness is the system that executes tests against the implementation under test.

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 Components

A conformant harness SHOULD have these functional parts:

Transport Adapter for UIAP messages
Fixture Loader for web app, bundle and discovery fixtures
Oracle/Assertion Engine
Artifact Collector
Result Aggregator
Clock/Timeout Controller

11. Fixture Model

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 Reference Fixtures

The suite SHOULD define at least these reference fixtures:

12. Artifact Model

The harness MUST be able to store evidence for test decisions.

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;
}

Rules

Every fail or invalid case MUST have at least one referenceable artifact.
message-trace SHOULD be required for core, runtime and workflow cases.
compiled-bundle SHOULD be required for authoring cases.
discovery-package SHOULD be required for discovery cases.

13. Test Case Model

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. Module Taxonomy

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

15. Test Modules and Required Cases

15.1 Module `core`

Required Cases

`CORE-ENV-001`

Goal: Envelope required fields are correctly validated. Assertions:

Envelope without uiap is rejected
Envelope without kind, type, id, ts, source, payload is rejected
payload MUST be an object

`CORE-ENV-002`

Goal: Response and error correlation. Assertions:

response MUST carry correlationId
error MUST carry correlationId

`CORE-SES-001`

Goal: Successful session handshake. Assertions:

session.initialize leads to session.initialized
selectedVersion comes from the offered version set
Session becomes active

`CORE-SES-002`

Goal: Error on incompatible version. Assertions:

Handshake ends with unsupported_version

`CORE-SES-003`

Goal: Error on missing required extension. Assertions:

Missing required extension leads to unsupported_extension or unsupported_profile

`CORE-SES-004`

Goal: session.ping / session.pong. Assertions:

pong correlates semantically to the ping
Session remains active

`CORE-SES-005`

Goal: Orderly termination. Assertions:

session.terminate leads to session.terminated
No further normal messages are processed afterwards

`CORE-CAP-001`

Goal: capabilities.get / capabilities.list. Assertions:

Capability response is formally valid
capabilities.list contains capabilities

`CORE-ERR-001`

Goal: Error object and error codes. Assertions:

error.payload.code is set
message is set

`CORE-ERR-002`

Goal: Unknown message type. Assertions:

Unknown type returns unknown_message_type

`CORE-VER-001`

Goal: Negotiated version remains binding. Assertions:

After handshake, messages carry the selected version

15.2 Module `capabilities`

Required Cases

`CAP-DOC-001`

Goal: Capability Document is formally valid. Assertions:

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

`CAP-ACT-001`

Goal: Action IDs are unique. Assertions:

No duplicate action.id

`CAP-SIG-001`

Goal: Used success signal kinds are declared. Assertions:

All success.kind values appear in successSignalKinds

`CAP-RISK-001`

Goal: Risk levels are valid. Assertions:

Only safe, confirm, blocked, unless a documented extension exists

Optional Cases

`CAP-CONS-001`

Goal: Consistency between role, affordances and actions. Example: textbox with ui.enterText, button with ui.activate.

15.3 Module `web.profile`

Required Cases

`WEB-SNAP-001`

Goal: Snapshot basic structure. Assertions:

PageGraph contains revision, rootDocumentId, documents, elements, viewport

`WEB-REV-001`

Goal: Revisions increase monotonically. Assertions:

Later snapshots/deltas do not have a backward-running revision

`WEB-DELTA-001`

Goal: Deltas reference a known base revision. Assertions:

baseRevision points to a known previous revision

`WEB-DOC-001`

Goal: Cross-origin opaque frames are correct. Assertions:

Opaque frames are marked as access="opaque"
No inner elements are falsely published

`WEB-SHADOW-001`

Goal: Closed Shadow DOM is handled correctly. Assertions:

Closed shadow contents are not published as freely accessible elements

`WEB-BIND-001`

Goal: Stable IDs take precedence. Assertions:

When stableId is present, it remains the canonical target identity

`WEB-SIG-001`

Goal: Core signals are publishable. Assertions:

At least route, dialog or status/toast signals are emitted correctly

`WEB-FOCUS-001`

Goal: Focus state is consistent. Assertions:

focus.target points to an existing element or is empty

Optional Cases

`WEB-SHADOW-002`

Goal: Open Shadow DOM is modeled correctly.

`WEB-FRAME-001`

Goal: Bridged cross-origin frames are correctly published as bridged.

15.4 Module `action.runtime`

Required Cases

`ACT-REQ-001`

Goal: Valid action requests are accepted or cleanly rejected. Assertions:

action.request leads to action.accepted or error

`ACT-TGT-001`

Goal: Target resolution via stableId. Assertions:

Unique stableId is resolved correctly

`ACT-TGT-002`

Goal: Ambiguity is not concealed. Assertions:

Ambiguous targets lead to target_ambiguous

`ACT-CHECK-001`

Goal: Actionability check. Assertions:

Non-interactable targets lead to target_not_interactable or documented recovery

`ACT-CONF-001`

Goal: Confirmation flow. Assertions:

confirm requirement leads to action.confirmation.request
Without grant, no execution occurs
deny leads to cancelled or failed with an appropriate cause

`ACT-CANCEL-001`

Goal: Cancel behavior. Assertions:

action.cancel cleanly terminates an active action

`ACT-VER-001`

Goal: Verification policy all / any / none. Assertions:

all requires all signals
any requires at least one
none requires no signal verification

`ACT-USER-001`

Goal: User activation cases are handled correctly. Assertions:

An action requiring activation leads to waiting_for_user, handoff or user_activation_required

`ACT-RETRY-001`

Goal: No unsafe retry. Assertions:

For non-idempotent actions with sideEffectState="unknown", no silent retry occurs

`ACT-RES-001`

Goal: Action result is complete. Assertions:

status, verification, optionally resolvedTarget, chosenExecutionMode present

15.5 Module `policy`

Required Cases

`POL-GET-001`

Goal: Policy document can be delivered. Assertions:

uiap.policy.get leads to a valid uiap.policy.document

`POL-EVAL-001`

Goal: Safe action with sufficient grant. Assertions:

Result is allow

`POL-EVAL-002`

Goal: Confirm risk. Assertions:

confirm risk leads to confirm, unless a stricter rule applies

`POL-EVAL-003`

Goal: Secret/credential without grant. Assertions:

Result is deny or handoff per policy, but never silent allow

`POL-RED-001`

Goal: Redaction rules take effect. Assertions:

Fields subject to redaction are masked in affected outputs

`POL-AUD-001`

Goal: Audit behavior. Assertions:

For an audit-required decision, a valid audit record is produced

`POL-HAND-001`

Goal: User activation / human actor rule. Assertions:

With a matching obligation, handoff or equivalent non-autonomy is enforced

`POL-STRICT-001`

Goal: Stricter rule wins. Assertions:

Conflicting rules are deterministically evaluated in favor of the stricter effect

15.6 Module `sdk.web`

Required Cases

`SDK-LIFE-001`

Goal: Lifecycle methods exist and function. Assertions:

start, stop, destroy are usable

`SDK-BIND-001`

Goal: bindElement / bindScope shape the snapshot. Assertions:

Bound IDs appear in the published state

`SDK-ACT-001`

Goal: Registered actions are executable. Assertions:

registerAction makes the action available
Runtime prefers the registered app action when appropriate

`SDK-POL-001`

Goal: Policy hook takes effect. Assertions:

A local deny decision prevents execution

`SDK-SIG-001`

Goal: Signal emission. Assertions:

emitSignal publishes a valid web signal

`SDK-FRAME-001`

Goal: Frame bridge validates channel and origin. Assertions:

Messages from an incorrect origin or incorrect channel are discarded

Optional Cases

`SDK-OVER-001`

Goal: Overlay is purely presentational. Assertions:

Overlay success does not replace action.result

15.7 Module `workflow`

Required Cases

`WF-DOC-001`

Goal: Workflow catalog is formally valid. Assertions:

initialStepId exists
Step IDs are unique

`WF-START-001`

Goal: Starting a valid workflow. Assertions:

uiap.workflow.start leads to uiap.workflow.started

`WF-INPUT-001`

Goal: Missing inputs are handled correctly. Assertions:

collect leads to uiap.workflow.input.request when values are missing
input.provide is correctly accepted or rejected

`WF-STEP-001`

Goal: Action step delegates to runtime. Assertions:

Workflow action leads internally to runtime execution
Result flows into workflow history

`WF-POL-001`

Goal: Policy integration. Assertions:

confirm leads to waiting_confirmation
handoff leads to waiting_user
deny leads to failed or defined recovery

`WF-CHK-001`

Goal: Checkpoint/resume. Assertions:

Checkpoints are created at permitted points
resume continues correctly

`WF-HAND-001`

Goal: Explicit handoff step. Assertions:

handoff step sets waiting_user

`WF-FAIL-001`

Goal: Recovery rules. Assertions:

Defined onError strategy is applied

`WF-RES-001`

Goal: Workflow completion. Assertions:

complete plus global success criteria lead to uiap.workflow.result

15.8 Module `discovery`

Required Cases

`DISC-PLAN-001`

Goal: Planning phase is formally correct. Assertions:

Discovery plan accepts valid seeds and environment

`DISC-RUN-001`

Goal: Lifecycle from start to result. Assertions:

start leads to progress and result or a clean error

`DISC-STATE-001`

Goal: At least one discovery state per seed. Assertions:

Initial state contains PageGraph and fingerprint

`DISC-DEDUPE-001`

Goal: Deduplication of equivalent states. Assertions:

Repeatedly visited identical states do not generate arbitrarily many new state nodes

`DISC-SAFE-001`

Goal: Safety policy is respected. Assertions:

Forbidden or destructive actions are not executed autonomously

`DISC-ART-001`

Goal: Core catalogs are present. Assertions:

Route, scope, element and action catalogs are produced

`DISC-EVID-001`

Goal: Candidates carry evidence and confidence. Assertions:

Every candidate has discoveredBy and confidence

`DISC-REV-001`

Goal: Review queue. Assertions:

Ambiguities, opaque boundaries or missing success signals produce review items

Optional Cases

`DISC-WF-001`

Goal: Workflow candidates are synthesized.

15.9 Module `authoring`

Required Cases

`AUTH-PKG-001`

Goal: Package manifest is valid. Assertions:

Exactly one package
Exactly one effective app manifest after resolution

`AUTH-IMP-001`

Goal: Imports and aliases. Assertions:

Aliases are unique
Imported IDs are correctly namespaced

`AUTH-OVR-001`

Goal: Overlay application is deterministic. Assertions:

Identical inputs and build context produce identical results
Conflicts are not silently hidden

`AUTH-LOC-001`

Goal: Locale references are resolved. Assertions:

Missing required texts are marked as errors or review blocks

`AUTH-REV-001`

Goal: Review gates take effect. Assertions:

prod bundle does not violate defined review rules

`AUTH-BLD-001`

Goal: Bundle compilation. Assertions:

Compiled bundle contains no unresolved imports/overlays
Build is reproducible

`AUTH-CONFLICT-001`

Goal: Conflict handling. Assertions:

Duplicate IDs or incompatible overlays lead to an error or explicit review warning

`AUTH-DISC-001`

Goal: Discovery imports are explicit. Assertions:

Discovery content is only incorporated into authoring via acceptance rules

16. Composite Profiles

16.1 `[email protected]`

This profile is passed when the following profiles are passed:

Recommended Additional Cases

[email protected], if onboarding/assistance use cases are advertised

16.2 `[email protected]`

This profile is passed when all base profiles are passed:

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

17. Test Execution Rules

17.1 Retry

A failed required test MAY be automatically retried exactly once if the first run was invalid due to an obviously external environment disturbance.

17.2 Flaky Tests

A test that fluctuates between pass and fail without changes MUST be marked as invalid until the cause is resolved.

17.3 Time Limits

Every test SHOULD have a timeout. Timeout violations in required cases lead to fail or invalid, depending on the cause.

17.4 Determinism

For authoring, policy and certain discovery cases, reproducibility MUST be verified when identical inputs and identical context are present.

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;
}

Rules

Every claimed claim MUST appear in the report.
failedProfiles MUST also contain profiles that fail solely due to dependency violations.
Reports SHOULD be machine-readably serializable.

19. Minimum Suite Deliverables

A reference conformance suite v0.1 MUST provide at least:

Profile definitions
Test case catalog
Reference fixtures
Report schema
Result aggregation
Documentation for harness execution

It SHOULD additionally provide:

Reference harness
CI-compatible runner
Golden artifacts
Example claims
Example reports

20. Example of a Claim Set

{
  "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. Example of a Report Fragment

{
  "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": "Message with incorrect origin was processed."
            }
          ],
          "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. External Conformance Statements

An implementation MAY only publicly claim:

“UIAP Core v0.1 conformant”, if [email protected] is passed
“UIAP Web Agent Host v0.1 conformant”, if [email protected] is passed
“UIAP Full Reference v0.1 conformant”, if [email protected] is passed

If only partial areas are passed, the statement MUST be precise. In other words, do not claim “we are UIAP-compatible” when in reality only the envelope parsing works and the rest consists of wishful thinking.

23. Recommended Next Artifacts

Following this spec, three things are practically still needed to make this immediately production-ready:

Reference Fixture Pack v0.1 with demo web app, policy cases, workflow cases, discovery environment and authoring sample pack.
Conformance Report JSON Schema v0.1 so that reports are machine-validatable.
CI Runner Spec v0.1 so that teams can automatically verify claims in CI and block bundle/SDK/runtime releases.

Normative References

[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 MUST NOT be executed against production systems without explicit authorization.
Test fixtures MAY contain sensitive patterns; test results SHOULD be redacted before publication.
Conformance results SHOULD be cryptographically signed when used as evidence toward third parties.

Changelog

Version	Date	Changes
0.1	2026-03-27	Initial draft

UIAP Conformance Suite

UIAP Conformance Suite v0.1

1. Purpose and Scope

2. Core Principles

3. Normative Keywords

4. Roles of the System Under Test

Role Semantics

5. Conformance Claims

5.1 Claim Descriptor

6. Conformance Profiles

6.1 Profile Dependencies

7. Status and Result Semantics

Semantics

Profile Evaluation

8. Test Severity Levels

Rules

9. Test Methods

Semantics

Normative Requirement

10. Harness Model

10.1 Test Harness

10.2 Harness Components

11. Fixture Model

11.1 Fixture Reference

11.2 Reference Fixtures

12. Artifact Model

Rules

13. Test Case Model

14. Module Taxonomy

15. Test Modules and Required Cases

15.1 Module core

Required Cases

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 Module capabilities

Required Cases

CAP-DOC-001

CAP-ACT-001

CAP-SIG-001

CAP-RISK-001

Optional Cases

CAP-CONS-001

15.3 Module web.profile

Required Cases

WEB-SNAP-001

WEB-REV-001

WEB-DELTA-001

WEB-DOC-001

WEB-SHADOW-001

WEB-BIND-001

WEB-SIG-001

WEB-FOCUS-001

Optional Cases

WEB-SHADOW-002

WEB-FRAME-001

15.4 Module action.runtime

Required Cases

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 Module policy

Required Cases

POL-GET-001

POL-EVAL-001

15.1 Module `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 Module `capabilities`

`CAP-DOC-001`

`CAP-ACT-001`

`CAP-SIG-001`

`CAP-RISK-001`

`CAP-CONS-001`

15.3 Module `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 Module `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 Module `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 Module `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 Module `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 Module `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 Module `authoring`

`AUTH-PKG-001`

`AUTH-IMP-001`