Nebula stores source state as content-addressed objects in a durable graph. Git and deployment platforms are compatibility projections of this graph, not the source of truth.

Galaxy
  Ref          # Named pointers to snapshots
  TreeSnapshot # Versioned file tree structure
  ContentBlob  # Source bytes keyed by content hash
  Workspace    # Isolated work context for agents or humans
  ChangeSet    # Delta between two snapshots
  Proposal     # Reviewable collection of changesets
  MergeIntent  # Planned composition into a ref
  Policy       # Access and visibility rules
  Projection   # Policy-aware export to Git/deployment
  VectorIndexManifest # Snapshot-keyed retrieval index

Blobs are stored by their content hash, not by path. This enables deduplication, integrity verification, and efficient snapshot incrementalism.

• →Content hash determines storage key
• →Identical content across files or repos shares storage
• →Snapshots reference blobs by hash, not by value

Refs point to snapshots, not commits. The distinction matters: a Nebula ref is a stable, named pointer that can be moved through merge operations.

# Git ref points to commit
main -> abc123 (commit)

# Nebula ref points to snapshot
main -> snapshot:xyz789

Nebula workspaces are isolated work contexts, similar to feature branches but with richer state. A workspace tracks its own snapshots, can have multiple active proposals, and can be switched without affecting other users.

• →Each workspace has independent snapshot history
• →Multiple proposals can be open per workspace
• →Switching workspaces updates the active pointer only
• →Workspaces can be created from any snapshot