Hold The Door

Inspiration A customer email can sound helpful and still quote the wrong price, offer a discount the customer doesn’t qualify for, or promise a feature that engineering hasn’t committed to. We built Approval Gate to catch those problems before sending. The goal was to make a clear decision, explain what triggered it, and stop the action when something needs fixing. What it does Approval Gate checks a draft and returns APPROVE, HOLD_FOR_REVIEW, or BLOCK. It combines company prices and policies with Ezio’s assessment of accuracy, tone, bias, and agreement. Known contradictions block the email. Missing eligibility information, uncertain claims, and unsupported promises go to review. Harmless messages can pass even when Ezio has no factual claims to score. The page shows the decision, reason, supporting evidence, and whether the simulated email action ran. Users can enter a draft with optional customer context or try a supplied sample in one click. How we built it We extended the supplied Python wrapper using the standard library. The independent checker reads the trusted CSV and JSON files, extracts relevant claims, and checks prices, discounts, eligibility, refunds, trials, and response times. The policy combines those findings with Ezio’s response. Individual contradictions override the overall score, and company checks continue to work when Ezio is unavailable. Every decision is audited, and only APPROVE can run the mock email action. The interface uses plain HTML, CSS, and JavaScript. It runs locally without external assets or dependencies, and all decisions stay on the server. Challenges Extracting claims took more work than comparing numbers. We had to handle written numbers, several claims in one sentence, billing context, and negated statements without falsely blocking valid emails. Testing also caught a response-schema mistake: Ezio returned claim wording in text, while our first parser expected claim. We corrected the parser and regression tests. What we learned The biggest lesson was that an overall score can hide a problem in one dimension. We also learned to distinguish “nothing was checked” from “a check failed,” and to preserve independent evidence during service failures. Our final customer-support practice run caught all eight bad inputs, approved all eight good inputs, matched all 16 expected decisions, and passed all six failure drills. That gives us a useful baseline; unusual wording remains a limitation of the rule-based checker.

Built With

• css3
• csv
• html5
• http
• javascript
• json
• python