Hypler publishes a reviewable VUSL design for Rangoon semantic interoperability

A design publication with narrow claims

Hypler published the VUSL design as a public, reviewable draft. The guide describes a provider neutral vocabulary for capabilities, artifacts, operations, observations, and relationships. Its stated purpose is to preserve meaning and provenance when systems are compared or inspected.

The publication does not announce a stable network protocol, a community standard, or a certified universal interchange layer. It is a design and implementation guide with a clearly bounded first subset.

That wording is deliberate. Semantic interoperability is useful only when readers can distinguish an accepted source fact, a provider report, a proposed mapping, and an unresolved gap. VUSL makes those distinctions part of the document rather than leaving them to an optimistic dashboard label.

Rangoon is the planned owner of local integration

The planned integration places local semantic authoring, lineage, decomposition, composition, revision, compilation, export, and inspection with Rangoon. Rangoon can work locally without requiring LNSAT, OpenShell, or another provider. External systems retain their native identities and enforcement duties.

This is a planned build direction for Rangoon. It is not a connected Hypler production integration, and no production deployment or live provider route follows from the publication.

The ownership split also protects rollback. A future semantic view can be removed or revised without replacing the original O1 or I1 records, changing a provider's authorization decision, or pretending that a local export installed successfully at a target.

The first implementation is an offline Rust subset

The current implementation described by the pinned source snapshot is a bounded Rust JSON inspection library. It accepts supplied bytes, applies the closed D0a observation shape, and returns fixed diagnostics. It does not discover credentials, open a network transport, call an engine, or mount a connected user interface.

The broader document names future semantic families and adapter boundaries. Those sections describe work that may be qualified later. They should not be read as a claim that a general serializer, public SDK, or provider adapter already exists.

The offline boundary is practical as well as cautious. A parser can be exercised with synthetic fixtures and bounded malformed input while keeping network, process, file, credential, and engine behavior out of the acceptance question.

Refusal is part of interoperability

VUSL uses exact wire identifiers, a closed nine key envelope, and explicit size and collection bounds. The D0a candidate caps one document at 131,072 UTF 8 bytes, depth 16, 256 values, 32 fields per object, and 64 entries per array. Oversized or ambiguous input is refused without truncation or guessed recovery.

The profile also omits native bytes and grants no authority. A provider report that says allow remains a report with unknown effect and no authority. That separation matters when a semantic view is shown beside policy, authorization, execution, or telemetry records.

The same discipline applies to identity. Matching display names, timestamps, trace strings, or digests cannot create a cross provider join. A source reference needs the exact system, environment, engine, contract, and native object scope required by the profile.

Native standards keep their jobs

The design names MCP, A2A, OpenTelemetry, Trace Context, and other standards as complementary. VUSL may describe a bounded relationship to one of them through a versioned adapter mapping, but a shared VUSL profile does not negotiate a compatible native protocol, authenticate ingress, or authorize execution.

That choice keeps semantic comparison from becoming a hidden replacement for provider contracts. Compatibility remains qualified per operation and direction, with translation loss made visible.

For operators, this means a VUSL panel can help answer what a source says and how a mapping was made. The native system still answers whether a call was accepted, whether a policy was enforced, whether an effect occurred, and what evidence supports that conclusion.

Next proof gates remain open

The next work requires immutable profile and schema identity, independent cross language parser evidence, qualified host mapping, boundary tests, and separate privacy and credential controls. A future transport would also need its own authentication, isolation, framing, cancellation, ordering, recovery, and redaction contract.

Hypler's current position is deliberately provisional: VUSL is public and reviewable, Rangoon integration is planned, and the source snapshot does not establish a live protocol, stable SDK, connected production route, or universal interoperability claim.

Those gates create a useful roadmap. First prove the closed offline subset. Then qualify individual mappings with exact versions, operation direction, data class, consent, and failure behavior. Only after that evidence exists can a later profile consider a connected host or transport, and that later profile would remain separately versioned from D0a.

Hypothetical example: a team reviews a provider report that says an operation was allowed. It retains the original identity and native version, labels the report as unverified, and records any mapping loss. It does not mark the action authorized or completed. A separate native engine would need to supply its own authorization and outcome evidence before a reviewer could assess those later stages. This example explains the planned review boundary; it is not a connected Rangoon demonstration.

Related capabilities

• SI infrastructure development
• MCP integration and interoperability
• Platform engineering and reliability