Assumptions & Invariants Ledger

Assumptions are things the project relies on that could be false. If violated, specific parts break. ### A-001: PostgreSQL is the only graph store **Assumption**: All turns and edges live in PostgreSQL, accessible via `GraphStore` trait. **What breaks if false**: Slice SQL queries won't work, connection pool assumptions fail. **Detection**: Attempt to use a different store → compile-time error (no other `GraphStore` implementations in production). **Mitigation**: Keep `GraphStore` trait abstract, avoid Postgres-specific SQL in core types. ### A-002: Content hashes will reach 100% coverage **Assumption**: The incremental backfill will eventually give every turn a `content_hash`. **What breaks if false**: `GraphSnapshotHash::from_content_hashes` can't be used universally, replay is less reliable. **Detection**: Monitor `SELECT COUNT(*) FROM memory_turns WHERE content_hash IS NULL` → should trend to zero. **Mitigation**: Keep stats-based fallback until coverage >= 99%. ### A-003: HMAC secret is 32+ bytes and never rotates **Assumption**: The `KERNEL_HMAC_SECRET` is strong and stable across restarts. **What breaks if false**: Token verification fails for old slices, replay breaks. **Detection**: Token verification failures spike after secret rotation. **Mitigation**: Document secret rotation requires re-slicing, or implement multi-key verification. ### A-004: Downstream services trust kernel tokens without re-verification **Assumption**: RAG++ and Orbit check `admissibility_token` but don't re-verify HMAC locally. **What breaks if false**: Performance degrades (double verification), but security improves. **Detection**: Check if downstream code calls `/api/verify_token` or does HMAC locally. **Mitigation**: Make token verification cheap enough (<5ms) that double-checking is acceptable.