psow-absow-pipeline

PSoW → ABSoW → Cert + Invoice Pipeline

Core data pipeline for the certification workflow. Three stages:

1. Parse (PSoW — Permitted Scope of Work)

permit-parser extracts structured data from permits, plans, and drive logs at upload. All 9 product divisions produce typed spec objects:

• UND: pier count, spacing, depth, PSI/torque, extension sleeves, manufacturer
• ANC: anchor count, spacing, rod length/diameter, plate dimensions, wall location
• BRC: strap/brace count, spacing, width, wall height, tensile strength, fastening
• SUP: column count, height, footer type/dims, beam section/LF, joist specs
• FND: wall thickness/height, footer width/depth, slab thickness, rebar spec, concrete PSI
• WTR: drain LF, pump count/HP, discharge LF, component list
• ENC: vapor barrier SF, wall LF, barrier mil, dehumidifier PPD, vents sealed
• RTW: wall height/thickness, footing dims, rebar spec, material

Auto-SOW creation (auto_create_sow_lines) creates Supabase SOW lines with specs in notes JSON. Add-on triggers fire automatically (UND→BKFL, WTR-BSMT→SLAB+WSEAL, SUP-COL→FTR).

2. Field Verify (ABSoW — As-Built Scope of Work)

Darius confirms or modifies scope via Rob/OpenClaw. The ABSoW bridge writes to BOTH Supabase (SOW_AS_BUILT_QTY) and SOW Gate SQLite (absow_confirmations) in a single operation.

If PSoW == ABSoW: all parsed data flows through automatically. If PSoW ≠ ABSoW: SOW_MODIFIED flag set; cert validation (Check 10) blocks until resolved.

3. Generate (Cert + Invoice)

• Auto-validation runs 10-point check at Field Complete
• Production days auto-calculated from SOW quantities (8 division rules)
• Cert generation uses depth-associated sparklines for pier cards
• Pre-invoice validation checks ABSoW completeness (blocks if modified scope unconfirmed)
• Confidence routing guardrails: $5K+, proprietary-form county, or incomplete ABSoW → queued for review

Reference Sources

• Field Guide: unlikely.pro/fieldguide (source: /opt/fieldguide/src/data.ts)
• Cert Module Library: unlikely.guide/cert-module-library.html
• Config: PRODUCT_SPEC_REGISTRY in /opt/unlikely-api/config.py

Related

• permit-parser — Extraction
• document-parser-service — Orchestration + auto-SOW
• field-inspection-service — ABSoW bridge + production days
• cert-data-service — Assembly
• cert-generator-v3 — PDF rendering
• invoice-service — Pre-invoice validation
• confidence-routing-service — Guardrails
• drive-log-parser — Pier data + depth readings
• auto-validation-service — 10-point check + production days trigger

As-Built Proposal Evidence Sources (updated 2026-07-29)

services/absow_proposal_service.py (Phase 3) parses scope-change submissions into staged per-line as-built proposals (absow_proposals, migrations 027/028). Three evidence sources, in authority order per the prompt:

1. Scope-change note — the submitter’s account of what changed
2. As-built drawings / updated permits — up to 4 PDFs (as-built/change-order filenames prioritized); drawing quantities override note prose
3. Production photos (added 2026-07-29, api be5d87a) — up to 8 photos from PHOTOS, ranked by the photo_validations Vision cache (work subjects → general site → unvalidated → Vision-flagged-unusable). Ground truth for what was actually installed: product-type mismatches vs documents become manual items citing the photo. Asymmetry rule: photo absence is never evidence of non-installation (coverage is partial) — no remove_line/qty reduction from photos alone; photo-vs-document count conflicts keep the document qty and drop confidence.

photos_read (jsonb) records attached filenames next to docs_read; AbsowProposalCard (portal a9c687f) shows the photo count with filenames in a tooltip. Nothing auto-applies — up_owner/up_admin reviews the diff and applies via field_inspection.update_absow, stamping absow_reconciled_*.