Engineering and architecture
How complete are your RFI and submittal logs? A quality check
By SourceX Editorial · Updated
Short answer
RFI and submittal logs are complete when each item can be followed from question to answer to consequence: a unique number, dated status changes, the actual response text, readable attachments and links to drawings, specifications and changes. Score a sample of projects on ten checks; response text and downstream links are where most logs fall short.
Key takeaways
- A complete log entry records the answer itself, not just a note that the answer is attached.
- Status history matters more than current status, because it shows how long each decision took and who held it.
- Score a sample across building types and system periods before judging a whole archive.
- Never backfill missing dates or answers; flag derived fields and keep the raw export untouched.
- Logs kept on a contractor's platform may not be fully yours to export, so record where each log lives.
What does a complete RFI or submittal log look like?#
A complete RFI or submittal log lets someone reconstruct every item without opening another system: who asked, what was asked, which drawing or specification section it concerned, what the design team answered, when each status changed and what the answer led to. That standard matters at closeout, in a claim and in any later use of the records, including licensing them to AI developers.
Most firms find their logs are complete on the easy fields and thin on the valuable ones. Numbers, titles and dates are usually there. The response text, the status history and the link to the resulting bulletin, supplemental instruction or change order are often missing or buried in a PDF.
Those gaps matter because AI developers building document-review agents need full question-and-answer exchanges to train and test them. A log full of titles with no answers is an index; a smaller log with complete exchanges is a record of expert judgment.
The ten-point completeness check#
The ten-point completeness check covers the fields that let an RFI or submittal record stand on its own. Run it on both log types; the same checks apply with small changes in wording.
| Check | Complete looks like | Common gap |
|---|---|---|
| Unique identifier | One number per item, with resubmittals and revisions linked to the original | Numbers reused after a resubmittal, or reset when the project moved systems |
| Created and due dates | Date received and date a response was due on every item | Due dates never entered, or entered only for urgent items |
| Response and closed dates | Date answered and date closed, recorded separately | Items closed in bulk at closeout, erasing the real timing |
| Status history | Each status change with its date, not only the current status | Only the final status survives an export |
| Roles of parties | Originator, reviewer and responder identified by company role and discipline | Free-text names with no role, or the field left blank |
| Question or package description | The full question or package description in text | A title such as door hardware, with the substance in an attachment |
| Response text | The design team's answer or review comments in text | A note to see the attached sketch, with no text answer |
| Attachments | Files present, readable and named so they match the item | Broken links after migration, or scans with no text layer |
| References | Specification section and drawing sheet tied to the item | References that appear only inside attachments |
| Downstream links | Links to the bulletin, supplemental instruction, revised submittal or change order the item produced | No link; the consequence lives in a separate log |
How to score your logs#
Scoring works best on a sample, not a whole archive. Pick a handful of projects that represent your main building types, delivery methods and the systems you used over the years, then score each check for each project log.
Treat the total as a guide to the next step, not a grade. A project that scores low on response text but high on everything else is often a better candidate than one that scores evenly but has no answers at all.
- Score 2 when the check is met for nearly every item in the project log.
- Score 1 when it is met for some items, or only inside attachments.
- Score 0 when the field is missing or unusable.
- Add the ten scores for each project, then compare results by system and by period.
- Keep the score sheet with the project list so the check can be repeated after fixes.
| Total per project | What it usually means | Next step |
|---|---|---|
| 16 to 20 | Exchanges are readable without the source system | Move to a metadata inventory and a rights check |
| 9 to 15 | A usable core with fixable gaps, usually response text or links | Extract text from attachments and rebuild links on one pilot project |
| 0 to 8 | The log is an index and the substance lives elsewhere | Find where answers live, such as email or markups, before deciding |
Where do the gaps usually hide?#
Gaps in RFI and submittal logs usually hide in the handoffs between systems. Answers drafted in Bluebeam markups, issued by email or sent as sketch PDFs often never make it back into the log's response field, so the log shows the item closed but not what was decided.
Migrations cause a second kind of gap. Moving from Newforma, a spreadsheet on a file server or an older platform to a new one can carry the register across but not the attachments or status history. Check one migrated project end to end before trusting the rest.
The third gap is custody. On many projects the contractor hosts the RFI and submittal workflow in its own Procore or Autodesk Construction Cloud project, and the design firm works in it as an invited collaborator whose access can end when the project closes. If your firm kept only downloaded reports, the log you hold may be partial, and use of the platform record may depend on the owner and contractor agreements.
Illustrative: an architecture firm scores its logs before a platform change#
Illustrative: a fictional architecture firm that designs multifamily housing and commercial interiors is retiring its project information system. Before the switch, the COO asks the operations team to score RFI and submittal logs on a sample of projects from both studios and from each period of the firm's systems history.
Identifiers and dates score well everywhere. Response text scores low on older projects, where answers went out as marked-up PDFs, and downstream links score low across the board. Projects where the contractor ran the logs in its own platform score lowest, because the firm kept only exported reports.
The firm extracts text from the marked-up responses in its own logs, rebuilds links to bulletins on a pilot project and sets contractor-hosted projects aside pending a contract review. It ends up with a smaller set of complete exchanges and a migration plan that carries attachments and status history across intact.
How to fix gaps without rewriting history#
Fixing an RFI or submittal log means making existing information readable, not inventing what was never recorded. Buyers, auditors and claims counsel all need to trust that a date or an answer reflects what happened at the time.
- Keep the raw export untouched and do all cleanup on a copy.
- Extract response text from PDFs and markups, and mark the field as derived.
- Map free-text statuses to a short controlled list, keeping the original value beside the mapped one.
- Rebuild links to bulletins, supplemental instructions and change orders only where the source document names the item.
- Leave missing dates blank rather than estimating them.
- Replace personal names with role and discipline labels before any sample leaves the firm.
How SourceX uses a completeness check#
SourceX uses a completeness check in the Supply step of the SourceX five-step transaction to decide whether a log package is worth scoping. The fit check needs only metadata: which systems hold the logs, the years covered, the fields present and your own scores.
If a package proceeds through Rights, the Preparation step applies only the fixes the firm approves. Its SourceX Evidence Packet then documents where each log came from, the licensing rights and permitted use, the privacy record and the firm's release authorization, and notes which fields were derived from attachments rather than captured at the time.
Frequently asked questions
Do we need to score every project in the archive?
No. A sample that covers your main building types, delivery methods and system periods shows where the problems are. Score more projects only where the sample reveals mixed results, such as the years just before or after a platform change.
Does a low score mean the logs have no value?
Not necessarily. A low score often means the substance lives elsewhere, in markups, email or sketches. If those can be tied back to log items, the archive can still yield complete exchanges. A log with no recoverable answers is much harder to use.
Who owns an RFI log kept in the contractor's platform?
That depends on the owner-contractor agreement, the owner-architect agreement and the platform's terms. The design firm's own responses are usually its work, but the platform record may sit with the contractor or owner. Record where each log lives and review the contracts before using it.
Should withdrawn or void RFIs stay in the log?
Yes, keep them and label them clearly. A withdrawn question still shows what a contractor found unclear, and removing it breaks the numbering sequence. A clear status stops anyone mistaking a withdrawn item for an unanswered one.
Can we score logs already archived as PDF reports?
Yes, though PDF reports often hold only current status and summary fields. Score them as they are, then check whether the original system, a database backup or the project folders still hold the status history and attachments the reports left out.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.