NirmaanAI — Solution Documentation
AI-Powered Energy Intelligence Layer for India. Rodic InfraAI Innovation Challenge 2026 · AI for India Energy Stack.
Live application: https://nirmaanai.tecell.in · Testing report: https://nirmaanai.tecell.in/reports/testing-report.html · Demo video: https://youtu.be/XJhZFgefzBI · Acknowledgements: https://nirmaanai.tecell.in/acknowledgements.html · Contact: [email protected]
Approach
Problem. Energy data (meters, buildings, transformers, calendars) sits in separate systems and is mostly used for retrospective reporting. Operators find abnormal load, supply-quality problems and peaks too late to act (BRS §2).
Idea. NirmaanAI is an intelligence layer between raw measurements and operational decisions, organised around one journey: Detect → Understand → Predict → Act.
| Step | What NirmaanAI does | Where to see it |
|---|---|---|
| Detect | Learns each meter's normal behaviour in context and flags unusual consumption, supply-quality and peak-demand behaviour | https://nirmaanai.tecell.in/events |
| Understand | Investigates each event across building → transformer → campus, with related electrical parameters, history and a grounded plain-language explanation | https://nirmaanai.tecell.in/overview |
| Predict | Forecasts demand 15 minutes to 24 hours ahead, with prediction intervals | https://nirmaanai.tecell.in/forecast |
| Act | Prioritises events (Critical / High / Medium / Low), gives operational guidance and answers questions through a tool-grounded AI assistant | https://nirmaanai.tecell.in/assistant |
Design principles. 1. Data first, honestly. Every source file is ingested into one unified model. Gaps and invalid readings are flagged, never hidden, and missing data is never treated as an anomaly. 2. Measured, not demonstrated. Detection and forecasting are evaluated with controlled tests and held-out data. All results are published (https://nirmaanai.tecell.in/reports/testing-report.html). 3. Grounded AI. Language models only phrase results that the analytics computed, and never invent numbers or causes. Answers are checked against the source results. 4. No over-claiming. There are no theft or fault labels without evidence. The inferred topology is marked as inferred, and future modules are shown as "Coming soon". 5. Built to scale. The same entity/observation model and engines extend from one campus to DISCOM smart meters, feeders, renewables and grid data (BRS §38).
Solution architecture
Energy data sources NirmaanAI intelligence layer Users
─────────────────── ──────────────────────────── ─────
Building meters ─┐
Mains / UPS feeds ─┤ Ingestion & Unified Intelligence Priority & Web dashboard
Transformers ─┼─► data quality ─► energy data ─► engines ─► explanation ─► AI assistant
Campus aggregates ─┤ model (detect, layer Open API
Calendar & context─┘ forecast, peaks)
The platform has five layers:
- Ingestion & data quality. Reads heterogeneous source files, standardises time (Indian Standard Time) and units, retains source metadata, and flags missing, duplicate and invalid readings instead of discarding them.
- Unified energy data model. One common structure for every source: entity (campus, transformer, building, supply type), parameter, value, unit and quality status. Intelligence can then be applied uniformly and related across the Building → Transformer → Campus hierarchy.
- Intelligence engines: - Baseline intelligence: learns what "normal" looks like for each entity. - Anomaly and supply-quality intelligence: detects unusual consumption and electrical behaviour. - Peak-demand intelligence: identifies peak periods and the entities that contributed. - Demand forecasting: short-term predictions with uncertainty ranges. - Relationship analysis: estimates how buildings relate to transformers where this is not documented, always clearly marked as inferred.
- Priority & explanation layer. Ranks events for operators and produces plain-language explanations and recommended next steps from computed results only. Recommendations are guidance, never automatic control actions.
- Experience layer. A web dashboard (Detect → Understand → Predict → Act), an AI assistant for natural-language questions, and an open read-only API.
Technical implementation
| Area | Implementation |
|---|---|
| Data processing | Python analytics pipeline with a columnar analytical store. It processes the full I-BLEND dataset (25.1 million one-minute records, 112 million measurements) end to end |
| Machine learning | Statistical and machine-learning models for baselines, anomaly detection and forecasting, selected and validated on held-out data (see the testing report) |
| Evaluation framework | Controlled test scenarios, held-out test periods and consistency checks, with results published openly |
| Backend | REST API serving pre-computed intelligence, with fast responses (≈ 0.1 s typical) |
| Frontend | Responsive web application with interactive charts, event investigation and the assistant |
| AI assistant | Language models connected to the platform's own analytical results through controlled tool access. It answers only from computed data, cites the events it used, and falls back gracefully across providers |
| Deployment | Hosted application on a dedicated server behind an encrypted Cloudflare Tunnel (HTTPS), with no inbound ports exposed. Updates are published only after testing |
| Quality assurance | Automated test suites for the backend and frontend, plus visual checks of the live application before each release |
Tools and APIs used
Languages and frameworks: Python, TypeScript, React, FastAPI.
Data and machine learning: pandas, NumPy, DuckDB, Apache Arrow/Parquet, scikit-learn, XGBoost, statsmodels.
AI models and services: Anthropic Claude (directly and via OpenRouter) and Meta Llama 3.1 (run locally through Ollama) for the assistant. OpenAI audio via OpenRouter for the demo video's voice-over.
Infrastructure: Uvicorn, Cloudflare Tunnel, systemd. Testing: pytest, Vitest, Playwright.
NirmaanAI public API (read-only, JSON) at https://nirmaanai.tecell.in/api/…:
| Endpoint | Purpose |
|---|---|
/api/health |
Service status and data range |
/api/overview |
Daily campus summary, events, peaks, forecast, insights |
/api/events, /api/events/{id} |
Detected events and event investigation context |
/api/peaks |
Peak-demand events and contributors |
/api/timeseries |
Measurements and expected values for an entity |
/api/buildings/compare, /api/transformers/compare, /api/supply/mains-ups |
Comparative intelligence |
/api/forecast |
Demand forecast with uncertainty range |
/api/metrics |
Published evaluation results |
/api/modules |
Live and upcoming modules |
/api/assistant/ask |
Natural-language questions (rate limited) |
Full credits and licences: https://nirmaanai.tecell.in/acknowledgements.html.
Data privacy and compliance
- No personal data. The PoC uses only the public, CC0-licensed I-BLEND research dataset: aggregate building and transformer electrical measurements, anonymous building occupancy counts, and an academic calendar. It contains no names, household or customer identifiers, addresses or billing records. No personal data within the meaning of India's Digital Personal Data Protection Act, 2023 is collected or processed.
- Data governance. Source, file, entity, parameter, unit, time interpretation and quality status are retained for every measurement. Original values are never altered.
- Synthetic data. Test scenarios used for evaluation are kept separate from operational data and are always labelled as synthetic.
- AI use. The assistant sends only excerpts of computed, public-dataset-derived results to model providers. It is instructed not to make causal claims (e.g. theft or faults) without evidence. Questions are not stored beyond transient server logs, and users are asked not to enter personal information.
- Security. The site is served over HTTPS through Cloudflare, with no inbound ports open. The public service is read-only apart from the rate-limited assistant. Credentials are kept outside the codebase in protected configuration.
- For production use with real DISCOM or customer data, NirmaanAI would add authentication, role-based access, encryption at rest, audit logging, consent and purpose-limitation controls aligned with the DPDP Act, and data-isolation per organisation. These are outside this PoC's scope and are not claimed here.
Limitations
The results come from a single campus dataset and aren't generalised to DISCOM or national scale. The dataset has no ground-truth anomaly labels, so detection quality is measured with controlled tests, and no event is presented as theft or a confirmed fault. Building–transformer relationships are inferred, not documented. Full results and limitations: https://nirmaanai.tecell.in/reports/testing-report.html.