Four Conditions to Verify When Cloud-Sharing TS As-Built Inspection Tool Data

When using a TS as-built inspection tool on site, not only the accuracy of the measurements themselves and the ease of creating reports are important verification items, but also how measurement results are shared. In particular, when multiple stakeholders—site personnel, construction managers, internal reviewers, and client-side reviewers—view the same as-built data, if cloud-sharing procedures are not well established it can lead to missed reviews, referencing outdated data, incorrect permission settings, and rework before submission.

In this article, we explain four conditions that practitioners should confirm in advance when using the TS as-built inspection tool with cloud sharing. Rather than simply whether data can be saved to the cloud, it is important to clarify who can check which data, in what state, and to what extent.

Table of Contents

• Basics to prioritize when cloud-sharing a TS as-built inspection tool

• Condition 1: The scope of as-built data to be shared is clearly defined

• Condition 2: Viewing and editing permissions can be separated by stakeholder

• Condition 3: The field and the office can access the same up-to-date version

• Condition 4: Pre-submission review histories and correction details are easy to trace

• Common mistakes with cloud sharing and preventive measures

• Operational aspects to verify when selecting a TS as-built inspection tool

• Summary: Consider cloud sharing as a mechanism to reduce rework in as-built management

Fundamentals to Prioritize When Sharing TS As-Built Inspection Tools via Cloud Sharing

The TS as-built inspection tool is used to organize measured-point information acquired with total stations and similar devices, as well as design values, measured values, differences, standard values, judgment results, and so on, in order to streamline as-built management. Traditionally, it was common for data measured on site to be brought back to the office, checked by the person in charge, and then compiled into reports. However, as the number of sites increases or the number of reviewers grows, merely transferring the data can take time, and it can become difficult to tell which file is the latest version.

The purpose of using cloud sharing is not simply to put data on the internet. What matters is making the as-built information obtained on site available to the people who need it at the time they need it. For example, if the construction manager in the office can check the as-built values immediately after the site personnel take measurements, it becomes easier to detect exceedances of standard values or omitted measurement points early. If an internal reviewer can view the same data before submission to the client, it is easier to reduce the risk of replacing forms or repeat measurements.

On the other hand, while cloud sharing is convenient, if mismanaged it can also cause confusion. Problems that can occur include unverified data being shared, people who should not edit changing figures, decisions being made based on outdated data, and submitted content not matching what’s on the cloud. In other words, cloud sharing is a useful feature but also an area that should be governed by clear rules.

When using a TS as-built inspection tool shared in the cloud, there are four main perspectives to consider: the scope of data to be shared, permission management, synchronization of the latest version, and tracking of verification history. If these four conditions are in place, it becomes easier to carry out as-built management verification tasks smoothly. Conversely, if any one of them remains unclear, differences in understanding between the field and the office can arise, potentially causing rework before the final submission.

In practice, it is often the handling of peripheral information, rather than the measurements themselves, that causes confusion. If measurement point names, control cross-sections, measurement date and time, the person who performed the measurement, the design data used, coordinate systems, evaluation criteria, and revision histories are not organized, it becomes difficult to explain later why a result turned out the way it did. For cloud sharing, it is important whether these pieces of information can be reviewed together.

Also, attention must be paid to the on-site communication environment. Even if cloud sharing is assumed, communication can become unstable in mountainous areas, underground, in the shadow of structures, or in remote parts of development sites. Therefore, do not assume constant real-time sharing; you need to check whether it can safely synchronize when communication is restored, whether the states before and after synchronization can be distinguished, and whether duplicates or overwrites will not occur.

Cloud sharing should be regarded as a mechanism to improve the quality of as-built management. Rather than using it simply because it is convenient, adopting the perspective of using it to standardize verification processes, reduce differences in understanding among personnel, and prevent re-measurements and resubmissions will make it easier to realize the benefits of the TS as-built inspection tool.

Condition 1: The scope of as-built data to be shared is clearly defined

The first condition to check when sharing via the cloud is that it is clear what is being shared. In as-built management, simply sharing measurement results is not sufficient. Even if you only look at the measured values, you cannot perform a proper verification unless you know which design values those figures were compared against, which measurement points they correspond to, and under what conditions they were assessed.

The data handled by the TS as-built inspection tool include measurement point names, measured coordinates, design values, actual measured values, differences, specification values, pass/fail determinations, measurement date and time, measurers, work types, measurement locations, control cross-sections, and the correspondence with drawings and design data. When sharing via the cloud, you need to decide which of these items to show to stakeholders. If the review is only within the site, it may be acceptable to share detailed operational data, but for external reviews or client checks you may want to show only the information organized for submission.

If the scope of shared information remains ambiguous, unnecessary data may become visible and information needed for verification may be lacking. For example, even if only the assessment results are shared, if the original measured values or design values are not visible, the reviewer will have difficulty judging why it passed. Conversely, if all in-progress work data is shared, there is a risk that unorganized figures will be mistaken for the official results.

Therefore, when sharing via the cloud, it is desirable to handle in-progress data, data for internal review, data for pre-submission checks, and submitted data separately. At minimum, you need to ensure it is clear which data are preliminary and which have been confirmed. In as-built management, since re-measurements and corrections can occur even at the same survey points, it is important to prevent old measurement results from being mixed with the latest measurement results.

The unit in which data is shared is also important. Whether you share the entire construction project at once, by trade, by groups of measurement points, or by report will affect how easy it is to verify. Centralized management may be convenient for site personnel, but reviewers are more efficient when they can see only the scope they need. This is especially true on sites involving multiple work sections or multiple personnel, where the ability to divide the sharing scope finely impacts the ease of operation.

Also, it’s a point to check whether the as-built data and related materials can be reviewed together. If you can associate not only the measurement results but also design data, drawings, site photos, notes, and verification comments, it will be easier to confirm the contents later. For example, if the discrepancy at a certain survey point is large, having the situation at the time of measurement or supplementary notes makes it easier to determine whether it was a simple measurement error or caused by site conditions.

When deciding the scope of sharing, it is easier to organize if you separate the perspectives of the person entering data on site, the person reviewing it, the person approving it, and the person preparing the submission materials. The data entry person needs a detailed editing screen, while the reviewer needs a screen where judgement results and their rationale are easy to see. For the approver, it is important to be able to identify changes and items that remain unchecked. For the person preparing the submission materials, it is important that the items reflected on the forms are correctly assembled.

When introducing cloud sharing for the TS completion inspection tool, it is important not to share all data from the start but to design the sharing scope to match the actual verification flow. If you decide who sees what, at which stage to share, and whether the data can be edited after sharing, data handling will stabilize and unnecessary verification work can be reduced.

Condition 2: Ability to separate viewing and editing permissions for each stakeholder

The next important point in cloud sharing is permission management. As-built data contains critical information related to construction quality and submission documents. Therefore, leaving it in a state where anyone can freely edit it can lead to unintended changes or missed checks. When using the TS as-built inspection tool with cloud sharing, you need to confirm whether you can separate those who can view from those who can edit.

On-site personnel may register and modify measured values, add measurement point information, and attach photos and notes. In contrast, construction managers and internal reviewers are responsible for verifying measurement results, checking differences, and reviewing report contents. Furthermore, when sharing with external reviewers or the client, it is safer to grant view-only access without editing rights. Thus, the permissions required vary according to stakeholders' roles.

If access controls are inadequate, confirmed data can be changed afterwards. For example, you might think you only corrected a measurement point name just before submission, but that can affect the order of reports or which items are subject to evaluation. Alternatively, another staff member might overwrite older values, leaving it unclear which measurement result is correct. To prevent these problems, it is important to limit the scope of what can be edited and ensure that confirmed data cannot be changed inadvertently.

With access control, you should verify whether it can be managed not only at the user level but also at the site level, section level, and data level. For companies handling multiple sites simultaneously, if a person responsible for one site can view the as-built data of another site, this poses an information management risk. When partner companies or external personnel are involved, it is desirable to ensure they can access only the necessary sites and only for the necessary periods.

Also, temporary sharing requires caution. When you temporarily show data for internal checks or client review, if access remains available after the check is finished, unnecessary viewing may occur later. Being able to set an expiration for shared access, stop sharing, or view a list of who it has been shared with is very important in practice.

A commonly overlooked aspect of access control is the handling of downloads and exports. Even if cloud access is intended to be view-only, if reports or data can be exported they may be stored as separate files by the recipients. That itself isn’t necessarily bad, but unless you decide which version of the data was exported and how to handle changes made after export, outdated reports may remain.

Cloud sharing requires a balance between convenience and security. To keep on-site work running smoothly, it is important that the people who need it can access data immediately. However, if anyone can edit, the reliability of as-built management declines. By separating permissions such as view, edit, approve, export, and suspend sharing, it becomes easier to operate securely in a way that fits actual work.

In particular, it’s important to confirm internally whether as-built data has been checked before submission. If you edit data that has already been confirmed, establishing a workflow that requires re-checking will help prevent oversights after changes. When selecting a TS as-built inspection tool, it’s important to verify not only that it supports detailed permission settings but also that it can be used seamlessly with your actual on-site workflows.

Requirement 3: The ability to confirm the same latest version on-site and in the office

A major advantage of cloud sharing is that it makes it easier for on-site staff and the office to view the same data. However, in actual operations, confusion can arise if the handling of the latest version is unclear. When using cloud sharing with the TS as-built inspection tool, you need to confirm when measurement results taken on-site will be shared, whether the screen viewed in the office shows the latest version, and whether you can distinguish between pre-correction and post-correction data.

In construction quality management, measurements are sometimes retaken after the initial measurement. It is not uncommon to re-measure the same location—for example, when measurement conditions were poor, when there may have been an exceedance of a reference value, or when the measurement point may have been recorded incorrectly. If the original and re-measured results get mixed, the inspector may make an incorrect judgment. Knowing which version is the latest is a basic requirement of cloud sharing.

Even when data measured on site are shared automatically, they are not necessarily verified at that time. Data immediately after measurement may not yet have had the measurement point names checked or abnormal values reviewed. For that reason, being the latest version and being verified should be considered separately. Making it clear whether data are the latest but unverified or the latest and verified makes it easier to avoid mistaken decisions.

Also, at sites with unstable communication environments, you need to pay attention to synchronization timing. Data saved on on-site terminals and data reflected in the cloud may temporarily differ. If the office only looks at outdated information on the cloud and makes decisions, discrepancies can arise with the latest situation on-site. It is important to be able to check whether there is data waiting to be synchronized, whether any data failed to synchronize, and when the last update time was.

When managing the latest versions, it's safer to avoid relying solely on file names. Including dates or the responsible person's name in file names can make things easier to understand, but variations in how people enter them occur. If multiple files with similar names are created, or if someone forgets to change the name after updating a file, it becomes unclear which is the correct data. Having a mechanism in the cloud to check the update timestamp, who updated it, its status, and whether it has been verified makes management more stable.

To ensure the on-site team and the office are looking at the same latest version, it's important to define the workflow from measurement to verification. For example, if the on-site personnel perform an initial check after measuring, sync the data to the cloud, and then the office staff perform a secondary check, it becomes clear who verifies at each stage. Conversely, a vague process where someone just looks at the measurements as soon as they're taken disperses verification responsibility and makes oversights more likely.

Being able to view the same up-to-date version also helps with remote verification. If there is a measurement point on site that is difficult to judge, experienced staff in the office can advise while viewing the data on the cloud. If measured values, differences, field notes, and photos can be checked simultaneously, it becomes easier to share the situation than by explaining over the phone or via messages alone. This speeds up on-site decision-making and makes it easier to determine whether re-measurement is necessary.

However, relying too much on sharing the latest version can weaken on-site verification. If people assume that uploading to the cloud means someone will look at it, errors in measurement point names or omissions in measurements may be missed on the spot. Cloud sharing should be used to reinforce on-site verification, not to replace it. The idea of performing a primary check on site and a secondary check via the cloud leads to more stable operations.

If you use the TS as-built inspection tool via cloud sharing, be sure to check that the latest version is easy to identify, the synchronization status is clear, and it’s easy to confirm who updated it and when. When these are in place, you can reduce discrepancies between the field and the office and make it easier to avoid rework before submission.

Condition 4: It should be easy to track the pre-submission confirmation history and revisions

The fourth requirement is that the verification history and any corrections be easily traceable. In as-built management, it is important not only that the final reports and submitted data are correct, but also that the verification process leading to them can be explained. In particular, when there are measurement points close to the reference values, re-measured points, or corrected points, you need to be able to trace why they were corrected, who verified them, and which value was ultimately adopted.

When data is shared in the cloud, multiple people view the same information, so confirmation comments and correction instructions tend to arise. For example, an office reviewer may point out an error in a measurement point name and a field staff member may correct it. For measurement points with large discrepancies, it may also be necessary to confirm whether re-measurement is required. If such exchanges are conducted only verbally or through individual contacts, it becomes difficult to check the history later.

If a system keeps a record of verification history, you can organize who checked what and when, which items were flagged, and how those flags were addressed. This is useful not only for internal checks before submission but also for responding to inquiries later. In as-built management, past measurement results are sometimes reviewed after construction has progressed. If the reasons for corrections are recorded, it becomes easier to understand the situation even if the person responsible has changed.

When tracking revisions, simply retaining only the final values can be insufficient. Whether you corrected a measured value, changed a measurement point name, adjusted the correspondence with design values, or reviewed the judgment criteria can significantly alter the meaning. It is important not only to note changes in numbers but also to understand which items have changed.

Also, caution is required when implementing a workflow that completely deletes pre-correction data. Although the desire not to retain erroneous data is understandable, if the history of re-measurements or corrections can no longer be reviewed, it becomes difficult to explain why the final value was chosen. To avoid unnecessary confusion, it is desirable to clearly indicate the final adopted value while keeping past records reviewable as needed.

Confirmation history also helps clarify the division of responsibilities among personnel. If there is a workflow in which on-site staff take measurements, the construction manager checks them, and an approver decides whether to submit, knowing each person’s confirmation status makes it possible to identify where work is stalled. When it is unclear who is expected to confirm, unconfirmed items may be discovered just before submission.

With cloud sharing, how you use the commenting feature and status management is also important. Allowing people to write comments freely can make it hard to tell whether something has been checked, needs correction, or requires re-measurement. If you operationally separate states such as under review, correction requested, corrected, confirmed, and ready for submission, stakeholders can work with the same understanding.

In pre-submission checks, it is also necessary to confirm that the content reflected on the forms matches the content in the cloud. In practice, mistakes can occur, such as having corrected something in the cloud but the form still being output with the old data, measurement values being updated after the form was created, or proceeding to prepare for submission with review comments still remaining. Being able to verify before the final output that there are no unchecked items or unresolved comments left provides reassurance.

Being able to track the confirmation history and the corrections is not merely a management function but an element that supports the reliability of as-built inspections. When using the TS as-built inspection tool’s cloud sharing, check not only whether measurement results can be shared but also whether the flow of verification, correction, and approval is visible. This reduces anxiety before submission and helps achieve as-built management that is easier to explain.

Common Mistakes in Cloud Sharing and Prevention Measures

In cloud sharing of the TS as-built inspection tool, the convenience can lead to several mistakes. A typical one is looking at outdated data. If the field team has remeasured but the office reviews unsynced data and makes a decision, unnecessary comments and incorrect requests for corrections can arise. To prevent this, it is important to make a habit of always checking the last updated time, the sync status, and the confirmed indicator.

Another common problem is expanding the sharing scope too much. Showing all data to everyone involved may seem to increase transparency at first glance. However, in reality the volume of information becomes excessive, making it hard to tell what needs to be checked. In particular, if unorganized measurement data and work-in-progress notes are shared, reviewers may mistake them for final contents. The scope of sharing should be narrowed according to the purpose of the review.

Mistakes in permission settings are another point to watch. If someone you shared with intending only view access has editing rights, unintended changes can occur. It is also undesirable for access rights to remain for retirees, transferred employees, or external parties after construction work is completed. When using cloud sharing, it is safer to establish a policy of regularly reviewing shared recipients and their permissions.

Inconsistencies in the notation of measurement point names and management items are also a problem that tends to become more noticeable when sharing on the cloud. When multiple people enter data, the same measurement point may be written slightly differently. Such notation inconsistencies cause confusion when creating reports or performing searches. By deciding in advance how to name measurement points, how to write work type names, and rules for entering management items, it becomes easier to verify information after sharing.

Care must also be taken in how comments are handled. If a reviewer leaves a comment but it’s unclear whether it has been addressed, you’ll end up having to confirm by other means. The workflow should include not only leaving comments, but also updating the status of those comments, rechecking after they have been addressed, and checking for unresolved comments before submission. If comments continue to remain, it becomes unclear which ones are valid points.

Relying too much on cloud sharing and omitting immediate on-site checks is also a problem. In as-built measurements, it is important to be able to notice abnormal values or missing measurement points immediately after measuring on site. Even if you can check later on the cloud, if a re-measurement becomes necessary after leaving the site, the amount of rework will be substantial. It is important to follow the order of performing an initial verification on site and then sharing the results on the cloud.

Also, you need to be careful about the timing of report output. If a report is created based on data that are still under verification, and measurement values or measurement-point information are updated afterwards, the report and the data in the cloud will no longer match. Just before submission, confirm that the data used to create the report have been finally verified. If changes occur after the report is created, you also need an operational procedure to decide whether reissuing the report is necessary.

Preventing mistakes in cloud sharing requires rules as well as features. By clarifying who will take measurements, who will verify them, when they will be shared, and under what conditions something will be considered ready for submission, cloud sharing can become a system that is useful in practical work. When introducing a TS as-built inspection tool, it is important not to decide based only on a list of features, but to anticipate the types of mistakes likely to occur at your own sites and confirm whether you can operate it in a way that prevents them.

Operational aspects to check when selecting a TS as-built inspection tool

When choosing a TS as-built inspection tool, people tend to focus on measurement support and report output features, but if cloud-based sharing is assumed, checking operational aspects is also essential. No matter how feature-rich it is, if on-site staff find it hard to use, reviewers have difficulty locating the information they need, or the sharing settings are too complicated, it will be difficult for it to become established in everyday practice.

First thing to confirm is whether on-site operations are easy to understand. Cloud sharing begins with field personnel correctly registering and synchronizing data. If the post-measurement confirmation screen, the display of synchronization status, the checking of unsent data, and the readability of judgment results for each measurement point are intuitive, it becomes easier to reduce input errors and omissions in sharing. Being able to use it without hesitation even when busy on site is extremely important in practice.

Next, you need to check whether it will be easy for the office side to review. Office reviewers are in a position to judge the validity of measurement results even when they are not on site. Therefore, it is important that the list of measurement points, locations with large discrepancies, unverified items, and places that may require re-measurement can be found easily. Rather than simply displaying data in a list, confirm whether the screen layout makes it easy to access the items that need to be checked.

Whether it fits your internal approval workflow is also important. Depending on the company, the composition of people involved in verification differs — the measurer, the site representative, quality control personnel, the administrative department, etc. If a cloud-sharing system does not match your approval workflow, you will end up supplementing it with separate spreadsheets or other communication methods. Even if everything cannot be completed within the tool, deciding in advance how much will be managed by the tool and what will be covered by internal rules makes operation easier.

Data retention periods and searchability are items you should also check. After construction is completed, you may need to review past as-built data. If there are later inquiries or you want to use them as references for similar projects, being able to find past data easily is a major advantage. Make sure it is easy to search by site name, work type, measurement date, person in charge, measurement point name, etc., and that you can separate unnecessary data from important data.

Handling communication environments is also important on-site. Even when using cloud sharing, measurements are sometimes taken in places with unstable connections. Whether work can continue if the connection drops, whether data can be safely synchronized later, and whether synchronization failures are clearly communicated directly affect field operations. Operations that can only be used on the assumption of always-stable connectivity can leave some sites uneasy.

Ease of training should not be overlooked. The TS as-built inspection tool is not necessarily used only by staff experienced in surveying and as-built management. New personnel or representatives from partner companies may also use it. For that reason, it is important that it be easy to explain how to read the screens, how to perform post-measurement checks, cloud-sharing procedures, how permissions are handled, and the pre-submission check workflow. If usage becomes dependent on individual users, operations are likely to break down when personnel change.

Also, verify compatibility with existing business workflows. If your company already uses certain form templates, verification procedures, or approval methods, you need to check whether they will conflict with how the tool will be operated. Adapting operations to the tool can be effective, but if it places too much burden on the workplace it will not become established. Before implementation, write out the flow from the field to submission and clarify where to integrate cloud sharing.

When selecting a TS as-built inspection tool, it is important not only to consider whether it has the necessary functions, but also whether it can reduce on-site mistakes, lessen the burden on reviewers, and ease anxiety before submission. Cloud sharing is a mechanism that supports the verification tasks that occur between measurement and report preparation. Therefore, prioritizing ease of use for both on-site personnel and reviewers when choosing a tool is the quickest way to increase the effectiveness of its implementation.

Summary: Consider cloud-based sharing as a mechanism to reduce rework in as-built management

The four conditions to check for cloud sharing of the TS as-built inspection tool are the sharing scope, permission management, latest-version management, and verification history. If these four conditions are in place, the field and the office can review the same information together, which makes it easier to reduce rework such as missed measurement points, overlooking threshold exceedances, decisions based on outdated data, and report edits before submission.

Cloud sharing is not just a storage location. It is an operational platform for stakeholders to review, correct, approve, and submit as-built data. Therefore, it is necessary to organize in advance who to share what with, who can edit, which data is the latest version, and what kind of verification history will be retained.

When introducing a TS as-built inspection tool, it's important not to judge it solely by measurement accuracy or report output, but to consider how it will be shared on-site, who will verify it, and at what stage it will be used as submission documentation. Once cloud-sharing operations are established, on-site decision-making becomes faster, office checks are smoother, and explaining results to the client becomes easier.

On the other hand, if the scope of sharing is unclear, permissions are too lax, or the latest version is hard to identify, cloud sharing can actually cause confusion. The more useful a feature is, the more important it is to establish rules for its use. By performing an initial check on-site, a secondary check in the cloud, and creating a process to review the verification history and form contents before submission, it becomes easier to stabilize the quality of as-built management.

If you're going to review TS as-built inspection tools, evaluate cloud sharing not as a "function for sending data" but as a "mechanism for reducing rework in as-built management." Establishing workflows that let you quickly verify coordinates and as-built information collected on site, share them among stakeholders, and carry them through to submission documents will lead to improved operational efficiency.

If you want to handle on-site measurement, coordinate management, form and report creation, and cloud sharing as a single workflow, it is important not to judge based solely on a specific product name but to check whether it fits your own site conditions and verification flow. By clarifying the roles of TS as-built inspection tools and cloud sharing, and by considering how to link the information obtained on site to verification and submission, it becomes easier to create an as-built management system that better matches actual operations.