FEED and BASIC engineering (sometimes called pre-FEED and FEED at different companies, or Phase 2 and Phase 3) are often described interchangeably in project schedules, but they impose fundamentally different document control demands. The distinction matters because the nature of change, and the risk of a missed inconsistency, differs substantially between the two phases.
This article is not a general primer on project phases. It is a focused look at which document types change most in each phase, why they change, and where the cross-document consistency risk is highest as a result.
FEED: Conceptual Definition, Frequent Revision
Front-End Engineering and Design is the phase where the project is defined well enough to support a reliable capital cost estimate, typically with an accuracy target in the range of plus or minus 10 to 15 percent. The document set produced during FEED is comprehensive enough to describe the process but not yet detailed enough to construct from.
During FEED, the documents that change most frequently are process-level: the process flow diagrams, the heat and mass balance, and the P&IDs, which are at a preliminary or checked level (often called P2 or IFR, Issued for Review). The P&IDs at this stage typically show major equipment, primary piping routes, major control valves, and key instrumentation. Minor instruments may be shown schematically without full tagging. Process conditions on the P&ID are based on the current heat and mass balance, which is itself still being refined.
The document control challenge in FEED is that everything is iterative and the rate of change is high. A heat and mass balance revision every two to three weeks is not unusual on an active FEED study. Each HMB revision potentially affects the P&IDs, the equipment datasheets (if preliminary sizing has started), and the process data sheets. But FEED teams are typically small, often 5 to 12 engineers, and the informal cross-checking that happens in a small team catches most of the cascades before they become persistent inconsistencies.
The FEED-to-BASIC Transition: Where Inconsistencies Get Locked In
The handoff from FEED to BASIC engineering is a critical consistency checkpoint that is often under-managed relative to its risk. At the end of FEED, the client approves the FEED deliverables as the basis for BASIC engineering. Those approved deliverables become the frozen baseline from which detailed design will develop. Any inconsistency in the FEED deliverables that was not resolved before handoff is now embedded in the baseline.
On a typical project, the FEED-to-BASIC handoff is preceded by a period of intense document finalization and client review that introduces its own inconsistency risk. Comments received from the client during FEED review are incorporated in a compressed timeframe. P&ID revisions issued in response to client comments may not propagate completely to every affected document before the FEED deliverable register is frozen.
The result is a BASIC engineering baseline that is mostly consistent but contains a handful of residual discrepancies: a process condition on a P&ID that does not match the final HMB, a preliminary equipment note that references an operating pressure from an earlier HMB revision, a line size that was changed in the final P&ID revision but was not updated in the hydraulic summary. These are the discrepancies that BASIC engineering teams inherit and must either resolve explicitly or carry forward into detailed design.
BASIC Engineering: More Documents, More Cross-Reference Surface
BASIC engineering expands the document set substantially. The P&IDs go from preliminary to IFC-level (Issued for Construction) or equivalent. The instrument list becomes a formal instrument index with full tagging. Equipment datasheets get issued for procurement. Line lists are developed. The cause-and-effect matrix is produced. Utility flow diagrams and single-line electrical diagrams appear.
The rate of change during BASIC engineering is lower than during FEED, but the cross-reference surface, the number of documents that are logically connected and must be consistent, is much larger. A change to an operating condition on the P&ID now needs to propagate not just to the HMB but also to the instrument index, the equipment spec, the line list, and potentially the cause-and-effect matrix. The same number of engineers may be doing the cross-checking, but there are many more documents to check.
A useful way to think about this: during FEED, document consistency is mostly a single-layer problem (does this document reflect the current HMB?). During BASIC engineering, it becomes a multi-layer problem (does this document reflect the current P&ID, which reflects the current HMB, which reflects the current reservoir/feed composition data, and are all the intermediate documents updated to match?).
Which Document Changes Most in Each Phase
| Document Type | Change Rate in FEED | Change Rate in BASIC | Consistency Risk Shift |
|---|---|---|---|
| Heat and Mass Balance | High (biweekly) | Low (frozen or locked) | Risk shifts downstream to documents that used old HMB values |
| P&ID | High (preliminary) | Medium (checked/IFC) | Downstream impact grows as document set expands |
| Instrument Index | Low (partial/scoping) | High (primary output) | Highest consistency risk is in BASIC, absorbing changes from multiple sources |
| Equipment Datasheets | Medium (preliminary sizing) | High (procurement issue) | Vendor submissions create a new layer of cross-check in BASIC |
| Line List | Low (not fully developed) | High (primary output) | P&ID-to-line-list discrepancies concentrated here |
Where to Focus Consistency Checking
The implication for document control is that the type of consistency checking needed differs by phase. During FEED, the highest-value check is ensuring that each P&ID revision reflects the current HMB, since the HMB is the master process data source and is changing frequently. A relatively small number of documents need checking, and the checking can be fairly targeted: which operating conditions on the P&ID have changed relative to the previous HMB?
During BASIC engineering, the highest-value check shifts to the downstream impact of P&ID revisions. The HMB is largely frozen, but the P&ID continues to be revised based on design development, vendor information, and client review comments. Each P&ID revision potentially affects the instrument index, equipment datasheets, line list, and cause-and-effect matrix. The question is no longer just "does the P&ID match the HMB?" but "which documents need to be updated as a result of this P&ID revision, and have they been?"
This distinction is not merely conceptual. It determines where an automated consistency tool should focus its checking effort. We built SnapScale to address the BASIC engineering problem first because that is where the cross-reference surface is largest and the inconsistency cost is highest. Catching a discrepancy between the instrument index and the P&ID before the HAZOP study, rather than during it, is where the time savings are most tangible.
The Handover from FEED Contractor to BASIC Contractor
Many capital projects split FEED and BASIC engineering between different contractors, with the owner acting as the interface. This creates an additional consistency challenge at the handoff. The FEED deliverables produced by Contractor A become the basis documents for Contractor B, who may interpret them differently, use different numbering conventions, or identify inconsistencies that were missed in the FEED review.
This transition is a particularly rich source of early BASIC engineering rework. Contractor B often discovers that some values in the FEED P&IDs do not match the FEED HMB, or that the equipment list uses preliminary designations that need to be reconciled with the formal tag register before detailed design can proceed. This reconciliation work is a direct cost of inconsistencies that accumulated during FEED and were not caught at the handoff.
We are not saying that all of this rework is avoidable. Some amount of design development naturally requires revisiting FEED assumptions. The rework that is avoidable is the purely mechanical finding and correcting of values that were already changed in one document but not propagated to others. That is the problem SnapScale targets.