Skip to content
Docs for briefcase-ai v3.3.0see what’s new.

How oci-bai Works

oci-bai has two pieces: a gateway and an artifact graph server. Every OCI push goes through the gateway; the server builds and serves the graph.

The push pipeline

docker push localhost:8080/my-repo:v1
OCI Gateway ← any docker push / crane push
│ records manifest, files, derivation edges
Artifact Graph ← commit DAG, dedup store, SBOM index
│ indexes packages, weight format, CUDA version
Search / CLI ← oci-bai log / diff / search / provenance
  1. Gateway receives the push, computes content-addressed chunks, and calls the graph server.
  2. Graph server writes a commit: manifest digest, derivation links (inferred from shared layers or declared via cohort push), and the file tree.
  3. Indexers run asynchronously: package extraction, model-weight detection (safetensors, GGUF), telemetry (imports, syscalls) when available.
  4. CLI reads from the graph server over gRPC — no separate data store.

Deduplication

When you push fifty fine-tunes of the same base model, only the novel content-addressed chunks are stored. The weight-sharing percentage the CLI and dashboard report is derived from how many chunks the candidate shares with its parent commit.

Shared %Meaning
≥ 90%Same checkpoint — re-uploaded or tag change
50–90%Partial fine-tune — adapter or head-only update
5–50%Significant retraining
< 5%Full fine-tune — all weights retrained

Engine seam

The CLI speaks to the graph server over gRPC with server reflection — no generated stubs required. Set OCI_BAI_SERVER to point at a non-local instance.

Delegation mapping

CLI commandWhat runs
oci-bai log <ref>Graph server: commit DAG walk
oci-bai diff <v1> <v2> --depth benchGraph server: benchmark verdict delta
oci-bai provenance <ref>Graph server: derivation tree
oci-bai search <query>Graph server: catalog query
oci-bai whodepends <ref>Graph server: reverse derivation walk
oci-bai attach-bench <ref>Graph server: write benchmark verdict record
oci-bai hunt <ref>verdictml HuntEnv episode