A regulated-domain system for modelling, validating, and issuing UK electrical inspection and certification artefacts in accordance with BS 7671.

This project is part of the RossEngineering organisation and represents a focused exploration of system design, correctness, and long-term maintainability within a compliance-driven domain.

Electrical certification under BS 7671 is not primarily a UI problem or a document-generation problem.
It is a correctness, consistency, and traceability problem operating under regulatory constraint.

This project exists to explore and demonstrate:

• How inspection and certification workflows (EIC, MEIWC, EICR) can be modelled as explicit, testable domain processes rather than ad-hoc form filling
• How validation rules can be expressed as data and evaluated deterministically, rather than embedded implicitly in UI or controller logic
• How systems operating in regulated environments can remain maintainable as standards evolve

What distinguishes this project from others in the organisation is its emphasis on domain correctness over feature breadth, and on long-term comprehensibility over short-term convenience.

The project intentionally prioritises clarity of behaviour and reasoning over novelty, speed of delivery, or surface-level polish.

• Explicit behaviour over implicit magic
• Clear separation of domain, application, and delivery concerns
• Defensible, boring architectural choices where possible
• Extensibility without conditional sprawl
• Systems that remain understandable as rules, schemas, and standards evolve

Where trade-offs exist, preference is given to predictability and auditability over abstraction or cleverness.

• Type: Platform / Reference Implementation
• Runtime: .NET (backend), Flutter (client)
• Data: Structured relational storage + versioned JSON contracts
• Authentication: Out of scope for core domain (delivery concern)
• Deployment target: Local development and containerised environments

The architecture is intentionally structured to keep domain logic isolated from delivery mechanisms, enabling the same core rules and workflows to be exercised via different interfaces without duplication or drift.

src/
api/ # .NET API solution (Domain/Application/Infrastructure/Api/Tests)
app/ # Flutter client (offline-first MVP scaffold)
tests/
docs/
contracts/ # Versioned schemas and validation rules

Exact structure may evolve, but boundaries are intentional and enforced.

• .NET SDK (current LTS)
• Flutter SDK
• Docker (optional, for containerised development)

dotnet run --project src/api/Bs7671Certifier.Api

API health check:

curl http://localhost:5080/health

Backend tests:

dotnet test src/api/Bs7671Certifier.sln

API example: GET /jobs

Request:

curl http://localhost:5080/jobs

Example response:

[
  {
    "jobId": "8fd6c16b-b6ac-45d8-95f8-51352edd98ca",
    "certificateType": "EIC",
    "payloadJson": "{\"client\":{\"name\":\"ACME Ltd\"},\"site\":{\"address\":\"10 Long Street\"}}",
    "createdAtUtc": "2026-02-09T18:45:32.1203741+00:00",
    "updatedAtUtc": "2026-02-09T18:45:32.1203741+00:00"
  }
]

cd src/app
flutter create .
flutter pub get
flutter run

The client calls the API at http://localhost:5080 in development and bundles a local copy of rule/schema contracts from src/app/assets/contracts.

Configuration is intentionally minimal.
Any required environment variables or local overrides are documented inline or in /docs.

This project deliberately avoids:

• Acting as a fully compliant, scheme-endorsed commercial product
• Encoding regulatory interpretation beyond widely accepted industry practice
• Optimising for rapid feature expansion or UI completeness

These constraints are intentional and help keep the system focused on its core purpose.

Active development (experimental)

Work is driven by design clarity, correctness, and learning value rather than delivery timelines.

• Modelling of regulated workflows as explicit domain processes
• Data-driven validation and rule evaluation
• Offline-first system design with synchronisation boundaries
• Long-term maintainability strategies for evolving standards
• Clear architectural separation in a non-trivial problem space

This repository follows the RossEngineering contributing guidelines.
See CONTRIBUTING.md for details.

MIT Licence

• Keep changes small and intentional
• Prefer documentation and tests over clever abstractions
• Make domain behaviour explicit, even when verbose
• Revisit assumptions as standards, requirements, or understanding evolve