Lookahead Constraint Scan

The scan should return lookahead activities that look blocked, each tied to a source cite the superintendent can open in the project system. A cite is an RFI identifier plus its live status, a delivery line (item, promised on-site date, vendor of record if present), or a permit record (type, status, issuing body). The superintendent still owns the call: keep the activity, shift it, staff a workaround, or send the flag back as noise.

The model does not own the lookahead. It does not close documents. It does not move dates in the CPM. If you need a logic-tied schedule from scope, that is a different job, covered in CPM schedule generation from scope. This page is only the join between the rolling lookahead and three constraint sources the field already watches: open RFIs, material deliveries, and permit status.

A six-week window is a design choice. Use the same horizon the job already brings to the weekly coordination meeting. If the superintendent looks four weeks out, scan four. Stretching to six because a template says six does not make the list more true.

Empty stays empty. If the RFI log, delivery register, and permit tracker have no row that matches an activity, do not invent a blocker to fill the page. A short list the superintendent can check before the meeting is the quality bar. A long list padded with guessed constraints is a quality failure.

Start from the lookahead, not from the constraint logs. Each activity already has a name, a location or area, a trade, planned dates, and usually a cost code or WBS tag. Those fields are the join keys. The scan should not keyword-match the entire project log and dump every open RFI onto week one.

For RFIs, restrict to records the source system still marks open, unanswered, or in review. Match on the area, system, or spec section the activity actually installs. An open RFI about roofing membrane on a penthouse is not a blocker for interior drywall on Level 2. Project systems such as Procore or Autodesk hold the RFI log the job already uses. If a superintendent closed the RFI in the field meeting but the log still shows Open, the scan will flag it. That is a stale status, not a new field hold. Pair this with RFI auto-response drafting only after the log status is trustworthy. Drafting a response does not make a closed RFI open, and it does not turn an open RFI into a delay.

For material deliveries, join on the material the activity consumes, not on the vendor name. Long-lead items (curtain wall, switchgear, air handlers, elevators) often sit on a procurement log with an ETA older than the lookahead. If the activity's early start is before the promised on-site date, flag it and cite the delivery row. If there is no delivery row, do not infer a shortage. A related check, critical material delivery ETA prediction, can refresh a stale ETA. This scan should not invent an ETA. It should cite the date that already exists, or stay silent.

For permits, join on work type and location. Facade, after-hours, street closure, hot work, and occupancy-related permits are the usual holds. Match the permit's status field as the source system stores it: applied, in review, issued, expired. Do not treat in review as issued. Do not treat an issued permit for a different elevation as coverage for this one.

Keep the join conservative. Require at least one shared key (area, system, spec, or material) plus an open or not-issued status. Ambiguous matches belong in a review queue, not on the superintendent's daily list.

Take a mid-rise envelope lookahead. One activity in week three reads: install storefront, Level 2 west elevation. The scan should attempt three joins and stop when the sources have nothing. This is an illustration of the join, not a job record.

RFI join: if the log still shows an open item on storefront anchors at that elevation, cite the identifier and the status field as stored. Do not write a question the log does not contain. If the log has no open storefront RFI for that area, this cite is absent. Do not create one.

Delivery join: if the procurement register shows insulated glass units for that elevation with a promised on-site date after the activity's early start, cite the line (item, quantity if present, promised date). If the register has no glass line, do not flag a glass shortage.

Permit join: if the tracker shows a facade permit still in review for that elevation, cite the permit type and status. If the tracker has an issued facade permit covering that elevation, do not flag it.

The superintendent gets zero, one, two, or three cites for that activity, never a synthesized risk score. They open the cited records. They may already know the RFI was answered on a sketch that never hit the log, that the glass is on a truck the register has not updated, or that the permit issued yesterday. Those dismissals are the job. The scan's quality is whether each flag is checkable, not whether the list is long.

Flagging a closed RFI as open is the fastest way to lose the room. Retrieval that ignores status, or that reads a PDF copy of an RFI later closed in the log, will keep the activity blocked on paper. Require the live status field. If status is missing, do not guess Open. Drop the cite or send it to review. Never let a closed record appear as a current hold.

Missing a long-lead delivery is the opposite error. The lookahead shows install air handlers in week five. The procurement log has the units on a factory date past that week, but the join keyed only on mechanical and skipped the equipment tag. The activity stays green. The fix is a stricter material key (tag, spec, or PO line), not a looser keyword. If the source has no row, the scan stays empty for that activity and the planner still has to ask procurement. Silence is honest. A guessed delivery date is not.

Treating a constraint as a delay claim is a process failure, not a model failure. A flag is not notice, not entitlement, and not a time-impact analysis. An open RFI or an unissued permit may be a real hold on that activity. It may also be work the crew can sequence around. Writing the flag into a delay narrative, a daily report, or an owner letter without the superintendent's review turns a planning aid into a claims document. Keep the output labeled as a working list. Keep cites as pointers, not as findings of delay.

Other routine misses include matching the wrong elevation, treating answered-pending-revision as closed, flagging a delivery that is for a later phase, and reading a permit expiration as a never-issued permit. Each is a join or status error. Fix the keys and the status filter before adding more sources.

Design clashes found in the model are not this scan. If two systems occupy the same space, that belongs with BIM design clash detection, then, if needed, an RFI. Do not double-count a clash as a lookahead blocker unless an open RFI or permit already exists.

The superintendent or planner who runs the weekly lookahead is the reviewer. They should be able to open each cite in the same system the job already uses. If a flag cannot be opened, it does not ship.

Do not put recommended crew sizes, weather calls, or safety observations on this list. Do not auto-resequence the lookahead. Do not mark an activity complete. Do not create an RFI from a suspected gap. If the sources are empty, the list is empty, and that is the correct quality outcome.

Vendors such as Procore and Autodesk are the class of system that already stores the logs. The scan reads those records. It does not replace the log, the coordination meeting, or the person who still owns the week.