Every refinery, terminal operator, or EPC that decides to buy a digital twin platform eventually produces the same document: a requirements matrix built by combining a corporate IT security checklist with a list of features copied from whichever vendor's sales deck impressed the project sponsor. The result is an RFP that scores vendors on whether they can check a box for \"3D visualization\" or \"AI-powered analytics\" while missing the questions that actually determine whether the platform survives past the pilot — questions about who owns the underlying asset data, what happens when your inspection provider changes, and whether a field engineer can add a new tag without opening a support ticket and waiting six weeks.
\nAs an ASNT Level III who has spent as much time reviewing inspection data pipelines as writing procedures, I've watched this play out from the vendor side and the asset-owner side. Enterprise digital twin platforms are very good at winning RFPs and mediocre at surviving the first turnaround cycle after go-live, because the RFP never asked the questions that expose the gap. This checklist is built from the questions that actually matter — the ones that separate a platform your NDT inspection management and reliability teams will still be using in three years from one that becomes shelfware after the implementation team leaves.
\n\nMost digital twin demos show a beautiful 3D model with a few color-coded corrosion overlays already populated. What they don't show is the six months of manual data entry it took to get there. Before you sign anything, ask the vendor to demonstrate — live, with your actual file formats — how thickness readings from a UT grid survey, PAUT sectorial scan files, TOFD B-scans, and manual corrosion mapping reports flow into the twin without a human retyping numbers into a spreadsheet first. Ask specifically:
\nIf the answer to any of these involves \"our implementation team will build a custom connector,\" get that scoped and priced as a fixed deliverable in the contract, not left as a services estimate that grows once you're locked in.
\n\nA digital twin that only shows inspection results in isolation from process data is a viewer, not a twin. Ask how the platform connects to your process historian (PI, Honeywell PHD, or equivalent), your CMMS/EAM (SAP PM, Maximo, or a purpose-built NDT and asset system), and your P&ID/isometric drawing set. Specifically press on whether tag mapping between the historian and the 3D model is a one-time manual exercise performed by the vendor's services team, or whether your own engineers can add, remap, or correct a tag association without a change order. This single question predicts more about long-term cost of ownership than almost anything else in the RFP.
\n\nEnterprise digital twin incumbents overwhelmingly sell on a quote-only, custom-scoped basis with pricing disclosed only after a multi-month sales cycle involving several discovery calls, a proof-of-concept, and a procurement negotiation. That is a legitimate model for a $50 million capital project, but it makes basic budget planning nearly impossible for a mid-size operator trying to compare three platforms on equal footing. Your RFP should force every vendor to answer the same structured cost-transparency questions, even if the final number is still \"contact us for a quote\":
\nAtlantis NDT's digital twin platform is positioned deliberately against the quote-only, feature-gated model — every deployment is scoped, customized, and quoted directly against what an operator actually needs, without bundling unrelated enterprise modules the team will never touch. That doesn't mean price is disclosed in a blog post (it isn't, and shouldn't be, since every asset base and integration scope is different) — it means the conversation starts from your requirements, not from a standard SKU list built for a Fortune 500 IT budget.
\n\nThe single most common complaint from reliability and inspection teams two years into an enterprise digital twin deployment is not about the 3D rendering quality — it's that adding a new inspection field, changing a corrosion rate calculation, or adjusting a dashboard KPI requires a paid change order and a queue behind other customers' requests. Ask every vendor, in writing, whether your own engineers can configure new asset classes, custom inspection templates, and dashboard views without vendor involvement, and ask for a demonstration of that configuration happening in real time during the RFP evaluation, not just a slide claiming it's possible.
\nThis matters most for NDT-specific workflows. A generic industrial digital twin platform built primarily for rotating equipment and process control will treat inspection results as a generic attribute field.
\n\nA digital twin platform that ingests process historian data and 3D asset models sits at the boundary between your IT and OT (operational technology) networks — exactly the boundary that industrial cybersecurity frameworks like IEC 62443 and the NIST Cybersecurity Framework exist to protect. Your RFP should require every vendor to answer:
\nRefineries and terminals with TCEQ air permits and process safety management (PSM) obligations under OSHA 29 CFR 1910.119 already have IT security review processes for any system touching process data — loop your cybersecurity team into the RFP evaluation from the start rather than discovering a blocking security finding after the contract is signed.
\n\nDigital twin platforms accumulate years of inspection history, 3D models, and configured workflows — which is exactly why vendors have little incentive to make data export easy. Before signing, get explicit contract language covering:
\nThese questions rarely come up in a sales cycle because they only matter after you've already committed, which is precisely why they belong in the RFP rather than the eventual off-boarding conversation.
\n\nA realistic pilot for a single unit or a defined set of vessels and piping circuits should be scoped, timelined, and priced separately from a full-plant rollout, with success criteria defined in advance — not \"the vendor will tell us if it worked.\" Ask each vendor to commit, in the RFP response, to a specific pilot scope (for example, one process unit, a defined tank farm, or a single turnaround's worth of vessels), a specific timeline to first usable data in the twin, and a specific list of what \"successful pilot\" means from your side — not theirs. Vendors who resist committing to measurable pilot success criteria are signaling that the platform's value is harder to demonstrate on a compressed timeline than the sales process suggested.
\n\nNearly every digital twin vendor now leads with \"AI-powered predictive maintenance\" somewhere in the first slide of the deck. Before scoring that claim in an RFP, ask the vendor to specify exactly what the model predicts, what data it was trained on, and what happens when your asset class or operating conditions differ from whatever data set the model was built against. A predictive corrosion or failure model trained primarily on generic rotating equipment data will not meaningfully predict fixed-equipment corrosion under cyclic thermal service without asset-specific tuning, and a vendor who can't explain that distinction clearly during a technical evaluation call is not the vendor who will be able to explain a false-positive prediction to your reliability manager eighteen months in. Ask for the model's false-positive and false-negative behavior in plain language, not a marketing accuracy percentage with no context — and ask whether the model retrains on your site-specific data over time, or ships as a static model applied uniformly across every customer regardless of asset type.
\nIt's also fair to ask how the platform handles the much more mundane reality that predictive models need a baseline of historical data to be useful at all. A twin with six months of inspection history behind it cannot meaningfully predict a failure trend that plays out over a 10-year RBI interval — ask the vendor to be explicit about the minimum data history needed before predictive features produce anything more reliable than a generic industry benchmark.
\n\nEvery enterprise digital twin vendor will offer reference customers hand-picked to describe a smooth implementation. Get more signal by asking for a reference specifically in your asset class — refining, midstream, or chemical processing, not just \"industrial\" broadly — and ask that reference customer pointed questions about the exact issues this checklist raises: how long did self-service configuration actually take to become real, what was the true implementation timeline versus the one quoted at contract signing, and what would they do differently if they started the project over. A second technique worth building into the evaluation process is the reverse demo: instead of watching the vendor's prepared walkthrough, bring your own sample data set — a real UT thickness survey file, a real P&ID, a real corrosion loop history — and ask the vendor to configure a working model live, in front of your team, during the evaluation. Vendors confident in their self-service configuration claims will do this without hesitation; vendors who stall or ask to \"follow up after the call\" are telling you something important about how their implementation team actually works once the contract is signed.
\n\nPull these into a single scoring matrix and require every vendor to respond to the same questions in the same format — a platform that can't answer a direct question directly during the RFP stage will not become easier to work with after the contract is signed. Score data ingestion, integration depth, self-service configuration, cybersecurity posture, contract portability, and pilot commitment as separately weighted categories rather than one blended \"features\" score, since a vendor can score well on visualization polish while failing every question that determines whether your reliability engineers still trust the platform two turnarounds from now.
\nThe teams that get the best outcome from this process are the ones who treat the RFP as a filtering tool for eliminating platforms that can't answer hard questions plainly, rather than a formality on the way to a decision the project sponsor already made. A platform built to be affordable, accessible, and fully customizable should welcome every one of these questions — if a vendor deflects on pricing transparency, data portability, or self-service configuration, that reluctance is itself the answer you need before you sign.
\n\nThe organizations that regret their digital twin purchase eighteen months in almost never regret the 3D rendering quality — they regret not asking who owns their data, what a new field costs to add, and what happens if the relationship ends. Build an RFP around those questions first and the feature checklist second, and you'll filter out the platforms that were never going to survive contact with your actual inspection program regardless of how good the demo looked.
\n\nAtlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.
\n