Data platform lock-in, closed APIs, and contracts lacking exit clauses—these three issues rarely surface during the technical phase; instead, they erupt only during the final acceptance phase. This article provides actionable criteria for identifying and mitigating delivery risks.

For EPC contractors, the primary risk in smart streetlight projects lies not in the construction phase, but in the final acceptance phase.

It is only after the hardware installation is complete, the system has gone live, and the client has formally signed off on the project—that the real problems begin to emerge.

Data cannot be exported.

Platforms cannot be switched.

Historical records cannot be migrated.

At this juncture, the party held accountable is the EPC contractor—not the equipment supplier.

The reason is simple: the contract was signed as an EPC (Engineering, Procurement, and Construction) general contract; therefore, you—the general contractor—are the ultimate party responsible.

I. What Constitutes the Actual Deliverable in a Smart Streetlight Project?

Many EPC teams, when evaluating smart streetlight projects, define the deliverables merely as: light fixtures + controllers + management platform + construction and installation services.

This definition is incomplete.

What the client is truly accepting is a sustainable, operational data system.

A standard smart streetlight network continuously generates five categories of data on a daily basis:

• Traffic flow and transit patterns

• Pedestrian trajectories and behavioral records

• Environmental monitoring parameters

• Equipment energy consumption and status data

• Video analytics results

When aggregated over time, this data evolves into one of the client's core assets for urban management.

If this data cannot be fully delivered to the client following final acceptance, the project cannot be considered truly complete.

II. Where Does the "Lock-in" Problem Originate?

The prevailing architectural model in the industry is as follows:

• Edge devices perform local caching

• Data is uploaded to the supplier's cloud platform

• The client accesses the data by logging into an account

This architecture offers rapid deployment and low upfront costs, making it the default solution for the majority of suppliers.

However, it suffers from a fundamental structural flaw: the actual control over the data remains in the hands of the supplier.

Here are the three most common scenarios encountered after final acceptance:

Scenario 1: The Client Requests Data Migration

The raw data format is proprietary; the necessary export tools are provided solely by the supplier; exporting the data incurs additional fees; or, in some cases, there is simply no available pathway to export the data at all.

Scenario 2: The Client Decides to Switch Platform Suppliers

The new platform is unable to read the historical data from the previous system, necessitating a complete system redeployment. Who bears the cost? If the contract fails to specify this, the financial liability reverts back to the EPC general contractor.

Scenario 3: The Client Requests a Data Audit

The supplier provides only aggregated summary reports, while the raw data remains inaccessible to external parties. Consequently, the client is unable to independently verify the data, leading to a crisis of trust that casts doubt upon the quality of the EPC contractor's delivery. None of these three scenarios represent technical issues; rather, they are all issues regarding contractual structure.

III. Private Clouds Cannot Resolve the Vendor Lock-in Problem

A common strategy adopted by EPC teams is to request that vendors provide a private cloud deployment. While this approach is not inherently wrong, it is insufficient.

A private cloud deployment remains a form of vendor lock-in if any of the following conditions apply:

• The database schema is defined using proprietary vendor specifications.

• API interfaces are incomplete or not open.

• The permission management system cannot be independently configured by the Client.

• Data export relies on proprietary vendor tools.

A private cloud merely alters the physical location where data is stored; it does not alter the ownership or control over that data.

IV. Four Rights That Must Be Explicitly Defined in the Contract

For most smart street lighting projects, contractual issues rarely stem from a lack of detail in technical specifications; instead, they almost invariably arise from the complete absence of exit clauses. While functional descriptions may span ten pages, data migration—a critical aspect—is often not mentioned even once.

The following four rights must be explicitly defined within the contract:

• Data Ownership: All data generated by the project—including raw data, metadata, and analytical results—shall be owned by the Client; the Vendor shall hold only limited usage rights for the duration of the contract term.

• Data Access Rights: The Client shall have the right to access all raw data with full permissions at any time, without being restricted by account hierarchy levels or data export quotas.

• Data Export Rights: The Client shall have the right to export all data in an open, standardized, and machine-readable format, without reliance on proprietary vendor tools and without incurring additional fees.

• Data Migration Rights: Upon termination of the contract, the Vendor must deliver all data and interface documentation in their entirety within a specified timeframe, and must unconditionally cooperate with the system migration process without imposing any technical or commercial barriers.

The absence of any one of these four rights will inevitably lead to additional costs or disputes during the later stages of the project—costs and disputes that will ultimately have to be borne by the General Contractor.

V. Open APIs: The Prerequisite for a Controllable System

Whether or not a vendor provides a complete set of open APIs serves as the most direct criterion for determining whether a system is truly controllable.

The provision of open APIs implies the following capabilities:

• The Client can integrate the project data into their own city management platform.

• The Client can independently replace the vendor without suffering any loss of data.

• The Client can independently conduct data analysis and generate reports.

A system lacking open APIs is, in essence, a "black box." The Client sees only the interfaces and reports provided by the vendor and is unable to independently verify the integrity and accuracy of the underlying data.

VI. Regulatory Compliance: Evolving into a Prerequisite for Project Delivery

In markets such as South America and the Middle East, smart street lighting projects involving video capture and behavioral data collection are facing increasingly stringent data compliance requirements. Core constraints include:

• Data must be stored within the national borders.

• Cross-border data transfer requires explicit authorization.

• The retention period for video data is subject to regulatory restrictions.

• Data access must be fully logged.

These requirements have already begun to appear in tender documents. If the system architecture fails to meet compliance criteria during the design phase—and subsequently fails to pass the final acceptance phase—the cost of remediation shall be borne by the General Contractor.

Compliance is not an optional add-on; it is a fundamental prerequisite for the system architecture.

VII. 5 Questions to Confirm Before Delivery

Before signing a supply contract for a smart street lighting project, the General Contractor team should verify the following points item by item:

1. Is the data stored in an environment that the Client (Party A) can independently control?

2. Can the Client access the complete raw data at any time?

3. Upon termination of the contract, can all data be exported in its entirety and without any conditions?

4. Does the vendor provide a complete set of open APIs and corresponding interface documentation?

5. Does the system architecture satisfy the data compliance requirements of the country where the project is located?

Until clear answers to these five questions are obtained, any technical evaluation is essentially meaningless.

Conclusion

The primary delivery risk in smart street lighting projects centers on a single critical point: whether true control over the data has been effectively transferred to the Client.

The correct sequence for evaluation is as follows:

First, verify the data sovereignty clauses → Next, evaluate the system architecture → Finally, compare the products and pricing.

For projects where this sequence is reversed, the General Contractor assumes full responsibility for any risks arising during the final acceptance phase.