Hermes MCP DB Scheme
Hermes uses a compact SQLite schema with one job per table.
1. concerns
What Hermes currently cares about.
- one row per account/market scope
- source tracks where the concern came from (
trader_inventory, hermes_config, manual)
- status marks whether Hermes should actively watch it
2. cycles
One Hermes evaluation pass.
- records the periodic polling loop
- ties observations, derived state, narratives, decisions, and actions together
3. observations
Raw adapter outputs.
- stored once per cycle, concern, and source
- payload remains unparsed JSON
- this is the fact layer, not the interpretation layer
4. states
Derived structured state.
- compact signals like regime, liquidity, sentiment pressure, event risk, execution quality
- one row per cycle and concern
- intended for query and dashboard use
5. narratives
Hermes’ synthesis.
- one row per cycle and concern
- concise human-readable summary plus key drivers, risk flags, and uncertainties
6. decisions
Control intent.
- what Hermes decided or recommends
- can be observe, recommend, or act
- stores target strategy and policy when relevant
7. actions
Outbound effect log.
- what was sent to Trader
- request/response are stored as JSON
- keeps decision and execution separate
8. coverage_gaps
Gap discovery and recommendations.
- missing strategy, market, or account coverage
- keeps Hermes aware of blind spots without conflating them with decisions
Core flow
concern -> cycle -> observations -> state -> narrative -> decision -> action
Coverage gaps are attached to the same cycle and can be linked to a concern when the gap is specific.