Exports, retention, and leaving: your data on your terms

Inspection history is worth more the longer it runs. Twenty years of thickness readings on a vessel are the corrosion rate; the rate is the remaining life; the remaining life is the interval. A platform that holds that history holds the basis of your inspection program, and the question of how you get it out is not a procurement formality. This paper covers what a complete export of inspection data contains, why an open API changes the exit question, what retention must preserve so the record stays defensible, what becomes of the audit trail, and how to make portability contractual rather than a portal feature.

Why is inspection data portability different from ordinary SaaS export?

Exporting a CRM is a table of contacts. Exporting an inspection platform is a graph.

• The records reference each other. A reading belongs to a CML, the CML to a component, the component to an asset, the asset to a facility. A finding references a photo, a damage mechanism and a workflow history. Flat CSVs that drop those references leave you with numbers and no equipment.
• The engineering context is data too. A thickness value without the nominal thickness, tMin and its method, design pressure, material, allowable stress and joint efficiency cannot be recalculated. A CML export that carries only the latest reading has lost the inputs.
• The history is the product. Corrosion rates are derived from the sequence of readings. An export that gives you the current state but not the sequence has thrown away the rate.
• The attachments are evidence. Photos, annotated drawings, UT scans and signed PDFs are part of the record, and each must stay bound to the record it belongs to, with its timestamp and author.

Portability, for inspection data, means the whole graph, with references intact, in formats your next system or your own engineers can read.

What formats should an inspection data export include?

No single format serves every use. A complete export offers several, for different consumers.

• Structured data through an API, in JSON, with the identifiers that link records. This is what your next platform or your data team consumes.
• Workbooks and CSV for engineers and auditors who work in spreadsheets, with one sheet or file per record type and stable identifiers so the sheets can be joined.
• PDF reports for the human-readable, signed record: cover, header and footer, tenant branding, per-locale dates. These are what an auditor reads, but they are not what a migration uses.
• Attachments in their native formats, referenced by record identifier, not dumped into a folder to be sorted later.
• The audit trail as structured data, per tenant, with the fields needed to recompute the hash chain.

Bulk export should be a named permission, granted narrowly and logged every time, because the same capability that protects your exit is the largest data-loss vector the platform has. Scheduled reports and exports, running on a timer to a location you control, turn the export from an event into a routine.

Ask the vendor for a sample export from a demo tenant before the pilot, and have an engineer open it. If the CML sheet has a thickness column but no tMin column, keep asking.

How does an open API change the exit question?

The strongest portability guarantee is not an export button. It is a documented API you can call whenever you want.

An OpenAPI specification that covers the platform's endpoints does three things for you:

1. Continuous extraction. Your data team can script a nightly pull of every record type into your own warehouse. The exit becomes a routine you already run, not a project you begin under pressure.
2. Verification. You can reconcile the API against the UI on your own schedule: CML counts, latest readings, open findings. Discrepancies surface while the vendor relationship is healthy.
3. Independence from the vendor's export feature. Export screens change, get rate-limited or get moved to a higher tier. A documented API with tenant-issued keys is a contract in code.

Ask how many endpoints are documented, whether tenant administrators can issue and revoke API keys themselves, and whether the keys are tied to a role so that a read-only extraction key cannot write. Ask to see the specification, not a slide about it.

Two cautions. First, API access should not be the only path; a workbook export for the engineer with no scripting support is still needed. Second, be skeptical of claims about pre-built connectors to named enterprise systems. Ask to see them in the product. An open API and workbook import and export are a clear and reviewable integration surface; a connector on a roadmap is not.

What must retention preserve: the record as executed

Retention is usually discussed as a duration. For inspection records, the harder question is fidelity.

A completed inspection was executed against a form: specific fields, dropdown options, units, locale and date format. Forms change over years. If a 2019 record is rendered against the 2026 form definition, every value may be intact and the record is still not what the inspector signed. A field that has since been renamed reads differently. An option that has since been removed shows blank.

The requirement is that a completed record pins the field configuration, locale and reference options it was executed with, so it renders forever as executed. This matters for retention in two ways:

• Within the platform, a record you open in ten years must look like the PDF generated on the day.
• In an export, the configuration must travel with the values, otherwise the receiving system will interpret a legacy field with a current label.

Test it: ask the vendor to open a record completed under a form version they have since changed, and compare it to a PDF generated at the time.

Retention duration then follows your regulatory and engineering needs. For pressure equipment, the useful retention is the life of the equipment plus the investigation window after it; corrosion history has no expiry date while the vessel is in service. Confirm the platform does not purge readings or attachments on a timer.

What happens to the audit trail when you export or leave?

The audit trail is the evidence that your records are what they claim to be. It has to be portable too.

• The export is itself an event. Who ran the export, when, from where, under which request id. This protects you as much as the vendor.
• The trail is exportable. Per tenant, as structured data, with the actor, tenant, request id, IP, user agent and timestamp for every event, and with the hash fields needed to recompute the chain independently.
• Nothing was deleted. A trail that has been pruned by a retention job is a trail with gaps an auditor will find. The right policy is that audit events are never auto-deleted; storage tiers, never purges.
• Sync history is included. Field-level conflict records from offline capture (local value, remote value, resolver, time) are changes to the record and belong in the trail you take with you.

The record proves what the reading was. The audit trail proves the record is what it was. Take both.

How to write portability into the contract and test it before signing

Portability that lives in a portal feature can be changed. Portability that lives in the contract cannot. Work through both during the pilot.

Test during the pilot:

• Load a real unit's history, including attachments, through the import path.
• Run the full export and reconcile it against the UI with an integrity engineer: CML count, latest reading per CML, governing corrosion rate, open findings, signatures.
• Pull the same data through the API with a tenant-issued key and compare.
• Time both paths.
• Open an older record and confirm it renders as executed.

Write into the contract:

• The formats and the scope of a full export, including attachments and the audit trail.
• The turnaround time for an export request and any cost.
• The post-termination window in which your data remains accessible, and what happens at its end.
• Confirmation that exports are not tier-gated.
• The API specification as a referenced document.

Do this while you are choosing, not when you are leaving. The vendor that welcomes the test is telling you something; so is the one that does not.

How intelliSPEC handles it

intelliSPEC's integration surface is an OpenAPI 3.0 specification with 514 documented endpoints, tenant self-service API keys that are tenant-bound signed tokens tied to a role, Excel workbook import with assisted column mapping, CSV, PDF generation and bulk export. Report definitions with datasets and layouts drive PDF output with cover, header and footer, tenant report branding, per-locale date formats, scheduled reports and workbook export. Data-subject request handling is built in. There are no ERP or CMMS connectors; the open API and workbook import and export are the integration surface.

Completed records pin the field configuration, locale and reference options they were executed with, so a finished inspection renders forever as executed, and every CML carries its engineering fields (nominal thickness, tMin and its method, design pressure, material, OD and schedule, allowable stress, joint efficiency, corrosion allowance, grid geometry, latest thickness and three corrosion rates) so an export carries the inputs, not just the answers.

Every data export and import is an audit event with actor, tenant, request id, IP and user agent, chained per tenant with SHA-256 and verifiable by a recompute routine; audit events are never auto-deleted. Offline sync writes field-level conflict records into the same trail.

For the controls around who may export, see role based access for inspection software; for the trail itself, see the immutable audit trail. The security posture behind both is published in the Trust Center, and what each tier includes is on the pricing page.