How SEIF works

SEIF is git and Docker for AI context: sovereign workspaces, Pods that orchestrate them, and an engine CAS you can verify in public.

View diagram source (Mermaid)

flowchart TB
  Account --> Pod
  Pod --> Umbrella[Umbrella image]
  Pod --> Standalone[Standalone image]
  Pod --> Compose[Compose-image]
  Umbrella --> Store[".seif/ store"]
  Store --> CAS[Engine CAS]

Workspace image

Umbrella image — one canonical `.seif/` store, many pinned git members (e.g. seif-projects).
Standalone image — its own `.seif/` and cycles; not a member of an umbrella.
Compose-image — lives under a Pod; isolated `.seif/` per image in the manifest.
Marked by `workspace.seif.json` (SEIF-WORKSPACE-v2) at the image root.

Try workspace in the Demo

Three workspace image types: umbrella, standalone, and compose-image

Pod orchestrating workspace images across Mini, Air, and Windows hosts

Pod

Groups multiple workspace images under one host directory.
`.seif-pod/` holds compose copy + `nucleus_ref.json` per image — not their sovereign data.
Multi-host: Mini writer, Air observer, Windows test — same Pod, different machines.
Run `seif compose push` to refresh pod refs and child nuclei.

Try Pod overview in the Demo

Object model

Hierarchical tree-of-trees under `.seif/` (cycles, memory, modules…).
Nucleus root anchors the workspace; gates run before finalize.
Engine stores content-addressed blobs in CAS — pull by hash, verify by evidence.
Browse the live-shaped tree in the demo Objects tab.

Browse object model in the Demo

Merkle object model from blobs and trees to nucleus and Engine CAS

Evidence

Signed artifacts live in your workspace evidence list.
Logged entries expose `/{workspace_fp}/sync/{log_entry_id}` — no login required.
RFC-6962 inclusion proof + gate verdicts on the verify page (when log is wired).
Local-only evidence stays local — no false public verify affordance.

See signed artifacts in the Demo

Local store vs Engine CAS

Local `.seif/` is sovereign on your disk — you own the store.
Engine workspace id (`ws_*`) names the remote CAS bucket after `seif push`.
Pod paths use `stores/pod/{pod_id}/` when compose sync is enabled.
Neon holds auth and refs; blobs live in R2 — web never parses `.seif/` in the browser.

Read technical docs

Relationship between local .seif sovereign store and remote Engine CAS

At a glance

	Workspace image	Pod	Engine CAS
Git / Docker analog	Git repo / project	docker-compose stack	Container registry (CAS)
What it owns	`.seif/` sovereign store + nucleus	`.seif-pod/` refs + N workspace images	`stores/workspace/{ws_id}/` blobs
Typical use	One team, one scope (umbrella or standalone)	Multi-host, multi-workspace orchestration	Sync target after `seif push`

Demo: workspace →Demo: Pod →Explore log →

Why SEIF, not…

Claude ProjectsClaude Projects — Per-vendor, per-conversation. SEIF persists across agents and machines; you own `.seif/`.

Cursor RulesCursor Rules — Static prompts in one IDE. SEIF modules are signed, classified, audit-logged artifacts.

Copilot WorkspaceCopilot Workspace — Repo-scoped, no transparency log. SEIF spans repos and produces regulator-grade evidence.

Join the Waitlist Try Pod demo Technical docs