How MaintenanceOS handles a dangerous repair report

Not the AI.

In MaintenanceOS, the AI's job is language. It listens to or reads what someone reports and turns it into a structured repair request. What happens next is decided by fixed rules on our server: how safe it is, where it sits in the job's lifecycle, and whether it needs approval. The AI can't override those rules, however the conversation goes.

That's deliberate. Language models are good at understanding people. They shouldn't be the last line of defence on a dangerous report.

Here's the route a report takes when the rules flag it as dangerous. It's an illustration, written for this page.

Some reports can't wait in a queue. Our rules look for the warning signs of a safety-critical problem in what's reported. When they find one, the report can enter escalation and human review, and a critical-safety latch keeps it with a person until someone authorised clears it.

We've deliberately not published the list of report types our rules treat as safety-critical.

Our product team hasn't signed it off in our claims register yet, and we'd rather tell you it's missing than describe it vaguely.

The rules work from the words people use, and no rule set catches every way a danger can be described. So keep telling your residents what to do in an emergency, too.

Where there's an immediate danger to life, the assistant's guidance is to call 999. Not 911, and not "we'll get someone out". It doesn't give the gas emergency number or a power-cut number, so keep those in your own tenant information and out-of-hours script.

What decides "safety-critical" is the rule set, not the AI's judgement on the day.

When a report is marked critical for safety, MaintenanceOS sets a latch on it. While the latch is on, the case stays with a person, and only someone with the authority to clear it can do so.

Think of it as the job card that stays pinned to the board until the right person signs it off.

An authorised person. Not the AI, and not the caller.

Clearing a latch is a human decision, and it's recorded. The point isn't to slow your team down. It's to make sure that when a dangerous report is closed, a real person with the authority to close it made that call.

Which roles count as "authorised" isn't published yet.

That includes whether anyone outside your own team, such as a contractor, could ever clear a latch. It hasn't been signed off in our claims register.

This is the rule tenants feel most, so it's the one we're strictest about. The assistant is built not to invent:

• a booking or an appointment time
• that a contractor or engineer has been sent
• a refund, compensation or a waived fee
• account information
• a safety reassurance ("it'll be fine, leave it till Monday")

If nothing has been arranged, it's built not to say it has. The report is recorded, and the gap isn't filled with a promise. A tenant told "someone's on the way" when nobody is will be angrier than one told the truth, and they'll be right to be.

MaintenanceOS has no authority to move money. Quotes and invoices go through checks, but there's no payment, refund, compensation or client-money execution in the system.

A caller who asks for a person can ask to be transferred, but live transfer is still under testing, so we don't yet promise the call will reach someone. If something goes wrong technically, the system is built to fail safe. It doesn't quietly hand the call somewhere unplanned.

Consequential actions leave evidence: what was asked for, what was attempted and what actually happened. MaintenanceOS keeps audit events and action evidence alongside the work order, so you can see the history of a repair without relying on someone's memory.

There's one rule that matters most here. The system only reports something as done when there's evidence it succeeded. "Job booked" is only said if the booking actually exists.

MaintenanceOS is built for many organisations on one system, and it keeps each one's records apart: properties, residents, contractors, work orders, jobs, communications, exports, action evidence and call records. Tenant-isolation controls sit in the code and are covered by tests. One letting agent's data is designed to be kept apart from another's, and an operation for one organisation is tied to that organisation.

Calls and callbacks from the phone provider are signature-checked, so requests pretending to come from it are designed to be rejected.

Your properties, residents and contractors sit in your own organisation's space in MaintenanceOS, and work orders, jobs and communications are tied to them.

What the AI can't do is switch the safety floor off. The rules that decide safety, lifecycle and approvals sit above the AI, and they stay there. Which settings your own team will be able to change isn't published yet.

In a demo we'll show you how your portfolio would be set up, and what's in place now versus still being built.

At our 30 September 2026 product checkpoint (code version 498ad82), all 196 targeted claims-and-safety tests passed. They're automated tests run against the product code in a controlled test set-up, not on a live service. They cover explicit transfer, the "never invent" rules, tenant isolation, lifecycle integrity, decision rules, invoice rules and state-machine controls, among others.

Earlier, on 10 September 2026, local acceptance was evidenced: a full test pass, readiness checks, and backup and restore. "Local" means run on our own machines, not on a hosted service.

These are dated, targeted results. They show that specific rules behaved as designed in testing. They don't prove every rule will hold in every real situation, and voice intake is still under testing.

Pre-launch: MaintenanceOS is still under testing, and we're taking early-access requests.

We won't publish uptime figures, logos or star ratings we haven't earned.

No tool makes you compliant on its own, and we won't pretend otherwise. Your legal duties as a landlord, agent or housing provider stay with you. What MaintenanceOS is designed to do is capture repair reports properly, keep dangerous ones in front of a person, and leave a record of what happened.