One model, local or remote Runtime

Documentation status: architecture. Compactness and target support are evidence-backed claims only when a benchmark/platform record exists.

The useful architectural invariant is not a size number. It is that application code can depend on the same conceptual/public contract while Runtime placement changes below it.

Generated API
  -> IClientRuntime
     -> local adapter -> ABI -> Runtime
     -> remote adapter -> RPC -> Runtime

A proof scenario for constrained deployment should use the same business model in both placements: load the model, request a published action, let a declared rule accept or reject it, capture the conceptual trace, then run the same contract against a remote/server placement.

What this proves depends on measured evidence. Do not turn a demonstration on one device into a generic superiority claim. Record startup time, resident memory, disk footprint, dependency set and capability gaps only under a named protocol.

For application developers, placement should stay below business services unless locality itself is part of the business requirement.