Data Integrity – Data Patching

Data Integrity – Data Patching

Objective

This document describes the operation of the KSI VISION Data Patching system, designed to ensure the continuity and consistency of indicators in the event of exceptional situations involving partial or total data loss.

The main objective of data patching is to reconstruct missing or invalid data (at an hourly level) when there is no way to recover the original data, ensuring that macro analyses and historical trends are not affected.

Context and General Principles

KSI VISION implements multiple preventive and automatic recovery mechanisms to minimize data loss.

Prevention and Automatic Recovery

• In the event of Internet connectivity issues, the local server stores up to 16 hours of data by default, which is automatically synchronized once the connection is restored.
• The integrity of the entire system (cameras, servers, and connectivity) is continuously monitored by the KSI VISION monitoring team, which takes proactive corrective actions when incidents are detected.
• Many incidents are resolved without customer intervention or impact on final data.

When Data Patching Is Required

Data patching is used only when it is not possible to recover the original data, for example:

• Persistent configuration errors
• Prolonged power outages affecting servers or cameras
• Critical failures in camera–server communication
• Irreversible loss of historical data (partial or total)

Data Patching Characteristics at KSI VISION

Characteristic	Description
Manual application	Patching operations are executed only upon explicit request and approval by the client or an authorized user.
Not automatic	By default, no patching is applied in the platform.
Full traceability	All patched data is clearly identified and marked as such.
Reversibility	Patched data can be differentiated, audited, and removed at any time.
Controlled scope	Patching is applied per store, node, and specific time range.

Data Patching Methodology

Statistical Principle

The KSI VISION data patching system uses a statistical method based on historical hourly averages, allowing missing values to be reconstructed without altering macro trends.

The user can configure:

• Number of historical weeks to average
• Backward time offset from which historical data will be taken

This allows consideration of both recent patterns and historical seasonality (for example, the same period in the previous year).

Missing Hourly Data

Data is considered missing when one or more hours within a selected time range do not contain valid information.

Procedure

1. Missing hours within the selected range are identified.
2. For each missing hour, historical data from the same hour and same day of the week is selected.
3. Data corresponding to the configured number of weeks is collected.
4. The hourly average is calculated.
5. The average value is assigned as the patched data for that hour.
6. The hourly behavior is replicated while preserving the original temporal shape.

Example

If data is missing between 14:00 and 17:00 on Wednesday, July 19, and the configuration specifies 3 weeks, the system:

• Takes data from 14:00–17:00 from the last 3 available Wednesdays
• Calculates the average for each hour
• Applies those values as patched hourly data

If only 2 valid weeks are available, the average is calculated using those 2 weeks.

Visual Example of Statistical Patching

Data Patching Configuration

Patching Execution List

The platform displays a complete history of patching executions, including:

• Execution date
• Patched date and hour range
• Patching type
• Affected stores or nodes
• Execution status

This enables full auditability, control, and traceability of the process.

Creating a Data Patching Execution

When creating a new execution, the user must define:

Field	Description
Fill with data	Activates the patching process for the selected range
Start date	Beginning of the period to be patched
End date	End of the period to be patched
Patching type	Statistical method to be used
Number of weeks	Number of historical weeks used for averaging
First week backward	Time offset used to consider older historical data

Important Considerations

Note

• Data patching applies to both partial and total data loss.
• At least one comparable valid historical period must exist to perform averaging.
• Patched data should preferably be used for aggregated and trend-level analysis.

Best Practices

• Use data patching as sparingly as possible.
• Prioritize recent weeks unless seasonality is required.
• Validate results before using them in executive reporting.

Support and Approvals

Every data patching execution must include:

• Explicit request from the client or an authorized user
• Internal validation by the KSI VISION team
• Prior approval before application

For questions or support:

📧 ksi.support@ksivision.com