Conceptual transport

Milestone 1 defined these conceptual operations without a wire binding. The subsequent experimental HTTP binding now implements them in a loopback-only Go development server, with dependency-first uploads and an object inventory. Hosted networking remains outside milestone 1.

Operation	Meaning
has(id)	Reports whether complete bytes for this ID are present.
get(id)	Returns exact canonical bytes or a missing-object error.
put(id, bytes)	Verifies identity/encoding/schema and stores immutably; identical re-upload is idempotent.
resolve(ref)	Reads the current ID of a supported reference.
update(ref, expected, next)	Atomically compares the current value with expected, then publishes next or reports conflict.

An absent ref is distinct from an empty or malformed ID. expected can represent absence when creating a ref. HEAD is mutable local workspace selection; registry refs are keyed by identity and can only be created or reaffirmed, not retargeted. This does not imply Git branches or arbitrary mutable branch naming.

Synchronization should discover missing IDs with has, traverse canonical references, transfer their missing objects, validate the complete graph, and only then publish references. A receiver can stage valid objects whose dependencies have not arrived yet, but MUST NOT advertise a state as validated until its reachable graph satisfies objects.md. Hash match alone is insufficient.

Evidence, decisions, and operation results are reverse associations. Starting only from a state’s forward references does not discover them. A synchronization session must explicitly advertise these metadata roots or enumerate object IDs, then transfer their dependency closure. A future discovery/inventory binding must specify this; the five conceptual calls alone do not provide enumeration.

Objects are immutable, so independent object uploads can run concurrently. Mutable references require compare-and-swap semantics, not last-writer-wins updates. Failures may leave complete unreferenced objects; partial bytes must never become visible at their final IDs. Receivers enforce size/depth limits and reject hash mismatches, invalid encoding, unsupported versions, and invalid graphs.

The HTTP binding specifies a local bearer credential, public/private reads, inventory pagination and retry behavior. Hosted identity management, encrypted connections, signatures, batching, resumable transfer, remote HEAD semantics and garbage collection remain future work. No authentication or transport security should be inferred from content addressing. AIPHub may implement storage, evaluation and collaboration using this boundary; local AIP remains independently usable.