Interfaces and shared access

The console and graphical client make the running system accessible to its operator. They present state, accept commands and connect local input and display mechanisms to the runtime. Model execution, memory selection and authoritative transitions remain on the GPU, so an interface can change its presentation without changing who owns the underlying state.

Tool use follows an explicit permission path. The selected configuration, applicable role or operator grant, and installed capability determine which actions are available. An operator's direct command and a tool requested during generation enter through their respective controls.

Supplied-context inference accepts the messages provided with a request and returns output generated on the GPU. It leases an available execution slot for that work and releases the slot on completion. This mode suits applications that manage their own conversation context and need a bounded inference operation.

The gateway provides model discovery, capability reporting, JSON or streamed completion, native request status and cancellation of an exact request. Supported image and audio inputs use the processing assets and device consumers associated with their model configuration.

The caller controls the submitted context. This operation does not establish a persistent cognitive conversation, publish inferred memory or execute the operator's server tools. Applications that need continuing identity and scoped memory use the shared service contract.

Continuing service binds authenticated participants to persistent spaces and conversations. Each conversation has a durable identity, ordered input and working memory state. Execution slots are leased for active work, allowing the conversation to outlive a connection or a particular period of GPU activity.

Scope determines how that history is used:

• Private spaces admit explicitly named members.
• Room spaces support configured sharing among their members.
• Instance scope serves currently admitted participants under its own rules.

Creating a broader space leaves existing private memory within its original scope. Publication into a wider scope is a separate recorded operation with provenance. Recall is assembled from admitted access and recorded state, rather than from a participant's textual claim about their role.

Persistent operation identities and receipts support reconnection. A retry can recover a saved terminal result without repeating its effects. An admitted operation whose result was not saved becomes interrupted after recovery; the client can then decide how to proceed explicitly. Streamed output is observed as it arrives, while durable completion establishes the recoverable outcome.

The host gateway handles HTTP transport, authentication, bounded message framing and media transfer. The device independently checks admission against the installed principal and grant configuration. Those grants cover the requested action, selected model, resource allowance and access to returned state.

Authentication and remembered identity serve different purposes. A memory may describe a participant, but a credential establishes the identity of the current connection. Deployment credentials, tool roots and local trust grants therefore remain external to a portable CCIR. A destination supplies its own authority when it activates the saved runtime.

The gateway and core operate within a configured host trust boundary. Service grants constrain protocol operations; host account permissions and deployment controls govern the surrounding machine. Keeping those responsibilities explicit lets an operator expose the intended service while retaining control over local tools and native code.