Why FEL2 tie-points are where projects bleed

Tie-points are the small print of every FEL2 study. A tie-point list lives next to the BFD as a clean numbered table: inlet at 65 psig, outlet at 80°F, vapor fraction 0.02. It looks like a checklist. It is not a checklist.

The pattern

A tie-point fixes an interface condition between two engineering scopes. The handoff might be between Torus and an EPC, or between two disciplines inside the same EPC. What gets written in the table is what the downstream party will design against. When the upstream party's PFD evolves, which it always does, the table does not move with it unless someone moves it.

What we see

The recurring failure: the line list shifts a process condition after FEL2 freeze, and the tie-point table does not update. The mechanical group sizes a pump against the old pressure. The downstream EPC sizes an exchanger against a stream composition that no longer exists. Both deliverables ship. The mismatch is found in commissioning.

The fix is not better PDFs. The fix is treating the tie-point table as a typed contract, with the line list and the PFD as the type system. Every time a relevant cell changes upstream, the tie-point row should fail a check until it is reconciled.

The check

Three rules catch most of the damage:

1. Stream identity. Every tie-point row maps to exactly one stream tag in the PFD. If the stream tag is deleted or renumbered, the tie-point row goes red.
2. Condition reconciliation. The pressure / temperature / phase columns must match the values on the corresponding line in the line list. Tolerance bands declared explicitly per tie-point.
3. Owner attestation. A tie-point row is not "approved" until both upstream and downstream owners attest. Attestation expires when either side's source document version changes.

Closing

The tie-point table is the API contract between scopes. Treat it like one. Fail loudly on drift. The discipline that catches a tie-point drift in FEL2 saves three months on the back end.