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 TreeSnapshotId02
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 trail03
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