On this page
The two failure modes are familiar enough that most operators have run both, usually in that order.
The trusting version: standards are agreed, everyone means it, and nobody checks. Things drift. The owner notices six weeks later, is disappointed, and has the same conversation again. Over time the team learns that agreements are aspirational, which is a more corrosive lesson than any individual failure.
The scrutinising version: the owner starts checking. Things improve. The team experiences the checking as distrust, which it partly is, and the strongest members, who have options, leave first. The venue is now more compliant and worse.
Why both fail for the same reason
Both approaches treat accountability as a relationship between two people, where one is either trusting or watching the other.
Framed that way it cannot work. Trust without verification is not a system, it is a hope. Verification directed at a person is surveillance, whatever it is called, and people respond to surveillance by managing the signal rather than doing the work.
The version that works moves the question off the relationship. Not is this person doing their job, but did this specific thing happen, and what followed. That sounds like a semantic distinction and it is the whole difference.
Four properties of accountability that does not corrode
It is about a thing, not a person
"Every comp over ten dollars gets a reason logged" is a thing. It is checkable, it is impersonal, and checking it is not an accusation. "Are you managing the comps properly" is a judgement about a person and will be heard as one.
It is visible to everyone it applies to
A standard checked privately reads as a case being built. The same standard, with the current state visible to the team, reads as a shared target. Fair and visible beats personal and private, reliably, and the difference costs nothing to implement.
The interval is short
A check six weeks after the fact is an audit. A check the following week is a routine. The short interval is what makes it unremarkable, and unremarkable is the goal: accountability that feels like an event is accountability that feels like a threat.
It records the outcome, not just the compliance
Whether the thing was done matters less than what happened when it was. A team asked to do something that then visibly makes no difference will stop doing it, correctly. Recording the result is what separates a standard from a ritual.
The thing owners get wrong first
Too many things at once.
An owner who has just gained visibility into their venue typically finds eleven things that are wrong and tries to address all of them. The team experiences a sudden wave of new requirements, none of which are followed up individually because there are eleven, and the whole exercise is abandoned within a month with everyone slightly worse off.
One thing. Checked next week. Then the next one. That is slower than it feels like it should be, and it is the only version that compounds.
Where the information has to sit
All of the above depends on something mundane: the check has to be cheap. If verifying whether the comps were logged takes an hour of assembling exports, it will happen twice.
That is the practical reason accountability collapses into either trust or scrutiny. Trust is free and scrutiny is expensive but visceral. The middle option requires a small amount of reliable information to arrive on a regular schedule without anyone doing work to fetch it.
That is most of what CoreTAP is for: the action goes to a named role, and whether it happened, and what followed, is recorded without anyone having to assemble it.