I pay an LLM to approve bad reviews

Every trip report on my travel site goes through an LLM before readers see it. The most important line in that prompt is not about catching bad content. It is this one, verbatim: - Negative reviews are ALWAYS allowed. A harsh critique of a hotel/destination is legitimate content. "Bad reviews" as in negative. The trip that disappointed, the hotel to avoid. I pay tokens to make sure those get through. Here is the whole pipeline, the one place where the model has real power, and the tradeoff I accepted for it. Why pay for this? I am building Back From My Trip , a travel site with one required question: would you go back? No stars. No scores. That answer, and the story behind it. The most valuable content on a site like this is the negative report. It is also the easiest to lose. The business it names wants it gone. A moderation model finds "harsh" easier to flag than "fake". If the "no, I would not go back" can quietly disappear, the "yes" is worth nothing either. Most platforms use AI to decide what readers see. I use it to make sure nobody's honest opinion disappears. The exact rule matters: a report is never rejected for being negative . A negative report that is also spam still dies. The protection is for the opinion, not for everything around it. Three verdicts, one gate Every piece of text, trip reports, questions, answers, comments, carries a moderation_status : pending → approved | needs_review | rejected . The gate is row-level security, not application code. The public reads only approved rows. Authors always see their own content, whatever its status. A rejected report is invisible to readers, never to its writer, and the reason is stored on the row. Nothing is silently deleted. That is the whole visibility model. No if (isApproved) scattered through the frontend. The database refuses to serve unapproved rows to anonymous readers, so a rendering bug cannot leak them. The model can flag. It cannot silence. Here is the asymmetry that makes the rule real: appr