Decision record and audit record: two records with two jobs in AI Otel
A decision record explains what changed and who approved it. An audit record proves the history was not altered. Learn the difference, the limits of undo, and how to test any vendor.
Contents
Key takeaways
- A decision record answers what was decided and whether it can be undone; an audit record answers whether anyone touched the history.
- Small changes apply automatically and are logged, larger ones wait for a person, and the line between them is fixed in code rather than set by the hotel.
- Every change can be undone except a message already sent to a guest, because unsending it is not something software can do.
- Past records can only be appended; changing or deleting them is closed in the database, and if someone still alters one, the chain shows it.
- Tamper-evident is not tamper-proof: the record cannot hide an alteration, which is a weaker and more honest claim than saying alteration is impossible.
A decision record says what changed, who or what proposed it, who approved it and whether it can be undone. An audit record says whether anyone touched the history: entries can only be appended, and the chain shows any alteration. AI Otel built both; both are built and run in a public demo environment.
At two in the morning a weekend rate moves. By nine the general manager wants three answers: what changed, who or what changed it, and can we put it back. A change notification answers the first. The other two are the ones worth testing for. After reading this you will be able to tell the two records apart, know which questions each one answers, and test any vendor, including us, with a short checklist.
What is a decision record in hotel software?
A decision record is a structured entry written at the moment something changes: the previous value, the new value, the time, who or what proposed the change, who approved it, and whether it can be reversed.
It is not a chat transcript and not a screenshot. It is data a manager can read without calling an engineer: a short list of changes, each with its reason attached. The reason field is what separates it from a notification. A message that says the rate is now lower tells you nothing about why, and nothing about how to get back.
Actions sit in three safety tiers: some run directly, some need one person's confirmation, and the most sensitive need two. Small changes apply automatically and are logged. Larger ones wait for a person before they take effect. The line between small and large is fixed in the software, not a setting the hotel adjusts, so a vendor should be able to tell you exactly where it sits.
The record is written when the change happens, not rebuilt afterwards from memory or from a nightly summary. A record assembled later is a reconstruction, and a reconstruction can be wrong. For the reader, the test is simple: pick any change from last week and ask the system to show you the previous value and the reason. If it cannot, you have an activity log, not a decision record. The same idea applies to AI assistants: what the PMS assistant can do and what waits for a person depends on which tier each action sits in.
What is an audit record, and how is it different?
An audit record answers a different question: has anyone touched the history? It is the record of the record, kept so that the decision record can be trusted later.
Past records can only be appended. Changing or deleting an entry is closed in the database itself, not hidden behind a permission screen that an administrator could switch off. Each entry is linked to the one before it. If someone still alters an entry by another route, the link no longer matches and the chain shows the break. That is the mechanism behind the word tamper-evident.
The division of labor is clean. The decision record holds the content of decisions; the audit record holds the integrity of the container that stores them. You read the decision record to find out why a rate moved. You read the audit record to satisfy yourself that the answer was not edited after the fact.
A system with only a decision record can tell you what happened but not whether the account is intact. A system with only an audit record can prove nothing was touched while telling you nothing about why anything happened. Both are needed, and neither substitutes for the other. The audit record is also where events that are not decisions appear: an AI assistant booking a room on a demo property is an event to be audited, not a proposal that a person approved. For a fuller standard of what a good AI audit trail should show, both records are the minimum.
What does tamper-evident mean, and why not tamper-proof?
Tamper-evident means an alteration cannot be hidden. It does not mean an alteration cannot happen, and no software vendor can honestly promise that.
Anyone with enough access to a server can change bytes. What software can do is make the change visible afterwards, so that a reader knows the account has been disturbed. The mechanism is two things together: append-only storage at the database level, and a chain that links each entry to its predecessor. Either alone is weaker.
The weaker word is the more useful one in an audit conversation. An accountant or an inspector asks whether you would know, not whether interference is impossible. It also sets the right expectation inside the hotel: staff should understand that the record is designed to reveal edits, not to make them unthinkable. Vendors slip into stronger language because it sounds better in a sales meeting, and the stronger language is the one that fails first under questioning. This is one reason the safety layer came before the model choice in how we built our system.
Watch outThree phrases to strike from any vendor answer
Strike "tamper-proof", "blockchain" and "impossible to change". Ask instead: if someone altered an entry, how would I find out, and what would I see?
Which changes can be undone, and which cannot?
Every change can be undone, except a message already sent to a guest. Undo is itself a new entry: the original stays where it is and the reversal is recorded beside it.
Undo is not erasure. If a rate is restored, the record shows the change and the restoration, in order, with both timestamps. Erasing the first entry would leave a reader unable to explain the second. The exception is outbound communication. Once a message reaches a guest, the guest has read it. Reversing the record would make the record disagree with what actually happened in the world.
The same logic already governs money in a hotel system: financial records are never deleted, corrections are voided and reversed, and the night audit closes the business day. The decision record borrows that discipline for operational changes. For a hotel team, the practical consequence is a rule: treat anything that leaves the building as its own class of action, and put a person in front of it. A confirmation step costs seconds; an unsendable message costs a guest. The wider class of irreversible actions in hotel AI: messages, refunds and invoices deserves its own review.
Key pointThe one irreversible class
A message already sent to a guest cannot be undone. Everything else in the decision record can be reversed with a new entry. Design the confirmation step around this class first.
How do the two records work together?
They run side by side on the same event: the decision record explains the change, and the audit record fixes it in place so the explanation can be trusted later.
For example, a revenue manager lowers a weekend rate by a small amount. The change is small enough to apply directly, so it takes effect and is logged with the old value, the new value, the time, the person and the reason. The same event lands in the audit record as an appended entry linked to the one before it. Nothing about the content changes; what changes is that the entry can no longer be quietly rewritten.
Two days later the manager reverses it. That produces a second decision entry and a second audit entry. The history now reads as a change and a correction, which is the truth.
For example, on our demo property an AI assistant finds, holds and books a room within the limits the hotel sets. That booking is audited, not ledgered as a decision: it appears in the record as an event with its details, not as a proposal that a person approved. Keeping those two shapes apart matters. If every automated event were written as a decision awaiting approval, the record would fill with items nobody decided, and the real decisions would be harder to find.
This is where the AI Otel decision record and its companion stand today. The decision record is built and runs in a public demo environment: small changes apply automatically and are logged, larger ones wait for a person, and every change can be undone except a message already sent to a guest. The audit record is built in the same environment: past records can only be appended, changing or deleting them is closed in the database, and if someone still alters one, the chain shows it.
| Question | Decision record | Audit record |
|---|---|---|
| What it answers | What was decided, by whom or what, and can it be undone | Has anyone touched the history |
| What it holds | Previous value, new value, time, proposer, approver, reason, undo state | Every entry in order, each linked to the one before |
| Who writes it | The system for small changes, a person approving larger ones | The system, whenever any entry is written |
| Can a past entry be edited | No, a correction is a new entry | No, editing and deleting are closed in the database |
| What it never shows | Whether the history itself was altered | Why a decision was made |
What should a hotel ask a vendor about its records?
Ask for a demonstration on a real change from your own property, not a slide, and ask the same seven questions of every system you compare.
A vendor that can answer these in plain language, without an engineer in the room, has built the record for hoteliers rather than for its own developers. If the answer to the edit question is a permission setting, ask who can change the setting. That is where most claims quietly fall apart. Ask for the export too: an accountant, an inspector or a group owner will eventually want the record outside the system, and an export that only an engineer can read is not an export.
Checklist
- Can I see who or what made this change, and when?
- Can I see the previous value next to the new one?
- Can I undo it, and does the undo appear as a new entry rather than replacing the old one?
- Which actions can never be undone, and does the system warn me before them?
- Can an administrator edit or delete a past entry, and who can change that setting?
- If someone did alter an entry, what would I see, and how quickly would I see it?
- Can I export the record in a form my accountant can read?
What to do next
Ask your vendor to show you both records on one real change from your own property, in plain language, before you sign anything. The two ideas fit together simply: the decision record explains what happened and whether it can be reversed, the audit record keeps that explanation honest, and undo repairs the state without rewriting the story. If you want to see how we built ours, request a briefing at https://ai-otel.com/contact.
Frequently asked questions
Is a decision record the same as an activity log?
No. An activity log usually shows that something happened and when. A decision record adds the previous value, the reason, who or what proposed the change, who approved it, and whether it can be reversed. Without those, a manager can see motion but cannot explain or undo it.
Can a booking made by an AI assistant be undone?
A booking can be cancelled the way any booking can, and the cancellation is recorded as a new entry rather than by deleting the original. What cannot be undone is a message already sent to a guest, because the guest has already read it. Bookings by AI assistants are audited as events, not written as decisions a person approved.
Does an append-only record use blockchain?
No. Append-only storage at the database level plus a chain linking each entry to the previous one gives the property that matters: an alteration cannot be hidden. Blockchain is a different design with different costs, and a hotel does not need it to answer an auditor's question.
Who inside the hotel can see these records?
The hotel's own team reads its own decision record in plain language, and the audit record exists so that the same team, an owner or an external auditor can check the history later. Each hotel's data is separated at the database level. Ask any vendor to show you the export before you rely on it.
Are these records in use in hotels today?
Both are built and run in a demo environment. OtelCiro, the ecosystem's hotel growth and consultancy arm, works with paying hotel clients today, and the hotel operating system is built and working, ahead of launch.