Creating an audit trail for GNSS survey data
An audit trail connects original observations to processing decisions, accepted coordinates and issued versions without relying on personal memory.
Define the questions the record must answer
A GNSS audit trail should allow a reviewer to determine where a coordinate came from, which configuration applied, what processing changed it and why it was accepted. Begin with those questions rather than a desire to collect every possible log. The record needs stable identifiers and meaningful relationships. A large folder of files can still be unauditable if no one can connect an exported point to its original occupation and review decision.
Choose a level of detail proportionate to the project. Routine mapping and critical control may require different records, but both benefit from a clear chain of provenance. Identify the authoritative source for field observations, coordinate definitions, processing configuration and final issue status. Document who can approve changes so the trail describes an actual controlled workflow rather than an ideal process that staff do not follow.
Continue learning GNSS data handover: what to include with the final coordinates
Preserve original observations and setup evidence
Retain raw receiver data and controller records where required by the project, along with mark identifiers, timestamps, antenna information and relevant field notes. Protect originals from accidental overwrite. A corrected derivative should remain linked to its source rather than replace it silently. This makes it possible to distinguish a verified correction from an unexplained change introduced during conversion or office cleanup.
Use stable point and session identifiers across files. Avoid reusing a point name for a different physical feature or renaming sessions without a mapping record. Photographs and sketches should carry identifiers that connect them to the relevant setup. A picture named image001 can be valuable only if the archive preserves enough context to establish which mark and observation period it represents.
Continue learning Organizing GNSS project folders for reliable processing and handover
Record configuration as part of provenance
Associate observations with the project coordinate system, correction source, antenna height procedure and relevant equipment configuration. Keep effective times for changes. A survey spanning several days may use different firmware, receiver units or localization versions. Without those boundaries, an analyst may attribute a coordinate shift to field conditions when it actually follows a configuration change.
Store approved templates and configuration exports where supported, but supplement proprietary files with readable descriptions of critical definitions. A future reviewer may not have the same software version. The archive should identify the reference frame, epoch, projection and height workflow independently of a menu label. This makes the record durable and reduces reliance on screenshots that show values without explaining their interpretation.
Continue learning Archiving GNSS raw observations for useful future processing
Capture processing runs deliberately
Give each significant processing run an identifier and retain its inputs, software version, settings and output report. Record the question the run was intended to answer. A diagnostic run that temporarily releases a constraint is different from the accepted production solution. Clear labels prevent an intermediate coordinate list from being mistaken for the final result simply because it was generated most recently.
Where supporting products are downloaded automatically, preserve a manifest or the permitted files needed for reproducibility. Record conversion and decimation operations as well. The audit trail should distinguish recorded observations from derived exchange files and processed coordinates. This allows another analyst to repeat the accepted workflow without guessing which of several similar files was selected by the original operator.
Continue learning Designing a backup and recovery strategy for GNSS projects
Make review decisions visible
Record exceptions, investigated causes, corrections, exclusions and acceptance decisions. Link each decision to the relevant observation or point identifier and supporting evidence. A statement that bad points were removed is insufficient. The reviewer needs to know what made an observation unsuitable and whether its exclusion affected other calculations, such as an adjustment, transformation or surface model.
Keep original and revised values with their status where practical. If an antenna height transcription error is corrected, preserve the field evidence supporting the correction and the recalculated result. If an anomaly remains unresolved, retain that limitation. The audit trail should not imply that every quality concern was fully explained merely because the final coordinate table contains no warning symbols.
Continue learning GNSS data handover: what to include with the final coordinates
Track dependencies beyond the coordinate table
GNSS coordinates can feed GIS layers, CAD drawings, surfaces, volumes and other derived products. A control or transformation change can therefore affect many outputs. Record which issued products depend on which accepted coordinate version. When a correction occurs, follow those dependencies and identify the files requiring revision rather than updating only the master spreadsheet.
Use a deliverable manifest with version identifiers and, where appropriate, file hashes. Hashes can help verify that a file has not changed, but they do not establish its measurement quality or approval status by themselves. Pair integrity checks with meaningful metadata. A perfectly preserved wrong export remains wrong, so the record must identify both file identity and the acceptance decision that applies to it.
Continue learning Organizing GNSS project folders for reliable processing and handover
Keep issued versions and supersession clear
Separate working outputs from approved deliverables. Record issue dates, recipients through the organization's normal process and the reason for any replacement issue. If a dataset is superseded, preserve the relationship between versions. Downstream teams should be able to determine whether an old coordinate list remains valid without contacting the original analyst or comparing thousands of rows manually.
Avoid filenames that rely only on words such as final, latest or new. Use a consistent version convention and a manifest that names the authoritative issue. The audit trail should survive copying to another storage location, so include readable metadata with the package. A project folder's modified date is not a reliable substitute for a documented issue history.
Continue learning Archiving GNSS raw observations for useful future processing
Protect the record without exposing secrets
Apply appropriate access and backup practices to the archive. Credentials, tokens and unnecessary personal details should not be embedded in public reports or client data packages. Keep operational secrets in suitable private storage and record only the service identifiers needed to understand the workflow. This preserves reproducibility without turning an audit package into an accidental disclosure of account access.
Assign responsibility for maintaining the record and test recovery from backup. An audit trail that exists only on one analyst's workstation is fragile. Use organizational storage and a clear retention policy appropriate to the project. Periodically ask another qualified person to locate the source and acceptance evidence for a selected point; that simple exercise can reveal missing links before a formal review exposes them.
Continue learning Designing a backup and recovery strategy for GNSS projects
Deliver an understandable chain of evidence
The final archive should let a reviewer move from issued coordinate to accepted processing run, original observation, setup information and quality decision. Provide a concise index or manifest rather than expecting users to infer the chain from folder names. Include known limitations and unresolved dependencies. The goal is practical traceability, not a claim that every file can be understood without any professional interpretation.
A well designed audit trail reduces rework and strengthens confidence in the survey. It makes corrections easier to investigate, supports future reuse and distinguishes genuine measurement changes from processing or configuration changes. Most importantly, it preserves the reasoning behind the accepted coordinates after the original crew and office staff are no longer available to explain the project from memory.
Continue learning GNSS data handover: what to include with the final coordinates
Practical checklist
- Define the questions the record must answer.
- Protect the record without exposing secrets.
- Deliver an understandable chain of evidence.
Plan your GNSS setup
Compare the EQ10 and EQ20 receiver specifications, then discuss the configuration and support your project needs.
Compare GNSS receivers
