TransCanada Keystone Pipeline GP and the control records behind pipeline operations

Summary

• TransCanada Keystone Pipeline GP is a historical identity in the current public record: the Canada Energy Regulator now describes South Bow GP (Canada) Ltd. as formerly TransCanada Keystone Pipeline GP Ltd., while South Bow entities own and operate the Keystone system after the 2024 separation from TC Energy.
• The most revealing technology evidence is not a product page. It is the chain linking construction records, pipe identity, in-line inspection data, pressure history, SCADA alarms, controller actions, field confirmation, repair decisions and regulator access.
• Public investigations show that detection is layered and imperfect. Control-room alarms supported shutdowns in major incidents, while inspection tools and historical records did not always expose the physical condition that later failed.
• Cross-border control raises real data-sovereignty and locality questions, but the location of a Calgary control room does not prove where databases are hosted. The defensible questions concern authority, access, retention, lineage, export and recovery under Canadian and U.S. obligations.
• South Bow's ERP transition, integrity work, incident restrictions and proposed 2026 settlement make the commercial test concrete: automation is worthwhile only if reduced reconciliation and stronger evidence outweigh migration, storage, integration, lock-in and data-quality labour.

At 9:01 on the evening of December 7, 2022, the liquids pipeline control centre received a volume-imbalance alarm on the Keystone system, followed by an emergency-line trip alarm. Six minutes later, the controller initiated an emergency shutdown. By 9:20, the affected section between Steele City and Hope had been isolated. Those times, preserved in the U.S. Pipeline and Hazardous Materials Safety Administration's investigation, look like the clean output of an industrial control system: signal, decision, action.

The rest of the investigation makes the technology story much less comfortable. An estimated 12,937 barrels of crude oil escaped near Washington, Kansas, much of it reaching Mill Creek. The failure was traced to a circumferential girth weld subjected to external loading. PHMSA attributed the main source of that load to inadequate soil compaction after replacement work in 2010. Several inspection runs had not identified the condition that later mattered. A tool passing through the line on the night of the rupture did not identify a leak at the eventual failure fitting before the failure.

The available inertial data had no post-construction 2010 baseline against which later movement could be measured.

That sequence is a useful way to understand the company in this directory entry. The technology question is not whether Keystone had sensors, alarms, inspection tools or databases. Public records show that it did. The question is whether many different records, created by different people and instruments over many years, can be joined into a dependable account of the asset before a physical defect becomes an emergency.

The answer cannot be inferred from a pipeline name. Nor can it be inferred from one successful alarm. A control centre can respond correctly to the state it can see while the longer history of construction, soil movement, weld geometry and tool capability remains incomplete. A field crew can perform an inspection while the selected instrument is poorly suited to the eventual defect. A regulator can require records while identifiers, formats and vendor data make the evidence costly to reconstruct.

A company can migrate its enterprise systems successfully enough to run the business while still reporting weaknesses in financial-reporting controls. These are different layers, and a serious assessment has to keep them separate.

A historical name and a current operating boundary

The first record to govern is the company identity itself. TransCanada Keystone Pipeline GP Ltd. is the name attached to the directory entry and to years of Canadian regulatory material. It remains important because historical audits, financial-resource tables, toll proceedings and operating evidence use it. But current public records do not support treating that name as the complete description of present ownership or operations.

The Canada Energy Regulator's 2024-25 decision summary identifies South Bow GP (Canada) Ltd. as formerly TransCanada Keystone Pipeline GP Ltd. South Bow's Annual Information Form says the liquids-pipelines business was transferred from TC Energy to South Bow in the 2024 spin-off. In the United States, the Justice Department's July 2026 announcement identifies South Bow (USA) LP and South Bow Infrastructure Operations Inc. as owner and operator in the complaint concerning the 2022 Kansas spill. South Bow's current website presents the Keystone Pipeline System as its core operating asset.

This is more than naming etiquette. Legal identity determines which company signs a filing, holds an obligation, employs or contracts a worker, controls a system, receives a regulator request and carries a liability. Historical identity determines whether an old construction record, inspection report, incident action or toll decision can be found after the corporate boundary changes. A data model that simply replaces every TransCanada or TC Energy label with South Bow would lose provenance. One that leaves every old name unlinked would fragment the record.

The practical requirement is an identity history, not a preferred brand string. Each company, operator, asset, pipeline segment, pump station, pipe joint, inspection run and regulator case needs a stable identifier and dated aliases. A search for a 2017 event should retrieve evidence filed under TransCanada. A 2025 corrective action should resolve to South Bow. A user should be able to see that the operator context changed without being told that the underlying pipe was newly created in 2024. This is the kind of unglamorous master-data work on which every more ambitious automation depends.

The boundary also prevents a common analytical mistake: attributing all present claims to the old entity or all old events to the new one without qualification. South Bow inherited an operating asset and its history, but the record should still preserve who did what, under which name, at which date. A regulator, insurer, shipper, engineer or investigator needs that temporal precision. So does a board trying to decide whether a corrective action is complete.

What the control record has to join

A pipeline operating record is not one database. It is a chain of observations, decisions and evidence spread across physical and organisational systems. At the field edge are instruments measuring pressure, flow and equipment state. SCADA brings selected values and alarms to controllers, who use procedures, displays and communications to operate pumps and valves. Leak-detection logic may compare volumes or model hydraulic behaviour. Maintenance systems hold work orders. Inspection vendors deliver large datasets from tools that travel inside the pipe. Engineering teams interpret anomalies.

Construction records describe materials, welds, coatings, replacements and tests. Emergency systems track notifications, resources and response actions. Regulatory systems turn parts of that history into reports, orders and compliance evidence.

Each layer has its own time scale. A pressure value may matter within seconds. A controller handover spans hours. A work order may remain open for days. An inspection interval runs over years. A weld or soil-compaction record may become decisive more than a decade after construction. Corporate ownership can change while the physical asset stays in the ground. The control record has to preserve enough context to connect those clocks without pretending they are interchangeable.

The U.S. control-room management rule gives a public outline of what that means for controllers. Operators must define roles in normal, abnormal and emergency conditions; record shift changes; verify relationships between field equipment and SCADA displays when changes are made; test backup arrangements; review safety-related alarms; check set-points and descriptions; coordinate changes with control-room and field personnel; train controllers; and retain compliance records. These are not optional features in a software brochure. They are operating duties.

Canadian rules frame the same problem at management-system level. A company must integrate operational activities and technical systems with human and financial resources. It must identify hazards, maintain inventories, generate and retain records, provide access to people who need them, coordinate employees and contractors, plan for abnormal events, monitor activities and correct deficiencies. It must also evaluate whether enough human resources are assigned to the management system. Taken together, the rules describe a socio-technical control system: data, procedures, tools, authority and labour.

This distinction matters because a screen can be current while the underlying asset history is not. The controller may see an accurate pressure value mapped to the right field instrument, yet an engineering assessment may lack a useful construction baseline. Conversely, a deep archive can contain every old report but fail to support a decision if the records cannot be matched to the right pipe joint or compared across inspection vendors. Freshness and completeness are different qualities. Queryability and correctness are different qualities. Retention and recoverability are different again.

For Keystone, the public record exposes several identifiers that have to stay aligned: mileposts, pump stations, pipeline segments, nominal diameters, wall thicknesses, manufacturers, weld types, tool runs, anomaly locations, pressure set-points, special-permit conditions and incident case numbers. If a location is described one way in construction records, another way in a vendor dataset and a third way in a regulator filing, automation can amplify the mismatch. It will return an answer faster, but not necessarily the right one.

A mature operating record therefore needs provenance at field level. Who produced the value? Which instrument or tool observed it? What was the calibration or capability? Which software version processed it? Which engineer accepted the interpretation? What physical location and asset revision did it refer to? Was the value measured, calculated, forced, manually entered or inferred? Did a later review supersede it? These questions sound administrative until an accident investigation needs an answer. Then they become the operating history of the pipe.

Detection worked, but detection was not omniscience

Three incidents illustrate the difference between seeing a rupture and seeing the conditions that precede it.

In November 2017, Keystone ruptured near Amherst, South Dakota. The National Transportation Safety Board records that the Calgary operations control centre was monitoring SCADA, detected the leak and shut down the pipeline. Field staff travelled to the indicated location, confirmed the rupture and began the spill response. The NTSB identified a fatigue crack, likely originating from mechanical damage to the exterior during construction, as the probable cause.

There are two truths in that finding. The operational system detected the release and supported a response. The deeper causal condition had grown from earlier physical damage. The first truth supports the value of telemetry, alarm logic, trained controllers and field mobilisation. The second shows why real-time visibility cannot substitute for construction quality, integrity assessment and long-lived asset records.

The 2022 Kansas failure makes the boundary even sharper. A cleaning and leak-detection tool was in the pipeline section that evening. PHMSA's report says the tool passed the fitting that later failed and did not identify a leak there. This is not surprising once the time sequence is understood: a system that has not yet ruptured may not present the leak signature the tool is designed to detect. But the report also examines earlier in-line inspections and their capabilities. Some tools were not designed for girth-weld cracks or bulges. Sensor performance can degrade through bends and wall-thickness transitions.

The physical geometry around the failure combined both conditions.

The lesson is not that inspection was useless. It is that an inspection result is inseparable from the question the tool was capable of answering. "No indication" is not the same as "no defect." A useful record must preserve tool type, sensor limits, resolution, run conditions, vendor analysis, confidence, geometry and the classes of threat that were outside scope. If a later user sees only a green status or a closed work item, the system has compressed away the caveat that gives the result meaning.

The missing 2010 inertial baseline is similarly important. PHMSA reported that inertial data from 2013 and 2018 showed no movement between those two runs at the failure location, but no post-construction inertial dataset had been collected in 2010 to establish a baseline. That does not prove a particular movement occurred before 2013. It proves that a useful comparison to the immediate post-construction state was unavailable. No later data platform can recreate a measurement that was never taken.

This is the hard limit on recoverability. Backups can restore files. Data lakes can consolidate vendor deliveries. New analytics can revisit old signals. None can manufacture a trustworthy baseline after the fact. The commercial value of record design is therefore partly option value: collect and preserve enough context today so an engineer can ask a question tomorrow that was not obvious when the data was created.

The April 2025 event near Fort Ransom, North Dakota, adds another view. PHMSA's corrective action order says a technician at the pump station heard a loud noise and initiated a local emergency shutdown. The Calgary control centre received alarms and initiated a pipeline shutdown, then remotely actuated valves to isolate the line on either side of the spill. Regulators went both to the site and to the Calgary control room. The reported release estimate was 3,500 barrels.

This sequence should resist a simplistic contest over whether a person or an automated system "found" the event. The public record describes a local sensory observation, local action, control-centre alarms, remote action and field/regulatory response. The defence is layered. Its quality depends on whether each layer has authority, current procedures, reliable communications and a common understanding of asset state. A human hearing something abnormal is not evidence that automation failed. An alarm is not evidence that human judgement is redundant.

PHMSA's 2025 order is particularly revealing because it turns incident concern into data requirements. The company had to reduce pressure on affected portions, adjust relevant alarm limits and software set-points, review pressure data monthly, account for inspection anomalies, re-evaluate ten calendar years of in-line inspection results including vendor raw data, document tool runs and features, commission independent testing, produce root-cause analysis and prepare a remedial work plan. That is a generation chain for engineering evidence: collect, preserve, interpret, challenge, document, act and report.

The order also exposes why vendor lock-in is not an abstract procurement concern. If a regulator can require ten years of raw vendor data, the operator needs durable rights to retrieve it, understand its schema and relate it to current asset identifiers. A PDF summary is not equivalent to raw signal data. A proprietary viewing application that no longer runs is not a recoverable record. A vendor's anomaly naming convention is not useful if it cannot be mapped to the operator's pipe tally.

Contract terms for export, documentation, retention and migration are therefore part of pipeline integrity, not merely information-technology housekeeping.

The audit trail is a management system

The Canadian regulator's 2018 emergency-management audit provides a different kind of evidence. It did not say that no hazard work existed. The audit reviewed procedures, training material, exercises, work orders, hazard and barrier inventories, manuals and other records. It found no issue of non-compliance in several assessed areas. But it also found that the company had not demonstrated a documented overarching process showing how hazard-identification activities and their inputs and outputs were consistently managed. It identified a separate shortfall in the contingency-planning process and required corrective action.

That nuance matters. Organisations often have many competent activities without a fully explicit system connecting them. Teams may perform exercises, update manuals, identify hazards and complete work orders, yet still struggle to show how one output changes another controlled process. The failure is not necessarily the absence of work. It is the absence of a reliable path from evidence to decision.

Enterprise automation is often purchased to solve this linkage problem. A hazard is entered once; the system routes it to an owner; related controls and plans are updated; training is assigned; exercises test the change; findings become corrective actions; dashboards show overdue work; evidence is retained for an audit. In theory, the process is clean. In practice, the hard part is preserving meaning across different professional groups. Engineers, controllers, emergency planners, field technicians, contractors, finance teams and regulators do not use the same vocabulary or require the same level of detail.

Automation can fail in two opposite directions. It can be too loose, allowing records to accumulate without enforced ownership, dates, dependencies or closure evidence. Or it can be too rigid, forcing users to select simplistic categories that do not reflect the physical situation. The first creates an archive nobody trusts. The second creates tidy reports that omit inconvenient reality. A mature system has controlled structure, but it also allows caveats, attachments, supersession, dissent and escalation.

The 2018 findings should not be used as a verdict on South Bow's current state. They predate years of corrective work and the 2024 corporate separation. Their value is analytical. They show the regulator asking the same question that should shape a technology assessment now: not merely whether records exist, but whether their inputs and outputs are explicitly connected through the management system.

The same principle applies to incident learning. A root-cause report is useful only if its findings change other parts of the system where the same threat may exist. PHMSA's 2025 order required analysis of whether lessons applied elsewhere on the network. That requires more than attaching a final report to an incident case. The operator needs to identify comparable pipe, manufacturers, weld geometry, pressure cycles, environmental conditions, inspection histories and operating limits across the system.

A lesson becomes operational when it changes a query, an inspection plan, a set-point, a work order, a training scenario or a capital decision.

Cross-border control is not the same as data residency

Keystone's control-centre geography creates an obvious locality question. Public incident records place the operational control centre in Calgary while failures and field actions occurred in South Dakota, Kansas and North Dakota. U.S. regulators sent investigators to the Calgary control room after the 2025 event. Canadian regulation applies to the Canadian system and company. U.S. pipeline, environmental and commercial rules apply south of the border. The operating record must work across jurisdictions even when the physical pipe and the people looking at it are not in the same country.

It would be tempting to call this proof that Keystone's operational data resides in Canada. The public evidence does not support that claim. A controller's location does not reveal the hosting location of SCADA servers, historians, backups, vendor platforms, maintenance systems or regulatory archives. A company can operate a control room in one country while processing, replicating or retaining different data classes elsewhere. Without architecture and contract evidence, server geography remains unknown.

Data sovereignty is still relevant, but it should be framed through authority rather than guesswork. Which legal entity controls each record? Which regulator can demand it? Which records must be retained, in what form and for how long? Can U.S. investigators obtain complete control-room evidence in Canada? Can Canadian staff access data tied to U.S. assets without losing the audit trail? Do incident holds prevent routine deletion? Can inspection data supplied by a U.S. or international vendor be exported in a form the operator can preserve? What happens to access rights when an employee, contractor or corporate owner changes?

The regulatory sources give partial answers at the level of duties. Canadian rules require records to be generated, maintained and made available to people who need them in their work. U.S. control-room rules require records demonstrating compliance. Corrective orders can demand raw inspection data, analyses, draft and final reports, pressure reviews and evidence of decisions. These obligations favour portability, traceability and controlled access. They do not prescribe one cloud, one country or one database.

The right architecture question is therefore whether the record can move lawfully and remain intelligible without losing custody. Replication may improve resilience, but only if copies have clear authority and retention rules. Centralisation may improve queryability, but only if field and jurisdictional context survives. Local storage may reduce one dependency, but only if regulators and engineers can obtain a complete record when needed. Encryption and access controls protect sensitive data, but only if emergency access and evidentiary preservation are designed as well.

Corporate separation raises the same questions. South Bow emerged from TC Energy with assets, liabilities, people, contracts and information dependencies that had to be separated or replaced. An enterprise application can be moved; an operating history has to remain continuous. The more important locality boundary may be organisational rather than geographic: what stayed in a former parent's environment, what moved to the new company, what was recreated, and which historical records remain accessible under transition agreements.

The ERP migration is relevant, but it is not SCADA evidence

South Bow's 2025 annual report offers unusually concrete evidence about enterprise-system change. In April 2025, the company implemented a new enterprise resource planning system and ancillary applications across the organisation, ending use of its former parent's ERP under a transition arrangement. Management concluded that general information-technology control deficiencies associated with the new environment contributed to a material weakness in internal control over financial reporting at year end.

The report says affected automated and manual controls depended on configuration or system-generated data, while also stating that no material misstatement had been identified in the financial statements.

This disclosure matters to an assessment of enterprise-software automation because it is direct evidence of migration complexity. A newly independent operator had to establish systems, modify business processes, redesign controls and validate data integrity. It also spent capital on information systems and leasehold improvements as part of becoming independent. These are real costs of separation that sit beside the more visible cost of physical infrastructure.

The disclosure must remain in its lane. It is not evidence that SCADA alarms, leak detection, pressure control or integrity systems were defective. Financial-reporting controls govern access, changes, reports and accounting processes in a particular control framework. Pipeline-control systems have different safety functions, operating procedures and regulatory tests. The same company can have a financial IT weakness and a functioning control centre. Conflating them would be both technically careless and unfair.

There is still a useful common lesson. Automated decisions are only as dependable as the configuration, access governance, change control and data on which they rely. South Bow's annual report notes that some manual controls relied on system-generated reports and that certain data could have been adversely affected. In pipeline operations, a different set of controls relies on system-generated values and reports. The evidence does not show the same weakness there, but it shows why independent validation matters whenever a business replaces a major system.

A rigorous migration would reconcile opening balances, master data, user roles, interfaces, reports, approvals, retention and historical access. For a pipeline company, the broader enterprise landscape may also connect finance to procurement, maintenance, contractor management, inventory, projects and regulatory cost recovery. If a work order drives a purchase, an asset record supports depreciation, an integrity program creates operating expense, or a pressure restriction affects throughput and revenue, the handoffs between operational and financial systems need stable identifiers even when the systems remain segregated for safety.

This is where software architecture becomes commercial architecture. A best-of-breed integrity tool may serve engineers well but create reconciliation labour if asset IDs do not match the maintenance or finance system. A central ERP may improve cost control but be a poor place to store raw inspection signals. A cloud repository may reduce storage friction but increase egress or migration costs for large vendor datasets. A custom integration may remove duplicate entry while becoming a fragile dependency known to only a few employees. The right design is the one that keeps evidence usable across these boundaries at an acceptable total cost.

Labour is part of the control system

The public record repeatedly returns to people. The 2025 event involved a technician at a pump station, controllers in Calgary, remotely operated equipment, field response crews, regulators at the site and control room, independent laboratories and engineering analysis. South Bow says more than 200 resources were mobilised during response. Its 2025 filing reported approximately 536 employees across the company and subsidiaries. Canadian rules explicitly require annual evaluation of whether sufficient human resources support the management system.

These facts challenge the idea that better automation simply removes labour. Some labour should disappear: duplicate entry, manual reconciliation, repeated document assembly, searches across disconnected archives and transcription between vendor formats. But the system also creates higher-value work. Someone must govern asset identity, validate inspection imports, tune and review alarms, manage configuration, investigate exceptions, challenge vendor analysis, maintain controller competence, test recovery, preserve evidence and explain decisions to regulators.

Local support matters because pipeline events are physical. A controller can isolate a segment remotely, but field personnel still have to find, confirm, contain, excavate, inspect, repair and restore. A model may identify a candidate anomaly, but engineers and technicians decide whether and how to investigate it. A work-order system can schedule a dig, but land access, equipment, weather, safety, contractors and material availability determine whether the plan is executable. The information system coordinates labour; it does not dissolve the site.

The most important support metric may therefore be time to trustworthy context, not time to close a ticket. Can a controller obtain the right procedure during an abnormal sequence? Can a field technician see the latest isolation state? Can an integrity engineer retrieve original pipe and weld records alongside every relevant inspection run? Can a regulator receive the underlying evidence without waiting for a vendor to rebuild an export? Can the next shift understand what the previous shift observed and changed? These are human questions expressed through system design.

Training is equally central. U.S. rules require controllers to practise abnormal conditions, communications and team response. Canadian management-system rules connect roles, competence and resources. A training record should show more than attendance. It should connect a person, role, qualification, scenario, result, remediation and expiry to the procedures and asset state that were current at the time. When equipment or software changes, the training impact should be visible. When an incident reveals a new failure mode, relevant scenarios should be revised.

Contractors and vendors extend the labour boundary. In-line inspection produces specialist data and interpretation. Metallurgical testing may be performed by independent laboratories. Emergency response can involve local authorities and outside equipment. Enterprise systems may be implemented by consultants. Each handoff adds a question of custody and accountability. Who verifies the deliverable? Who owns the raw data? Who can explain a proprietary field years later? Who is responsible when a vendor's identifier does not match the operator's asset record?

The answer cannot be "the platform." Platforms route accountability; they do not possess it. The named operator remains responsible for making defensible decisions. Good automation makes that responsibility visible by recording owners, approvals, deadlines, caveats and evidence. Poor automation hides it behind a status badge.

The commercial test is total record cost

The commercial case for a better operating record is visible in the consequences of weak or incomplete evidence, even though public documents do not disclose the full technology budget. South Bow reported that pressure restrictions following the 2025 incident reduced throughput and revenue. It increased in-line inspection runs and maintenance, contributing to a 94 per cent System Operating Factor for the year. Higher operational program spending affected the Keystone segment. These are not all software costs, and they should not be presented as such.

They are evidence that integrity decisions and operating limits have direct commercial effects.

The July 2026 proposed settlement over the 2022 Kansas spill makes the scale clearer. The EPA and Justice Department announced a civil penalty of more than $26.8 million, roughly $40 million of work intended to strengthen prevention and detection, and more than $3 million for Kansas restoration. The work described includes procedures, training, pipeline specifications, inspection schedules, operational limits and integrity, reliability and engineering assessments. The decree was still proposed and subject to public comment, but its structure is telling: financial consequence is tied to a program of better governed decisions.

The Canadian financial-resources table offers another measure of consequence. It lists TransCanada Keystone Pipeline GP Ltd. as an Oil Class 1 company with a C$1 billion requirement, conditionally approved in that annual report. That number is not a technology budget or an estimate of expected loss. It is regulatory evidence that the operating risk sits at a scale where the ability to respond financially matters.

Against that backdrop, storage and compute are rarely the decisive costs. Raw inspection data, historian records, engineering models, documents and backups can be large, but storage prices are legible. The less visible costs are migration, schema mapping, vendor egress, interface maintenance, identity reconciliation, access review, record classification, validation and the expert time needed to decide whether two observations refer to the same physical condition.

Lock-in has several forms. Technical lock-in occurs when raw data needs a proprietary application. Semantic lock-in occurs when only a vendor knows what fields and confidence codes mean. Contractual lock-in occurs when exports, retention or transition support are expensive. Human lock-in occurs when a few specialists understand a custom integration. Evidentiary lock-in occurs when the operator can view a result but cannot preserve enough underlying material to defend the decision independently.

The 2025 corrective action order shows a practical exit test: could the company re-evaluate ten years of vendor raw data and analysis, explain the review method, list tool runs and features, and relate similar characteristics to other locations? Any proposed system should be judged against questions like those. If the operator cannot obtain its own evidence in a documented, usable form, a low subscription price is misleading.

Data-quality labour also has to be counted honestly. A new platform may automate imports but create an exception queue when locations, units or asset IDs do not match. An artificial-intelligence layer may summarise reports but still require engineers to verify that caveats and tool limitations survived. A central catalogue may improve discovery while demanding sustained stewardship. These costs are not arguments against modernisation. They are the labour required to make modernisation real.

The counterfactual is not free. Existing systems also demand reconciliation, ageing expertise, manual searches and bespoke exports. A missing baseline can make later analysis less conclusive. Fragmented incident evidence can slow regulator response. Poor master data can send maintenance history to the wrong asset. The commercial decision is whether a change reduces total record cost and improves decision quality across a long enough horizon to justify migration risk.

For Keystone, that horizon has to be measured in decades. Pipe installed and replaced around 2010 became central to a 2022 investigation. A 2017 rupture was traced back to likely construction damage. Inspection histories are revisited years later under new questions. Corporate ownership changed in 2024, but obligations and asset history continued. A five-year software contract is short beside the life of the evidence.

What a serious diligence demonstration should show

Public evidence cannot answer whether South Bow's private systems keep data fresh, governed, queryable and recoverable under repeated use. It can, however, define a credible demonstration.

Start with one physical location and ask the operator to traverse the record. The demonstration should move from current asset identity back to manufacturer, material, weld, installation or replacement, pressure test, coating, inspection history, anomalies, engineering reviews, work orders, operating limits and incident relevance. Historical company aliases should resolve without erasing who owned or operated the asset at each date. Units, coordinates, mileposts and segment names should remain consistent or show documented mappings.

Then test freshness. Change a controlled field condition or simulated set-point through the authorised process. Show when the source changed, when dependent systems received it, who approved it and how users know they have the current version. For SCADA-related changes, show point-to-point verification and the relationship between field equipment, display, alarm description and set-point. For maintenance or integrity changes, show how a completed action changes the risk view and future plan.

Test queryability with uncomfortable questions rather than prepared dashboards. Find all inspection runs covering a specified joint. Retrieve the vendor raw data and interpretation. Explain tool capability and known blind spots. Identify forced or inhibited alarm points over the required review period. Show pressure exceedances and the decisions attached to them. Find every open corrective action derived from a particular incident lesson. A useful system should return evidence and caveats, not only a score.

Test recoverability by removing a dependency. Assume the primary application is unavailable, a vendor contract has ended or a key specialist is absent. Can authorised staff restore the record, interpret the export and continue safe decision-making? Can the organisation recover the latest approved procedure and the history it superseded? Can it demonstrate custody and integrity of evidence supplied to a regulator? Backups that restore bits but not meaning are limited public evidence.

Test cross-border access explicitly. Show which records are controlled by which legal entity, where authoritative copies are retained, which roles in Canada and the United States can access them, and how regulator requests are fulfilled. Document replication, deletion, legal hold and incident-preservation rules. Do not accept a control-room address as an answer to data locality.

Test the human system. Observe a shift handover, an alarm review, an inspection-data challenge, a field-to-control-room communication and a contractor deliverable review. Measure duplicate entry and exception handling. Ask users which spreadsheets or side channels they maintain because official systems do not fit the work. Those unofficial records are often where stale state and hidden labour live.

Finally, test economics with a complete model. Include licences, storage, compute, network, migration, integration, validation, vendor support, training, cyber controls, disaster recovery, retention, regulator exports and data stewardship. Add the cost of operating in parallel during transition. Compare that with avoided reconciliation, faster evidence retrieval, reduced dependence on proprietary formats, better maintenance planning and fewer preventable operating surprises. Do not claim avoided spill costs unless the causal case is genuinely supportable.

The evidence should be sampled across repeated use, not demonstrated once on a clean example. Month-end reporting, annual alarm reviews, periodic inspections, staff turnover, vendor changes and abnormal events stress different parts of the record. A system that works in a prepared workshop can still fail when the same asset has accumulated another decade of evidence.

A measured verdict

The public record supports a strong conclusion about the nature of the problem and a restrained conclusion about the quality of the solution.

The strong conclusion is that Keystone is governed through information as well as steel. Controllers depend on sensor and alarm state. Engineers depend on inspection capability and historical baselines. Field teams depend on current isolation, procedures and asset location. Regulators depend on retained evidence and traceable decisions. Finance depends on accurate operating costs, toll treatment and enterprise reports. Corporate separation depends on continuity across names, systems and access rights. Local response depends on people receiving the right context in time.

The restrained conclusion is that public documents do not expose enough of South Bow's present architecture or operating data to say that this chain is consistently fresh, governed, queryable and recoverable. Incident reports reveal effective detection and shutdown actions in important moments. They also reveal historical conditions that inspection and records did not fully expose before failure. The 2018 audit documents past process-linkage shortcomings, but not the post-correction or post-spin-off state. The 2025 ERP disclosure is meaningful evidence of enterprise migration risk, but not evidence about pipeline-control performance.

That balance is more useful than a generic technology score. It identifies where evidence is strong, where it is bounded and where a buyer, board or regulator should ask for a demonstration. It also avoids the false promise that one platform can solve construction quality, metallurgy, controller judgement, field response and corporate governance by itself.

The deepest lesson in the Keystone record is that detection and memory are different capabilities. An alarm can tell a controller that the system has changed now. Only a governed history can help an engineer understand how the system arrived there. That history has to survive tool limits, vendor changes, missing measurements, staff turnover, new questions, cross-border oversight and corporate separation.

TransCanada Keystone Pipeline GP matters today as part of that history. Its name connects older audits, permits, decisions and incidents to the present South Bow operating boundary. The technology challenge is to preserve that continuity without confusing past and present, to automate evidence movement without erasing caveats, and to give people enough trustworthy context to act before a weak signal becomes a large consequence.

That is the real control surface behind pipeline operations. It is not a single dashboard and it is not a claim of perfect visibility. It is the disciplined connection of physical assets, measurements, inspections, decisions, people and obligations over time. Public evidence shows why the connection matters. Proving how well it works requires the private operating record itself.