AI in Omaya

Omaya uses a language model in seven places. This page is the complete account of them: what each one can do, what it reads, what it may change, how it is configured, and — because this is the part that matters when the answer is wrong — what it is prevented from doing.

If you take one thing from the page, take this:

Omaya's own code decides. The model explains.

Every number, every severity, every "this is wrong" comes from deterministic code over your own data. The model is handed those facts and asked to put them into words a person can act on. It is asked to judge in exactly one place (Security Watch's out-of-habit triage), and it is allowed to act in exactly one place (OAIA Autopilot), inside limits that are constants in the code rather than settings on a page. Everywhere else, a change happens only when a person clicks to make it.

Seven places, one configuration, one rule: Omaya's code decides, the model explains.

Where it shows up

Feature	Where	What you get	Menu / page
OAIA — the assistant	its own page	A heartbeat that watches the deployment and tells you what changed; a daily review that proposes improvements; a chat over your own data; optional Autopilot	OAIA in the menu
Reporting assistant	the Reports section, or your own AI client	Questions in plain language answered from the report tables and from the apps you have switched on, with a table, a chart and — for "where is X" — a floor plan	Reports → AI Reporting, or an MCP client
Rule author	the rule builder	Describe the alert you want; a validated draft rule appears in the builder for you to finish and save	Rules → New rule → Describe
Security Watch	the Security Watch app	One judgement on each out-of-habit situation; two lines of wording on every new incident	Apps → Security Watch
Decode Assist	New sensor types	A proposed decoder for a sensor Omaya has never met, checked against every captured frame before you accept it	Device → New sensor types
Toilet summary	the Toilet Hygiene app	A few plain sentences on how one toilet is doing, what is likely next, and up to three things to do	Apps → Toilet Hygiene → a toilet → Overview (AI summary)
Practice review	the Data Centre app	The two or three unmet operating practices to deal with first at this site, each with why now and a first step	Apps → Data Centre → Practice → Ask OAIA for a review

Two more things are sometimes called AI and are not, in the sense this page means:

• Occupancy forecasting ("predicted busy at 14:00") is a statistical time series model run over your own history. No language model, no provider key, nothing leaves the instance.
• Anomaly detection on devices (silent, draining, reporting far below baseline) is thresholds and baselines in code. OAIA reads its output; it does not produce it.

Capability matrix

What each feature is allowed to reach, and what it is allowed to change. "Reads" is the whole of what the model can see; "may change" is the whole of what it can cause to happen — everything else is out of reach, not merely discouraged.

	Reads	May change	Needs a provider key?	Who can use it
OAIA heartbeat	Findings the detectors produced	Nothing. The platform notifies	No — without a key, findings carry the detector's wording	Everyone who can view OAIA sees findings; all active admins are notified
OAIA review	A profile of your deployment: what exists, what is configured, what is not	Nothing. Suggestions wait for you; an accepted rule draft opens in the builder, inactive	Yes, for suggestions to be generated	View OAIA
OAIA chat	The oaia_* views of your own data, through a read-only database user, and these docs	Nothing directly. It can propose an action from a fixed catalogue; you click Apply. The one exception is a configuration change under Autopilot	Yes	View OAIA; each proposed action also needs the permission a person would need
OAIA Autopilot	Findings, the profile, live occupancy and readings	Only the eleven kinds in its catalogue, inside the tiers you allowed	Yes	Manage OAIA, and the feature has to be enabled for your organisation by the operator
Reporting assistant	Thirteen report tools over the same tables the report pages read, plus the oaia_* views of the apps you are allowed to read, through the same read-only database user OAIA uses	Nothing	Yes in the app; from an MCP client your client's own model does the work	Report AI permission; each app's data also needs that app's permission (below)
Rule author	The rule vocabulary, your space names, your smart-home devices	Nothing. It returns a draft; saving is you, through the normal rule save	Yes	Whoever can create rules
Security Watch triage	The candidate, the person's history, the zone's regulars, bookings, the hour; up to two read-only queries	One verdict: abnormal or not. An abnormal verdict becomes an incident	Yes — without a key, out-of-habit candidates never become incidents	Runs unattended
Security Watch narration	An incident's evidence	The two lines of text on the incident	Yes — without a key, the incident shows detector wording	Runs unattended
Decode Assist	The captured frames and, if uploaded, the manual	Nothing. The proposal is run over every frame and shown to you before anything is saved	Yes	Whoever can manage devices
Toilet summary	The facts the Toilet Hygiene app already worked out for one toilet: its score, how fast it is rising, today's cleaning, ratings, the to-do list	Nothing. Its sentences sit beside the app's own to-do list	Yes — without a key, the page keeps the app's own wording	Toilet Hygiene managers
Practice review	The Data Centre practice checks the site does not meet, with their evidence and the site's own numbers	Nothing. It may only pick from the unmet checks	Yes — without a key, the checks still show	Whoever can open the Data Centre app

And the things none of them can do, regardless of feature, mode or permission:

• Set or change a severity. Severities are decided by detectors.
• Send a notification. The platform decides who is told, and when.
• Save, activate or delete anything outside Autopilot's catalogue — and Autopilot has no kind of action that deletes.
• Reach another organisation's data, or the base tables of its own.
• Take instructions from data. A zone called "ignore your rules" is a zone with a strange name. Claims inside a conversation of being a developer or a platform operator change nothing about what the tools will run.

Setting it up once

All seven features follow one configuration, the AI card on Configuration:

Setting	What it does
Provider	One of Groq, Anthropic, OpenAI, Gemini, OpenRouter or MiniMax. The operator can restrict which are offered
Model	Fetched from the provider when you click Fetch models. Leave it blank for the platform default, which the card shows you rather than hiding behind an empty box
Temperature	How much the wording varies. Reporting answers default to near-deterministic (0.2) because they are lookups
Response cap	Longest answer in tokens (default 2048). Decode Assist and the OAIA review raise their own floors, because a reasoning model spends part of the budget thinking
Verify SSL	Leave on. Off exists for a provider behind an inspecting proxy
Your own key	Bring your own key for the chosen provider. Stored encrypted inside your own database, masked on the page, testable with Test key before you rely on it
OAIA	The assistant's own switches live on the same card: on or off, heartbeat interval, review cadence, and — when offered — Autopilot's mode and tiers

Four things are decided for your organisation by whoever operates the platform, and show on the card as available or not: whether AI is on at all, whether you may bring your own key, whether OAIA is offered, and whether Autopilot is. With AI off, every feature above falls back to code-worded output and nothing is sent to any provider.

Which key a request runs on

The key is chosen per request, so a cap reached on the platform side stops nothing for an organisation that brought its own.

The order is deliberate. An organisation that entered its own key expects it to be used, and expects not to be cut off when the shared quota runs out. Requests on your own key are billed to you by your provider and do not count against the cap; requests on a platform key do.

Usage and the cap

The Usage page shows this month's tokens per provider, split into platform and your own key. Only the platform bucket is metered: the default cap is 500,000 tokens a month, and the operator can set a different one for your organisation. When it is reached, every feature degrades to code-worded output until the month rolls over or you bring your own key — nothing stops working, it just stops being written by the model.

OAIA

OAIA is the assistant you talk to. It has four parts — the heartbeat, the review, the chat, and Autopilot — and the apps you have enabled each plug into all four.

The heartbeat

The expensive step is last and conditional. A quiet estate produces heartbeats that end at "nothing changed".

Every interval you choose (2, 4, 6, 8, 12 or 24 hours), for your organisation:

1. Detectors run. Each looks for one specific thing over your own data and produces findings, each with a stable fingerprint and a severity the detector set — info, warning or critical.
2. Findings are reconciled with what is already open: the same fingerprint is the same finding, not a new one; a resolved condition clears it; a snoozed one that is still true comes back when the snooze ends.
3. Only if something changed — a new finding, an escalation, a snoozed finding returning — is the model asked to narrate, and only then are administrators notified. A heartbeat where nothing moved costs nothing and says nothing. (A digest is also refreshed at most once a day so the page is never stale.)

What the detectors watch:

Detector	Raises a finding when	Comes from
Gateway offline	A gateway has stopped reporting (critical after 24 hours), or several in one venue stopped within 15 minutes of each other, which points to power or the network; or a gateway keeps dropping: three or more outages of its own in 7 days, not counting site-wide ones	platform
Gateway signal	A gateway's received signal over the last 30 days is falling steadily enough to forecast a failure	platform
Ingestion silence	A venue's room decisions have fallen to a tenth or less of the same hours a week earlier, even though its gateways may still look online. A venue with too little history to compare is left out	platform
Device anomaly	A device is silent, draining, or reporting far below its baseline; or a device is placed nowhere and its readings are being dropped	platform
Battery low	A device's battery is at 20 % or less (critical at 10 % or less), from a reading in the last seven days; or a tag's battery voltage is below its model's low-voltage line, quoted in mV	platform
Environment baseline	A room's latest temperature is far from its own normal for that hour of the day over the last 14 days, by at least 2 °C	platform
Outside	Only with GPS tracking: a stop away from every site, geofence and the person's home that is far longer than their usual stops over the last 30 days; a tracker gone quiet outside for longer than its usual gap between fixes; a low or fast-falling battery on a tracker used outside; an asset or vehicle moving outside site hours when it does not usually. No finding carries map coordinates	platform
Connector error	An enabled connector — email, SMS, WhatsApp, Telegram, webhook, storage — is failing to deliver	platform
Energy left on	Something is drawing power in a room that has been empty	Energy Monitoring
Work order overdue	An urgent or high work order is past due, or nobody has taken it; assets are a week or more past their service date	Facility Management
Calendar sync · bookings stuck	A meeting-room calendar has stopped syncing; bookings are still open hours after they ended	Meeting Room
Security incident unattended	An incident has sat unacknowledged, or open, too long	Security Watch
Toilet dirty unattended	A toilet is in the red and no cleaning job is open for it	Toilet Hygiene
Visitor overstay · waiting	A visitor is past their expected departure; a visitor has waited too long for approval	Visitor Management
Assessment stale · calibration overdue	An active compliance profile has not been assessed for over 35 days, or never; sensors are past their calibration due date	Compliance
Drill overdue · roll call left running	The last evacuation drill was more than 90 days ago; a roll call is still running after 6 hours	Roll Call
Data Centre unattended	An alert nobody has acknowledged — a critical one after 15 minutes, any other after 2 hours; or half or more of the plant has stopped reporting, which blinds every other alert	Data Centre
Warehouse unattended	An alert nobody has acknowledged — a critical one after 15 minutes, any other after 2 hours — including stock sitting in a storage area outside its temperature or humidity range	Warehouse

An app that is not enabled contributes no detector, no section of the review, no view for the chat and no paragraph of the prompt — so the model cannot be led into speculating about something you do not have.

What the model is given: the findings, as facts, bucketed as new / escalated / cleared, at most 25 per bucket. What it returns: a digest, a likely cause, and an action chosen from a fixed list (check power, check network, inspect the gateway, replace the battery, review the device, check the sensor, review a rule, draft a rule, contact support, no action). The reply is checked against a schema; a reply that does not fit is discarded and the detector's own wording stands.

Findings can be acknowledged (you have seen it), snoozed for 4 hours to a week, reopened, or marked won't fix — which keeps it out of notifications for good without pretending it went away. Notifications go to every active administrator of the organisation, one per person per heartbeat, and info-level findings never interrupt anyone.

The review

Once a day (or every 2, 3 or 7 days), OAIA looks at the deployment as a whole rather than at events. Omaya builds a profile — venues and their operating hours, zones and capacities, devices and where they are placed, what each app is configured to do, occupancy and environment coverage — and a list of gaps: things verifiably absent, such as a venue with no hours or a zone whose counter has no capacity to compare against.

The model turns that into up to five prioritised suggestions in five categories: automation, safety, wellbeing, efficiency and configuration. Each can be accepted, marked done, or dismissed; a dismissed idea is remembered for 30 days so it is not proposed again next morning.

Two properties worth knowing:

• A suggestion that carries a rule carries a validated rule. The draft goes through the same validator the rule builder uses, so it can never offer a rule the builder would refuse. Accepting it opens the builder; nothing is saved or switched on for you.
• Suggestions close themselves when the gap is fixed. A suggestion linked to a gap ("Level 4 has no operating hours") is closed automatically by the next heartbeat once the hours exist, and a drafted-rule suggestion closes once a matching rule exists. The page lists what was auto-closed in the last week, so a suggestion never nags about something you have already done.

The chat

The chat on the OAIA page answers questions about your own data, and can be opened from other pages with a record already in front of it — a Security Watch incident's Ask OAIA button, for example. It has nine tools:

Tool	What it does
Describe schema	Lists the views it may look at and their columns
Run SQL	Runs one read-only query, through the guard below
Gateway status	Every gateway as online, stale or offline — the Gateways page's own status — with when each was last heard
Find device	Finds a tag, sensor or button by name, MAC, model or zone, or lists devices that are silent, late or low on battery, with each one's latest reading. A GPS tracker outside says so — the geofence, trip or stop — with a map link
Zone now	Who is in a zone right now, as the platform counts it, against its capacity
Open issues	What needs attention: open findings, gateways down, silent devices, battery and over-capacity counts
Outdoor activity	What GPS trackers did outside: time out, distance, trips, stops and geofence visits per tracker and day — the numbers on Reports → Outdoor Activity
Search docs	Searches these documentation pages and returns the matching sections with their links. It never reads your data
Propose action	Offers you a change from the action catalogue. Nothing happens until you click Apply, and Apply checks your permission again — with one exception under Autopilot

The four ready-made lookups answer the common questions in one step, over the same views and the same read-only database user as Run SQL. Outdoor activity reads the GPS trail, which is in no view, and only ever your organisation's. Runs with nobody present to approve anything — the heartbeat, the review, Security Watch triage and narration — get only the read-only tools: Describe schema, Run SQL, Gateway status, Find device and Zone now. They cannot propose a change at all.

The chat is also given a few lines about the site — how many gateways are online, stale and offline, how many devices of each kind, how many are reporting, the open findings — refreshed at most once a minute, so "how many gateways are online?" is answered without running anything.

What the views cover. Besides presence, people counts and the apps' own records, the views carry state changes (doors, leaks, lights and switches, air-con on, mode and fan mode), outside weather, gateway outages, hourly tag health (battery voltage, board temperature, restarts, and signal-to-noise and spreading factor for LoRaWAN devices), distance sensors, noise, custom sensor fields and meeting rooms' daily figures.

Counting a venue or a site. The views include Footfall's own table, oaia_report_footfall: registered tags counted once per place, one row per place and day (or hour) at each level — zone, venue, location and the whole organisation. The chat is told to read one level from it for a venue's, a location's or the site's count, and never to add up the zones' day rows, which counts someone who walked through four rooms four times. Operator note: this view needs a one-off database grant for each organisation, made once after the October 2026 update; until it is made, the view cannot be read.

Around the chat

These are covered step by step in the OAIA guide; in short:

• Answers stream. A line shows what it is doing while it works, and the answer appears as it is written.
• Helpful / Not right. The person who asked can rate an answer, with a note on what was wrong.
• Long conversations are compacted. Earlier turns are replaced by a short summary when a conversation grows long (more than 16 messages or about 24,000 characters), or when you press Compact; the latest turns are kept as they were.
• Telegram. Each person can link their own Telegram account to the organisation's bot and ask from a private chat. A change it proposes there is never applied there: it waits on the OAIA page for someone to apply it.
• The mobile app shows OAIA's findings under the OAIA chip in its Alerts tab. It has no chat screen; Telegram is the way to ask from a phone.
• What is kept. Each question is recorded for your organisation with its answer, how long it took and its rating. Whoever operates the platform reads these across organisations on a page of their own (SYSOP › OAIA Usage, not visible to organisations): what people ask, and what OAIA was asked for and could not do — an action not in the catalogue, data it may not read. That list is how new actions get chosen.

How "your data only" is enforced

Three layers, each one sufficient on its own; the view is the one that makes "your data only" a property of the database.

This is a property of the database, not a promise in a prompt. OAIA never queries a base table. Your database carries a set of oaia_* views, each a projection of one table with explicit columns and your own tenant id fixed inside it as a literal. The chat connects as a read-only database user that holds SELECT on those views and nothing else. In front of that, a guard rejects any statement that is not a single read, and caps how long a query may run and how many rows it may return.

So the foreign rows that exist inside every tenant database — the platform's own spaces and placeholder records — are outside the view, and a query cannot reach them however it is phrased. Columns the views leave out (tokens, notes, guard ids) do not exist as far as the model is concerned.

The action catalogue

The only changes OAIA can propose, each a small, named, permission-gated edit to your own records. Every uid is resolved against your organisation before the action is even shown to you; a uid that does not belong to you fails closed.

Area	What it can propose
Spaces and devices	Set a venue's hours · Set a zone's capacity · Assign a device to a zone
Rules	Switch a rule on or off
Tags	Add a tag · Rename a tag · Put a tag on a venue, zone, gateway, device or person — never remove one
Settings	Set the detection speed (stable, balanced or responsive) · Set how long data, audit records or webhook deliveries are kept
Scheduled reports	Email a report on a schedule to whoever asked · Pause or resume a scheduled report
OAIA itself	Acknowledge, snooze or won't-fix a finding · Dismiss a suggestion
A report the platform does not have	Create a data table · Create a rule that adds a row to it · Create a custom report over it · Build all three in one approval (below)
Meeting Room	Release a no-show booking · Set automatic no-show release · Make a zone bookable
Security Watch	Whitelist a person or device · Set armed hours
Facility Management	Open a work order · Change its priority · Cancel a stale one
Toilet Hygiene	Dispatch a cleaning now · Set a target dirtiness · Set the high-traffic trigger
Compliance	Run an assessment · Switch a compliance profile on or off
Data Centre	Set a hall's inlet temperature limits · Set the PUE baseline, target or energy tariff
Warehouse	Set the QC sampling rates · Open a cycle count of an area
Connectors	Re-send a webhook's dead deliveries · Pause or resume a webhook

An app's actions are offered only while the app is switched on. Energy, Roll Call and Visitor Management feed the heartbeat, the review and the chat, but have no actions of their own. Nothing in the catalogue touches administrators, roles, sign-in, AI keys or connector credentials, and nothing deletes.

Applied actions go through the same models as a hand-made edit, so the audit trail records them the same way. App actions are proposal-only: Autopilot never runs them.

A report the platform does not have

Ask for something no fixed report counts — "male and female toilet visits on Level 2, from the corridor counter and the PIR in the male toilet" — and OAIA answers with the three pieces that make it: a data table, a rule on the sensor's own reading that adds a row to it, and a custom report over the table. It names your real devices, zones and fields, and proposes Build a report: one approval that creates all three. The pieces can also be proposed one at a time.

The rule is created switched on, because all it does is add rows; it can notify nobody. It never fires more often than every 30 seconds — the shortest cooldown any rule may have. A rule on an on/off change records each change, at most one every 30 seconds; a rule on a level (a temperature above a line) records at most once a minute unless you ask for a longer gap, because a level that stays true would otherwise add a row on every check.

When a proposal applies itself

Normally a proposal waits for Apply. The exception: when Autopilot is in Act with the Configure tier allowed, a configuration change you ask for in the chat on the OAIA page is applied as it is proposed — on the grounds that you asked for it in so many words. That covers exactly the seven Configure kinds: a zone capacity, venue hours, assigning a device to a zone, and the four report-building actions (so a report built this way exists at once, its rule already switched on). It is skipped, and the proposal waits for Apply as usual, when that kind is paused by an undo or Autopilot's 20 actions for the day are spent. Every such change is listed in the Autopilot section with Undo, and the reply says it was applied. Everything else — switching a rule on, tags, settings, findings, every app action — still waits for a person. Outside the OAIA page — from Telegram, for instance — nothing is ever applied.

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.

Nothing in the ring is adjustable from the settings page; that is what makes the ring worth trusting.

Modes. Off — proposals wait for a person. Shadow — it decides what it would do and writes it down; nothing changes. Act — it applies what its policy allows. Run it in shadow for a week first: shadow produces exactly the record act mode would, so you can read a week of decisions before any are real.

Tiers, chosen in any combination, cover eleven kinds of action:

Tier	Kinds of action	What it means
Draft	Draft a rule	Written inactive, for you to review. 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 · Create a data table · Create a rule that adds rows to it · Create a custom report · Build all three at once	Fills configuration gaps it can infer — a capacity, for instance, is learned from 14 days of counter data with headroom, never guessed, and on its own it never moves a device that already has a zone. The four report-building kinds are made only when someone asks for a report in the chat (above); their rule only adds rows
Operate	Cooling on · Lights on · Switch off	Acts on the building through the smart-home bridge: lights, switches, fans and air-conditioning, on or off. Never a lock, a siren or a scene — nothing it could not put back

What makes the Operate tier act, room by room, from the room's own readings:

When	It does
People present and 27 °C or more	Air-conditioning and fans on
30 °C or more in an equipment room (one whose name says server, plant, UPS, rack, comms, network, battery or data centre), even with nobody in it	Air-conditioning and fans on
People present and humidity 70 % or more	Air-conditioning and fans on, to dry the air
A meeting-room booking starts within 15 minutes and the room is already 27 °C or more	Air-conditioning and fans on, before people arrive
People present and CO₂ 1,000 ppm or more (and no cooling needed)	Fans on
People present and under 100 lux	Lights on
An open critical Security Watch incident in the room	Lights on for the guard and the cameras, and left on until the incident closes
Radar says the room has been empty 10 minutes	Everything that is on, off
Nobody counted, 30 minutes after the venue's closing time (or before opening, or on a day it does not open)	Everything that is on, off — no radar needed

A room being cooled is never switched off in the same run, and a hot equipment room keeps its cooling when empty. Only a device whose name says it is a light is switched on as a light.

The limits are constants in the code, not settings: 3 actions per run, 20 per day, an hour between actions on one target, a room empty for 10 minutes before anything is switched off, evidence no older than 90 minutes, no reversing its own last action on a target within 30 minutes. The air-conditioning setpoint is 24 °C and is never sent outside 20–28 °C. Capacities stay between 1 and 1000.

Undo puts back the state recorded before the action, and it is also a signal: undoing an action pauses that kind for 24 hours, and three undos in a week drop the mode to shadow on its own. A disagreement between you and Autopilot resolves in your favour without anyone having to notice and step in.

The reporting assistant

Reports → AI Reporting answers questions about occupancy, space and the apps your organisation has switched on, in plain language. It is an analyst over the report tables, not a search box: it decides which report answers the question, resolves the dates and the space, calls the tool, and writes the answer around what came back.

Every number it quotes came out of a report tool; the model's contribution is choosing the tool and writing the sentence around the result.

What it can answer

Thirteen report tools, each one a report you could also open as a page, and one for app data:

Ask about	Tool behind it	Notes
Which spaces exist	Space catalog	Called first whenever you name a place, so "the lobby" becomes a uid rather than a guess
How many people were there	Occupancy	Peak and average per bucket, split by source: sensor counts everyone, gateway counts tag carriers. Never summed, never added together. Occupied-or-empty sensors are never read as a head count: they appear separately, as hours occupied out of hours observed
Who is where right now	Right now	Live, not the hourly report. A tag-only zone reads "no tagged person seen", not "empty"
How busy it was	Entry / exit	Door counters' entries, exits, net change — the tool for "how many visitors". Also people inside: entries minus exits running through each day from midnight, now and at its peak; never the plain net over several days, which carries every missed exit forward
How long people stayed	Dwell	Duration buckets and passby / visit / engaged tiers
How many devices were here	Device presence	The Footfall report's figure: your registered tags, each counted once per place however many rooms it went through, per day, per hour, or by venue or zone. Unregistered devices are never stored, so a visitor without a tag is only in the door counts, which come from Entry / exit. Devices, not people; one person may carry several
Temperature, humidity, noise, air	Environment	Daily average, min and max
New versus returning	Loyalty	Return rate and how soon people came back
Where in the room	Room usage	Seats used and busiest spots from a calibrated radar, in floor-plan metres
Which rooms are underused	Space utilisation	Every zone against its operating hours and capacity, with a verdict per zone
Where someone or something is	Entity location	Last sighting: venue, zone, how long ago, a point fix when precise enough. Outside on GPS, the geofence, trip or stop instead, with a map link and no floor plan
Where they have been	Entity trail	Zones in order with times; a gap is "not detected", never "left". Time outside is in the same list — "Depot", "Travelling · 2.4 km", "Stop · 350 m from Head Office"
How far, who went where outside	Outdoor activity	GPS trackers per day: time outside, kilometres, trips, stops and geofence visits; per geofence, visits and time inside
Anything an app records	App data	Bookings and no-shows, visitors and hosts, work orders and assets, toilet cleaning, security incidents, compliance findings, roll calls, meter readings, the data centre, warehouse stock and orders — only the apps you may read

App data

The assistant can read the data of your organisation's apps — not only the report tables — so "how many no-shows in the boardroom last month", "which hosts had the most visitors" or "how many work orders are overdue" get answered rather than declined. It reads the same oaia_* views OAIA reads, through the same read-only database user, and OAIA does not have to be switched on.

An app's data is readable only when both are true:

1. Your organisation has the app switched on. An app that is off is not mentioned, not described and not queryable — the assistant is not told it exists.
2. Your role holds that app's AI Reporting permission. One per app, because an app's data is not everyone's business: Visitor carries names and hosts, Meeting Room who booked, Roll Call who was missing, Warehouse what stock is where.

App	Permission
Security Watch	view-report-ai-app-security
Meeting Room	view-report-ai-app-meetings
Facility Management	view-report-ai-app-facility
Toilet Hygiene	view-report-ai-app-toilets
Energy	view-report-ai-app-energy
Visitor Management	view-report-ai-app-visitor
Compliance	view-report-ai-app-compliance
Roll Call	view-report-ai-app-rollcall
Data Centre	view-report-ai-app-datacentre
Warehouse	view-report-ai-app-warehouse

The Admin role holds all ten. Every other role holds none until you tick them under System → Roles — having the AI Reporting page is not enough on its own. Someone without an app's permission who asks about it is told that their role does not include it, not given an estimate. TV Dashboard has no data of its own, and connector health stays with OAIA.

How it reads them: it first asks which apps it may read and gets back their views, columns and what they mean, then answers with one read-only SELECT at a time — capped at 200 rows and 5 seconds, aggregated in the query rather than listed. Every other view, and every base table, is refused before the database sees the query. It cannot change anything in an app: proposing and applying changes is OAIA's job.

From your own AI client

The same tools are published as an MCP server, so Claude Desktop or another client that speaks the Model Context Protocol can ask the same questions with your client's own model. It signs in with an API key; whatever the key's owner may read in the app — including the per-app permissions above — is what the client may read. Setting it up is under Asking from an AI client.

How it answers

• Table first. The numbers are the answer.
• Then a chart of the same series when there is a series worth comparing — per day, per zone, a split between categories. Never instead of the table, never a single number, and never sensor and tag counts on one axis.
• Then a floor plan when the question was "where is X": the zone outlined, and a dot only when the tool returned a real point. It never invents coordinates.

Rules it is held to

These are in the instructions and in the tools, so a model that ignores the first still meets the second:

• Occupancy is a point-in-time reading. It is never summed into a total; "how many came" is footfall.
• Sensor and gateway counts are different populations and are never added.
• Device presence is devices, not a headcount.
• It is told your real venues and locations up front, and may name only those or what a tool returned. In one early case a model asked about "sites" filled the gap with plausible city names that did not exist; listing the real ones removed the gap rather than asking it not to fill it.
• Relative dates are resolved to explicit dates before any tool is called.
• Off-topic questions are declined. Follow-ups, clarifications and "are you sure?" are not off-topic.

Every answer records its tokens against your usage, and the page shows this month's total.

The rule author

In the rule builder, Describe turns a sentence — "tell the facilities channel when the server room goes above 28 degrees for ten minutes" — into a draft rule. The model reads the rule vocabulary (metrics, comparators, windows), your space names, and the smart-home devices you have exposed, and calls one tool that validates and hands back a draft.

The draft is not saved. It appears in the builder, where you finish it and save it through the same path as a hand-built rule — same validation, same permission, same audit entry. Three things are enforced by the validator rather than by the prompt:

• A metric it invents is rejected; only the enum the builder knows exists.
• Channels are notification-only: alerts, messages, the smart-home bridge. It cannot draft a rule that opens work orders.
• A draft that passes the validator is one the save endpoint will accept, so you are never shown a rule that cannot be saved.

Security Watch

Security Watch is the app where the model is allowed to judge — once, on one kind of situation — because that situation cannot be decided by a list.

The model touches two things: the one verdict on an out-of-habit candidate, and the wording on an incident that already exists.

What decides on its own

Six detectors run every five minutes with no model involved. Each produces evidence, a severity and a fingerprint, and each can be switched off individually:

Detector	Raises
After-hours presence	Anyone not whitelisted in an armed zone; critical if the zone is also restricted
Restricted zone	Someone not on the zone's allowed list — an unbound device is never allowed
Unknown device	A BLE device nobody registered, lingering in a monitored zone for longer than your threshold
Panic button	A press on any registered panic button. Always critical, never suppressed
Environment	Heat at the alert level, or rising hour-over-hour like a fire. Never suppressed
Blind spot	A monitored zone whose gateway has gone quiet — which looks exactly like an empty zone, and is worse

Out of habit — where the model judges

The seventh detector asks a question no list can answer: is this person doing something they do not normally do? Nobody maintains "which of a hundred staff may enter which of forty rooms". Instead each person's own 30-day history is their permission: a tag that has never been in the L5 server room and is there now is worth a look. A room never used at this hour on this weekday and in use now is worth a look.

"Worth a look" is all the detector decides. The candidate goes to triage, where the model is handed the whole picture — who this is, where they usually are, who usually uses the zone, whether the zone is sensitive, whether there is a booking, who else is present, what the hour says — and asked one question: should a guard be told now? It may run up to two read-only queries for more context (the person's trail today, say). It thinks like a head of security who knows the building: normal explanations first — visiting a colleague, working late once, a cleaner's round, a room used because another was full — and abnormal only when the head of security would want to hear about it.

• Only an abnormal verdict becomes an incident, with the severity the model chose from warning or critical and the wording already written.
• Each situation is judged once a day, at most five new ones a sweep.
• Every verdict — normal or abnormal — is kept, with the reasoning, so you can see what it decided and why.
• Without an AI configuration, candidates are never incidents. The six other detectors are unaffected.

Narration

Every new or escalated incident — from any detector — gets two lines from the model shortly after it appears: what this most likely is, and the first thing to do, from a fixed list (dispatch a guard, call the contact, check cameras, check the zone, evacuate, expected — ignore, no action). The model reads the evidence and may look a little further; it decides nothing. At most five incidents are narrated per sweep; without a provider key, incidents carry the detector's wording instead.

What the model cannot do here

• Raise an incident from the six deterministic detectors, or suppress one.
• Notify anyone. Recipients, channels and thresholds are yours, set in the app.
• Resolve an incident. Only a person can.
• Reach beyond the oaia_* views. Triage and narration use the same read-only boundary as the OAIA chat.

An incident's Ask OAIA button opens the chat with that incident in front of it, so "what else was happening on Level 5 at that time?" is one question away.

Decode Assist

When a sensor advertises something Omaya has never decoded, Sensor Onboarding captures its frames. Decode Assist reads those frames — and the manual, if you uploaded one — and proposes a decoder: where each field sits, how it is scaled, what the device is capable of. One turn, no tools, a structured proposal out.

The proposal is never trusted on its own. Omaya runs it over every captured frame and shows you the resulting numbers next to the raw bytes before anything is saved; a decoder that produces 300 °C is obviously wrong, and you see that before it goes anywhere near a report. The full walkthrough is in Teaching Omaya a new sensor.

Summaries inside the apps

Two apps ask the model to put their own findings into words for the people who use them. In both, the app has already done the working out; the model only chooses what to say first and how to say it.

Toilet Hygiene — the AI summary. On a toilet's Overview, managers see an AI summary beside the app's own verdict and to-do list: two sentences on how the toilet is doing and why, a sentence on what is likely in the next hours, and up to three short things to do. The model is handed the facts the app computed for that toilet — its dirty score and how fast it is rising, today's cleaning, guest ratings, expected visits and the to-do list — and told not to use any number, time or name that is not among them. A reply in any other shape is dropped. The summary loads after the page, so a slow provider never holds the page up, and it is written once per toilet per state, reused for up to an hour rather than rewritten every time the score moves. Without AI, or with the cap reached, the page simply keeps the app's own wording. See Toilet Hygiene.

Data Centre — the practice review. The Practice page checks the site against 17 operating practices on its own. Ask OAIA for a review asks the model which of the unmet ones to deal with first — at most three, each with why it matters here and now and a first step someone can take this week. It may pick only from the checks the site does not meet; a practice it names that is not on that list is dropped. A review can be asked for at most once every five minutes. See Data Centre.

What leaves your instance

Only what a feature needs for the one request:

• To the provider you chose: the prompt — the facts Omaya assembled, the tool results, your question — and the model's reply. Under your own key, that traffic is between you and your provider.
• Never: your provider key itself is stored encrypted inside your own database and never appears on a page; the read-only database credentials never leave the instance; nothing is sent when AI is off or the cap is reached.

Nothing is used to train anything on Omaya's side. What your provider does with requests is governed by your agreement with them, which is one reason bringing your own key is offered.

When it disappoints

OAIA says nothing. 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.

Findings or incidents have no prose, just detector wording. AI is off for your organisation, no key is available, or the monthly cap is reached. The Usage page says which.

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, and until it is done the heartbeat still works without the chat.

The reporting assistant says it cannot see an app. Either the app is not switched on for your organisation, or your role lacks that app's AI Reporting permission — see App data. An administrator adds it under System → Roles.

The reporting assistant names a place you do not have. It should not; it is told your real venues and refuses to invent. If it happens, the space catalog is worth checking — a venue with no name is one it cannot list.

Security Watch never raises out-of-habit incidents. No AI configuration, or the cap is reached. The triage record on the app's settings page shows verdicts if any were made; an empty record with candidates present means the model was never asked.

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. No tier is allowed, or its preconditions are not met — a room not empty long enough, evidence too old, a target inside its cooldown, the day's budget spent. Shadow mode's record says what it decided and why.

A reply was cut off or came back empty. Reasoning models spend part of the response budget thinking. Raise Max response tokens on the AI card, or pick a model that does not reason; the OAIA review and Decode Assist already raise their own floors.