- 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.0 KiB
1.0 KiB
ADR-023: Per-attribute encryption, not per-node
Status
Accepted
Context
Encrypted data could be stored as an entire encrypted attributes blob or as individual encrypted attributes within the node. The choice affects queryability and schema design.
Decision
The EncryptedData schema is a single attribute within a node type's attributes, not the entire node. Per-attribute encryption preserves queryability on non-sensitive fields — a secret node can have unencrypted metadata alongside the encrypted value. The node key (identity) is always readable for queries.
Encrypting the entire attributes column would make queries impossible (can't find "all secrets for client X" if the client reference is encrypted).
Consequences
- Only sensitive payload is encrypted; identity and metadata remain queryable
EncryptedDataSchemavalidates the encryption envelope at write time- Different graph types can have encrypted attributes without special table definitions