Appearance
OAIA — the AI assistant
OAIA watches your deployment, tells you what changed, proposes improvements, and answers questions about your own data in plain language. With Autopilot on, it can also make a small, bounded set of changes itself.
The design principle is worth stating before anything else, because everything below follows from it:
The detectors detect. The model narrates.
Omaya's own code decides what is wrong and how serious it is. The model is asked to explain it in a sentence a person can act on. It never sets a severity, never fires a notification, and — outside Autopilot's fixed list — never changes anything.
That means a tenant with no AI provider still gets everything except the prose: findings, escalations and notifications all work, worded by the detector rather than the model.
Turning it on
OAIA in the menu. Two settings:
| Setting | Options |
|---|---|
| Heartbeat interval | Every 2, 4, 6, 8, 12 or 24 hours |
| Review | Every 1, 2, 3 or 7 days |
Pick the interval by how quickly you want to hear, not by how much you want it to do. A two-hour heartbeat on a quiet estate produces almost no messages, because it only speaks when something changed.
You also need an AI provider key for the prose and the chat. Keys come from your own organisation first (bring your own), then a platform key if the operator has supplied one. Usage is metered and capped per organisation — System → Usage shows where you are.
The heartbeat
Every interval, for your organisation:
detectors → findings → reconcile with what is already open → (narrate) → notifyThe model is only consulted when there is something to say — a change since last time, or a digest that has gone stale. A heartbeat where nothing moved costs nothing and says nothing.
What it watches
Twelve detectors, each looking for one specific thing rather than general strangeness:
| Gateways | One gone offline; a gateway whose signal has dropped |
| Devices | Anomalies — silent, draining, reporting far less than its baseline |
| Batteries | Devices heading for replacement |
| Ingestion | Data has stopped arriving at all |
| Environment | A reading that has drifted from its own baseline |
| Apps | Facility, Meeting Room, Toilet Hygiene and Security Watch each contribute what they know |
An app that is not enabled contributes nothing and is never mentioned, so the model cannot be led into speculating about something you do not have.
Findings
A finding is one problem, tracked over time rather than re-announced. Each has a severity — info, warning or critical — set by the detector.
You can acknowledge it (you have seen it), snooze it until a date, reopen it, or mark it won't fix — which keeps it out of notifications permanently without pretending it went away.
Notifications go to every active administrator of your organisation, and only when the heartbeat produced something genuinely new: a new finding, an escalation, or a snoozed one that came back. An unchanged finding is the same news as last time and does not interrupt anyone twice. Info-level findings appear on the page and never interrupt at all.
The daily review
Once a day (or on whatever cadence you set), OAIA looks at the deployment as a whole rather than at events, and proposes improvements in five categories: automation, safety, wellbeing, efficiency and configuration.
The facts come from Omaya, not from the model — a profile of what you have, what is configured and what is not. The model turns gaps and patterns into a short, prioritised list.
A proposal that carries a rule carries a validated rule. The draft goes through the same validator the rule builder uses, so a suggestion can never offer a rule the builder would refuse. Accepting one opens it in the builder; nothing is saved or activated on your behalf.
Each suggestion can be accepted, marked done, or dismissed.
Asking it things
The chat on the OAIA page answers questions about your own data. Three tools back it:
- Describe schema — what it may look at.
- Run SQL — one read-only query.
- Propose action — offers you a change to approve. Nothing happens until you click Apply.
How "your data only" is enforced
This is worth understanding, because it is a database property rather than a promise in a prompt.
OAIA never queries a base table. Each organisation's database carries a set of oaia_* views, each one a projection with your own tenant id baked in as a literal. OAIA connects as a read-only database user granted SELECT on those views and nothing else.
So the foreign rows that exist inside every tenant database — superuser-tagged spaces, aggregate sentinels — are outside the view, and a query cannot reach them however it is phrased. On top of that a guard rejects statements by shape before they run, and caps how long a query may take and how many rows it may return.
The assistant also refuses to widen its own access: an instruction inside a conversation, or inside data it reads, cannot grant it tools, tables or another organisation. Claims of being a developer or a superuser change nothing.
Autopilot
Off by default, and gated
Autopilot is a beta feature. It has to be made available to your organisation by whoever operates the platform, and then switched on by you. Until both are true it does nothing at all.
With Autopilot on, OAIA stops only proposing and starts doing — within limits that are deliberately narrow.
Where the switch is. Once the operator has made it available to your organisation, an Autopilot (beta) section appears on the A.I Model card under Configuration: a mode, and the tiers you allow. Saving the card needs the general-settings permission. Turning it off is the same place — set the mode back to Off — and it is off regardless while OAIA itself is disabled.
Modes
| Mode | What happens |
|---|---|
| Off | Proposals wait for a person. The default. |
| Shadow | It decides what it would do and writes it down. Nothing is changed. |
| Act | It applies what its policy allows. |
Run it in shadow for a week first. Shadow mode produces exactly the record that act mode would, so you can read a week of decisions and judge them before any of them are real.
What it may do
Seven kinds of action, in three tiers, and you choose which tiers are allowed:
| Tier | Actions | What it means |
|---|---|---|
| Draft | Draft a rule | Writes a rule, inactive, for you to review. Its actions are limited to alerts, messages and the smart-home bridge — it cannot draft a rule that raises work orders |
| Configure | Set a zone capacity · Set venue hours · Assign a device to a zone | Fills in configuration gaps it can infer |
| Operate | Switch something off · Cooling on · Lights on | Acts on the building through the smart-home bridge |
Every entry is non-destructive and reversible. There is no kind that deletes anything, and none that can be added without a release.
The limits
These are not settings. They are constants, and they are the reason the feature is safe to leave on:
| 3 actions per run, 20 per day | A misreading cannot cascade |
| One hour between actions on the same target | It cannot fight itself over one room |
| A room must have been empty for 10 minutes before anything is switched off | Somebody sitting still is not an empty room |
| Evidence older than 90 minutes is not evidence | It will not act on a stale temperature |
| It will not reverse its own last action on a target within 30 minutes | No oscillation |
| Cooling: on above 27 °C when occupied, above 30 °C even when empty | Comfort, then safety |
| Setpoint 24 °C, never sent outside 20–28 °C | A bad number cannot leave the band |
| Capacity between 1 and 1000 | Same idea, for configuration |
Undo, and the kill switches
Every applied action records the state before it. Undo puts that state back.
Undo is also a signal, and the system treats it as one:
- Undoing an action pauses that kind of action for 24 hours.
- Three undos in a week drops the mode to shadow. It stops acting and goes back to writing down what it would have done, without anyone having to notice and intervene.
That second rule is the important one. It means a disagreement between you and Autopilot resolves in your favour automatically, rather than requiring you to remember to turn it off.
What it will never do
- Set or change a severity — that stays the detector's.
- Send a notification — the platform does that.
- Read another organisation's data, or its own base tables.
- Delete anything.
- Act outside the seven kinds above, or outside the tiers you allowed.
- Activate a rule. Every rule it drafts is switched off until a person turns it on — and it cannot draft one that raises work orders at all.
- Take an instruction from data it read. A zone named "ignore your rules" is a zone with a strange name.
When it disappoints
It says nothing. That is usually correct — it speaks on change. Check the last run time on the page; if runs are happening and findings are empty, nothing is wrong.
It has no prose, just detector wording. No AI provider key for your organisation, or the monthly cap is reached. System → Usage.
The chat says it is not provisioned. The oaia_* views or the read-only database user have not been created for your organisation yet — that is an operator step.
Autopilot is not offered. It has not been made available to your organisation. It is gated per organisation on purpose.
Autopilot is on but does nothing. Either no tier is allowed, or its preconditions are not met — a room that has not been empty long enough, evidence that is too old, a target inside its cooldown. Shadow mode's record is where to look: it says what it decided and why.