AI in Omaya

Omaya uses a language model in five 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.

Five 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	Questions in plain language answered from the report tables, with a table, a chart and — for "where is X" — a floor plan	Reports → AI Reporting
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	Sensor Onboarding	A proposed decoder for a sensor Omaya has never met, checked against every captured frame before you accept it	Devices → Sensor Onboarding

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	Nothing directly. It can propose an action from a fixed catalogue; you click Apply	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 seven 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	Twelve report tools over the same tables the report pages read	Nothing	Yes	Report AI permission
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

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 superuser change nothing about what the tools will run.

Setting it up once

All five features follow one configuration, the A.I Model 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	platform
Gateway signal	A gateway's received signal has dropped against its own history	platform
Ingestion silence	No data of any kind is arriving	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 is heading for replacement	platform
Environment baseline	A temperature has drifted from its own baseline	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	A work order is past due, or nobody has taken it	Facility Management
Calendar sync	A meeting-room calendar has stopped syncing	Meeting Room
Security incident unattended	An incident has sat unacknowledged, or open, too long	Security Watch
Toilet dirty unattended	A toilet has been past its dirtiness target without a cleaning	Toilet Hygiene
Visitor overstay · waiting	A visitor is past their expected departure; a visitor has waited too long for approval	Visitor Management

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 three 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
Propose action	Offers you a change from the action catalogue. Nothing happens until you click Apply, and Apply checks your permission again

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 — superuser-tagged spaces, aggregate sentinels — 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.

Platform	Meeting Room	Security Watch	Facility	Toilet Hygiene	Connectors
Set a venue's hours · Set a zone's capacity · Switch a rule on or off · Assign a device to a zone · Acknowledge, snooze or won't-fix a finding · Dismiss a suggestion	Release a no-show booking · Set automatic no-show release · Make a zone bookable	Whitelist a person or device · Set armed hours	Open a work order · Change its priority · Cancel a stale one	Dispatch a cleaning now · Set a target dirtiness · Set the high-traffic trigger	Re-send a webhook's dead deliveries · Pause or resume a webhook

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

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:

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	Fills configuration gaps it can infer — a capacity, for instance, is learned from 14 days of counter data with headroom, never guessed
Operate	Switch something off · Cooling on · Lights on	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

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. Cooling comes on above 27 °C when occupied and above 30 °C even when empty; the 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 and space 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

Twelve tools, each one a report you could also open as a page:

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
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	Footfall	Entries, exits, net change — the tool for "how many visitors"
How long people stayed	Dwell	Duration buckets and passby / visit / engaged tiers
Detection mix	Device presence	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
Where they have been	Entity trail	Zones in order with times; a gap is "not detected", never "left"

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.

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 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 A.I Model card, or pick a model that does not reason; the OAIA review and Decode Assist already raise their own floors.