CC-BY 4.0
Introduction
Digital archaeology has now evolved into a complex technological field where many platforms, software, and workflows coexist with similar and overlapping capabilities (Psarros et al., 2022; Sylaiou et al., 2025). Archaeological teams are faced with the dilemma of choosing the most appropriate platform for the digital documentation of their archaeological research. All available options promise to offer greater efficiency, higher accuracy and easy integration, but this coexistence often leads to confusion. The choice of the right software is not based only on the technological factor, but is also related to issues associated with accessibility, licensing model, compatibility with technological equipment, sustainability and the possibility of future migration to new platforms (Moullou et al., 2024; Sá et al., 2024).
The problem of technological dependency, i.e. the tendency to be limited to the use of a software or ecosystem, is a visible danger in archaeological research. Many archaeological research teams adopt specialised applications that offer easy-to-use interfaces and optimised workflows, but are tied to a specific operating system or data structure (Gunnarsson, 2018; Katsianis, 2012). Although these applications may seem quite efficient during an excavation period, they can prove to be quite limited in the long run, especially when the volume of data increases or when teams try to integrate this data into GIS platforms or other relational databases, or even when support for the software by the creators ends (Xu, 2024).
At the same time, the evolution of mobile and GIS technologies offers new opportunities for archaeologists, while also raising practical challenges for digital field documentation (Averette et al., 2016; Katsianis, 2012; Taylor et al., 2015, 2018). Proprietary GIS software like ArcGIS (Ames et al., 2020; Lindsay & Kong, 2020) and open-source GIS ecosystems such as the QGIS platform and its companion mobile application, QField (Fábrega-Álvarez & Lynch, 2022; Montagnetti & Guarino, 2021; Ostadabbas et al., 2020; Pažout, 2023; Saba, 2025), allow archaeological teams to bring to the field work environments that previously were only available on workstations back in the laboratory. These modern software packages offer a unified workflow that includes mapping, importing and analysing geospatial data that is accessible across devices and operating systems.
This article aims to emphasise that the long-term improvement of performance in archaeological field documentation, thanks to the integration of technological tools, is not tied to any single software, but depends mainly on the ability to transition, that is, the movement from one digital environment to another while maintaining methodological stability and data integrity. Through two case studies, referring to the transition, the first from iDig to QField for excavation documentation and the second from ODK to QField for archaeological survey documentation, the challenges, dilemmas, decisions and ultimately the results of such transitions are presented. The discussion that follows the presentation of the case studies aims to contribute to the framework of thought regarding the adaptability of archaeological research to developments in the technological field and to highlight the advantages of open and interoperable infrastructures that can evolve along with archaeological questions and the reality in the field.
Case study I: From iDig to QField for excavation documentation
Research context
The first case study is about the Neolithic excavation of the Paradimi (Bakalakis & Sakellariou, 1981) site (Rhodope, Greece) during the 2023–2025 excavation seasons, where the team decided to integrate the iDig software for all of the documentation and recording needs of the excavation. iDig is a tablet-based recording system (https://idig.tips/) developed by Bruce Hartzler and Georgios Verigakis to cover the needs of the Agora Excavations of the American School of Classical Studies at Athens (ASCSA) (Uildriks, 2016) and has since been adopted by other excavation teams (Boyd et al., 2021). The iDig software is designed to enable fast, accurate and consistent digital recording in the field. It supports offline data entry, which is essential when working in the field. Furthermore, it provides a built-in Harris Matrix, a useful tool for the field archaeologist during fieldwork. It also supports georeferenced images, synchronisation of data across iPads and direct connection to Leica total stations for direct spatial data recording and visualization. While iDig is a strong tool that enabled the Paradimi project to initially digitise the documentation of the excavation (Figure 1) and integrate its recording forms in the platform (Figure 2), as the project grew, limitations of the platform started to become more apparent.
Figure 1 - Digital documentation in the field with iDig, Paradimi excavation 2023
Figure 2 - iDig interface, Trench A in Paradimi excavation
Limitations
As stated above, iDig is a powerful software solution for digital documentation, but after a certain point, it presented several limitations. Initially, it was observed that the forms and attributes provided by iDig were tailored to the Agora excavation. The issue is not particularly difficult to resolve since several excavations have customised the documentation vocabulary to their needs (Tasaklaki & Arrington, 2024). The basic customization of field vocabularies and value lists is well documented and involves editing JSON configuration files. The major limitation lies in the closed architecture of iDig, which prevents extensions beyond the predefined JSON schema and therefore limits adaptability when project requirements deviate from the Agora excavation model. Another major limitation concerns hardware and operating system requirements, since iDig is designed and developed to run on iOS, meaning that an excavation project needs to align its hardware environment with this condition and procure iPads for its excavation team. That is a costly investment for a project, just for the ability to use this software. Expanding on this limitation, it can be noted that this issue hampers accessibility since data cannot be available on a cross-platform environment for review and analysis, which can cause problems in collaboration. Furthermore, in the standard configuration of iDig, users can synchronize their devices only when connected to the same network, which prevents remote monitoring and limits backup possibilities. However, the recent introduction of iDig Server has partially addressed these limitations by enabling improved synchronization options, although the requirement for iOS-only devices remains. Additional limitations are found in data management constraints. More specifically, iDig is not capable of connecting with external databases and poses file size and image resolution limits. Post-field analysis in GIS environments is challenging, since the data need to be manually transformed or processed via custom scripts in order to be imported into a GIS project. While iDig’s built-in web-server .tsv export option has improved data accessibility, the transformation process remains cumbersome. In general, from the preceding limitations, it is obvious that in such closed, specialised platforms, adaptability and interoperability are greatly reduced. Such was the case with the Paradimi excavation, as the project grew and expanded its analytical and research reach, the need for an open GIS-native environment became pressing.
Adopting QField for archaeological excavation
Under the aforementioned conditions and the pressing matter of switching to an open GIS-native environment, a decision was taken by the technical team to transition to the QField ecosystem. The first application of the platform was during the 2024 excavation season of the ancient city of Palaiopolis (Palaiokrassá-Kopitsa, 2018) in collaboration with the excavation team. The reasoning behind the change was, as discussed, the need to overcome the iDig limitations and achieve a workflow that would be interoperable and would not be limited by hardware, operating system or network and also be GIS-based.
The solution was QField, which is an open-source mobile app that is designed to function seamlessly with QGIS, a widely adopted open-source GIS software. In more detail, QField is designed to be able to bring a complete QGIS project to the field, thus making certain spatial analyses faster and more immediate after the collection of data. It also supports offline work and later synchronisation (Fábrega-Álvarez & Lynch, 2022; Ostadabbas et al., 2020). However, unlike iDig, synchronisation is not limited to local network connectivity as QField supports unified data management by connecting to a PostgreSQL database with the PostGIS spatial extension. (Sauer, 2023). This means that for synchronisation, only an internet connection is needed. Another significant advantage over iDig is its cross-platform capability, as it operates on both iOS (Figure 3) and Android devices (Figure 4). This promotes better collaboration within mixed-device teams in the field and eliminates the need to configure all excavation hardware around a single platform specification, thereby increasing overall flexibility. Additionally, since data collected through QField can be reintegrated directly into the QGIS environment, there is no need for manual transformation of data, as is the case with iDig, since the data forms that QField produces can be immediately imported to any GIS software. QField does not suffer from the same limitations on data size and image resolution as iDig. Also, concerning excavation documentation flexibility and adaptability, QField allows custom data entry forms that can be edited according to the excavation’s needs (Montagnetti & Guarino, 2021).
Figure 3 - QField interface depicting trenches in Palaiopolis excavation on an iOS tablet
Figure 4 - QField interface on an Android mobile device depicting unit creation and unit attribute form in Palaiopolis excavation
System architecture and component relationships
The QField ecosystem consists of three interconnected components (Figure 5). The core of the infrastructure consists of a PostgreSQL database server with PostGIS spatial extensions, which serves as the central repository for all excavation data. The database stores the geometric features (points and polygons) representing trenches, units, and find locations, along with their attributes (descriptions, categories, dates, and photos). The QGIS desktop application, which serves as the primary project configuration environment with the QFieldSync plugin installed, is also part of the core infrastructure. The plugin is responsible for the packaging of QGIS projects for mobile deployment and synchronization with changes made to project files. The QGIS desktop project maintains direct database connectivity, allowing project administrators to monitor data collection and make adjustments to project parameters as excavation requirements evolve. QGIS desktop can be installed on more than one computer, and project files can be synchronized via the QFieldSync plugin.
For synchronization and backup operations, QFieldCloud was deployed as a self-hosted instance running within a Docker container environment. While QFieldCloud can be used via SaaS (Software as a Service), which does not require specialized technical knowledge, the self-hosted version was chosen. This choice was motivated by two factors: the community free plan’s storage limitations (100 MB total project size, insufficient for extensive photographic documentation) and the need for offline editing of PostGIS layers, a feature supported only by paid plans.
Figure 5 - Three-tier QField architecture showing data flow from central PostgreSQL/PostGIS database through QFieldCloud synchronization layer to field devices operating in Offline Editing mode with local GeoPackage storage
The system operates in Offline Editing mode, one of QFieldCloud’s two packaging options for PostGIS data. In this configuration, when a field device downloads a project from QFieldCloud, the system automatically creates temporary GeoPackage files containing local copies of all PostGIS layers. Field teams use the local GeoPackages, and all changes are saved to them, regardless of whether they have an internet connection. This prevents data loss due to either an unstable internet connection and avoids conflicts from simultaneous editing of the same features by different team members.
The workflow proceeds in the following order. First, the project is prepared in QGIS desktop, where all project files and PostGIS layers are created simultaneously. Next, the project is uploaded to QFieldCloud with Offline Editing mode selected in the QFieldSync settings. Once the project is available on QFieldCloud, field devices connect using appropriate credentials and download project files via the QField app’s synchronization button. The downloaded project files include GeoPackages created by QFieldCloud, which serve as local copies of the project’s PostGIS layers for offline use on mobile devices. As team members collect data in the field, it is stored in local GeoPackage files. Upon synchronization, either manually via the ‘Push Changes’ button or automatically at predefined intervals, QFieldCloud extracts only the delta changes (edits, additions, and deletions) and applies them to the central PostGIS database. The updated data is immediately visible in the QGIS desktop application (which maintains a direct database connection) and becomes visible to other mobile users once they synchronize.
Team members in the field used their tablets or mobile phones, which had QField installed. All data entries were stored in each device’s local GeoPackage files, with synchronization with the central PostgreSQL database occurring three times a day during the excavation (mid-morning, noon, and at the end of the day). This mode of operation created a delay of approximately 2–3 hours before the data became visible to other users but ensured data integrity. Simultaneous editing of the same features by different users could have created conflicts, which would be resolved through the QFieldCloud interface. However, no conflicts occurred during the excavation period, as spatial separation of work areas and unique primary key constraints prevented simultaneous edits to the same features.
All of the above presupposes that a person with a certain level of technological expertise is available to configure and customize the digital environment, a condition that not all archaeologists are trained to meet (Masson-MacLean et al., 2021). Setting up such workflows often requires familiarity with database structures, GIS configuration, and synchronization mechanisms, skills that are not always part of the standard archaeological training.
Evaluation and comparison
During the 2024 season in Palaiopolis, several users tested the QField system in the field for both data recording and post-processing procedures, and reported positive feedback on the way the system worked. In the 2025 season, QField was used along with iDig at the Paradimi excavation site in order to compare the applications and ensure a smooth transition from iDig to QField. QField emulated iDig logic by having custom documentation forms, which in turn emulate the traditional excavation documentation form. The data collected through these forms, whether they concerned finds, units, or features, were in a format that could be integrated directly into the GIS environment. Users found really useful that all the data layers (finds, units, orthophotos) were within one project. Tools such as layer transparency and quick search were handy in the field. Post-field processing was highly accelerated and efficient, as noted, since the data were already GIS-ready, and certain analyses could even be made in the field. Also, very importantly, near-real-time sync kept field and lab teams aligned. It is quite significant that training the teams to use the software was neither challenging nor time-consuming, since the app has an intuitive interface that is easy to learn even for non-GIS users.
However, QField also presents some limitations that should be noted. First, the connection to total stations remains quite complicated in practice, as there is no detailed guide like the one for iDig. It should be mentioned that QField does not require an external intermediate device, such as an Arduino, to communicate with the total stations, while also supporting a wider range of total stations, unlike iDig, which currently only supports Leica stations.
Another limitation relates to Harris Matrix generation. While iDig automatically generates the Harris Matrix from recorded stratigraphic relationships, QField does not natively support matrix visualization. Stratigraphic relationships must be systematically recorded in the field, with matrix generation handled through external tools in post-processing. This approach offers more flexibility but requires deeper technical familiarity and foresight in the design of the data model. For this reason, each stratigraphic unit was recorded with a unique identifier and attributes, with stratigraphic relationships (above, below, cuts, fills) captured in a separate database table as paired unit connections. The relationship data were available in the QGIS desktop environment, where they could be exported and processed using external Harris Matrix generation tools or custom plugins (Costa, 2023).
The use of QField in the field proved in action that flexibility and openness outweighed the convenience that the closed, specialised systems provide. As mentioned, both the technical advantages and field user feedback confirmed that the cross-platform and open-source setup vastly improved efficiency, interoperability and data quality. Even though initially some training is necessary, it is counterweighed by the long-term benefits. Concluding, the most significant gain from the transition from closed specialised systems to open and flexible ones is the fostering of digital resilience, meaning the ability to adapt the tool to the data and the research questions and not vice versa.
Case Study II: From ODK to QField for archaeological survey
Research context
Following the successful implementation in excavation documentation, the second case study focuses on a similar transition within the context of surface survey. A suitable case study was the intensive surface survey conducted in 2024 in the area around the Neolithic tell of Paradimi, within the framework of the PAREX project (Tasaklaki et al., 2024). The aim of this project was to detect new Neolithic sites through the identification and analysis of surface finds, as well as the identification of new archaeological sites from other periods in the surrounding Aegean Thrace plain. At the same time, emphasis was placed on data collection, aiming to better understand settlement patterns in combination with natural resources and geomorphology.
The Thracian landscape and modern interventions posed significant methodological challenges for the archaeological surface survey. The main concern was the need for adaptive survey strategies due to intensive agricultural cultivation, which created varying ground visibility and accessibility depending on crop cycles and vegetation cover. To address these challenges, the project initially designed and employed an ODK-based (Open Data Kit) mobile framework for structured field data entry (Sgouropoulos et al., 2024). Although ODK has the ability to collect geographic data and then integrate it into QGIS via available plugins, using the ODK framework for intensive surface survey revealed some limitations related to the workflow. The primary limitation concerned ODK’s data model and export structure, since spatial data are exported as CSV files where multiple GPS points collected within a single form submission are stored in formats requiring custom Python scripts for transformation into GIS-compatible geometries.
During the implementation of the intensive surface survey methodology, a serious dilemma arose regarding the recording of finds in the field. Either complete a separate form with full attributes for each individual artifact, a time-consuming process requiring extensive form navigation, repeated dropdown selections, and multiple submissions per walker, or record all artifacts from a fieldwalk in a single form submission, with only GPS coordinates varying between finds while descriptive attributes (artifact type, count, density observations) remained constant for the entire collection. This limitation derives from ODK’s hierarchical data model, which is optimized for discrete data collection events (household surveys, medical records, individual interviews) rather than rapid spatial point collection with varying attributes. Additionally, the lack of real-time visualization during fieldwork limited tactical decision-making, as density patterns and spatial distributions were only visible after evening data processing.
Adopting QField for archaeological survey
In order to counter these issues, the research team used QField as a mobile GIS platform for recording archaeological finds and collecting field data. The QField software, which provides direct compatibility with QGIS, permitted the project to unify data recording, mapping, and analysis within a single digital environment (Montagnetti & Guarino, 2021). Following the same system architecture as the excavation case study described above, a custom digital form was designed to allow users to record key characteristics of the archaeological finds identified during the survey, as well as additional data relevant to the research area. The recorded attributes included artefact type, material, chronological determination, field unit, surface visibility, photographs, and general comments (Figure 6). Furthermore, the GNSS module of each user’s smartphone enabled the automatic georeferencing of each record.
Figure 6 - Data capture using custom forms and smartphones’ GNSS receivers (left), field walkers using QField for data collection (right)
This direct integration of spatial data for each recording transformed the data processing workflow even from the field data collection stage. The ability of the QField project to display raster and vector layers in near-real time allowed the use of base maps, satellite imagery, and vector layers representing cadastral agricultural land boundaries (Fábrega-Álvarez & Lynch, 2022). The combined use of these layers conveniently served as the main field research units instead of a predesigned artificial grid (Figure 7). This adjustment was made to take into account both the real conditions of modern land use and the need to record finds in delimited units, which in this case were the individual agricultural plots visible in the satellite background.
The visible layer of satellite imagery within QField combined with the display of the user’s location, proved to be a particularly useful addition to the recording process carried out in the field, as it helped walkers/users maintain orientation, appropriate spacing and methodical collection of archaeological finds during surface research.
Figure 7 - Base map and layers on QField’s interface, fully customizable
Data Collection
The archaeological surface survey was conducted over two six-day periods (spring and autumn 2024), covering an area around the Neolithic settlement of Paradimi of slightly less than nine square kilometres. The surface survey workflow utilised the same technological infrastructure as the excavation implementation described above. The system was configured in Offline Editing mode, same as the excavation setup, with the main difference lying in synchronization frequency. The survey teams synchronized every 30-45 minutes or at the end of each fieldwalk in individual fields (compared to three times daily for excavation) to enable adaptive tactical decisions based on the artifact distribution patterns.
The decisions were made based on feedback from the visualization. After each synchronization, the QGIS desktop project was manually refreshed to display newly collected artifact points (Figure 8). Density heatmaps were generated in QGIS using the built-in heatmap renderer. When the heatmaps revealed high-density areas, supervisors instructed survey teams to reduce walker spacing from the standard 10 m intervals to 5 m in the survey units. This adjustment enhanced artifact recovery in archaeologically rich zones. It should be noted that the term “near-real-time” in this workflow refers to archaeologically meaningful timeframes. The synchronization lag of 30-45 minutes between artifact collection and visualization proved acceptable for the tactical decision-making required in surface survey.
Evaluation and comparison
Comparing the two approaches, QField addressed the specific limitations encountered with ODK in our survey implementation. As detailed above, the critical advantages were: 1) Native GIS data formats eliminating the CSV-to-geometry transformation process. 2) A data model supporting individual artifact records with full attributes without field workflow penalties. 3) The near-real-time visualization capability enabling adaptive survey decisions within the same field day. Both systems support offline data collection, a fundamental requirement for survey work. However, the synchronization architectures differ: ODK excels at offline-first design with end-of-day processing, while QField’s frequent sync cycles (described above) enabled the visualization-driven tactical adjustments central to our methodology.
Figure 8 - Sample of a map created in QGIS instantly from field data, within the QGIS survey project
However, the transition to using QField from both ODK and conventional workflows also presented challenges. In particular, setting up the digital environment and creating and customizing forms in QGIS required a certain level of technical expertise, as discussed above. Additionally, initial implementation revealed occasional synchronization conflicts when multiple desktop QGIS installations edited the same project simultaneously. These conflicts occurred at the project configuration level (QGIS project files, layer styling definitions, form configurations) rather than in field-collected data, and were manually resolved through QFieldCloud’s conflict resolution interface, which displayed conflicting versions side-by-side for comparison. This issue was mitigated by establishing a workflow protocol where project configuration changes were coordinated among team members, with only one person modifying project settings at a time while others focused on data review and analysis. Field device synchronization (the upload and download of collected GeoPackage data) operated independently and did not produce version conflicts, as QFieldCloud’s Offline Editing mode handles data-level conflicts through its built-in delta synchronization mechanism. Gradually, as the project progressed, workflows stabilized and user experience improved, resulting in a reduction or even total resolution of issues. After the complete implementation of the digital workflow described above, the project researchers concluded that the benefits in data collection speed, data quality, analysis capabilities and adaptability far exceeded the implementation costs.
The outcome from the case study of the surface survey around the site of Paradimi proved in practice that mobile GIS platforms, such as QField, can provide a set of features capable of supporting an archaeological field survey. Despite challenging survey conditions (intensive cultivation, limited visibility, and modern installations), the project maintained high data resolution requirements. It is worth noting that the project demonstrated that the methodological continuity of a field research can be maintained, and in the case described above even improved, while changing the underlying digital framework. This successful transition was achieved by prioritizing software based on open data structures and spatial integration. Both during the transition stages from one software to another and throughout the workflow of the research, the project team ensured the security of the data by keeping it usable, available for further study, and available for sharing with future research initiatives.
Discussion about adaptability and openness
From the aforementioned case studies, one can conclude that the efficiency of digital methods is not directly linked to a specific software, but depends on the ability to adapt to new technological environments that arise as technologies evolve. It may seem safe for a group of researchers to continue using the same software for a long period, because stability creates a sense of trust. However, it should be taken into account that technological stillness can create problems and hide risks, such as data fragmentation, isolation and ultimately the abandonment of projects due to the lack of interoperability, the difficulty of data analysis and non-compliance with new international standards. Open GIS ecosystems such as QGIS and QField adopt a modular architecture consistent with open data principles, meaning that the development of the systems focuses on the data and the operations that need to be performed on them, thus allowing the creation of customized data collection forms, layers and databases that can be modified each time to serve the needs of different projects from excavation and survey to the management and display of cultural material. The adaptability presented by these ecosystems allows researchers to develop methodologies that serve the needs in the field and are not limited by software limitations.
Another significant advantage of the open systems is found in data portability. Data formats such as GeoPackage, CSV, and PostGIS are easily readable, interoperable, and not dependent on a specific software. This approach aligns with FAIR principles (Findable, Accessible, Interoperable, Reusable) (Wilkinson et al., 2016), which emphasize data structures that remain usable beyond their original software context. This ensures that primary archaeological datasets will remain available and usable even if the software used to create them is discontinued. As presented in both case studies, the implementation of QField led to smoother integration between field and analytical workflows, thus reducing redundancy and human error. In addition, the projects proved in practice that open-source infrastructures can be preserved locally, providing the teams with complete control over data security and ethical management, which is particularly important in archaeological research. These developments also relate to broader discussions about the implications of large-scale digital data and digital infrastructures for archaeological research practices (Huggett, 2020).
When moving from one system to another, it is inevitable that there will be a period of adjustment, which will certainly depend on the learning curve of the software. The success of the transition is not only influenced by the capabilities of the new software, but also by the culture of the team. A culture of openness and adoption of new workflows should be cultivated in the team. This culture is reinforced through team training, documentation and testing in order for the team to have a positive attitude towards the transition, but most importantly to continue to feel confident during the transition. In the two case studies presented, both the excavation team and the surface survey team reported that when users recognised the benefits of near-real-time visualisation and data coherence, the implementation of the system accelerated rapidly.
Furthermore, projects that use community-based software for development and implementation can benefit not only from the support provided by the community regarding technical difficulties but also from the dissemination of technical achievements between institutes. This also strengthens the sense of belonging and reduces the isolation of projects.
In closing the discussion about openness, we should mention that it does not come without costs and challenges. Maintaining digital infrastructures requires quite specialized technical knowledge and server management skills. Also, there is a need to create common standards for collecting and recording archaeological data within GIS systems that would ensure interoperability between systems (Tsiafaki & Michailidou, 2015). However, the aforementioned challenges can be overcome by relying on the advantages of adaptability. Thus, prioritizing data over software, a core tenet of open data practices (Kansa & Kansa, 2021; Marwick et al., 2017), can ensure the long-term protection of archaeological datasets against technological obsolescence. Looking at current technological developments, one can see that there is a need for greater integration of the mobile GIS sector in photogrammetry, 3D modelling, and AI-based image recognition, thus giving archaeologists even more possibilities for immediate analysis and interpretation while they are in the field. This integration is easier to achieve in the context of openness.
Conclusions
As described in the above case studies, the experience of archaeological research in Greece demonstrates that the transition from one software platform to another is feasible, and above all beneficial, in accordance with the principles of openness, flexibility and methodological coherence. The transitions produced several improvements in daily practice. Efficiency gains came primarily from eliminating data transformation steps. Both iDig and ODK required intermediate processing to make field data usable in GIS, while QField’s native formats were immediately ready for analysis. Data integrity improved through QFieldCloud’s conflict detection and regular synchronization backup points.
Based on the two case studies, two main conclusions can be drawn. Firstly, archaeological teams should be ready to reshape digital workflows if technological developments are capable of contributing to the improvement of the efficiency of digital practices. Secondly, open digital ecosystems support the combination of workflows related to field recording, management and analysis across different archaeological contexts. The use of QField for both excavation and survey in our case studies exemplifies this flexibility: a single system handled diverse data types (stratigraphic contexts, features, surface finds) within unified project environments, eliminating the technical fragmentation and training overhead associated with methodology-specific software solutions, while ensuring that archaeological documentation can be reused and extended.
In closing, it should be emphasized that from the experience gained from the two archaeological investigations at the two sites in Greece, Palaiopolis of Andros and Paradimi of Rhodope, it appears that archaeological innovation in the digital age depends less on specific technological tools than on the adaptability of the teams using them.
Funding
The authors declare that they have received no specific funding for this study.
Conflict of interest disclosure
The authors declare that they comply with the PCI rule of having no financial conflicts of interest in relation to the content of the article.
Acknowledgments
Preprint version 2 of this article has been peer-reviewed and recommended by Peer Community In Archaeology (https://doi.org/10.24072/pci.archaeo.100696; Drillat & Regnier, 2026).