A construction monitoring report for management is one page that answers four questions: what condition the assets are in, what happened and how it was handled, which trends require a decision, and what you expect from management. Behind that page sits a second document, the engineering report, with calibration debt, temperature compensation, threshold tuning and data quality. Without that backing, the first page is an opinion, not a report. Below you will find the structure of both documents, a fill-in template for the page, and the rules that help management read the report even in a month when everything is green.
In brief
- Write two reports: a one-page management report for decisions and a longer engineering report for evidence. Mixing both in one document weakens both.
- The management report has a fixed structure: asset status in three colors, events and their handling, trends that need decisions, data quality, 7- and 30-day risk, and recommendations with cost as a category.
- A green month is still a result: show how many readings arrived, what the alarms caught, and what decisions the monitoring enabled. Otherwise management will think it is paying for silence.
- Do not paste raw charts, do not leave jargon unexplained, and do not end a paragraph without saying what it means.
- The engineering report answers the question, "Can this page be trusted?" Calibration debt, temperature compensation, threshold tuning, data completeness.
- Set the frequency to the audience: operator daily, engineer weekly, management monthly or quarterly, plus a report after an event.
Two reports, not one
The most common mistake in monitoring reporting is trying to make one document serve everyone. The engineer gets too little detail to verify anything, and the director gets too much to understand anything. The result: the engineer still logs into the platform, and the director reads the first sentence and the last one.
The management report is a decision document: short, fixed in structure, ending with a recommendation and an assignment of responsibility. The engineering report is an evidence document: it describes the condition of the measurement system, data quality, and justifies every assessment on the management page. The first answers, "What do we do?" The second answers, "How do we know?"
Picture a maintenance director with a dozen assets who receives a monitoring document once a month. If they have to read twenty pages just to learn that everything is fine, they will not read any pages next time. A single page with three colors, two events and one recommendation can be read in an elevator. The scenario is hypothetical, the conclusion is not.
| Criterion | Management report | Engineering report |
|---|---|---|
| Purpose | Decision: do / do not do / observe | Evidence: how we know what we wrote |
| Audience | Management, owner, contract director, finance director | Monitoring engineer, designer, supervision, auditor |
| Length | One page, fixed structure | As needed; usually several to a dozen pages |
| Language | Status, risk, cost as a category, deadline | Units, thresholds, channels, corrections, statistics |
| Charts | None or one, interpreted in a sentence | Multi-axis charts, trends, profiles, spectra |
| Reading time | Five minutes | As long as needed for verification |
| Contents | Status in three colors, events, trends for decisions, data quality, 7/30-day risk, recommendations | Calibration debt, temperature compensation, threshold tuning, data SLA, 7/30-day risk assessment with justification |
| Question it answers | "What do I need to do and by when?" | "Can this management page be trusted?" |
| Signatory | Engineer responsible for monitoring | Engineer responsible for monitoring |
The same person signs it, but writes it differently. If you are still setting up monitoring, start with the complete SHM guide - here I assume the data are already flowing and you are asking how to explain them.
A green month is still a result
You know the fear: the third report in a row is green and someone at the meeting asks why you are paying for monitoring if "nothing is happening". The worst answer is a page that says only "no remarks". It confirms that monitoring is a cost of silence. A good answer shows that silence was measured.
Four things worth including even in a green month. How many readings arrived and with what completeness - as an illustration, a logger with a reading at the default 15-minute interval, delivers 96 readings per day per channel, or 2 880 in a 30-day month, where periodic measurement would give one or none. What the alarms caught and rejected: warnings after heat that, once temperature was taken into account, turned out to be the structure "breathing" over the day are work done by the alarms, not their failure. What decisions the monitoring enabled: moving to the next excavation phase without stopping the works, cancelling an ad hoc inspection after strong winds, confirming that the proof load test did not leave a permanent deformation. And what changed in seasonal trends compared with the previous year, if you already have a comparison.
One mechanism it is worth explaining to management once: between two periodic measurements the structure is invisible, and risk does not wait for the measurement date. Continuous monitoring does not make the asset safer by itself. It means you learn about a change while there is still a cheap way to act. A green page proves that this mechanism worked throughout the month, not only on the day of measurement.
What this means for you: if every month you show data completeness, rejected false warnings, and decisions made on the basis of trends, then in the month when the page turns yellow, management will not ask whether it works. It will ask what to do. We cover how to talk to management about the monitoring launch itself separately in the post on justifying monitoring to management.
What the management report must contain
Set the structure once and keep it in every issue. Management learns it after two or three reports and then reads the page like a dashboard. Changing the structure between issues is a loss of trust, not a refresh.
Asset status in three colors
The first section is a list of assets or zones with one color next to each: green (channels within limits, data complete), yellow (warning threshold exceeded, trend to observe, or a data gap on an important channel), and red (alarm threshold exceeded or an event requiring action). The color must follow directly from the channel states OK / WARNING / ALARM / NO_DATA, not from the author's impression. If an asset is yellow because of missing data, say so. Missing data is a different risk than a threshold exceedance and requires a different decision.
At the end of the section, add one sentence on what changed since the previous report. It says more than three charts.
Events and how they were handled
For every threshold exceedance in the period: what, when, who took ownership of the notification, what was established, when it was closed. Five columns, one line per event. Management does not need to know the value in mrad. It needs to know that someone responded within a defined time and that the matter has an owner. If an alarm turned out to be false for measurement reasons, write that too, together with what was done to prevent a repeat. The event handling history is also material in case of a dispute. We cover that in the post on monitoring data as evidence in a dispute.
Trends that require a decision
Not every trend. Only those for which you expect that, within a defined horizon, something will need to be done: increase the reading frequency, order an inspection, change the work schedule, ask the designer for an opinion. Each one should be described in a single sentence in consequence language: "if the current pace continues, the warning threshold will be reached within a few weeks." Leave the slope in mm per day out of this page. That belongs in the engineering report. If you have more than three such trends, choose three and leave the rest to the engineers. Management will make at most three decisions at a meeting anyway.
Data quality, risk and recommendations
The last three sections of the page are shorter, but they are what separate a report from a bulletin. Without them, management gets a description, not a basis for a decision.
Data quality and SLA
One line per asset: data completeness for the period, channels in NO_DATA for longer than the agreed time, channels with a deviation from the reference reading that need checking. Management does not ask about data quality until it turns out that there was no data on the day of the event. It is better for them to see this line every month and get used to the fact that a green asset also means a green measurement system.
7- and 30-day risk
A short assessment: what may happen within a week and within a month if the trends continue, and what planned actions are coming up (next excavation phase, proof load, forecast frost, thaw). Two horizons, because they support two different decisions: seven days is for operational decisions (standby, increased reading frequency), thirty days is for budget and schedule decisions. The engineer formulates the assessment. The statistics in the engineering report tell them which channels are moving away from their baseline, but they know what will happen on site next month.
Recommendations with cost as a category
Each recommendation is a verb, an owner, a deadline and a cost category. A category, not an amount. In a monitoring report you do not price the work. You indicate the weight of the decision: "within the current contract", "requires a separate order", "requires an investment decision". Prices will come later, from offers. A report without recommendations shifts responsibility to the reader and ends up as information, not a decision. If there is nothing to recommend in a given month, say so clearly: "no recommendations; next assessment after phase ...". That is a decision too.
One-page template
Below is an A4 page skeleton to copy. The ellipses are places to fill in; keep the section headings unchanged in every issue.
Monitoring report - period: ... - ..., issue no. ... Assets: ... · Author: ... · Date: ...
1. Asset status. Asset A - green · Asset B - yellow (reason: ...) · Asset C - green. Since the previous report, the following changed: ...
2. Events and handling. What ... · when ... · who took ownership ... · findings ... · status (closed / open until ...).
3. Trends for decision (max. three). If the current pace continues ... within ...; proposed action: ...
4. Data quality. Asset A - completeness ..., NO_DATA ..., channels to check ... (one line per asset).
5. Risk. 7 days: ... 30 days: ... Planned actions: ...
6. Recommendations. Verb ... · owner ... · deadline ... · cost category (contract / separate order / investment decision).
Details and justification: engineering report no. ... Signature: ...
Five rules keep this page in line. First, one page really means one page. If section 3 has more than three items, the rest go to the engineering report. Second, the colors mean the same thing in every issue. Third, every event has an owner and a status, even if you are the owner. Fourth, the data quality section never disappears, even when it is dull, especially then. Fifth, the footer always points to a specific engineering report with a number, because that is what defends the page in an audit.
What not to write in the report
Raw charts without interpretation. A slope chart against temperature is an excellent tool for an engineer, because it separates the structure's daily "breathing" from a permanent trend. For a director, it is two lines, one of which wiggles. If a chart is going on the management page, it should be only one chart and only with a caption that says what is visible and what it means. If you cannot write that in one sentence, the chart is not ready.
Jargon without explanation. "Channel INC-03 exceeded WARNING on axis B after thermal compensation" is correct and useless for someone who does not know what axis B is. The management version: "the tilt sensor on the north wall exceeded the warning threshold; after temperature was taken into account, the exceedance remains, so it is not a heat effect." Longer, but the reader knows whether to worry.
No "what it means". Every paragraph on the management page ends with a consequence or a decision. "The tilt trend is X" is an observation. "The trend has persisted for the third month; we recommend a designer's opinion before the next work phase" is a report. A paragraph without a consequence does not belong on this page.
Two habits to finish with. Do not write "no remarks" if data were missing in the period. Those are two different things, and management has the right to know which one happened. And do not change the meaning of colors between issues: if yellow in March meant "trend to observe", in April it cannot mean "power failure".
The engineering report as backing: calibration debt and temperature compensation
The management page is only as strong as the report behind it. The engineering report has four pillars and one overall assessment. These determine whether the color on the first page is justified. The first two pillars concern the sensors themselves.
Calibration debt. Calibration debt is a listing of channels whose reading has drifted away from the reference reading (zero) more than the structure's behavior would explain, together with drift calculated as the slope from the last 7 and 30 days. You also add what you know outside the data: when the sensor was last checked and whether it has a certificate. String sensors manufacturers do not publish one universal recalibration interval. They recommend periodic verification where the sensor can be removed or compared with a reference instrument, and the interval is set by the monitoring design. A sensor with debt does not stop measuring, but it stops being evidence: every threshold exceedance on such a channel can be challenged by asking about drift. On the management page this appears as one line in the "data quality" section and, if needed, as a recommendation with a cost category.
Temperature compensation. Temperature compensation is a correction of the sensor reading for the component resulting from changes in the temperature of the sensor itself and the structure, so that what remains in the assessment is what the structure is really doing. Without it, thresholds lie in both directions: in summer they generate false warnings, in winter they hide real exceedances. The engineering report shows which channels are compensated, on what basis, and how strongly the value depends on temperature before and after correction. If the dependence remains clear after compensation, the coefficients need improvement. Every "the trend persists" on the management page means "it persists after compensation."
What this means for you: these two pillars answer the first question asked in a dispute or audit: "How do you know it is the structure, not the sensor?" It is better to have the answer in the report before anyone asks.
Threshold tuning, data SLA and risk assessment
Threshold tuning. Thresholds set before commissioning are a hypothesis. After the first weeks of data, the engineering report assesses which thresholds create noise, which stay silent for too long, and proposes corrections, with the rule that project alarm thresholds are not changed without the designer's decision. Every change is recorded: who, when, old value and new value, and you add the reason in the report. We describe how to select and tune thresholds separately in the post on alarm thresholds in construction monitoring. Management gets only one conclusion from this section: "the alarms are reliable" or "tuning is in progress, false warnings are possible during the transition."
Data SLA. Data SLA, the contractual completeness level, is the number of readings that arrived compared with the number that should arrive at the actual logger cadence, for example every 15 minutes by default, or more often, calculated per channel, together with the length of gaps, their cause (power, transmission, service), and the freshness of the last reading. A data gap is a gap in evidence and in protection. Monitoring that was silent during an event protected against nothing. In the engineering report this is a table; on the management page it is one number per asset.
7- and 30-day risk assessment. The overall assessment rests on four pillars: reliable data, compensated trends, tuned thresholds and trusted sensors make it possible to say something about the future. Statistics identify channels that are moving away from their baseline faster than usual; the engineer combines that with the work plan and weather. If one pillar is weak, the assessment should show it: "the 30-day assessment is subject to uncertainty because two channels have calibration debt." Management prefers to hear about uncertainty from the engineer rather than from an expert witness.
How often and for whom
Report frequency follows the decision the recipient makes and how quickly they need to make it. A daily management report is noise. A quarterly operator report is a quarter late.
| Recipient | Frequency | Content | Form |
|---|---|---|---|
| Operator / duty engineer | Daily (review), immediately after an event | Channel states, alarms to confirm, NO_DATA, service tasks | Dashboard + SMS/e-mail notifications |
| Monitoring engineer / designer | Weekly or after a work phase changes | Compensated trends, threshold tuning proposals, calibration debt, data SLA | Engineering report |
| Site manager / contract manager | Weekly, immediately on ALARM | Zone status, events and their handling, impact on the next works | Engineering report summary + events |
| Asset manager | Monthly, before periodic inspection, after weather events | Asset status, seasonal trends, material for periodic inspection under Art. 62(1) of the Construction Law | Management report + engineering appendix |
| Management / owner / finance director | Monthly or quarterly, after each red event | One page: status, events, trends for decisions, data quality, 7/30-day risk, recommendations with cost category | Management report |
| Supervision, insurer, dispute party | On request | Engineering report, export of period data, alarm history with confirmations | Evidence package |
Three notes. A report after an event is a separate genre: shorter, with a timeline (when the threshold was exceeded, when notification was sent, who confirmed, what was established) and without a 30-day risk assessment if it is too early for one.
Second: for the asset manager, monitoring does not replace the periodic inspection. Article 62(1) of the Construction Law requires an inspection at least once a year, and for buildings with a building footprint over 2 000 m² and other structures with a roof area over 1 000 m² at least twice a year, by 31 May and by 30 November. It is carried out by a person with construction qualifications, and the monitoring report is material for them, not a protocol.
Third: if management only sees the report when something is wrong, they learn that the monitoring report is bad news. A regular green page builds the trust needed in the month when it turns yellow.
What it looks like in Inclify
In Inclify, the backing for the management report is in the platform, in the project engineering reports tab. Calibration debt shows, for each channel with a reference reading, the current deviation from the reference and the drift from the last 7 and 30 days. Temperature compensation matches the temperature channel with the raw and compensated channel and shows how strongly the value depends on temperature before and after correction, with a status for each path. The 7/30-day risk assessment calculates a statistical trajectory of deviation from baseline for each channel. Alarm tuning proposes warning and alarm thresholds based on the measurement history together with the expected number of events per week, and you can apply the proposal in one action. Data SLA calculates completeness against the actual logger cadence, gaps, freshness and the overall score per channel.
You build the "events and how they were handled" section from the alarm history: OK / WARNING / ALARM / NO_DATA states with the time of transition, who and when confirmed the notification, silences always with a deadline. Threshold and equation changes go into the audit log with the value before and after. Multi-axis charts, such as tilt against temperature, make it possible to distinguish daily temperature changes from a lasting trend, and if one chart is to go on the management page, you save it as an image; export table data to CSV. The platform does not generate a ready-made PDF. You write the one page yourself, in an editor or presentation, and that is intentional: a person signs the colors and the recommendation.
AI analysis detects statistical anomalies (deviations from a baseline window, spikes, channels with no change) and writes a Polish comment on the calculated results. We treat it as an assistant that points the engineer to what to look at, not as the author of the report. More about what AI does well and what it does not can be found on /platform/ai and in the post AI in construction monitoring: what works.
FAQ
How long should a management monitoring report be?
One page in a fixed structure: asset status in three colors, events and their handling, trends that require a decision, data quality, 7- and 30-day risk, recommendations. Anything that does not fit on the page belongs in the engineering report, which the first page references in the footer. If the report grows, it mixes evidence with decisions.
Can the management report replace the engineering report?
No. The management report says "what we do", the engineering report says "how we know". Without the backing of calibration debt, temperature compensation, threshold tuning and data SLA, the colors on the first page are an opinion that is hard to defend in a dispute or audit. The same engineer signs both documents, but writes them for different readers.
What should be written in the report when nothing happened during the whole month?
Data completeness, the number of readings, warnings rejected after temperature was taken into account, and the decisions the monitoring enabled, for example moving to the next work phase without an ad hoc inspection. A green month is the result of the measurement system at work, not the absence of a result. A report that shows only "no remarks" in a quiet month teaches management that it is paying for silence.
What should be done when data were missing during the reporting period?
Write it clearly in the data quality section: which channels, for how long, for what reason, and what was done. Missing data is a separate state (NO_DATA), not "no remarks". If the gap concerned a channel important for the current phase, the asset gets a yellow color and the risk assessment flags uncertainty. Better uncertainty now than finding out after an event that the data were not there.
Can AI write a management report?
AI is good at detecting statistical anomalies and preparing a comment on the data, which speeds up the engineer's work. It does not know the context of the works, the contracts or the responsibility, so the recommendation and signature stay with a human. Treat AI as an assistant that points to what to look at. This text describes engineering practice and is not legal advice. Reporting obligations come from the contract, the design and the regulations.
Sources and further reading
- Act of 7 July 1994 - Construction Law (Articles 61, 62 - obligations of the owner and manager, periodic inspections) - ISAP
- PN-EN 1997-1 Eurocode 7: Geotechnical design - Part 1: General rules (clause 2.7 observational method: monitoring plan and contingency plan; chapter 4: monitoring and maintenance) - Polish Committee for Standardization, sklep.pkn.pl
- Simmonds A.J., "Long term monitoring using vibrating wire sensors", SHMII-6, Hong Kong 2013 (drift and recalibration of vibrating wire sensors) - ishmii.org
- NIST/SEMATECH e-Handbook of Statistical Methods, 1.3.5.17 "Detection of Outliers" (z-score and outlier detection) - itl.nist.gov
- Series posts: Construction monitoring (SHM): complete guide · Alarm thresholds: how to set them · AI in construction monitoring · Monitoring data as evidence in a dispute · How to justify monitoring to management
What next
If your monitoring report is twenty pages long today and nobody reads it, or one page without backing that can be defended, we will show, using an example of an asset similar to yours, how to assemble one page for management from the engineering reports in the platform. The simplest first step is to connect the existing sensors or run a pilot on one asset, so that the next monthly report already has backing. We respond within 24 hours: let's talk.