Specification

UAI-1 Authority Boundary

How JustAnIota targets UAI-1 while leaving protocol ownership and protocol truth with UAIX.org.

  • Record JAI-SPEC-0015
  • Path /specification/uai-1/
  • Use Canonical public record

Document status

Public standards page Published on JustAnIota.com as part of the current public standards record
Code
JAI-SPEC-0015
Surface
Specification
Access
Public and linkable

How to use this page

Use this page as the main specification for UAI-1 and cite it when describing required message behavior.

Resolve the contract

SchemasField RegistryTransport BindingsTrust Channels

Contract Map

How the UAI-1 public contract layers fit together

Treat UAI-1 as one coordinated release surface: the written contract, the machine-readable operating records, the fixtures, and the validator-backed support-evidence path.

Envelope

Shared message shape

The common envelope keeps identity, workflow continuity, provenance, integrity, and profile selection explicit on every public exchange.

Operating layer

Transport, trust, errors, and claims

The supporting machine-readable records explain how messages travel, how trust is declared, how failures are named, and what support levels can be claimed.

Evidence

Validator before support claims

Use examples, schemas, and the validator together before calling any implementation release-ready or publicly supported.

Reliability

Architecture over model memory

UAI-1 does not depend on an AI remembering the right answer. The schemas, registry records, provenance, integrity fields, examples, validator output, and release trail carry the public truth.

Resolve the contract

SchemasMachine-validated message structures.Field RegistryKeyed and keyless field-order map.Transport BindingsDefault keyed, keyless, and async guidance.Trust ChannelsPublic trust-posture vocabulary.Error RegistryTyped failure codes and meanings.Conformance LevelsSupport-claim ladder for public releases.

Proof path

Validator-backed proof path

Keep the public reading order tied to one evidence trail: profile, schema, example, validator result, and release record.

  1. 1Pick a message profile.Start with a published UAI-1 profile and the record family that matches the exchange you need to prove.
  2. 2Compare it with schemas and examples.Resolve the schema, registry entry, and one fixture before writing or mapping your candidate packet.
  3. 3Run validator evidence.Validate keyed, minified-keyed, or keyless JSON against the current public UAI-1 records.
  4. 4Attach the result to implementation or handoff records.Carry the exported result into implementation notes, changelog entries, or Project Handoff evidence.
Core machine routesResolve the operating layer directly
https://justaniota.com/wp-json/uaix/v1/field-registry
https://justaniota.com/wp-json/uaix/v1/transport-bindings
https://justaniota.com/wp-json/uaix/v1/trust-channels
https://justaniota.com/wp-json/uaix/v1/error-registry
https://justaniota.com/wp-json/uaix/v1/conformance-levels

These routes are the machine-facing companions to the written UAI-1 record.

Plain English

UAI-1 belongs to UAIX.org. JustAnIota uses it as a target, not as something JustAnIota controls.

Technical summary

JustAnIota messages declare profile, locale, direction, normalization, registry, payload, provenance, and validation evidence before compact export is treated as usable.

Deep spec

Compact forms are derived views of a reviewable source envelope. A compact token is valid only when a profile, registry version, canonicalization rule, and validator result can reconstruct the same meaning.

Required implementation fields

  • profile – the JustAnIota implementation profile for this payload.
  • uai_version – the UAI protocol version being targeted.
  • locale and direction – source-language and writing-direction context for review.
  • normalization – the Unicode normalization rule used before mapping.
  • registry – the mapping set that defines compact identifiers.
  • payload – readable source data or compact token sequence.
Code example
{
  "profile": "jai.iota-1.message.v1",
  "uai_version": "UAI-1",
  "locale": "en-US",
  "direction": "ltr",
  "normalization": "NFC",
  "registry": "justaniota-demo-registry",
  "payload": {
    "intent": "request_review",
    "subject": "validator_result"
  }
}
Transfer formatOptimized (Keyless) JSON
Code example
[
    "jai.iota-1.message.v1",
    "UAI-1",
    "en-US",
    "ltr",
    "NFC",
    "justaniota-demo-registry",
    [
        "request_review",
        "validator_result"
    ]
]

Field order follows the keyed JSON example, the published schema order, and the public field registry.