- Create decisions/ directory with 32 numbered ADRs (ADR-001 through ADR-032) extracted from inline DD/SD/ED/SE decision sections - Create open-questions.md with 16 OQs organized by theme, cross-referenced to ADRs, with status tracking (resolved/open) - Create README.md as architecture index with doc table, ADR table, and lifecycle status definitions (draft/reviewed/stable/deprecated) - Replace inline decision sections in all spec docs with ADR reference tables - Replace inline open questions with OQ references to centralized tracker - Update frontmatter: metagraph-module.md, overview.md, sqlite-host.md → reviewed; schema-evolution.md and encrypted-data.md remain draft - DD1-DD10 → ADR-009 through ADR-018 - D1-D8 → ADR-001 through ADR-008 - SD1-SD5 → ADR-019 through ADR-023 (SD5 folded into ADR-006/008) - ED1-ED5 → ADR-023 through ADR-027 - SE1-SE5 → ADR-028 through ADR-032
1.1 KiB
1.1 KiB
ADR-011: Config as Module entry with Literal values
Status
Accepted
Context
Graph type configurations can be general (any valid config at construction time) or specific (frozen values for a particular graph type). The Module format needs to express both.
Decision
The general Metagraph.Config uses Type.Union with defaults for construction-time validation ("any valid config"). Specific graph types freeze config values to Type.Literal, making the config a precise contract rather than a validation surface.
Construction flow: consumer provides a general config → validated against Metagraph.Config → the specific graph type Module freezes the values with Type.Literal.
Consequences
Metagraph.Configaccepts{ type: "directed" | "undirected" | "mixed", multi: boolean, allowSelfLoops: boolean }with defaultsCallGraph.Configis{ type: "directed", multi: false, allowSelfLoops: false }— frozen, no ambiguity- Type narrowing from Union to Literal is explicit in the Module, no builder step needed