Your hotel runs on promises.
Who checks they were kept?
Your systems say it’s done.
We go and look.
A refund promised at the desk. A rebooking agreed on the phone. A rate override keyed in at 2am. Your systems will tell you all three happened. Siringo plugs into those same systems and checks, one by one, whether they actually did.
Three things we never mix up
- tried ≠ done
- confident ≠ proven
- no evidence ≠ all fine
Works across
- PMS / CRS
- CRM
- Payments
- Service desk
- Comms
What it costs today
Nobody catches these.
three teams, each seeing their own bit
Three ordinary failures. In all three, every system did exactly what it was told to do, so no alarm goes off and nobody goes looking. The money leaves weeks later, on a different line, and no one connects it back to the promise that started it.
A refund promised at the desk, never paid.
Your systems sayrefund noted on the reservation · no payment record
What it costsA chargeback, something free to make up for it, and a review that outlasts both.
A rate override nobody was allowed to make.
Your systems sayrate applied · no approval on file
What it costsMoney off the rate. It balances perfectly in the books, so nobody ever asks.
A date change confirmed to the guest, wrong in the PMS.
Your systems sayreservation updated
What it costsA guest walked at check-in: the free night, the rebooking, the rate difference.
The GM sees the apology, not the cause. Finance writes the leakage off as noise. The brand asks for evidence at audit and gets handed the log of the system that made the mistake in the first place. Siringo is one record all three can read, kept by the only party that did not make the promise. We do not publish a figure for what this costs you, because we have not measured your hotel. You already have the three numbers it is made of: chargebacks, comps, and rate variance nobody could explain.
What it does
We check every step.
A guest asks for something. Someone decides, someone promises, someone acts, and a record changes somewhere. Siringo checks each of those steps by itself, using evidence it collects itself. Never the word of the system that made the change.
- Intent & contextguest intentwhat they asked for
- required contextwhat had to be passed on
- Governancepolicywhich rules applied
- authoritywho was allowed
- Actor behaviordecisionwhat was decided
- promisewhat we told them
- actionwhat was tried
- System truthsystem mutationwhat actually changed
- final outcomewhat is true now
It only counts as done when the outcome is really there and the evidence shows it. Getting the earlier steps right is not enough on its own.
How it works
Six questions, one at a time.
never averaged into a single score
Each question gets its own answer, and none of them lean on each other. If we are missing the evidence a question needs, the answer is INCONCLUSIVE. That never gets rounded up to a pass.
Every question can come back as
- PASS
- FAIL
- INCONCLUSIVE
- NOT APPLICABLE
one of the four means we could not tell, and that is never counted as a pass
understanding
Was the guest understood?
information
Did the details get passed on?
policy
Were the right rules applied?
authority
Was this person allowed to do it?
execution
Did the systems really change?
outcome
Did the guest and the books end up right?
Evidence & controls
Why you can trust the answer.
Anyone can put a green tick on a screen. These seven rules are what make ours worth something. Each one is built into the database, the evaluator or the permission checks. None of them live in a policy document.
The same transaction, opened up.
- The contractJudged under Date Change Mismatch, at the exact version shown. Not against whatever the rules happen to say today.
- The findingInformation failed, and the record says right there that this is the one deciding the whole result.
- Not asked here4 of the 6 questions are not asked under this contract. They are struck out, not left blank. Not asked is not the same as passed.
A real page from our demo environment, running on a made-up hotel. No customer data.
EvidenceWe go and look in a second system
Where a workflow says the action or the outcome has to be proven, we only pass it if we go back to a separate system and find the change sitting there. If there was genuinely nothing to look at, the workflow has to say so up front. A vendor’s own log is that vendor’s word for it.
connector.verifyMutation() · we read it back ourselves, we never take the actor’s word for it
EvidenceWritten once, never rewritten
Evidence, audit entries and finished verdicts can only be added to. The app’s database user can read and insert, and that is all it can do. Nobody gets to tidy up a verdict afterwards.
append-only triggers · the app may SELECT and INSERT, nothing else · a redaction keeps the hash and leaves a tombstone
EvidenceJudged by the rules that were live at the time
When a workflow is published we seal a copy of it. Every transaction records the exact version it was judged under, so a verdict from last quarter still means what it meant last quarter.
sha-256 over the sealed copy · version and digest locked to each transaction
ControlNobody signs off their own work
Whoever raises a high-risk action cannot be the one who approves it, and there is no setting to turn that off.
ControlAn approval covers one thing, once
An approval is tied to one exact action, and it is used up the moment it is spent. It does not carry over to the next action, or to a changed version of the same one.
ControlEvery override is written down
You can override a control. Running a hotel needs that. What you cannot do is override one quietly: each one goes into the audit trail with who did it, when, and to which action.
ControlYour data stays yours
Which organization you belong to is decided on our server, never taken from the request. Ask for another company’s record and you get a 404, not a 403. A 403 would tell you the record exists.
The evaluator is deterministic. The same evidence gives the same answer today, in an audit two years from now, and to anyone who runs it again. The long version of each rule, and of what we do not claim yet, is on the security page.
Same bar for everyone
Your team
Front desk, reservations, revenue, finance. Anyone who can promise a guest something.
Outsourced centers
Contact centres answering, promising and acting in your name.
Integrations
Any system with a login that can change a record.
AI agents
Bots and copilots acting on a guest’s behalf.
Same six questions, same evidence, whoever did it. Being an AI is not an excuse, and it is not a reason to be suspicious either.
The mark
You can’t stamp your own work.
Silver gets its hallmark from an assay office, not from the silversmith who made it. That one rule is the only reason the stamp is worth anything. Same idea here.
Ours is two stamps, deliberately a little out of line. Only where they overlap is the ink solid, and that overlap is the part two separate records agree on. Everything outside it got recorded, but not confirmed.
It’s a real system, not a video.
Our demo environment runs the real evaluator over a made-up hotel. Real transactions, real verdicts, and no live guest data anywhere near it. We give out access on request, because what you get is a running system rather than a walkthrough.