Product
What it does when nobody is watching
It works out what needs doing and does it, in the systems where the work lives, inside a ceiling you set. Then the four mechanics that stop an unattended run going quietly wrong, none of which ask you to trust the model.
The work
A sentence, a schedule, and a ceiling
You do not draw a flow. You write the outcome, pin the systems it may touch, and set how far it may go: read only, ask every time, or act.
Write the outcome, not the flow
You state what should happen and pin the sources it may read. It plans each run itself, so reality changing does not break a diagram.
A ceiling you set, enforced server-side
Read only, ask every time, or act. Every call is classified before it runs, whatever the connector's token would allow.
A dry run before it is live
Every automation starts read-only. You watch one run end to end and see what it would have done, then raise the ceiling.
Watches that explain themselves
Backtested over 90 days before they can fire once, and when one fires it opens with what moved and why, not just that a threshold was crossed.
Apps, when the same work comes round again
A conversation worth repeating becomes something you open: a queue of renewals decided one at a time, a round where the team scores each site and adds a photo, a close where a step is blocked by a number it read. Aira shows what it would contain before anything is saved.
Analysis comes back as files you can send to someone: charts, spreadsheets, Word and PDF reports, decks, and voice. How every call is classified, where your data goes and what it is never used for are set out on the security page, and the same tiers and audit trail are available to your own code from the API.
What it reads
Your warehouse, your ledger, and the folder nobody cleaned
Warehouses and databases directly. Everything else over MCP, which means any vendor publishing a server, and hundreds already do. Plus the material that was never in a database: contracts and reports, site photographs, and the spreadsheet with merged headers.
Why you can trust it
Four mechanics, and each one makes the next possible
Metrics mean one thing
Definitions live as versioned records, not model interpretation. Changing one creates a new version, so an answer from March is still readable in March's terms. Without this, two runs of the same question are not comparable and nothing below is possible.
on_time_delivery_pct
v4Deliveries scanned within the promised window, over all completed deliveries.
Caveat travels with every answer: excludes deliveries refused at the door. Those are refusal_rate.
Also asked as: on time, OTD, delivery performance, SLA hit rate. Aira picks which governed metric answers a question. It never decides what the metric means.
It tells you when a number moves
Ask something twice and Insighter compares the new result against the frozen one, then names the cause: data that landed late, a backfill, or a definition that changed. A dashboard cannot do this, because it keeps no memory of what it last showed.
You asked this in April. The number moved.
Then
88.1%
Now
91.4%
A backfill rewrote history on 12 May. The April answer was correct for the data that existed when it was given.
Honest about freshness
Answers report how current each source actually is against the interval it promised. Where the data cannot support the recency your question implies, Insighter says so instead of answering anyway.
| Source | Age | Promise | State |
|---|---|---|---|
| orders_db | 4 min | 1h | within |
| ga4_export | 31h | 24h | stale |
| pricing_sheet | unknown | none | no promise |
Provable on your data
Accuracy becomes evidence you can export rather than an opinion you have to take on trust.
Your question set, scored weekly
96%
Curate questions whose answers you already know. The failures are usually not wrong answers, they are metrics nobody has defined yet, which is exactly the queue a data team wants.
See it on your own data
Pick the report you rebuild every week and watch it run once. That is usually enough to know.