These are not concept papers. GridProbity and OsciProbity are working MVPs (Minimum Viable Product) — two real power-system intelligence tools built by a single IT professional, using AI capability under deliberately different methodologies. One was built quickly, in flow, shaped by iterative "vibe coding". The other was built deliberately and methodically, with every behavior defined in a specification before a single line of code was written.
Both work. Above all, they demonstrate what a single individual or a small team can now build independently with the right AI tools and domain knowledge.
One engineer. Two enterprise-grade MVPs. AI as the force multiplier.
GridProbity and OsciProbity 2.0 were designed, architected, specified, and built entirely by a single person, augmented by AI coding tools. There was no development team, no dedicated QA, and no separate architects or UI designers. AI handled what previously required scale: the volume of code, the breadth of implementation, and the consistency of patterns. The domain knowledge, methodological choices, architecture, design, and engineering judgment remained human.
Unified Real-Time Power Grid Monitoring & Predictive Analytics Platform
Positioning
GridProbity is a full-stack power grid monitoring and predictive platform that reimagines what SCADA can be, moving beyond the dense, 1970s-era control-room UI. It is built using a transformative, vibe-driven pattern where AI agents and domain expertise move together in flow, letting architecture emerge from rapid iteration rather than upfront design. AI-assisted coding, modern web technologies, refined Python libraries, and data tooling augment parts of the classic SCADA stack, while engineering judgement and protection-domain knowledge stay firmly human. The result is a minimum-viable platform that one person built with the speed and confidence that previously required a team.
What It Does
GridProbity integrates real-time PMU (Phasor Measurement Unit) data streaming, advanced state estimation, Bayesian predictive modelling, network topology analysis, and power flow calculations into a unified monitoring environment for grid operators and analysts. It presents live grid state, voltage stability indicators, and alert conditions across a multi-view HTML dashboard, with a dedicated operator view, an enhanced analytics dashboard, and a PE (protection engineering) validation interface.
Watch on YouTube
GridProbity Monitoring and Predictive Analytics — full walkthrough recording.
Continuous real-time state estimation and voltage stability monitoring give control-room teams an always-current view of grid health — enabling faster, more confident decisions before faults escalate into outages.
A single platform consolidates bus-level measurements, network topology, power-flow calculations, and contingency analysis — eliminating the need for multiple siloed tools and giving engineering teams one authoritative source of truth.
An open-standards streaming layer capable of ingesting data from 0.1 Hz to 60 Hz — delivering sub-second grid-state updates to dashboards, operator panels, and connected analytics tools through documented API interfaces.
The platform ships as a self-contained, containerised stack that stands up in a single command — reducing time-to-value from weeks to hours and scaling from a single-server pilot to a load-balanced production environment without architectural changes.
GridProbity was developed using a transformative, vibe-driven coding pattern. The architecture was not specified upfront — it emerged through fluid collaboration between domain knowledge and AI multi-capabilities. Features were built in the order that felt most natural; the stack was chosen for immediacy (Vanilla JS, no framework overhead); and the UI was refined visually before being defined structurally. The AI agent functioned as a high-autonomy co-pilot, generating large sections of feature code shaped by domain knowledge. Architecture artefacts were authored after the fact to capture what was built.
Backend — Python 3.8+
| Layer | Technology | Purpose |
|---|---|---|
| Web Framework | FastAPI + Uvicorn (ASGI) | REST API + WebSocket server |
| Numerical Core | NumPy, SciPy | Array operations, signal math |
| Grid Modelling | pandapower | Power system load flow, network topology |
| Streaming Ingestion | Apache Kafka | Real-time PMU data stream |
| Visualisation | Matplotlib | Server-side plotting and analytics |
| Notebooks | Jupyter | Exploratory analysis, scenario prototyping |
| Data Validation | Pydantic | API schema validation |
Frontend
| Layer | Technology | Notes |
|---|---|---|
| UI | Vanilla JS ES6+ / HTML5 / CSS3 | No framework — lightweight, direct DOM |
| Real-time | WebSocket API (native browser) | Live data feed from backend |
| Build | Static files — no bundler | Served via Python HTTP server or Nginx |
Infrastructure
| Layer | Technology |
|---|---|
| Containerisation | Docker Compose |
| Production proxy | Nginx |
| Cloud deployment | Fly.io, Render |
| Dev environment | VS Code Dev Containers |
Power-System Oscillation Detection Engine
Positioning
OsciProbity 2.0 is a precision oscillation detection and probability-scoring engine built by a single researcher under a strict spec-driven, architecture-first methodology. Every module, every algorithm parameter, every API contract, and every database schema was fully specified across 27 specifications — before a single line of implementation code was written. The AI agents generated code from these specs, producing output that is verifiable, traceable, and structurally sound.
What It Does
OsciProbity 2.0 ingests real-time PMU data at 200 Hz and runs two parallel detection engines: Inter-area Electro-mechanical oscillations (0.05–4.0 Hz) and IBR Converter Interaction oscillations (4.0–40.0 Hz). Both engines execute an ensemble of six modal identification algorithms — Prony, ERA, ESPRIT, SSI, HTLS, and Matrix Pencil — synthesising outputs into a single confidence-scored probability result. An LLM intelligence layer then generates natural-language intelligence, interpreting events and narrating artefact significance — so DSP (Digital Singal Processing) outputs are legible to both engineers and non-specialist operators.
Watch on YouTube
OsciProbity 2.0 oscillation dashboard — full walkthrough recording.
Simultaneous IEM and ICI probability readouts, mode frequency and damping displays, and real-time confidence indicators — all specification-defined and contract-traced. The modular design enables addition of further detector types in the future, such as sub-synchronous control interaction (SSCI) events.
AI-powered natural language summaries of oscillation events, modes, forensic graphs, and artefacts — bridging DSP output and operator understanding. Runs on a standard 8-core CPU with 32 GB RAM in a fully air-gapped deployment, with no external API calls or third-party dependencies.
Per-algorithm mode contributions visible alongside the synthesised result. Not hidden in a black box. Every data point has a tooltip showing confidence, algorithm source, damping ratio, and mode frequency.
OsciProbity is built from the ground up for highly regulated and risk-averse organisations. Every decision, signal, and output is contract-traced, logged, and reproducible — giving compliance teams, auditors, and safety reviewers a complete, unambiguous record of system behaviour.
OsciProbity 2.0 was developed using a requirements, architecture, design, and spec-driven methodology — four phases completed before any implementation code was written.
Shared system requirements were elicited from grid engineering first principles, translated into numbered functional requirements covering every detection behaviour.
System topology, component decomposition, and module boundaries defined and frozen. Two detectors dual-engine architecture established at this stage.
API contracts, data schemas, algorithm recipes, and UI wireframes fully designed and reviewed across 27 documents. LLM intelligence layer specified.
Each design artefact hardened into a normative spec with a formal amendment protocol. Only then did code generation begin — AI producing implementation verifiable against spec, not developer intuition.
Backend — Python 3.11+
| Layer | Technology | Version | Purpose |
|---|---|---|---|
| Web Framework | FastAPI | 0.111.0 | REST API + ASGI server |
| ASGI Server | Uvicorn | 0.29.0 | Production server |
| ORM | SQLAlchemy | 2.0.30 | Async database access |
| Migrations | Alembic | 1.13.1 | Schema version control |
| DB Driver | asyncpg | 0.29.0 | Async PostgreSQL |
| Data Validation | Pydantic | 2.7.1 | Schema enforcement |
| Config | PyYAML | 6.0.1 | Spec-governed YAML config |
| Serialisation | PyArrow | 16.0.0 | Parquet artefact storage |
LLM Integration
| Layer | Technology | Role |
|---|---|---|
| LLM Role | Oscillation event intelligence | Generates natural language descriptions of detected events, modes, and artefacts |
| Integration Point | Post-DSP layer | Receives structured DSP output; produces operator-readable narrative |
| Deployment | Local / on-premise | No cloud API dependency — runs fully offline |
DSP & Scientific Engine
| Library | Version | Role |
|---|---|---|
| NumPy | 1.26.4 | Array operations, FFT |
| SciPy | 1.11.4 | Signal processing, optimisation |
| pandas | 2.2.2 | Windowed data management |
| scikit-learn | 1.4.2 | DBSCAN clustering for mode ID |
| statsmodels | 0.14.2 | Granger causality, statistics |
| EMD-signal | ≥1.6.4 | Empirical Mode Decomposition (HHT) |
| vmdpy | 0.2 | Variational Mode Decomposition |
| ssqueezepy | 0.6.5 | Synchrosqueezing transform, ridge detection |
| PyDMD | 0.4.1 | Dynamic Mode Decomposition, ERA, Matrix Pencil |
| joblib | 1.4.2 | Parallel algorithm execution |
Frontend
| Layer | Technology | Version | Notes |
|---|---|---|---|
| UI Framework | React | 19.2.6 | Component-based, spec-mapped |
| Routing | React Router DOM | 7.15.0 | Contract-defined routes |
| State | Zustand | 5.0.13 | Lightweight, typed store |
| Build | Vite | 7.3.3 | Fast HMR dev + production build |
| Language | TypeScript | 5.4.5 | Type safety across all contracts |
| Testing | Vitest | 3.2.3 | Unit + integration tests |
| DOM Testing | Happy-DOM | 20.9.0 | Headless DOM for Vitest |
| API Mocking | MSW | 2.3.1 | Contract-faithful API mocking |
Both GridProbity and OsciProbity 2.0 have been demonstrated to power system domain experts and IT professionals. The response was positive: the tools were recognised as technically credible, practically relevant, and meaningfully differentiated from existing vendor offerings. What made the reception particularly significant is the context: both tools were built entirely by one person with domain knowledge, augmented by AI. Expert feedback confirmed that the depth of implementation — the dual-band IEM/ICI architecture, the ensemble algorithm design, the LLM-generated event narrative, modern UI of Grid monitoring — is indistinguishable from team-scale engineering effort.
Domain knowledge. The same AI tools. What changes when you build with discipline versus flow? The table below captures the most significant differences observed across both builds — not as a verdict on which is better, but as an honest account of what each approach costs and what it produces.
| Dimension | GridProbity Transformative Build | OsciProbity 2.0 Spec-Driven Build |
|---|---|---|
| Build initiation | Started from a working concept; evolved in motion | Started from requirements elicitation; nothing coded until specs were complete |
| Architecture | Emerged through iteration; captured post-build | Defined upfront; frozen before implementation |
| Role of AI agent | High-autonomy co-pilot; generating features from intent | Controlled code generator; working from spec context, not conversation |
| Role of specs | Post-hoc documentation | Pre-requisite for code generation |
| LLM integration | None | Oscillation events, mode, post-DSP intelligence |
| Frontend approach | Vanilla HTML/JS — chosen for speed and directness | React 19 + TypeScript — chosen for component contract traceability |
| Algorithm handling | Embedded in working simulation scripts | 27 numbered spec documents govern every algorithm parameter |
| Testing approach | Functionality validation. | pytest + Vitest + MSW + golden fixture spec |
| Dependency governance | Requirements text file(current versions) | Pinned + hashed Requirements text file (normative spec) |
| Config governance | Environment-driven feature flags | Spec-versioned YAML; every parameter has a spec reference |
| Provenance | Not tracked | Algorithm version, config hash, library versions captured per result |
| Time to first working UI | Fast — days | Slower — weeks of specs before first UI |
| Confidence in correctness | Validated by running the system | Verifiable against spec before running |
| Where AI added most value | Feature generation, UI layout, rapid prototyping | Spec-compliant implementation; reducing logic drift and AI hallucination |
What both builds share is more interesting than what separates them: both are enterprise-grade MVPs, both use the same AI tooling, and both were built by a single person with power-system domain knowledge. The difference is not just where the intelligence lives — it is when operationalisation enters the thinking.
In GridProbity, intelligence lives in the domain expert's judgement — catching drift, shaping emergent structure, knowing when it feels right. That is transformative development: a small team exploring the boundaries of what is possible, with the operationalisation plan forming only once the business sees a viable solution worth scaling.
In OsciProbity 2.0, intelligence was front-loaded into the specs — so that code generation became closer to compilation than creation. That is spec-based development: a small-to-medium team undertaking structured delivery, with operational aspects built into the design from the outset and a concrete plan for operationalising it running in parallel with the build itself.
Neither is universally superior. The question any team must answer is: at what stage must operationalisation enter your thinking — and are you structured to carry it through?
Both artefacts are more than working systems — they are the empirical foundation of a broader research programme into how AI-augmented engineering teams should structure their work.
Building them surfaced something beyond the software itself: a set of repeatable AI development practices, integration patterns for embedding AI into governed workflows, and the beginnings of a practical AI engineering approach that takes seriously both the creative power of generative models and the accountability demands of enterprise environments.
The frameworks that emerged from this work — including the vibe coding pattern observed in GridProbity, the spec-authority model applied in OsciProbity 2.0, and a guardrail framework for constraining AI behaviour within defined operational boundaries — are discussed in the next section.