How the pipeline processes a batch

What: reads column P of the input spreadsheet. If Aljeel already wrote an emp_no, trust it.

When: only when Aljeel pre-filled — typically <10% on a new batch, ~98% on J26-788 where everything was hand-coded.

Conf: 1.0 · trace = L0→direct emp_no_col=NNNNNNN

What: parses any attached Oracle Fusion approval form for the "Person Number" field.

When: ticket folder has an Oracle Fusion-generated PDF form with Person Number filled in.

Conf: 1.0 if Person Number matches Manpower roster.

What: extracts the employee's @aljeel.com email from the .msg approval chain (skipping Sanad + system addresses). Looks up in the 677-row email master.

When: after L0/L1 miss. Most reliable on rows where the employee is the original requester in the forwarded chain.

Conf: 1.0 (Email column lookup) · 0.95 (learned cache fallback)

What: Aljeel ERP names approval emails like Personal Contribution Approval Requested for Hussein Saleh (1002066) on 2026-04-27. Regex captures the (NNNNNNN) emp_no.

When: ticket folder has at least one ERP-formatted .msg filename.

Conf: 0.95

What: if L2 didn't find an emp_no in the filename, walks the entire ticket folder and reads every .msg body looking for an emp_no pattern in the text.

When: ticket folders where filename was sanitized but the body still contains the emp number.

Conf: 0.85

What: normalizes GDS passenger format LAST/FIRST TITLE (e.g. SALEH/MARIAM MS(CHD)) → fuzzy-matches against Manpower full names with rapidfuzz. Strips titles (MR/MRS/MISS/DR/CHD/MSTR).

When: no emp_no in evidence but the passenger name is unique enough in Manpower (Levenshtein score >= 88).

Conf: 0.6–0.9 by match score · ambiguous → cascade continues.

What: double-metaphone phonetic match for Arabic→English variants (Mohammed/Mohammad/Muhammad, Hussein/Hussain, Khalid/Khaled, Abdel/Abdul). Custom 50-entry variance map.

When: L4 returned two candidates equally close — phonetic breaks the tie.

Conf: 0.75

What: matches against Manpower Arabic Name column using token-set fuzzy with Arabic normalization (alef variants, hamza, tatweel).

When: .msg evidence has the Arabic name but no Latin transliteration matches Manpower.

Conf: 0.85

What: if the approver in the .msg is a known line manager AND has exactly one direct report whose name fuzzy-matches the passenger, return that subordinate.

When: approval-chain rich, passenger name ambiguous.

Conf: 0.8

What: passenger IS a line manager not in Manpower (or new hire). Reverse-lookup: who has this person as Manager? If all subordinates share one cost center, use that as the manager's home CC.

When: rare — senior staff whose own Manpower record is incomplete.

Conf: 0.7 · flags MANAGER_CC_FRAGMENTED when subordinates disagree.

What: Gemini reads the .msg approval thread + OPEX PDF, returns explicit allocation (emp_no, CC, DIV, agency, solution) if mentioned by name.

When: when L0–L7.5 all miss. In v15.12 this rarely runs — the hybrid router at Stage 2 catches uncertain rows earlier and sends them to the richer full-evidence agent at Stage 3B.

Conf: high/medium per Gemini self-assessment.

What: learns passenger_name → emp_no mappings across all prior batches (cached in cache/passenger_to_empno.json). If we've resolved this exact name confidently before, reuse the answer.

When: consultants/regulars who travel repeatedly. Also catches names that L4 was just below threshold on.

Conf: 0.75 + cross-batch consistency check.

What: last resort. If description has sponsorship markers (HF/CRM-/EP-/conference) AND no employee was found, mark as external sponsorship: account=60307021, segments default to General (000), flag EMPLOYEE_NOT_IN_MASTER.

When: guest doctors, KOLs, conference attendees who are never in the employee master.

Conf: 0.4 — intentionally low so QC flags it for review.

Rule: if employee's Manpower division code is 888 (G&A), cascade's 60301004 (G&A Travel) beats LLM's 60301003 (S&M Travel).

Why: Aljeel splits travel expense at the account level by department type. G&A employees go to a different GL than commercial. LLM doesn't see this mapping; cascade does.

Rule: on travel rows (account 60301003/04), if cascade derived solution from the route (e.g. RUH→JED maps to solution X for this employee's home division), cascade's solution wins.

Why: solution code reflects which Aljeel business unit benefits from the trip. Cascade has Aljeel's internal route-to-solution mapping built in; LLM has to guess from text.

Rule: on sponsorship rows, if the OPEX prefix in the description (HF, CRM-, EP-, SIS-, AATS, IEPC) maps to a known agency, use that mapping: HF→10072 (Abbott), CRM→10038, EP→10095, etc.

Why: Aljeel's sponsorship-agency mapping is encoded as a lookup table from event-prefix to agency code. Cascade applies it deterministically; LLM can pull the wrong agency from event branding.

Rule: same logic as R3, but for solution code: OPEX prefix→solution lookup (HF→10050, CRM→10094, etc.).

Why: solution code identifies the medical specialty (cardiology, cardiac rhythm management, electrophysiology). Cascade has the canonical Aljeel mapping; LLM picks up adjacent words.

Rule: if Stage 1 detected a family travel cluster (CHD markers in description + shared route + same date), all rows in the cluster are unified to the modal sponsor's emp_no. LLM's per-row guesses on family rows are discarded.

Why: when sponsor brings spouse + 2 children on annual leave tickets, all 4 rows charge to the sponsor's home cost center (see the SALEH family case where rows 21–23 were unified to Hussein Saleh 1002066).

Rule: if LLM returns blank or null on any of CC / DIV / agency / solution, keep cascade's value for that specific field. Mix-and-match per field.

Why: LLM sometimes omits fields it's uncertain about. Cascade's default-better-than-blank policy keeps the row Oracle-ingestible.

What: the approval chain in the .msg evidence doesn't cover this row — no approval signature, or the approval is from someone not in the approval workflow.

Severity: HIGH on annual tickets and training; MEDIUM on regular travel.

Cleared automatically: if v15.11.2 family-cluster unification reassigns the row to a sponsor whose approval covers the whole family.

What: Mai (HR) is not in the approval chain on a training or annual-ticket row.

Scope: Mai is required only on HR-related items — NOT on sponsorships (those route through compliance, not HR).

Severity: HIGH.

What: informational tag added to every row in a family cluster after the modal emp_no is applied. Tells the reviewer "this row was reassigned because it's part of a family travel group."

Severity: INFO (not a problem, just transparency).

What: ticket amount ends in a suspicious round number (.00, .50) and is exactly at a typical fraud threshold (SAR 500, 1,000, 1,500, 2,000).

Why it's a signal: genuine airline fares have decimal complexity from VAT (15%); round numbers suggest manually-entered amounts.

Severity: MEDIUM.

What: the same employee has two tickets on the same route in the same week that aren't a clean return pair (i.e. not a balanced there-and-back).

Why: could be legitimate (changed booking) or could be double-charging.

Severity: MEDIUM.

What: personal-contribution approval where the employee approved their own request (no manager intervention in the chain).

Severity: MEDIUM — needs manager oversight.

What: VAT amount on the row doesn't match the expected rate. Domestic airline tickets carry 15% KSA VAT; international tickets are zero-rated. Anything else triggers the flag.

Severity: MEDIUM.

What: ticket is actually an EMD fare-adjustment line (rebooking/upgrade fee) rather than a fresh booking. No separate ticket folder expected.

Severity: INFO — prevents false NO_FOLDER flags.

What: invoice line claims a ticket # but no evidence folder exists for it. Could mean Jawal forgot to send the booking PDF, or the ticket # is wrong on the invoice.

Severity: HIGH — finance should request the missing documentation from Jawal.

What: .msg evidence file is on disk but its bytes are 0 — corrupted at upload. Approval coverage cannot be verified.

Severity: MEDIUM — Aljeel should re-pull from Outlook/SharePoint.

Status: proposed for v15.11.3; not yet shipped.

What: same employee + same route appears with a price discrepancy between the OPEX form value and the invoice value, OR appears in this batch and a prior one with different amounts.

Example: ALKHATIB/YAZAN MR (J26-593 R138) — form said SAR 850, invoice charged SAR 1,550.

Severity: HIGH.

What: a row that looks like a family-cluster member but the cluster spans multiple batches or doesn't fully match the in-batch family-cluster signature.

Severity: MEDIUM.