NEBULA

NEBULA-CONCEPTS-CANONICAL-MODEL(1)

Nebula Manual

NAMEcanonical model — How Nebula models source control without treating Git as the canonical data structure.
SOURCEnebula/docs/architecture.md
STATUSpre-alpha · protocol in design
01

Three-layer storage

Nebula separates metadata, blob bytes, and retrieval indexes into distinct storage layers with distinct failure domains.

output
Metadata DB
  repos, refs, snapshots, entries, workspaces, changesets,
  proposals, merge intents, policies, environments, integrations

Blob Store
  source bytes, binary files, encrypted private blobs,
  projection bundles, artifacts

Vector DB
  path/hash index metadata today
  future: semantic embeddings keyed by TreeSnapshotId
02

Merge as a protocol operation

Merge in Nebula is modeled separately from Git. It produces a MergeResult with explicit operation records for audit and replay.

output
Proposal
  -> MergeIntent     # Planned composition
  -> MergeResult     # Outcome with new snapshot
  -> Ref update      # Pointer advancement
  -> Operation record # Audit trail
03

Release gates

Release gates control when and how projections can be published. Gates can be immediate, delayed, or embargoed based on policy and approval state.

  • →Immediate: Merge completes the projection immediately
  • →Delayed: Scheduled release with configurable delay
  • →Embargoed: Blocked until explicit release signal