BEFORE
A flat queue of raw points
Human correlation required!TB12.SAT
Supply-air temperature high
!TB12.CWV
Valve command at 100%
!TB12.ZT-03
Zone-temperature deviation
Which machine? Which spaces? What happens next?2–4 h to dispatch (illustrative)
MirayaConcept · design-partner stage
The city,
understood.
Operations intelligence for cities, communities and buildings—turning fragmented telemetry into shared context, evidence-led action and outcomes you can verify.
For complex estates in India and the Middle East · SaaS or on-premises by design
MIRAYA / CITY COMMANDCONCEPT PREVIEW
Concept experience · illustrative synthetic data
SAFETY92/100+1.4
SUSTAINABILITY78/100+2.1
EFFICIENCY81/100−0.8
AVAILABILITY96/100+0.6
DISTRICT VIEW4 layers visible
Selected objectObjects, not raw points
KEY INSIGHT01 / 03
ENERGY · CHILLER PLANT 2
Cooling efficiency is drifting from its baseline.
18% below the weather-normalised baseline · QAR 4,100/week extra cost (illustrative)
EVIDENCE CHAIN
1
Source observationsQuality + timestamp retained
2
Object relationshipsLocation + consequence
3
Rule / modelConfidence remains inspectable
RECOMMENDED ACTIONReview plant sequencing
01A fragment of the intended City Command experience. Use the controls to inspect each synthetic insight.
The problem
More signals.
Less understanding.
Point-driven tools leave operators to reconstruct cause, location and consequence from disconnected alarms. Miraya is designed around a different unit of understanding: the object.
AFTER
One condition on one object
Context attachedAHU-TB-12-04
RANKEDDegraded cooling capacity
CAUSE 01
Suspected stuck cooling-coil valve
- Serves
- Zones 12-A + 12-B · occupied
- Observed by
- 3 correlated source points
- Consequence
- Comfort + energy + projected IAQ impact
Evidence → incident → qualified technicianOne shared record
The AHU-TB-12-04 scenario and timing are illustrative worked examples from the product architecture, not observed customer results.
The approach
A shared model of how the estate works.
Miraya’s intended role is not another isolated dashboard. It is an evidence layer above installed systems, connecting what an operator sees to what an executive measures.
Objects, not points
Assets, spaces and services carry typed relationships such as locatedIn, serves and feeds. An event inherits location and consequence.
Evidence before action
Every insight is designed to expose its sources, objects, rule or model and confidence. Consequential recommendations remain human-reviewed.
Baseline before promise
Measure current performance first. Classify savings as verified, attributed or projected—never blend them into an unsupported claim.
Intended capabilities
From raw signal
to verified outcome.
Six connected capabilities form the product thesis. Each is a design target to be validated with design partners, not a statement of general availability.
01 / TWIN & ONTOLOGY
Give data a place in the real world.
Map raw tags to assets, rooms, zones and systems. Preserve identity and relationships as the estate changes.
02 / EXPLAINABLE INSIGHTS
Show the reasoning, not just the answer.
Move from a finding to its observations, model version and quality record without losing the operational thread.
01
Source systemsBACnet · meter · occupancy
02
Governed objectsAHU · zones · chiller loop
03
Rule / modelVersion + confidence visible
03 / SPATIAL CONTEXT
Drill down without losing identity.
Move from district to building, floor, room and asset while the same governed object stays in view.
CityBuildingFloorAsset
04 / ACTION & DISPATCH
Carry context into the work.
Create an incident with impact, asset history and likely causes. Route it using skills, zone and roster context.
DetectedDispatchedResolvedVerified
05 / KPI-IMPACT LEDGER
Close the loop against the baseline.
Separate verified, attributed and projected impact. Keep the evidence behind every classification available for review.
Observed recoveryVerified
Shared contributionAttributed
Forward estimateProjected
06 / FLEXIBLE DELIVERY
Fit the estate, not the other way round.
Begin read-only alongside existing controls. Design SaaS-plus-edge or on-premises around actual residency and operating needs.
Installed systemsSite edgeSaaS / on-prem
Value by role
One model.
Seven operational lenses.
Each role sees a different decision, not a different version of the truth. Select a lens to explore its intended KPIs and actions.
City Command lens
One operational picture, from estate to asset.
Follow availability, energy and cost without waiting for a separately assembled report. Every executive figure is designed to lead back to the objects and observations behind it.
KPIs this lens watches
- Estate energy intensity
- Critical-service availability
- Verified savings against baseline
From insight to action
A strategic KPI breach could open an executive incident with its cause chain, affected services and estimated cost attached.
Intended workflow · scope validated per deploymentHow it works
The insight loop,
with evidence throughout.
A governed observation remains traceable from acquisition to outcome. The operational model adds meaning; the KPI tree sets priority; action is measured rather than assumed.
- 01
Sense
Connect installed systems without erasing source identity, units, time or quality.
- 02
Understand
Bind observations to governed assets, spaces, services and their relationships.
- 03
Steer
Rank insights against the KPIs the city sets, with evidence and confidence attached.
- 04
Act
Turn an approved insight into an incident, dispatch and resolution with an audit trail.
- 05
Prove
Verify the outcome against live values and a signed baseline before claiming value.
Consultancy-led by design
Discover → Baseline → Pilot → Scale → Operate
Start with one painful problem and its data. Establish the baseline before proposing scale.An honest roadmap
A concept with a defined path to proof.
Miraya is at Concept · design-partner stage. The architecture and intended workflows are defined; product capabilities, integrations and outcomes still need to be built and validated in real settings. No general-availability date is being promised.
CURRENT STAGE
Make the model tangible
- Product thesis and target architecture
- Object-led operational workflows
- Concept experience with synthetic data
What exists now is a product concept and design foundation—not a deployed city platform.
WITH DESIGN PARTNERS
Bound the first proof
- Select one evidenced operational problem
- Audit systems, data quality and permissions
- Agree a signed baseline and acceptance criteria
The first scope follows partner priorities and data readiness, not a predetermined feature checklist.
BEFORE SCALE
Prove each vertical path
- Test exact adapters and source behaviour
- Validate mappings, evidence and human review
- Measure incident resolution and KPI impact
Scale follows witnessed evidence. Protocol names and target capabilities are not universal compatibility claims.
Questions, answered plainly
Before you step inside.
What the concept means, what it does not claim, and where a design partnership would begin.
01Is Miraya available as a finished product?
Not yet. Miraya is at Concept · design-partner stage. This page and its concept experience describe the intended product and delivery method. A design partnership would test a bounded operational problem, available data and measurable acceptance criteria before any broader deployment is proposed.
02Does Miraya replace our BMS or control systems?
That is not the starting point. The architecture places Miraya above installed systems as a normalisation, ontology and evidence layer. Discovery begins read-only; local deterministic control and life-safety functions remain in their designated systems.
03Which systems can it connect to?
The target architecture includes OPC UA, BACnet, MQTT, Modbus and documented system APIs across BMS, HVAC, lifts, metering, water, access, footfall and ticketing. These are design targets, not a universal compatibility claim. Each engagement must test the exact system, firmware, protocol profile and permissions.
04Will AI operate equipment autonomously?
No autonomous safety or control claim is being made. Miraya’s principle is that every insight carries its evidence. Consequential recommendations require human review, and any future write action would need a separately approved use case, explicit allowlists, local interlocks and verified outcomes.
05Can it be deployed on-premises?
SaaS with a site edge and on-premises are both intended deployment shapes. The right shape depends on residency, bandwidth, operating ownership and the installed estate. On-premises is a deployment variant, not a promise of identical managed-service operations.
06How would value be measured?
Discover and Baseline come before Pilot. Current performance is measured and agreed before changes are made. Savings are intended to be classified as verified, attributed or projected—never blended—and compared with the signed baseline, normalised for occupancy and weather where relevant.
Bring one painful problem
Let’s find the signal
inside the noise.
Explore the intended operating model, then bring us the operational problem and data you want to baseline.