RFIs (Request For Information) are the highest-volume document on a typical commercial construction project — 200-2000 per build. /rfi-tracker is Kodori's AEC equivalent of /ap-review, with a morning-stand-up view of what's blocking the project.
**The flow:**
1. Contractor identifies a question on the drawings or specs. 2. Submits an RFI document — a one-page form with subject, project ref, requested by / of, location, dates. 3. Kodori's auto-classifier flags the doc as "RFI" (the existing doc-type-hint pattern). 4. The extract-rfi Inngest function pulls the structured fields via Haiku and writes them to the rfis projection. 5. Row lands on /rfi-tracker for the project team.
**What you'll see on /rfi-tracker:**
- **Open** — actionable count. - **Overdue** — open RFIs past their due date. Highlights red. The morning-stand-up view of what's blocking the project right now. - **Due in 7d** — open RFIs with a due date within the next week. - **Answered / Rejected** — closed RFIs for history. - **Top projects by open count** — quick scan of which projects have the most open questions.
Each row links to the RFI document on /doc/[id] for the full content; the inline display shows RFI # / subject, project, requested by → requested of, location (spec section, drawing ref), issued + due dates.
**Status lifecycle:**
- *open* — initial state after extraction. - *answered* — operator marks the RFI answered when the response is filed. - *rejected* — RFI declined (vendor won't answer, scope is out, etc.). - *extraction-failed* — Haiku couldn't pull a usable subject + RFI number; surfaces for human fill-in.
**Coming next:** linking response documents to their RFIs (when the architect's reply gets filed as a separate Kodori doc, mark the RFI answered with the response doc id); submittal tracking (the AEC counterpart for product / material approvals); change-order tracking. The infrastructure (extractor → projection → /rfi-tracker UI) is reusable for each.