RPC transport over ABI identity

Documentation status: architecture — see Maturity and evidence.

The RPC layer is designed as a remote facade over the same ABI-facing invocation identity used locally. It is not a second object model.

A request can carry:

abiVersion
TypeId / MethodId
TypeName / MethodName
InstanceId
CallKind
ReturnWireType
ReturnTypeId / ReturnTypeName
Arguments
Metadata

Metadata includes session and correlation identifiers, timeout, ABI version, client identity, caller kind, authentication token, and send time.

Object references

Remote runtime objects are represented by object references containing an InstanceId, TypeId, TypeName, and an expiration timestamp. The dispatcher resolves the instance reference to a native handle and enforces session ownership for stateful calls.

Remote release is explicit: a release request resolves the leased object and invokes the native release path before removing the lease.

Discovery and compatibility

The RPC model includes discovery information with Runtime version, ABI version, supported modes, roles, capabilities, and authorized capabilities. Authorized capabilities can be associated with TypeId and MethodId.

This provides a basis for generated clients to negotiate what the endpoint can execute rather than assuming that every generated member is remotely available.

Health and metrics

The RPC source also defines health and runtime metrics, including call/failure counts, active/released/expired leases, validation failures, HTTP status counts, latency totals/averages, and uptime.

Current maturity

The dispatcher identifies itself as a native/local embedded Runtime over ABI with an RPC facade and advertises native and RPC modes. That is strong architectural evidence for local/remote symmetry.

This page remains architecture because the inspected sources establish the transport and dispatcher model, not a complete public compatibility guarantee for every generated value kind and every binding.