| name | submittal-intelligence |
| description | Review and verify submittal compliance against project specifications. Trigger phrases include "review submittal", "check submittal", "submittal compliance", "does this meet spec", "compare to spec", "submittal review", "product data review", "shop drawing review".
|
| version | 1.0.0 |
Submittal Intelligence Skill
Overview
The submittal-intelligence skill performs comprehensive compliance reviews of submitted product data, shop drawings, and samples against specification requirements from project intelligence. It automates the verification process by:
- Extracting spec requirements from relevant CSI sections with testable, verifiable criteria
- Parsing submittal documents (PDFs, data sheets, shop drawings) to extract product specifications and performance data
- Building a compliance matrix that cross-references each specification requirement with the submitted value
- Determining compliance status for each line item: Compliant, Non-Compliant, Partially Compliant, or Unable to Verify
- Generating professional review comments suitable for architect/engineer review cycles
- Producing an overall recommendation: Approved, Approved as Noted, Revise and Resubmit, or Rejected
- Tracking submission history and flagging changes from previous revisions
The skill produces deliverables suitable for direct inclusion in RFI responses, meeting minutes, and project correspondence.
When to Use
- Submittal PDFs uploaded for review by contractors or suppliers
- Verifying products meet specifications before purchase or installation approval
- Preparing review comments for architect/engineer sign-off
- Processing shop drawing submissions for dimensional and detail compliance
- Evaluating "or equal" substitutions against original specification requirements
- Checking certification and testing data against spec-required standards
- Documenting compliance decisions in the submittal log for future reference
- Expediting review cycles when multiple submittals require rapid turnaround
Data Sources
- submittal_log — Historical record of submitted items, spec sections, review dates, and recommendation status
- spec_sections — Structured project specifications with required fields:
submittal_required (boolean) — indicates if spec section requires submittal review
key_req (array) — critical requirements in natural language
tolerances (object) — dimensional and performance tolerances
testing (array) — ASTM, ASHRAE, or other standards for verification
environmental (object) — VOC, lead-free, sustainability requirements
divisions (CSI division codes) — Division 03, 05, 07, 08, 09, etc.
- key_materials — Material specifications database with properties, certifications, and approved equal products
- document-intelligence skill — Used to parse and extract data from submittal PDFs, data sheets, and shop drawings
- project-data skill — Used to retrieve and reference project-specific requirements and approved materials
Workflow
1. Identify the Submittal
- Retrieve submittal ID from submittal_log if resubmission
- Or accept new submittal document (PDF, image, data sheet)
- Extract cover letter, item description, and submission metadata
2. Determine the Spec Section
- Query submittal_log by submittal ID to find associated CSI spec section
- If new submittal, ask user to specify relevant spec section (e.g., "Division 03 Concrete", "Division 08 Doors and Frames")
- Confirm with user if ambiguous
3. Load Spec Requirements
- Retrieve spec section from project intelligence
- Extract all relevant requirements into a structured checklist:
- Material properties (grade, PSI, finish, color)
- Dimensional tolerances (sizes, clearances)
- Performance ratings (fire ratings, sound ratings, load capacity)
- Testing standards (ASTM references with specific test methods)
- Environmental compliance (VOC limits, lead-free, RoHS)
- Certifications (UL, ICC, NFRC, FINEGRAIN, etc.)
- Note any "or equal" or "approved equal" clauses that allow substitutions
4. Parse Submittal Document
- Use document-intelligence skill to extract:
- Product name, model, manufacturer
- Technical specifications and properties
- Dimensional data (from shop drawings or product data)
- Testing certifications and lab reports
- Material certifications and safety data
- Installation notes and conditions
- Organize extracted data in same format as spec requirements for direct comparison
5. Build Compliance Matrix
- Create line-by-line comparison table:
- Column 1: Spec Requirement (reference code, e.g., "03.03.01")
- Column 2: Requirement Text (extract from spec)
- Column 3: Submitted Value (extract from submittal document)
- Column 4: Compliance Status (Compliant / Non-Compliant / Partially Compliant / Unable to Verify)
- Column 5: Notes (explanation or citation)
- Sort by compliance status to highlight non-compliances first
5a. Auto-Populated Compliance Matrix
When /process-docs processes a submittal package, the compliance matrix should be auto-populated before the user runs /submittal-review:
- From the submittal package, extract all product specifications (model, performance values, certifications, test reports)
- From
specs-quality.json, load the relevant spec section requirements for the material type
- For each spec requirement, find the corresponding submitted value:
- Match by property name (e.g., "compressive strength" in spec → "f'c" in submittal)
- Match by ASTM standard (e.g., spec requires "per ASTM C39" → look for C39 test results)
- Match by performance category (e.g., "fire rating" in spec → "UL listing" in submittal)
- Pre-populate the compliance matrix:
| Spec Requirement | Required Value | Submitted Value | Compliance | Source |
|---|---|---|---|---|
| Compressive strength | ≥4,000 PSI | 4,500 PSI | ✅ PASS | Mix design report p.2 |
| w/c ratio | ≤0.45 | 0.42 | ✅ PASS | Mix design report p.3 |
| Air content | 5-7% | Not provided | ❓ MISSING | — |
- Flag any row where:
- Submitted value < required value → FAIL
- Submitted value is missing → MISSING DATA
- Submitted value can't be compared (different units, different test standard) → NEEDS MANUAL REVIEW
This auto-population happens during /process-docs extraction. The /submittal-review command then presents the pre-filled matrix for the superintendent to confirm, override, or supplement with field observations.
6. Determine Compliance Status
- Compliant — Submitted value exactly matches or exceeds spec requirement
- Non-Compliant — Submitted value falls short of spec requirement (cite specific deficiency)
- Partially Compliant — Submittal addresses requirement in part but leaves ambiguities or conditions
- Unable to Verify — Required specification data missing from submittal (request clarification)
- See compliance-checking.md for detailed determination rules and examples
6a. Concrete Mix Design Submittal Review
When reviewing concrete mix design submittals, refer to the concrete-mix-design-extraction template in the foremanos-intel plugin's document-intelligence skill for detailed extraction guidance (if installed). Key compliance checks:
- Design f'c meets or exceeds specified f'c (with appropriate overdesign margin)
- w/c ratio does not exceed specified maximum
- Air content within specified range (especially for freeze-thaw exposure)
- Cement type matches spec requirement (Type I, II, III, V)
- Aggregate meets gradation and maximum size requirements
- Admixtures are from approved manufacturers list (if specified)
- Lab performing trial batch is accredited
- Cold weather and hot weather modification plans are included if project has temperature-dependent specs
7. Generate Overall Recommendation
Synthesize compliance matrix into recommendation:
- Approved — All requirements met, no deviations or exceptions. Ready for installation/procurement.
- Approved as Noted — All critical requirements met; minor clarifications, conditions, or non-critical deviations noted. Approved with contingencies documented.
- Revise and Resubmit — Specific deficiencies identified. Contractor must address identified items and resubmit. Cite section references and required corrections.
- Rejected — Does not meet fundamental spec requirements. Resubmit with different product/approach or escalate for waiver consideration.
8. Draft Review Comments
- Write in professional, objective tone suitable for RFI response or meeting minutes
- Use structured comment format: [Status] | [Spec Reference] | [Finding] | [Required Action]
- Group comments by spec section or compliance status
- Include recommendations for follow-up (additional testing, certification, shop drawings, etc.)
- Cite all references to spec sections, ASTM standards, test reports
- For non-compliances, specify corrective action required
9. Update Submittal Log
- Record review date, reviewer, recommendation, and comments
- Link to compliance matrix and any supporting documents
- If resubmission, note previous revision status and what changed
- Flag for escalation if needed (structural engineer, code official, etc.)
Review Comment Language Standards
Approved
The submitted [product/material] meets all applicable specification requirements and is approved for [procurement/installation].
Approved as Noted
The submitted [product/material] meets specification requirements subject to the following conditions/clarifications:
- [Condition 1]: [explanation, deadline, or required action]
- Approval granted pending completion of noted items.
Revise and Resubmit
The submitted [product/material] does not meet specification in the following respects:
- [Reference code] [Requirement]: Specification requires [required value]. Submittal provides [submitted value]. [Specific corrective action required].
- [Reference code] [Requirement]: ...
Please resubmit with corrections or request formal waiver if waiver is intended.
Rejected
The submitted [product/material] is not acceptable due to non-compliance with fundamental specification requirements:
- [Critical deficiency 1]
- [Critical deficiency 2]
Resubmit with alternative product meeting all spec requirements, or submit formal waiver request for architect/engineer consideration.
Lead-Time Alert System
The submittal-intelligence skill tracks submittal timelines and flags items at risk of missing critical path deadlines. This system prevents procurement delays, schedule impacts, and last-minute rush approvals.
Must-Submit-By Calculation
Working backwards from each submittal's critical path impact:
Timeline Logic:
- Activity Start Date (from
schedule.json → activities linked to this submittal)
- Minus Material Lead Time (from procurement specs or supplier standard terms)
- Minus Fabrication Time (manufacturer lead time after order placed; typically 2-8 weeks)
- Minus Approval Cycle Time (architect/engineer review to approval):
- Standard products (common, pre-approved): 2-4 weeks
- Complex/custom products (engineered, mock-ups, samples): 4-6 weeks
- Minus Preparation Time (contractor prep of drawings, samples, certifications): 1-2 weeks
Example Calculation:
Activity start date (PEMB erection): 03/23/2026
Minus: PEMB lead time: 30 days
Minus: Fabrication time: Already in PEMB lead time, covered
Minus: Approval cycle (engineered): 4 weeks
Minus: Preparation (drawings ready): 1 week
───────────────────────────────────
Must-submit-by date: 02/02/2026
Alert Tiers
Three escalating alert levels based on days remaining until must-submit-by date:
| Tier | Days Remaining | Status | Action |
|---|
| CRITICAL | Past due (negative) | Red flag | Submittal missed deadline. Escalate to PM/engineer immediately. Assess schedule impact. May require expedited review or change order. |
| WARNING | 0-7 days | Yellow flag | Due within one week. Verify submittal ready for submission. Confirm with architect review slot reserved. Prepare expedited review package if needed. |
| WATCH | 8-21 days | Blue flag | Due within 3 weeks. Monitor preparation progress. Confirm no blockers (missing data, approvals, samples). Schedule architect review. |
| NORMAL | >21 days | Green | On track. No action needed. Continue normal schedule. |
Daily Morning-Brief Auto-Check
The /morning-brief command automatically scans submittal-log.json and generates an alert summary:
Query logic:
- Find all submittals with
status != "approved"
- Calculate
must-submit-by date working backwards from linked schedule activities
- Compare to today's date
- Generate alert for each tier
Morning Brief Output Example:
SUBMITTAL STATUS — ALERTS ONLY (3 items at risk)
🔴 CRITICAL — Past Due
• Nucor PEMB Reaction Drawing (SUB-008)
Status: "under_review" (submitted 02/09, 9 days ago)
Needed by: 02/02 (7 DAYS PAST DUE)
Impact: PEMB erection critical path blocked
Action: Call Nucor today; escalate to CMW architect
🟡 WARNING — Due in 3 Days
• Schiller Door Hardware (SUB-012)
Status: "revision_submitted" (resubmit 02/15)
Needed by: 02/18 (3 days)
Impact: Door procurement dependent
Action: Confirm with architect; hold time slot for review
🔵 WATCH — Due in 18 Days
• Davis & Plomin HVAC Equipment (SUB-015)
Status: "under_review" (submitted 02/10)
Needed by: 03/05 (18 days)
Impact: HVAC procurement, MEP rough-in scheduled 04/27
Action: No urgent action; normal tracking
Project Intelligence Integration
When reviewing submittals or generating alerts, automatically enrich with data from the project intelligence store. These cross-references improve review accuracy and catch procurement/schedule risks early.
Procurement Lead Time Enrichment
Read procurement-log.json → For each submittal, look up the corresponding procurement entry by submittal_id. Pull expected_delivery, lead_time_weeks, and delivery_status → auto-populate fabrication_days and material_lead_time_days in the submittal record. If procurement entry shows delivery_status = "delayed", escalate the submittal alert tier accordingly.
Sub Contact Resolution
Read directory.json → subcontractors[] → When a submittal is overdue or needs follow-up, resolve the responsible sub's foreman name, phone, and email from the directory. Auto-fill contact information in alert action items: "Contact {foreman} at {phone} ({sub_name}) to expedite SUB-{id}."
Inspection Hold Point Linking
Read specs-quality.json → hold_points[] → For each submittal's spec_section, check if any hold points require submittal approval before the inspection can proceed. Flag linked hold points: "SUB-{id} approval is a prerequisite for hold point HP-{hp_id} ({inspection_name}). Inspection cannot proceed until this submittal is approved."
Cost Impact Flagging
Read cost-data.json → For submittals linked to critical path activities or high-value budget line items, show the budget amount at risk if approval is delayed. Include in alert output: "Budget line item {division} — {description}: ${amount} at risk if SUB-{id} delays procurement by {N} days."
Quality Test Correlation
Read quality-data.json → After a submittal is approved (status = "approved"), link subsequent material test results back to the approved submittal. For example, an approved concrete mix design (SUB-XXX) should be cross-referenced when 7-day and 28-day break results arrive: "Break test results for {mix_id} — 28-day f'c = {value} PSI vs. approved design f'c = {design_value} PSI. Status: {pass/fail}."
Installation Verification
Read daily-report-data.json → Flag if materials from a submittal are documented as installed in a daily report before the submittal status = "approved": "WARNING: {material} from SUB-{id} appears installed per daily report #{report_number} on {date}, but submittal status is still '{status}'. Verify approval before installation proceeds."
Submittal-Log Data Structure
For lead-time tracking, each submittal in submittal-log.json must include:
{
"id": "SUB-008",
"item": "PEMB Reaction Drawing",
"spec_section": "05 42 00",
"submitting_sub": "Alexander Construction / Nucor",
"status": "under_review",
"submitted_date": "2026-02-09",
"must_submit_by_date": "2026-02-02",
"approval_cycle_days": 4,
"material_lead_time_days": 30,
"fabrication_days": 0,
"preparation_days": 7,
"linked_schedule_activity_id": "A45-PEMB-Erection",
"linked_activity_start_date": "2026-03-23",
"critical_path_blocked": true,
"days_past_due": 7,
"alert_tier": "CRITICAL",
"notes": "Nucor sent initial, needs revisions for anchor bolt details"
}
Rejection/Resubmission Workflow
When a submittal is rejected or returned for revisions, auto-calculate new timeline impact:
Trigger: Submittal status changes from "under_review" to "revise_and_resubmit" or "rejected"
Auto-Calculation:
- Set new
revision_number (increment from previous)
- Capture original
must_submit_by_date
- Record
rejection_reason from architect's comments
- Estimate resubmission time (typically 3-5 business days for major revisions, 1-2 for minor)
- Add resubmission lead time to today to get new
expected_resubmit_date
- Recalculate new
must_submit_by_date (if 2nd revision, time is even tighter)
- Compare new deadline to original; flag if slipping past must-submit-by
- Alert to PM: "Resubmission due [date]. New approval cycle leaves [N] day margin."
Example Rejection Timeline:
SUB-008 PEMB Reaction Drawing (Nucor)
Original submission: 02/09
Original must-submit-by: 02/02 (MISSED by 7 days)
Rejection date: 02/12
Rejection reason: "Anchor bolt embedment depth needs verification per geotechnical report"
Estimated resubmission: 02/15 (3 days for revisions)
New approval cycle: 4 days (expedited given past-due status)
New must-submit-by: 02/19 (16 days past original deadline!)
Action: Flag to PM; assess schedule impact; consider change order if erection delayed
Resubmission Tracking
Track each revision with separate entries to maintain history:
In submittal-log.json:
{
"id": "SUB-008",
"item": "PEMB Reaction Drawing",
"revision_history": [
{
"revision_number": 1,
"submitted_date": "2026-02-09",
"status": "revise_and_resubmit",
"rejection_reason": "Anchor bolt embedment depth needs verification per geotechnical report",
"rejection_date": "2026-02-12",
"approval_cycle_days": 4,
"must_submit_by_date": "2026-02-02",
"days_late": 7
},
{
"revision_number": 2,
"submitted_date": "2026-02-15",
"expected_approval_date": "2026-02-19",
"status": "under_review",
"approval_cycle_days": 4,
"must_submit_by_date": "2026-02-19",
"days_late": 17,
"turnaround_time_days": 3,
"notes": "Expedited review requested; geotechnical verification confirmed"
}
],
"current_revision_number": 2,
"total_revisions": 2
}
Critical Path Submittal Flagging
Cross-reference each submittal with schedule.json critical path to flag items that will block the schedule if delayed:
Linking logic:
- Submittal's
spec_section maps to schedule.json material requirement
- Check if linked activity has
float = 0 or < 5 days
- If yes, set
critical_path_blocked = true
- These submittals get priority flagging in alerts
Example:
SUB-008 PEMB Reaction Drawing
Linked activity: A45-PEMB-Erection (critical path)
Float: 0 days
Flag: CRITICAL_PATH_BLOCKED = true
Alert priority: Highest — any delay impacts substantial completion
SUB-015 HVAC Equipment Data
Linked activity: A72-MEP-Rough-In (near-critical, float = 5)
Float: 5 days
Flag: CRITICAL_PATH_BLOCKED = false (but near-critical)
Alert priority: Medium — some schedule cushion but tight
Integration with /morning-brief and /daily-report
Morning Brief (/morning-brief):
- Scan all submittals with
status != "approved"
- List only CRITICAL and WARNING tiers (skip WATCH/NORMAL unless requested)
- Include must-submit-by dates and linked activities
- Provide action items for each flagged item
Daily Report (/daily-report):
- Include new rejections or resubmissions in "Open Items" section
- Note any submittals that crossed into CRITICAL or WARNING during the day
- Track turnaround time for resubmissions (days between rejection and resubmit)
- Update schedule impact assessment if critical path activities are affected
Cross-References
- project-data skill — Retrieves project-specific spec sections, approved materials, and submittal requirements
- document-intelligence skill — Parses PDFs and extracts structured data from submittal documents, data sheets, test reports, and shop drawings
- spec-requirement-extraction.md — Detailed guidance on identifying and structuring testable requirements from CSI specs
- compliance-checking.md — Detailed determination rules, evaluation methodology, and review comment templates