Received — Auto-set by Pipeline Shepherd when the 45-day threshold is crossed, or manually assigned by admin. Project enters the triage team’s queue.

In Review — Triage team is actively processing the project. May involve desk review (document inventory, cert readiness check) or field review (scheduling a site visit).

Blocked — Missing documents prevent progress. Requires triage_blocked_reason: one of missing_plans, missing_permits, or missing_photos. Can return to In Review when the blocking item is resolved.

Complete — Triage work is finished. Triggers project advancement to Ready for Cert (if cert validation passes) or returns project to originating branch.

1. Last Inspection Date (rollup from site visits) — PRIMARY. The most recent site visit completion date. This is the preferred clock source because it reflects actual field activity.

2. Permit Issue Date — FALLBACK. Used when no site visits exist (e.g., desk-review-only projects or pre-inspection permits).

3. Record Creation Date — LAST RESORT. Used only when both inspection and permit dates are missing.

Project already exists in the system and has been inspected before. Triage team reviews the document inventory (plans, permits, photos, driving logs), uploads any missing files, and runs cert validation. If documents are missing, an RFI is auto-generated specifying what is needed.

An old permit that was never inspected. Two sub-types:

• desk_review — sufficient documentation exists to certify without a field visit. Project goes directly to Ready for Cert after triage review.
• in_situ — a field visit is required. Full intake is performed (address, permit, jurisdiction, state, code cycle) and project enters the normal Intake → Scheduled pipeline.

Complete → Ready for Cert — triage review is done, cert validation passes, project advances into the processing pipeline.

Return → Originating Branch — project is sent back to the originating JES branch (BAL/MAN/RIC) for additional field work or coordination. The triage flag is cleared.

BALT — Baltimore zone permits. JES Baltimore branch territory (Maryland).

MAN — Manassas zone permits. JES Manassas branch territory (Virginia).

RIC — Richmond zone permits. JES Richmond branch territory (Virginia).

CLOSED — Finalized permits. Records move here when the permit is confirmed closed by the jurisdiction. Tagged with _closed_date and _original_zone.

Each tracker record is matched against two systems to build a complete picture:

• PMS (legacy) — cert_status_id, invoice_status_id from the historical PMS archive. Covers projects from 2018–2025 that may predate Entirely.
• Entirely (current) — project_status, cert_status, open_rfi_count from the active Supabase dataset. Cross-referenced by permit number, address, or customer name.

Matching uses permit number as the primary key. When no permit match exists, fuzzy address matching (80% threshold) is used as a fallback.

The closure workflow processes JES-provided spreadsheets of closed permits:

• Step 1 — JES uploads a closed permits spreadsheet (.xlsx) via POST /tracker/upload-closures.
• Step 2 — System matches permit numbers across BALT, MAN, and RIC zones.
• Step 3 — Matched records move to the CLOSED zone with _closed_date (today) and _original_zone (BALT/MAN/RIC) recorded.
• Step 4 — API returns: moved count, already_closed count, not_found count.

Auto When a project reaches Field Complete, the system automatically runs a 10-point validation checklist. If all checks pass, the project advances to Ready for Cert with no human intervention. If any check fails, an RFI is automatically generated and the project moves to Pending RFI until the issue is resolved.

Auto On validation PASS, the system also auto-calculates production days from SOW quantities (if not already set manually). Rules: 1 day per 6.5 piers, 1 per 10 anchors, 1 per 12 braces, 1 per 15 columns, 1 per FND component type, 1 base + 0.5 per 50 LF drain, 1 base + 0.5 per 500 SF encapsulation, 1 per 20 LF retaining wall. Manual overrides always take precedence.

Manual After Jacob drafts the cert and invoice, he chooses one of two paths based on confidence:

• Send Direct — Jacob is confident the package is correct. Cert and invoice are delivered immediately without additional review.
• Queue for Review — Jacob is not fully confident, or guardrails have been triggered. Package is queued for Dustin to review before delivery.

Guardrail The system automatically routes to review when: invoice total is $5,000 or more, the project is in Anne Arundel, Montgomery, or Prince William county (proprietary jurisdiction forms), or as-built scope (ABSoW) confirmation is incomplete (any SOW line using planned quantities instead of field-verified quantities).

Auto Before generating an invoice, the system validates ABSoW completeness. SOW lines modified in the field (PSoW ≠ ABSoW) must have confirmed as-built quantities — otherwise invoice generation is blocked. Unmodified lines without confirmation produce warnings but do not block. Admins can override with override_validation.

Auto When a new project intake is submitted, the system automatically enriches it with:

• Jurisdiction lookup — geocoding via Google Maps, matched to static jurisdictions JSON
• Certifier routing — correct certifier assigned based on state and county rules
• Forms detection — identifies required jurisdiction-specific forms (e.g., Anne Arundel, Fairfax, Stamford)
• Duplicate detection — fuzzy address matching (80% threshold) flags potential duplicates before approval
• Timeline estimation — estimated completion timeline based on SOW items and historical data

Enrichment data is stored on the intake request and displayed to schedulers and admins in an expandable panel during intake review.

Auto When permits, plans, or drive logs are uploaded, the parser extracts structured data for all 9 product divisions:

• Permits & plans — product codes, quantities, and typed specs per division (anchor rod lengths, footer dimensions, drain LF, barrier SF, rebar specs, wall heights, etc.)
• Drive logs — per-pier PSI/torque readings with depth association, extension sleeve tracking, installation dates
• Auto-SOW creation — parsed items are auto-created as Supabase SOW lines with specs in the notes JSON field (opt-in via auto_create_sow). Duplicate detection prevents re-creation on re-parse.
• Add-on triggers — UND-PUSH → ADD-BKFL, WTR-BSMT → ADD-SLAB + ADD-WSEAL, SUP-COL → SUP-FTR, etc.

If the permitted scope (PSoW) matches the as-built scope (ABSoW) — meaning no field changes — all parsed data flows straight through to cert generation and invoicing with zero manual intervention.

Auto When the field inspector reports as-built quantities via Rob (per-line or EOD batch closeout), the system writes to both Supabase (SOW_AS_BUILT_QTY) and the portal SOW Gate SQLite (absow_confirmations) in a single operation. This eliminates the need for a separate portal confirmation step — cert generation and invoice generation both read from SQLite first, Supabase as fallback.

If quantities differ from the permitted scope, the SOW_MODIFIED flag is set. Cert validation (Check 10: Scope Resolved) blocks certification until all modified lines have confirmed as-built quantities.

Auto When a payment arrives (EFT remittance or Revolut transaction), the smart matching engine scores each line item against open invoices:

• HIGH — exact invoice number + amount within $0.01 → auto-execute (mark paid, close project)
• MEDIUM — invoice match but amount differs, or amount match but partial reference → queued for human confirmation
• LOW — multiple candidates, no match, or combined payments → surfaces in dashboard for manual resolution

Guardrail Payments ≥ $5,000 always require human confirmation regardless of match quality (caps at MEDIUM).

The pipeline snapshot, analytics, and revenue reporting draw from three data sources, each with deduplication logic to prevent double-counting:

• Supabase — current active projects. Sole source of truth for all reads, writes, and creates.
• Xero archive — 2,286 invoices ($2.7M) and 2,269 payments from 2022–2024. Linked to existing projects via project_smartsuite_id; duplicates excluded from counts.
• PMS archive — 7,774 historical projects (2018+). Status mapped to Entirely buckets. Already-migrated projects (brand=BLACKHOUSE) excluded from counts.

The portal includes a real-time messaging system (WebSocket-based, SQLite persistence) that integrates with the project lifecycle:

• Project-linked conversations — conversations can be typed (direct, project, rfi, review) and linked to specific projects. All messages appear in the project’s Activity timeline.
• System event logging — status changes, cert generation/delivery, invoice creation/payment, file uploads, site visits, and hold events are auto-logged to the project timeline.
• Review queue integration — cert/invoice queued for review auto-creates a ‘review’ conversation. Owner approves or requests revision inline.
• RFI-as-conversation — any conversation can be flagged as RFI with severity, category, and due date. The RFI escalation chain (Day 1 → 3 → 5 → 7+) operates within the conversation thread.

Auto When permits or plans are uploaded, Claude Vision extracts scope items and maps them to the product catalog. The parser automatically detects when sub-component products are present and injects the required parent service lines:

• WTR-CDRAIN or WTR-DTIL → auto-adds WTR-CRWL (Crawlspace Water Management, $300/flat)
• WTR-BGUT → auto-adds WTR-BSMT (Basement Water Management, $300/flat)
• ENC-CSEAL, ENC-DEHUM, or ENC-RINS → auto-adds ENC-SYS (Encapsulation System, $300/flat)

Parent services are the billable inspection products that appear on invoices. Sub-components are scope documentation items ($0) that record what was installed. Both must exist for cert generation and invoicing to work correctly.

Auto Every cert and invoice email includes a 1×1 transparent tracking pixel. When the recipient opens the email, the pixel fires and records:

• Open events — timestamp, IP address, user-agent. Re-opens are tracked separately.
• Bounce detection — Gmail inbox scanned every 2 hours (Mon–Fri, 8 AM–8 PM ET) for mailer-daemon / delivery failure notifications.
• Delivery Ledger — historical log with summary metrics (sent, opened, unopened, bounced, open rate) and filterable table.
• Per-project timeline — delivery status (Opened, Bounced, Delivered) shown inline on each project’s delivery log.

Friday (the portal AI) operates in role-based voices and three escalating intelligence tiers:

• Tier 1 — Query Engine — query_data and describe_schema tools. Structured queries against Supabase with table/column allowlists. Null-aware filtering.
• Tier 2 — SQL + Cross-System — run_sql executes read-only SQL via Supabase RPC (SELECT only, 5-second timeout, 100-row limit). Cross-system tools: get_pipeline_alerts, get_recon_status, precedent_search, pricing_intelligence.
• Tier 3 — Write Actions — 6 capabilities: modify schedule, send certs/invoices, send WhatsApp, approve certs, render visualizations. All write actions use 60-second confirmation tokens and audit trail. Rate limit: 20 API calls/hour for owner/admin, 10/hour for others.

When a user asks Friday for a chart, graph, or visual, the response renders directly in the chat bubble. Three rendering tiers:

• Tufte SVG — inline SVG charts following Edward Tufte design principles. Muted earth-tone palette, no gridlines, data labels where appropriate.
• Recharts (interactive) — React-based charts with tooltips, legends, responsive sizing, and animations.
• Sandbox (arbitrary) — Custom HTML/SVG/JS rendered in a sandboxed iframe. No network access, no parent window access. For custom dashboards or infographics.