EcoWat is a Corporate Energy Operating System that gathers the energy reality scattered across invoice archives, field panels, technicians' memories and consultants' folders into a single context. Built for multi-site public institutions and large corporate organisations.
01 — Starting point
In large organisations — and especially in the public sector — the truth about energy does not flow through one channel. The data exists, but because it is never connected, it cannot produce a management decision. The technical team's work stays invisible and consultancy cannot scale.
Official records, live stream, operational memory and strategy meet on the same hierarchy tree.
Every field intervention leaves a sealed trace; the technical team's contribution becomes measurable.
Expert processes are embedded in the system instead of being rebuilt at every new institution.
Electricity and gas invoices, sitting in accounting, administrative affairs or procurement archives.
Live readings on site, in panels, or locked inside a hardware vendor's proprietary software.
Alarms, penalties and fault interventions living in staff memory or messaging groups.
ISO 50001 work, audits and projections scattered across different consultants' laptops.
Selecting any node recalculates the entire dashboard instantly — from the institution total down to a single meter. Locations nest into one another to form a tree of unlimited depth.
02 — The immutable backbone
Every EcoWat capability runs on one flexible hierarchy. However deep your organisation goes — directorate, hospital, block, floor, panel, meter — the tree adapts to it.
A user can only write within the location subtree they are assigned to; read access stays institution-wide.
Every report automatically aggregates all points beneath the selected node.
Each location is bound to a building type; its activity data and EnPI catalogue follow from that.
03 — Capabilities
Every capability is designed around role-based permissions and the rule of "separation": official data never blends with operational data, forecast never with measurement, system never with human.
The main screen where senior management sees the macro picture at a glance. Hierarchy tree fixed on the left; on the right, the official financial summary, live stream status, count of alarms awaiting action and the sealed active-savings counter, all recalculated for the selected node.
The highest-security layer, where official invoices and institutional declarations are processed. Shadow-invoice & AMR reconciliation chart, dynamic activity-data form.
Meter health matrix, current/voltage/harmonic series streaming at 15-minute intervals, and warnings as demand approaches the contracted limit.
Rules for reactive limit breaches, contracted power and communication loss. The alarm does not disappear even when the value returns to normal.
Energy baseline (EnB), significant energy uses (SEU) and a live EnPI panel. Single- and multi-variable regression with CUSUM drift tracking.
"If all lighting goes LED", "if a 1 MW rooftop PV plant is built", "if load shifts to the night tariff" — an extensible registry of 12 scenarios with one shared output: ₺/year · ROI · kWh · CO₂. Financing (grant or ESCO share) is built into every investment scenario.
The Candidate Benefit produced by the simulator is measured and sealed once it has been implemented in the field. In the periods after the project, the M&V engine verifies the net savings — stripped of weather and activity effects — against the baseline. For phased rollouts, expected and realised performance are pro-rated by date.
It does not dump raw data. It freezes data compiled from approved modules with the EcoWat system seal and a timestamp, producing PDF/Excel output. Alongside it sits the Access Log (context sessions) table, where every entry an Asya Mavi Enerji consultant makes into your context is visible — silent access is impossible.
04 — The visible-trust principle
Trust is not established by permissions (RBAC) alone. In EcoWat every critical step is recorded with four separate seals — leaving a record you can defend in front of an auditor.
The unique identity and digital signature of the person who entered the data, revised it or closed the alarm is attached to the record.
The server time (UTC) of the transaction is written immutably into the record; client clocks are not accepted.
A verification code is derived from the content of every record. Any change made directly in the database is detected immediately.
The justification a user writes for a critical change is stored as a legal declaration and cannot be deleted.
Records are only ever added to the audit collection; updates and deletions are forbidden. Every record carries the hash of the one before it — remove a row from the middle of the chain and verification fails.
05 — Binding decisions
The integrity of EcoWat depends on strict adherence to the structural rules below. No development or customisation that violates them can be requested — not even by a customer.
AMR data is operational. Raw meter readings cannot be used as a direct source in official report totals or financial statements; they are only a guide that verifies the invoice.
Even when field values return to normal the alarm stays on the list; it closes only after the responsible person writes an intervention note and approves it manually.
The engine's only output is a "Candidate Benefit". It cannot enter institutional active-savings totals until approval and field verification confirm it went live.
Invoices, activity data and intervention notes cannot be silently removed. Every change is retained through revision/version logic (immutable log).
A consultant may enter the customer context, but every session appears transparently in the customer's audit screens. Single vendor: Asya Mavi Enerji.
AMR readings are stored raw (pass-through). No transformation sits between the incoming signal and the stored value.
06 — Activity data normalisation
"This hospital burned 200,000 kWh this month" means nothing on its own — did more patients arrive, was it a cold winter, did a new block open? EcoWat normalises consumption against the activity data that reflects the institution's operational volume, turning it into efficiency per unit of work.
Round-the-clock service, medical equipment load, heavy HVAC and hot-water demand. The hardest typology: consumption cannot be cut, only made more efficient.
Wide multi-building footprint; seasonal and academic swings (exam periods, summer break). Seasonality is a mandatory variable in the baseline model.
24/7 high security, accommodation, continuous kitchen and laundry operation. Loads with zero tolerance for interruption dominate.
Weekday office density; HVAC and lighting peaking during working hours. The biggest opportunity: tracking out-of-hours base load.
Geographically dispersed, many small consumption points. Load driven by ambient temperature and equipment efficiency; communication loss is the most frequent alarm.
Consumption concentrated in the evening; hot water, heating and kitchen loads dominate. Electricity and gas must be tracked together.
07 — Try it live
The calculation below uses the real formulas from the EcoWat scenario registry. Move the parameters and watch annual savings, payback period and carbon impact recalculate instantly.
Whatever the scenario, the result comes out under the same four headings: annual savings (₺), payback period, energy saved (kWh) and CO₂ reduction. That is what lets the Benefit Ledger weigh an LED retrofit and a solar plant on the same scale.
Simulator output is a forecast. Only benefits implemented in the field and verified by M&V are posted to the institutional active-savings counter.
08 — From forecast to seal
The simulator looks forward and estimates. The Benefit Ledger looks back and measures. The transition between them is governed by a four-state machine — and the last step cannot be undone.
The scenario output is written into the ledger. Forecast ₺/kWh/CO₂ values are pre-filled from the simulation; nothing has happened in the field yet.
Field rollout begins in phases. Each phase (quantity and date) is added to the ledger; expected performance is pro-rated by date.
In the periods after the project, the baseline engine computes Σ(expected − actual): net savings stripped of weather and activity effects.
The realised gain is frozen with the system seal and locked. It now appears in the institutional active-savings counter and cannot be changed retroactively.
09 — Architecture
In EcoWat, official data, operational stream and audit trail never live in the same store. Three separate layers for security and performance, with schema-level isolation inside each.
10 — Frequently asked
No. AMR is only one of EcoWat's eight core capabilities, and it is positioned as operational data. EcoWat is an operating system that unites the official invoice, activity data, alarm response, ISO 50001 work, simulation and sealed reporting in one institutional context. AMR data never replaces official data; it only verifies the invoice.
No. EcoWat does not connect to meters directly; it receives data through the distribution company's official AMR API. This is both the legally correct channel and a way to go live without touching field hardware. The prerequisite is administrative rather than technical: consent forms and API access keys. We run that process with you.
That is a deliberate design decision. If an alarm vanished the moment the value returned to normal, the institution would learn nothing from the event. Instead EcoWat moves it to Resolved by system — awaiting approval; a single intervention note closes it. The result: the root cause of recurring faults no longer sits in one person's memory but in a searchable institutional record.
Only when you grant access, and always visibly. When an Asya Mavi Enerji consultant switches into a customer context, a "context session" opens; that session is listed in your own audit screen with its start time and what was done within it. Silent access is architecturally impossible — the access record itself is kept in the append-only audit layer.
Yes — but not by deleting. Official data records are immutable: a correction produces a new version row instead of overwriting the old one. The application always uses the current version, while an auditor sees the v1 → v2 chain together with its justification. This is the only defensible method, both for accounting discipline and for external audit.
A simulation is a forecast, and the system never hides it: every output carries a "Candidate Benefit" watermark and is excluded from institutional savings totals. The real figure emerges after you implement the project: the M&V engine measures what you actually gained, using the baseline model to strip out weather and activity effects. Forecast and actual sit side by side in the ledger.
Typologies and the metric catalogue are not constants buried in code; they are managed master data. A new building type and its activity metrics can be defined, and the EnPI formulas and dynamic data-entry forms are generated automatically from that definition. The same holds for simulation scenarios: adding one is a matter of adding a definition and a formula to the catalogue.
Let's begin
In a 45-minute session we will model your organisation together, assess your current invoice and AMR access, and produce a roll-out roadmap specific to you.
We review your organisational structure and existing data access together.
We run the consent-form and API access process with you.
Transparent corporate pricing based on location and meter count.