DreamDB v0 — Spec Index

A single navigable entry point for the DreamDB v0 specification. Maps every Open Question (OQ) to its owner and disposition and points at every spec document.

The 28 Spec Documents

Read the foundational documents first, then the relevant capability. Later owning sections refine earlier summaries; document number alone is not a blanket override. A conflict must be corrected or explicitly recorded, not silently resolved by order.

| 26 | spec/0026-entity-keys.md | Optional typed logical keys, stable entity identities and random revision tokens; mandatory lineage-v4; atomic Sample/tombstone/index publication; conservative divergent-key merge refusal — normative v1 | | 27 | spec/0027-progressive-geometry.md | Item-internal point/splat cells, packed payloads, paged hierarchy and discrete mesh LODs; authenticated incremental range reads — normative v1 |

Status and counting rules

This reconciliation is updated through main 213d948 (2026-09-10); it is not a live CI or release-status feed.

• Draft describes document maturity, not the absence of implemented code. Existing normative sections retain their obligations; a proposal does not become a supported capability merely because another section has shipped.
• Normative / Accepted means the stated contract is adopted within its scope. It does not imply every SDK implements it. For example, 0019 has a normative encryption format but no reference Dataset writer/reader.
• Implemented must name a capability and boundary. Shared Rust code exposed through Python/WASM is not independent-implementation agreement.
• Resolved OQ means the owning document gives the decision. Implementation, portable conformance, performance and deployment can remain separate work. A proposed answer or a test-category name alone is not closure.
• Performance examples are informative under 0023. Unbound test counts and historical benchmark-progress snapshots are not maintained here.

16 documents retain a Draft header: 0000–0009, 0014–0018, and 0023. This revision does not promote them wholesale. The other 12 are: 0010, 0011, 0013, 0019–0022, and 0026–0027 (Normative within their stated scope), 0012 and 0024 (Implemented), and 0025 (Accepted). Read the owning status paragraph for deferred subfeatures, notably QINCo, encryption runtime, compressed Fresh graphs and consumer freshness scheduling.

Open Questions: complete ledger

There are 104 distinct OQ identifiers: every numeric identifier OQ-1 through OQ-102 (none unused), plus OQ-PP1 and OQ-PP2 in 0023.

• Numeric questions: 77 resolved, 25 open.
• Named performance questions: 0 resolved, 2 open.
• Combined: 77 resolved, 27 open.

The six compatibility dispositions in the review record are recorded separately, without allocating new OQ identifiers. Their remaining feature/conformance limits do not silently add to or subtract from these totals.

Open: owner and functional area

“Open” includes deferred decisions and unfinished capability-specific conformance. The owner below is where a resolution must land, even when an earlier document originally raised the question.

Resolved: decision and owning contract

Each identifier appears once in this disposition table. A group shares an owning contract, not necessarily a delivery milestone.

Historical numbering

Keep these old references interpretable; do not reuse their numbers.

The original 0010 OQ-44–47 and 0012 OQ-48–49 retain their numbers. OQ-PP1/PP2 retain their published named identifiers rather than being silently renumbered into the numeric series.

Cross-cutting reading rules

See the reconciliation record for corrected contradictions and compatibility dispositions with their remaining limits. See README.md for usage; current release/CI evidence belongs with its exact commit and report, not a floating “all tests green” count in this ledger.