EVOLV/.agents/skills/evolv-database-influx-architecture/SKILL.md

---
name: evolv-database-influx-architecture
description: Design and review EVOLV data modeling and storage architecture for telemetry and dashboard consumption. Use when deciding InfluxDB measurement/tag/field schemas, retention/downsampling strategy, write/read payload structures, and Grafana query compatibility for Node-RED outputs.
---

# EVOLV Database Influx Architecture

## Mission
Shape telemetry data so it is queryable, performant, and maintainable for operations dashboards and analytics.

## Harness Execution Contract
- Start from current measurement/tag/field usage and dashboard queries.
- Define invariants before edits:
  - query compatibility for existing Grafana/consumer flows
  - bounded tag cardinality
  - explicit units and timestamp policy
- Provide validation evidence using representative payloads and queries.

## Scope
- Output payload structure from EVOLV nodes
- InfluxDB write model: measurement, tags, fields, timestamp policy
- Retention/downsampling implications for Grafana visualization

## Workflow
1. Classify data by usage:
- real-time control
- operator dashboarding
- long-term analytics
2. Define stable schema conventions:
- measurement naming
- tag cardinality controls
- numeric fields and units
3. Validate that node outputs map cleanly to write model.
4. Check query ergonomics for expected Grafana panels.
5. Specify retention/downsampling and backfill behavior.

## Design Rules
- Avoid high-cardinality tags for volatile identifiers.
- Keep units explicit and consistent over time.
- Prefer additive schema evolution; document breaking changes.
- Include timestamps that are consistent across nodes.

## Test/Validation Expectations
- Verify sample payloads produce intended point shape.
- Check representative queries for latency and result correctness.
- Include migration strategy when schema changes are unavoidable.

## Deliverables
Return:
- proposed schema (measurement/tags/fields)
- rationale tied to dashboard and analytics use
- changed files/tests
- migration and retention plan

Decision interview triggers:
- schema changes that break existing queries/panels
- retention/downsampling policies with data-loss tradeoffs
- backfill rules that alter historical comparability