Bound the input
Measure UTF-8 bytes, reject empty input, and stop streams over the message limit before schema work begins.
Transparent validation contract
How A2UI Validator works
A test-backed account of what the validator checks, which upstream files it uses, how results are ordered, and where a valid result stops.
Last verified July 17, 2026 ·
a2ui-v0.9.1-basic@3f6877bScope at a glance
A precise v0.9.1 contract
The validator accepts a JSON object, a JSON array, or non-empty JSONL lines and requires every message to declare exact v0.9.1. It checks the official Basic Catalog at https://a2ui.org/specification/v0_9_1/catalogs/basic/catalog.json; it does not infer support for v1.0 or custom catalogs.
Validation pipeline
Five ordered stages
Parse the stream
Try one complete JSON value first. If that fails, parse each non-empty JSONL line and preserve useful line locations.
Enforce the version
Reject missing, mixed, and non-v0.9.1 declarations before schema evaluation so older aliases cannot pass silently.
Apply the schemas
Ajv Draft 2020-12 checks message shapes, required fields, value types, allowed properties, and Basic Catalog components.
Inspect the graph
Independent deterministic rules check surface lifecycle, root reachability, references, duplicate IDs, cycles, and orphans.
Pinned schema provenance
Auditable upstream files
The three JSON files are copied without content changes from the a2ui-project/a2ui repository at commit 3f6877b8c3420cd6c6e80df8a51ebd01d7286644, retrieved July 15, 2026. The upstream files retain their Apache-2.0 license.
| File | Purpose | SHA-256 |
|---|---|---|
server_to_client.json | Server-to-client message envelopes | 2ba29dbcb57611225c96d3e064d05cf97e9d8224b293c8b20d37b93922a2d30d |
common_types.json | Shared A2UI value types | ac79788e95e5bdf0a39808953593a53c1bc9fcdcdb55480f4610613c6591e94c |
catalog.json | Official v0.9.1 Basic Catalog | 4c694b68ee51e0e5716add4bcfddafb6311089df07314832f27decaca319c0d3 |
Independent semantic checks
Rules schemas cannot express alone
- Duplicate surface creation
- Update or delete before create, and update after delete
- Duplicate component IDs
- Missing root components
- Unknown structural references
- Component cycles
- Orphan or unreachable components
Issue anatomy
Stable, locatable output
Each issue carries a broad code, stable subcode, message index, source line when available, JSON Pointer, surface ID when relevant, reason, and suggested repair. Results use deterministic sorting so the same input produces a predictable report.
Copy result creates a safe diagnostic summary. It does not include the original payload.
Result semantics
What “Valid” does—and does not—mean
A valid result means
No syntax, exact-version, pinned-schema, or documented semantic-rule issue was found for this input.
It is not a guarantee
It does not prove compatibility with every renderer, a custom catalog, v1.0, application behavior, accessibility, or security.
Test strategy
Public examples are executable evidence
Valid object, array, and JSONL fixtures run through the same production validator core. Every published error family also has a broken fixture and a repaired fixture, alongside version, size, message-count, timeout, copy-sanitization, and analytics allowlist coverage.
Execution boundary
Payload work stays in the browser
Parsing and validation run in a same-origin Web Worker. The application has no validation API or payload database. After optional consent, Google Analytics measures website pages and engagement, while the nine bucketed product events remain in a session-local verification buffer. Neither boundary receives the raw payload, full result, JSON Pointer, component IDs, or clipboard contents. Website delivery and analytics are described in the Privacy Notice.
Worker startup is separately bounded at 15 seconds; the 3-second validation budget starts only after readiness.
Corrections welcome
Found a reproducible discrepancy?
Send the stable code, browser version, and a minimal sanitized fixture—never secrets or a complete private payload.