Runtime Actor Identity And Authority Contract
Runtime actor identity decides which actor id a tool, client, server, trigger, or persistence flow should read from or write to in each execution mode.
How It Works
The resolver handles local preview ids, authoritative fallback ids, and network ids such as character:{uuid}. Authority state and runtime capabilities decide whether code can write locally, predict locally, request server authority, persist offline, or evaluate triggers.
Editor, standalone, offline, and connected modes use the same identity helpers to avoid string-comparison drift.
How To Use It
Use the resolver instead of hard-coded actor id strings. Decide the write intent first: authoring tool write, local prediction, authority request, offline persistence, or trigger evaluation. Then ask runtime capabilities whether that write is allowed in the current mode.
Invariants
Connected authority should disable local authoritative writes unless explicitly predicted. Local preview ids must not leak into persisted online state. Missing network actor ids should fail clearly before server-owned mutations run.
Debugging
String-comparison drift, stale account or character hints, missing network actor ids, and connected authority disabling local writes are the main failure modes. Use common-proto identity tests as the source of truth for expected capability outcomes.
Examples
An editor preview can write to the local preview actor. A connected client should send an authority request for the network character actor. An offline standalone run can persist locally when the capability matrix allows offline persistence.