In Triage — Set by the 45-day scan. Freezes normal workflow until resolved.

Resolved — Internal review complete. System runs cert validation; if all 10 checks pass, project auto-advances to Ready for Cert.

Returned — Sent back to originating team for additional work.

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.

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, or the project is in Anne Arundel, Montgomery, or Prince William county (proprietary jurisdiction forms).

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 (migrated from SmartSuite)
• 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 a payment arrives (EFT remittance, Stripe webhook, 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 now 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. Self-generated IDs (no SmartSuite dependency). SmartSuite receives a mirror copy during the soak period (through April 6, 2026).
• Xero archive — 2,286 invoices ($2.7M) and 2,269 payments from 2022–2024. Stored in Supabase tables xero_invoices and xero_payments. Invoices linked to existing Supabase projects (via project_smartsuite_id) are excluded from pipeline counts to avoid duplication.
• PMS archive — 7,774 historical projects (2018+). Status mapped to Mostly buckets. Projects already migrated to Supabase (brand=BLACKHOUSE) are excluded from counts. Branch resolved from address state (MD→Baltimore, VA→Manassas, CT→New Haven).

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. Creates a chronological audit trail alongside human conversations.
• 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 now automatically detects when sub-component products are present (e.g. WTR-DTIL, ENC-CSEAL) 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. Matched to tracking tokens by message ID or recipient.
• Delivery Ledger — historical log at /portal/delivery-ledger 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.

Auto Field update endpoints (arrival, inspection notes) include a 5-minute deduplication window. If the same event type is submitted for the same project within 300 seconds, the duplicate is silently blocked. Prevents repeated comm_log entries from network retries or app double-taps.

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 (catches both blank fields and explicit “Not Invoiced” values). Friday self-discovers the schema before querying.
• Tier 2 — SQL + Cross-System — run_sql executes read-only SQL via Supabase RPC function (SELECT only, 5-second timeout, 100-row limit, banned keyword detection, financial column redaction for non-privileged roles). Cross-system tools: query_stripe (invoices, payments, subscriptions), query_calendar (schedule), get_pipeline_alerts, get_recon_status. Schema reference (~800 tokens) injected into the system prompt for privileged users.
• Tier 3 — Write Actions — 6 capabilities: modify schedule (create/reschedule/cancel visits with two-phase preview/confirm), send certs and invoices (owner bypasses $5K guardrail; admin subject to guardrails), send WhatsApp messages, approve certs inline, and render visualizations. All write actions use 60-second confirmation tokens and audit trail via comm_log. Rate limit: 20 API calls/hour for owner/admin, 10/hour for other roles. Slash commands bypass the rate limit (zero API cost).

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. Types: bar, horizontal bar, line, sparkline, dot plot, pie, donut, gauge, stacked bar, grouped bar, area, scatter. Muted earth-tone palette, no gridlines, data labels where appropriate.
• Recharts (interactive) — React-based charts with tooltips, legends, responsive sizing, and animations. Types: bar, line, area, pie, radar, scatter, composed, treemap, funnel. Tufte-styled axis and tooltip treatment.
• Sandbox (arbitrary) — Friday generates custom HTML/SVG/JS rendered in a sandboxed iframe (<iframe sandbox="allow-scripts">). Tufte CSS tokens pre-injected. No network access, no parent window access. For custom dashboards, infographics, or layouts that go beyond standard chart types.

The backend wraps each visualization in markers ($$FRIDAY_CHART$$, $$FRIDAY_RECHARTS$$, $$FRIDAY_SANDBOX$$) that the frontend parses and renders as the appropriate component.