Kinra OS Peer Protocol v1

The full normative contract lives in KINRA-OS-PEER-PROTOCOL.md. Kin owns the Peer behavior and wire. Kinra OS owns its office, context, capabilities, dispatch, consequence classes, proposals, approvals, artifacts, journal, memory, browser, and every human authority.

This is a distinct authenticated HTTPS and NDJSON boundary. It is neither the Outpost service API nor the Rig computer protocol.

What v1 carries

• authenticated service and instance identity plus explicit major-version negotiation;
• bounded health, readiness, and protocol-capability discovery;
• one non-queued turn with a bounded prompt, exact ContextFrame, and only Kinra OS-supplied strict capability descriptions;
• ordered AssistantText streaming, including non-empty formatting chunks;
• at most one ProposeOperation per model round;
• exact PeerToolResult continuation before the next round;
• cancellation and exactly one TurnComplete or TurnError within the bounded stream, with the final event slot reserved for that terminal;
• one exact pre-output retry and explicit degraded behavior; and
• canonical closed JSON with fail-closed replay, Unicode, bound, redirect, disconnect, and terminal-order checks.

Authority boundary

The Peer can describe or propose a capability. It cannot dispatch, approve, classify human authority, expand the catalog, or claim to speak for the human. No Kin memory, credential, grant, session journal, live Session, terminal history, Outpost state, or Rig authority crosses the protocol. No Kinra OS state becomes a Kin journal or memory.

Executable evidence

The typed stdlib leaf under src/kin/peer_protocol contains the strict codec, lifecycle validator, metadata-only projection, and model-free reference Peer. The hermetic suite under tests/test_peer_protocol proves the complete lifecycle and hostile inputs.

The typed, socket-free execution boundary under src/kin/peer_service drives an injected model round stream through that exact codec and lifecycle machine. Its in-memory route dispatcher and tests/test_peer_service prove all five routes, exact receipt continuation, cancellation of upstream work, single-turn refusal, and metadata redaction without a credential, provider selection, listener, deployment, or Kinra OS runtime dependency.

KinPeerAdapter handoff

The future adapter checklist is normative section 16. In short, the adapter must validate and pin the authenticated Peer identity, map the seven local semantic types field-for-field, supply only its sealed registry’s Peer-eligible model tools, let the Kinra OS runtime own dispatch, return the exact local receipt, enforce one active turn, cancel on disconnect, degrade without damaging the office, and log only the allowed metadata projection.

Production service hosting, credential/TLS provisioning, standalone leaf packaging, model-driver selection, and representative live-inference qualification remain open. Version 1 adds no Cloud appointment or failover behavior.