# 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.