Audit Trail & Process State

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

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

Change detection

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.

Inspection

When the trader or a TSO queries a number, the full chain from input to submission is on disk, per day.

Re-runs

Re-posting a forecast updates the stored input and hash; the orchestrator (or manual step calls) re-runs from there.

No infrastructure

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.

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

⌘I

Implementing the Service

Running the Service

Reference

Internal API

Why it exists

Change detection

Inspection

Re-runs

No infrastructure

​Why it exists

Change detection

Inspection

Re-runs

No infrastructure

Why it exists