Monitoring Data as Evidence in a Dispute: How to Collect and Store It

In brief

• The dispute is not about whether you have a chart, but about where the chart came from and whether it can be trusted.
• A reliable record has eight traits: baseline condition, sensor identification and calibration, consistent time, raw data alongside converted data, a change trail, a communication log, a human decision trail, and export plus retention.
• A communication log with raw frames answers the question “what arrived, when, and from which device” - a spreadsheet cannot do that. In many platforms, however, raw frames live for a shorter time than measurements; if they are to serve as evidence, define their retention period in the contract.
• Alarm acknowledgement (who, when) and timed silencing capture what people did with the information, not only what the sensors showed.
• Retention, export and party access are defined in the contract before installation, not after the first letter from counsel. Three things cannot be done retroactively: the zero reading, the log, and the decision trail.

The dispute starts with the question, “How do you know that?”

If you have ever been in court or at a meeting with the other side’s expert, you know the drill. You present a chart of the adjacent masonry wall tilting next to an excavation. The line is flat. Then come the questions: how do you know that sensor was working at all, when was it calibrated, and why is there a gap in the table between Tuesday and Thursday? At that point, the chart stops being evidence and becomes a claim.

That is probably what worries you: after a letter from the neighbour’s counsel, you could be left with a chart nobody will accept and a table you cannot defend. That concern is healthy, because it can be turned into a checklist. Evidence is what you can show behind the chart, and that can be prepared in advance.

Monitoring data as evidence is a measurement record together with the information that allows a third party to reconstruct how the record was created and assess whether it can be trusted. The chain of custody for measurement data is the documented path of each number from the sensor, through transmission and processing, to the archive from which someone reads it years later. The basics of SHM are covered in the complete guide to structural monitoring.

Liability for damage caused to a neighbouring property is most often based on the provisions of the Civil Code on torts: Article 415 (fault principle) and Article 435 § 1 (risk principle for an enterprise driven by natural forces). Courts classify construction companies, including general contractors, as such enterprises - this was confirmed by the Supreme Court in its judgment of 17.03.2022 (II CSKP 482/22) in a case concerning damage to a neighbouring building caused by works on an adjacent plot. Article 147 of the Civil Code, in turn, prohibits an owner from carrying out earthworks in a manner that threatens neighbouring properties with loss of support, and the duties of the site manager (Article 22 of the Construction Law) include, among others, keeping construction records and stopping the works if a danger may arise.

The burden of proving a fact lies with the party that derives legal effects from it (Article 6 of the Civil Code), but under the risk principle, only force majeure or the sole fault of the injured party or a third party can relieve liability - in practice, the contractor will want to show that the damage is not connected with its works. Without data, there is nothing to show. We discuss this in more detail in the post on monitoring neighbouring buildings during construction. The same applies to a hall owner who, after an incident, must show that between periodic inspections under Article 62 of the Construction Law, they reacted to signals.

How an expert reads this data

An expert appointed by the court in a case requiring special knowledge (Article 278 of the Code of Civil Procedure) or an expert for one of the parties does not begin with the chart. They begin with questions about the method. First: the baseline-condition documentation and the sensor layout plan. Second: calibration certificates and the method used to convert the raw signal into physical units. Third: the continuity of the record and an explanation for every gap. Only fourth: the values themselves.

If, for any of the first three questions, the answer is “I do not know, the subcontractor handled that,” the evidential value of the rest drops, even if the numbers are favourable. The expert will also ask whether the thresholds on the day of the incident were the same as today and whether the system time matched the site log. What does this mean for you? Prepare answers to those four questions before anyone asks them. The rest of this text explains how.

8 traits of a reliable measurement record

The table below is a checklist developed from disputes, not taken from a standard. The third column is the most important: these are the questions to ask the monitoring provider before signing the contract, not after.

If the provider answers immediately and shows it on the screen, you are in a good place. If the answer is “we can add that later,” write it into the contract as an obligation with a deadline. If the answer is “we do not have that, we do it differently,” that is also a good answer, because you know what you need to add yourself, for example by periodic export to your own archive. A broader set of questions - on ingest, alarms, roles, hosting and total cost - is in the post how to choose a structural monitoring platform: a 30-question checklist.

Raw frames and the communication log - why an Excel chart is not enough

A spreadsheet is not bad. The problem is what a spreadsheet does not carry: the context in which the number was created.

Raw frame, converted value, calibration

A raw frame is the exact content of the message sent by the measuring device (logger, hub, or sensor with its own transmission) to the platform, including the device ID, time and values in the form they came out of the transducer. The converted value is the same information after the calibration formula and corrections (temperature, zero reading) have been applied. Between the two is mathematics, which can be correct or not - and that is often the subject of expert dispute.

Illustrative example: a vibrating wire sensor returns the wire vibration frequency; strain is calculated from the difference between the squares of the current and zero frequencies multiplied by the sensor constant from the manufacturer’s data sheet, and then corrected for temperature. If you only have a column “strain [µε]” and the expert asks about the constant and whether temperature compensation was active from the beginning, you can answer only if the platform stores frequency and temperature next to the result. Hence requirement no. 4 in the table: a calibration correction made a year later should not overwrite history, but should leave the source and a trace of who introduced it and when.

Communication log: what arrived, when, and from which device

A communication log is a chronological record of transmissions between field devices and the platform: reception time, device ID, frame content, acceptance result. It serves three evidential functions.

First, it confirms origin. The value in a table could have been entered manually; the frame in the log came from a specific device at a specific time, in a form that nobody formatted.

Second, it separates measurement time from reception time. Devices buffer data when there is no signal and send it later. Without two timestamps, you cannot distinguish “the sensor measured this at 14:15” from “the data arrived at 14:15,” and in a dispute about whether you stopped the works in time, that matters. A good platform also keeps the device clock aligned with its own and does not accept frames with a drifting time - so “14:15” means the same thing on every sensor.

Third, it documents absence. A gap in the data will always be used by the other side (“there were no measurements exactly then”). The log shows whether the device was silent (no frames), whether it sent data that the platform rejected (rejected frames - and why), or whether it arrived later from the buffer. These are three different stories. The NO_DATA state, meaning the platform signals that no reading is available from a channel in the expected time window, is information, not simply the absence of information: if it was flagged, notified and acknowledged, you have a record that you knew about the gap and reacted.

One thing providers rarely like to talk about: raw frames take up a lot of space, so platforms usually keep them for a shorter time than measurements - days or weeks, not years. Converted measurements remain, the log disappears. If the log is to serve as evidence, you have two options: agree a longer retention period for the specific project in the contract, or periodically download the log to your own archive. What does this mean for you? Before signing the contract, view the log on screen and ask how many days it lives.

Alarm, acknowledgement, silencing: the human decision trail

Sensors do not make decisions. People do, and the dispute almost always concerns decisions: whether you knew, when you knew, and what you did. That is why alarm history is just as important as measurement history. The decision trail consists of three elements.

Alarm acknowledgement is the action recorded in the platform when a specific person accepts the alert and takes responsibility for it. A record saying “WARNING alarm on channel X was created at 06:42, SMS sent to authorised persons, taken over by the site manager at 06:51” says more than an entire table of values. The absence of acknowledgement for many hours is also a record - uncomfortable, but honest.

Timed silencing is the deliberate decision that the alarm will not repeat notifications for a specified period, with a date when it resumes and a reason recorded in the platform or in the site log (for example, “planned work near the sensor”). Silencing without a deadline and without a reason is the worst possible entry in a dispute: it looks like turning off the bell because it was annoying.

Escalation is a predefined path: who receives the information if the first person does not acknowledge within the set time, and who decides to stop the works. Not every platform handles this automatically. If yours does not, the path is written into the procedure (a second number in the notification group, a call from the duty officer), and the evidence remains the same: the time the alarm was created, the time it was acknowledged, and the record of what happened next.

Illustrative example - one alarm, three versions of the documentation:

• Version A: “On 12 March, the warning threshold was exceeded. The site manager was informed by phone.” A log entry, from memory, without a time.
• Version B: a printout from a spreadsheet in which the row for 12 March is highlighted in yellow.
• Version C: the alarm history in the platform: creation time, thresholds valid on that day, time and user account of the person who acknowledged it, silencing until a specific hour, return to OK state - plus a construction log entry with the time: “excavation in section 3 stopped, geotechnical engineer called.”

Version C does not guarantee victory. It does show that the organisation had a procedure and followed it, and that is what matters most in disputes about due diligence. We describe how to build thresholds and a procedure that leave such a trail in the post on warning and alarm thresholds.

Retention and export - what to put in the contract

The most common mistake is not technical. The question “where will this data be in three years?” is asked for the first time when a claim arrives. Yet claims for damages from a tort generally expire after 3 years from the date on which the injured party learned of the damage and the person responsible, and no later than 10 years from the event, or 20 years in the case of damage resulting from a felony or misdemeanour (Article 442¹ of the Civil Code). The construction ends after months. The data must outlive the contract.

Below are clauses to consider in the contract with the monitoring contractor or platform provider - a list from an engineer for discussion with the lawyer who will give it legal form.

• Retention period counted from the end of monitoring, separately for: raw and converted measurements, raw frame logs (usually the shortest - enter a number of months or an obligation for periodic export), alarm history and dynamic events (vibrations), which take up the most space.
• Export scope: raw and converted measurements, calibration coefficients and conversion equations, threshold configuration with change history, alarm history with user actions, communication log - in an open format readable without the provider’s software; delivery time on request and any cost.
• Party access: who has an account and with what permissions (investor, contractor, supervising inspector, and possibly the owner of the neighbouring property in read-only mode), and whether the platform allows such access to be limited to one project.
• Fate of the data after the contract expires: transfer of the complete archive, deadline, confirmation of receipt, the point at which the provider may delete the data; who owns the data (usually the client).
• Baseline-condition documentation as an annex: zero-reading report, sensor layout plan, calibration certificates, photos; obligation to preserve the trail of every later change to thresholds and coefficients.
• Response procedure as an annex: thresholds, notification list, acknowledgement times, escalation path (in the platform or outside it), permissions to silence alarms, responsibility for responding to NO_DATA.
• Personal data: if the platform contains the phone numbers and email addresses of alarm recipients, the hosting provider acts as a processor and a data processing agreement under Article 28 of the GDPR is required.

Not every clause is needed every time. Next to a historic masonry building, all of them will help. For monitoring the girders of your own hall, at least retention, export and the decision trail are needed; what to keep in case of inspection or an incident is covered in the post on periodic inspections under Article 62 and continuous monitoring of halls. What does this mean for you? Print this list and take it to the meeting with the provider - half an hour of discussion now can save weeks in a dispute.

Three things you cannot do retroactively

The cost of inaction here is not that you will pay more. It is that some things simply will not be possible when they are already needed.

First: the zero reading. The pre-work condition of the structure exists only before the works. Cracks inventoried after the neighbour’s first letter are already “yours,” because you cannot prove they were there before.

Second: the raw frame log. If the platform keeps it by default for a few days, then on the day the dispute begins, the log from the day of the incident is usually already gone. A longer retention period or periodic export is agreed before installation, not after.

Third: the decision trail. Alarm acknowledgements cannot be added after the fact, and a construction log “from memory, without a time” is weak protection. The procedure - who acknowledges, within what time, who calls next - must exist on the day the alarm occurs.

That is why there is only one moment for this conversation: before signing the monitoring contract, and at the latest before the first excavation. Everything agreed later will only reduce losses.

Hypothetical scenario: a neighbour’s claim and the monitoring log

The scenario is hypothetical: it does not describe any real structure, implementation or dispute, and the values and dates are illustrative.

Imagine an excavation for two underground storeys, a few metres from a pre-war masonry building. Before the works, a baseline inventory was prepared: description and photos of existing cracks, zero-reading report for tilt sensors on the building’s gable wall and the excavation support, crack gauges on three cracks, and a vibration sensor in the basement. Readings every 15 minutes by default, or more often, thresholds set by the excavation support designer. Four months later, the owner of the masonry building reports a new crack in the stairwell and demands compensation, pointing to the earthworks as the cause.

What the monitoring log shows in this scenario:

• Baseline-condition documentation dated before the excavation, in which the crack in the stairwell does not appear (or does appear - then the dispute looks different, but you know that first).
• Continuity of wall tilt measurements: changes in a daily pattern correlated with temperature (multiaxis chart), with no permanent trend; one transmission break marked as NO_DATA, acknowledged by the site manager within an hour, with a note about power supply replacement; buffered data resent after connectivity was restored with the original timestamps - and communication log frames, because the contract provided for retention for the duration of the works.
• One warning alarm on the crack gauge during the week when excavation reached the level of the second underground storey: time of creation, acknowledgement, silencing for 48 hours, construction log entry about stopping work in the section and calling the designer, return to OK state after two days.
• Vibration events on the days when the roller was operating: recorded waveforms, peak values below the limits adopted on the basis of PN-B-02170 for this building class (more in the post on vibration monitoring of buildings during construction) - available for the expert’s review.

What the monitoring log does not show, and what should not be inferred from it:

• It does not prove that the crack did not appear. It proves that at the measurement points, within the measured quantities, no changes exceeding the thresholds were recorded. If the crack is far from the sensors, the expert will rightly ask why it was not measured there - and this brings us back to the importance of the sensor layout design.
• It does not replace the causation assessment by a construction expert. Monitoring provides facts about the structure’s behaviour over time; interpretation of causes (building age, installations, alterations, ground conditions) belongs to the expert.
• It does not speak for periods it does not cover. If monitoring started two weeks after the works began, those two weeks have no record, and that must be stated honestly.

The log does not “win the case.” It moves the discussion from “you say, I say” to “here is the record, please challenge it.” That is a major difference in cost, time and stress, even in a settlement.

What this looks like in Inclify

The Inclify platform stores request/response raw frames from devices together with metadata: what arrived, when and from which device; the administrator can view and download the exact frame content in the panel. This applies both to sensors installed by the Inclify team and to the client’s loggers connected via HTTP/JSON. To be clear: the raw frame log is retained by default for 7 days, the period is configurable - if the frames are to have evidential value in your project, longer retention or periodic downloads must be written into the contract. Measurements - raw values from the logger and values converted by the project equations - are stored in a time-series database in UTC without automatic deletion (older data is compressed, not deleted).

The measurement timestamp is assigned by the device in UTC; the platform does not accept frames whose clock differs from the server by more than 30 s, and it sends the correct time back to the device, while buffered backlog is resent with the original timestamps. Measurements enter only through the device channel - there is no manual entry form and no file import. Configuration changes (equations containing calibration and compensation coefficients, thresholds, devices, users) are written to the audit log with before and after values; the platform does not have a function for restoring the state before a change.

Each channel has the states OK / WARNING / ALARM / NO_DATA. Alarm acknowledgement records who performed it and when, silencing always has a deadline (from one minute to one year), and transitions between states are written into the alarm history. SMS and email notifications go to users according to their preferences; there is no automatic escalation to additional people - the path is written into the procedure. Permissions have three levels (superadministrator, client administrator, read-only user), and each client’s data is isolated; there are no project-based roles, so access for someone outside your team is discussed individually.

You can export table data to CSV, save charts as images, export dynamic signals to XLSX (PDF is not available), and the data SLA report shows completeness, gaps and record freshness. More on the monitoring platform. The export scope and retention period are written into the contract - ask about them directly, as you would any provider according to the table above.

Sources and further reading

• Act of 23 April 1964 - Civil Code (Articles 6, 147, 415, 435, 442¹) - isap.sejm.gov.pl
• Act of 17 November 1964 - Code of Civil Procedure (Articles 278, 308, 309) - isap.sejm.gov.pl
• Act of 7 July 1994 - Construction Law (Articles 22, 61, 62) - isap.sejm.gov.pl
• Judgment of the Supreme Court of 17 March 2022, II CSKP 482/22 (construction enterprise as driven by natural forces; damage to a neighbouring building) - sn.pl
• Regulation (EU) 2016/679 (GDPR), Article 28 - eur-lex.europa.eu
• PN-B-02170:2016-12 Assessment of the harmfulness of vibrations transmitted through the ground to buildings - sklep.pkn.pl
• Technical documentation of vibrating wire sensor manufacturers (conversion formulas) - geokon.com

What next

If you are facing an excavation next to someone else’s building or signing a monitoring contract, review the eight-trait table with the provider now - before the first scoop of the excavator, because you cannot do the zero reading and the log retroactively. If you want to see a communication log with raw frames, the audit trail, alarm history with acknowledgements and export on a project similar to yours - book a conversation. We reply within 24 hours, and if you already have sensors and loggers, connection to the platform on one pilot building takes a few days.