We prove the work was actually done
Hotam is a project assurance platform. It answers one question: was the work an organization said was completed actually completed correctly, and can that be proven with objective evidence?
The problem: done is not the same as correct
Every project ends with someone marking it complete. A ticket closes, a checklist is ticked, a status turns green. That record says the work was done. It does not prove it.
In IT projects the gap shows up a few weeks later. Four laptops never got the security agent because they were switched off that afternoon. A license was queued and never applied. A backup ran once and has not run since. Nobody lied; the environment simply moved on from the moment the note was written. The client finds out first, and the rework lands on the service provider.
Most quality checks look at the record of the work. Hotam looks at the work itself.
The approach: expected, observed, evidence, decision
Every result in Hotam comes from the same model:
- Expected state: what the project promised, taken from its scope and turned into specific requirements that a person reviews
- Observed state: what the systems of record actually report, read through read-only connections
- Evidence: every fact keeps where it came from, when it was observed, and which device or user it is about
- Decision: fixed, tested rules compare expected with observed and return Passed, Failed, Warning or Unknown
AI reads. It never grades.
Scope documents are written in plain language, and AI is good at reading language. So Hotam uses AI for one job: turning a project's scope text into proposed requirements. A person reviews and edits them before anything runs.
AI never decides whether a requirement passed or failed. That decision is deterministic code, the same input always gives the same answer, and every answer can be traced to its evidence.
Unknown is better than a false pass
When a system cannot be read, or does not hold the fact a check needs, the result is Unknown, with the reason. It is never shown as passed. A verification tool that turns green when it does not know is decoration, and the first time a client discovers one of those greens, every other result becomes suspect. We would rather show you an honest gap.
Starting with MSPs
We start with managed service providers and the IT projects they deliver: client onboardings, Microsoft 365 migrations, security rollouts, device deployments. The evidence already lives behind the APIs of the systems MSPs run every day, such as their PSA, RMM, Microsoft 365 and documentation, and the cost of a gap is easy to see.
Today Hotam reads Autotask, NinjaOne, Microsoft 365 and IT Glue. See how we integrate.
Where it goes next
The engine is not specific to IT. A work order, a shipping rule or a definition of done also says what should happen, and a system of record also says what did. Manufacturing, warehousing, software delivery and field service are the direction we are building toward, with people who know each industry. They are not available today, and we will not pretend otherwise.
Talk to us
We are looking for a small number of MSPs to work with as design partners. If you want to see what your last project QA missed, write to hello@hotam.io.
From completed to verified.
Bring one real project. Hotam reads the scope, checks the systems, and shows you what your last QA missed. If it finds nothing, you have proof. If it finds something, you found it before your client did.