Repository navigation
💡 Correction-learning loop for gmail-ai-classifier (relabels become personal rules in a Sheet) #673
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Summary
Detect when the user manually changes a label the classifier applied, for example moving a thread from Promotions to Finance/Purchases. Record the correction in a personal rules Sheet. Once a sender or subject pattern has been corrected N times, promote it to a deterministic fast-path rule automatically. This turns tuning from code PRs into data the user owns.
Market Signal
SaneBox's core selling point is that moving a message is the training signal. Reviews describe 5-10 corrections a day in week one, falling to almost none by week two. Zapier's AI steps and Gmail's AI Inbox offer no user-owned, inspectable rule store. An open, auditable 'rules you taught it' Sheet differentiates on both privacy and control.
User Signal
In the last 30 days, five of the 26 merged PRs only added vendor-specific rules to code.gs: #652 (signature/tax shields), #655 (Discount Tire/Tire Rack), #657 (Event RSVP shield), #661 (recruiting ATS), #664 (recruiter/Eventbrite). DETERMINISTIC_RULE_SPECS_ is a pipe-delimited DSL hardcoded in a 7,376-line code.gs, alongside 30+ hardcoded shields. The README's 'Classification Tuning Lifecycle' is manual: observe, edit CUSTOM_PROMPT_RULES, run tests. Every household's personal vendors currently need either a code change or prompt hacking.
Technical Opportunity
The classifier already applies AI/* operational labels and runs auditEmailClassifications() daily over recent threads. That audit pass can compare current labels with the classifier's last decision (stored in a per-thread property or a hidden log sheet) and log the differences as corrections. DETERMINISTIC_RULE_SPECS_ is already data-shaped, so the same parser can read extra rows from a user Sheet (USER_RULES_SHEET_ID) and merge them ahead of the built-in rules. The repo's existing extract-to-src/index.js pattern keeps the diffing and rule-promotion logic in pure, testable functions.
Assessment
Adversarial Review
Strongest objection: Users relabel for reasons other than misclassification, which can produce noisy rules. The work also adds Sheets scope and complexity to an already very large script.
Rebuttal: Promotion needs a threshold (for example 3 consistent corrections for the same sender domain) and lands in a 'proposed' column the user approves with a checkbox. Nothing silently rewrites routing. Sheets is already part of this suite (calendar-to-sheets). Moving vendor rules out of code into data shrinks code.gs over time, and it ends the stream of single-vendor PRs, which are a maintenance cost today.
Suggested Next Step
Prototype in two pieces. (1) Extend auditEmailClassifications() to emit a corrections log (thread, sender domain, from label, to label) into a Sheet. (2) Add a parser that loads USER_RULES_SHEET_ID rows in the DETERMINISTIC_RULE_SPECS_ format. Measure correction volume for 2 weeks on a maintainer account before adding auto-promotion.
Generated by the weekly feature-ideation agent (Mary, BMAD Analyst). Sources: Gemini API terms · Gemini deprecations · Apps Script release notes · Vertex AI advanced service · Gmail Gemini era · SaneBox review · Workspace Studio
All reactions