TSO outage data-quality workshop

A small Python workshop for practising reliable, maintainable agentic-AI-assisted delivery.

Note: the use case is fictitious and exists solely to practise the agentic delivery methodology.

The exercise concerns an auditable planned-outage data-quality report. It reads asset and outage-request CSV extracts and will eventually identify invalid requests and duplicate request IDs before the data is used by downstream planning or operational-support processes.

The workshop improves quality, not productivity. Any productivity gain must not reduce reliability.

Safety boundary

This project is a data-quality exercise. It does not approve, schedule, alter, or execute outages. It produces traceable findings for a human process to investigate.

Starting point

The repository intentionally contains only the architecture scaffold, representative CSV inputs, and a command-line interface that runs the structural extract validation. The business behaviour is introduced through tests during the workshop.

• outage_quality/domain/: pure outage and asset value objects (no I/O, no framework)
• outage_quality/application/: use cases, their ports and report contracts
• outage_quality/infrastructure/: CSV and other replaceable I/O adapters
• outage_quality/interfaces/: thin command-line interface
• data/: representative, non-operational CSV examples
• tests/data/: copies of the CSV fixtures used by the automated tests
• plans/: intent and implementation plans for the exercise

Dependencies flow inward:

interfaces -> application -> domain <- infrastructure

Run

uv run validate_extracts
uv run python main.py
uv run pytest -n auto tests/ -v
uv run pre-commit run --all-files

validate_extracts reads data/assets.csv and data/outage_requests.csv, runs the structural extract validation, prints a per-file report, and exits non-zero when any file fails its contract.

Workshop intent

As an outage-planning data user, I want an auditable report of invalid and duplicated planned-outage requests, so that incorrect or conflicting input data is identified before it enters downstream planning and operational-support processes.

The detailed alignment and TDD delivery plan are in plans/.