This note captures the working model for Hermes as discussed in chat.
Hermes sits above Trader, Crypto, Metals, and News. It observes the world, evaluates coverage, derives state, forms a narrative, makes a decision, and then optionally acts on Trader.
Hermes is read-mostly and explainable. It should not become a trading engine itself.
Hermes runs in cycles.
Each cycle answers:
Concerns define what Hermes watches.
Examples:
Concerns can come from:
Hermes should mirror Trader coverage, but in v1 it should not create instances automatically.
Primary sources for v1:
Later sources:
For each concern, Hermes polls the relevant adapters.
Example:
Hermes stores raw adapter outputs as observations.
This layer is factual and should not interpret anything.
Hermes converts observations into compact state fields.
Examples:
Hermes writes a short explanation of the current picture.
The narrative should be human-readable, but still structured enough for dashboards and debugging.
Hermes decides one of the following:
If acting, Hermes may send a control command to Trader.
Hermes logs the outbound action and the response.
Decision and execution must remain separate.
If Hermes finds missing coverage, it records a gap and recommendation.
This is important and should not be merged into decisions.
The SQLite schema should keep these layers separate:
Start with:
That gives Hermes a real spine before we add more inputs.
Do not store the same idea twice. Raw facts, derived state, prose, and control intent all belong in different places.