Files
storage/docs/architecture/decisions/015-edge-constraints-as-named-entries.md
glm-5.1 67ccfbf928 docs: restructure architecture docs to flowgraph pattern
- 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
2026-05-29 07:19:03 +00:00

1.3 KiB

ADR-015: Edge type constraints as named Module entries

Status

Accepted

Context

Edge type constraints (allowedSourceTypes/allowedTargetTypes) could be stored only as DB columns (JSON text arrays) or as first-class parts of the schema with validation and serialization.

Decision

Edge type constraints are named Module entries (e.g., TriggeredEdgeConstraints), not just DB columns. This gives them schema validation (Value.Check) and serialization (JSON Schema with $defs). The repository layer projects these entries to the existing edge_types.allowedSourceTypes/allowedTargetTypes columns. The DB schema doesn't change — Module entries are the source of truth, DB columns are the persistence projection.

Empty constraint arrays [] mean "no restriction" (any node type valid). Omitting the *EdgeConstraints entry means the same. An explicit entry with empty arrays is invalid.

Consequences

  • Constraints are validatable at the schema level, not just at the DB layer
  • moduleToDbSchema() extracts constraint entries to DB columns
  • Constraint data survives serialization/deserialization cycles via JSON Schema $defs
  • DB columns remain allowedSourceTypes text and allowedTargetTypes text with JSON arrays

References