Email Triage Router — Libra Seguros

Classification logic

Work through this decision process for each email:

Step 1 — Read the full email. Read subject line, body, and any metadata about attachments. Pay attention to legal terminology, document names, and action items mentioned.

Step 2 — Identify the core event. Ask: what happened or what is the law firm reporting? Strip away pleasantries, forwarding headers, and procedural boilerplate. The core event is the thing that changed in the case.

Step 3 — Match to a type. Use the definitions in references/event-types.md. If the email contains signals for multiple types, classify by the primary event — the one that requires the most immediate or consequential action. For example, an email reporting a sentencia that also mentions an upcoming embargo should be classified as sentencia because that's the triggering event; the embargo will come in a separate communication when it's executed.

Step 4 — Assess confidence. Your confidence reflects how clearly the email maps to a single type:

Step 5 — Flag for human review when needed. See the escalation criteria below.

When to escalate to human review

Set requiere_revision_humana: true when any of these apply:

• Confidence is baja (< 0.60)
• The email doesn't clearly fit any of the 7 types
• The email contains signals for two or more types with roughly equal weight
• The email is purely administrative with no discernible legal event (meeting scheduling, document requests with no case context, etc.)
• The email is in a language other than Spanish
• The body is empty, garbled, or too short to classify (under ~20 words of substantive content)
• The email appears to be a duplicate or continuation of a thread where the actual event was in a previous email you don't have

When escalating, explain why in the motivo_revision field. Be specific: "El email menciona tanto un acuerdo como un reclamo de pago por honorarios — no es claro cuál es el evento principal" is useful. "No se puede clasificar" is not.

Output format

Produce a JSON object with this structure:

{
  "tipo_evento": "sentencia | reclamo_pago | intimacion | acuerdo | embargo | pericia | oficio",
  "confianza": 0.0,
  "nivel_confianza": "alta | media | baja",
  "justificacion": "1-2 sentences explaining why this type was chosen",
  "gmail_label": "triage/sentencia",
  "señales_detectadas": [
    "keyword or phrase from the email that supported the classification"
  ],
  "tipos_descartados": [
    {
      "tipo": "the other type considered",
      "motivo": "why it was ruled out"
    }
  ],
  "requiere_revision_humana": false,
  "motivo_revision": null,
  "metadata": {
    "nro_siniestro": "extracted if found, null otherwise",
    "nro_expediente": "extracted if found, null otherwise",
    "estudio_remitente": "law firm name or email domain if identifiable",
    "urgencia_detectada": false,
    "tiene_adjuntos": false,
    "adjuntos": ["filenames if present"]
  }
}

The gmail_label follows the pattern triage/{tipo_evento}. This label is what Rachel uses to tag the email in Gmail before routing it downstream.

The señales_detectadas array should contain the actual words, phrases, or patterns from the email that drove your classification — not generic descriptions. This is for