> ## Documentation Index
> Fetch the complete documentation index at: https://docs.energy.nlead.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit Trail & Process State

> Every run of a delivery day is inspectable, re-runnable and drives change detection

The bridge keeps a deliberately simple, file-based audit trail under
`AUDIT_DIR` — one directory per delivery day:

```text theme={null}
data/audit/2026-07-29/
├── forecast_input.json        # the customer's request, verbatim
├── state.json                 # input hash + hash each process step last ran on
├── positions.json             # production, consumption, net, open, total_open
├── open_position_20260729.csv # exactly what was written to sFTP
└── engrate_submission.json    # schedules, balance check, Engrate response
```

## Why it exists

<CardGroup cols={2}>
  <Card title="Change detection" icon="arrows-rotate">
    `state.json` records which input hash each step last processed — that
    is the entire mechanism behind the orchestrator: a step is stale iff
    its hash differs from the current input hash.
  </Card>

  <Card title="Inspection" icon="magnifying-glass">
    When the trader or a TSO queries a number, the full chain from input to
    submission is on disk, per day.
  </Card>

  <Card title="Re-runs" icon="rotate">
    Re-posting a forecast updates the stored input and hash; the
    orchestrator (or manual step calls) re-runs from there.
  </Card>

  <Card title="No infrastructure" icon="feather">
    Plain JSON and CSV files — no database to operate. In Azure the
    directory is an Azure Files share so it survives restarts and
    scale-to-zero.
  </Card>
</CardGroup>

<Note>
  This is intentionally not over-built: no schema migrations, no retention
  policy yet. If regulatory retention requirements land (e.g. REMIT),
  revisit — the writer is a single small adapter (`adapters/audit.py`).
</Note>