These pages describe the system that exists now: its architecture, invariants, change boundaries, and test ownership. Design history and proposals belong in RFCs; user behavior belongs in the user guide.
- Read Architectural invariants.
- Use the domain map in Lance alignment, then read the complete upstream pages relevant to the task.
- Use Testing to find existing coverage and establish a focused baseline before adding or changing tests.
| Topic | Guide |
|---|---|
| Components, authority, and read/write/control flows | Architecture |
| Non-negotiable guarantees and deny-list | Architectural invariants |
| Query planning, traversal, search, and mutation orchestration | Execution |
| Atomic multi-table publication | Write path |
| Crash classification and convergence | Recovery |
| Three-way branch integration | Merge |
| Managed and external Blob boundaries | Blob internals |
| Cluster apply, serving snapshots, and writer ownership | Control plane |
| Bounded graph-batch ingestion | Ingestion |
| Release, wire, storage, and dependency compatibility | Versioning |
| Task | Guide |
|---|---|
| Find the owning suite, helpers, failpoints, and cloud gates | Testing |
| Understand PR and release workflows | CI and releases |
| Change required checks or repository policy | Branch protection |
| Write or reorganize documentation | Documentation guide |
| Review a parser boundary regression example | Camel-case filtering case study |
The workflow YAML, code, and tests are authoritative for exact command lines, serialized fields, constants, and assertions. Developer docs explain ownership and invariants rather than duplicating those details.
- RFC process and registry
- Release notes
- Git history for superseded implementation plans and handoff notes
An implemented RFC records why a decision was made; it does not replace the
current guides above. A roadmap belongs in an issue, not in docs/dev/.