# 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, jou…

<!-- SOURCE: docs/KINRA-OS-PEER-PROTOCOL.md, src/kin/peer_protocol/, src/kin/peer_service/ -->

The full normative contract lives in
[KINRA-OS-PEER-PROTOCOL.md](https://github.com/kinra-ai/kin/blob/dev/docs/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](/docs/kin/protocol/) 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](https://github.com/kinra-ai/kin/tree/dev/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](https://github.com/kinra-ai/kin/tree/dev/tests/test_peer_protocol)
proves the complete lifecycle and hostile inputs.

The typed, socket-free execution boundary under
[src/kin/peer_service](https://github.com/kinra-ai/kin/tree/dev/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](https://github.com/kinra-ai/kin/tree/dev/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](https://github.com/kinra-ai/kin/blob/dev/docs/KINRA-OS-PEER-PROTOCOL.md#16-future-kinra-os-kinpeeradapter-handoff).
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.

_Source authority: Kinra Site (src/content/docs/kin/KINRA_OS_PEER_PROTOCOL_INDEX.md)._