Record reasoning as well as files
A folder containing photographs and meshes does not explain why a reconstruction took its final form. Documentation should connect each significant interpretation to its supporting observations, assumptions and review. This explanatory record is sometimes described as paradata: information about how a knowledge-based visualization was constructed. Keep it readable to people who do not use the same modeling application.
Start with stable object and project identifiers. Include the collection reference where permitted, the purpose of the work, responsible contributors, access conditions and dates of acquisition or revision. Distinguish the physical object from its digital representations. Several models can describe one object, and a single published scene may combine material from several records.
Create a source register
Give every photograph, drawing, scan and comparative source an identifier. Record its creator, date where known, holding institution, access location, rights status and relevance to the project. Identify uncertain attribution or dating rather than quietly choosing an answer. Where the source cannot be redistributed, retain an appropriate citation and explain the access restriction.
A source register should also record limitations. An archival photograph may have been cropped, reversed or reproduced from a later print. A cast may transmit a restored rather than an earlier state. A scan may omit the base. These details are easy to lose when sources become thumbnails in a modeling workspace, but they can materially change the interpretation.
Maintain an operation and decision log
For each meaningful change, record the input version, operation, output version, responsible person and reason. Separate routine technical processing from interpretive intervention. Removing isolated scan noise is not the same as extending a broken finger, even if both happen in the same application. Note when an operation affects the evidence-bearing surface.
| Record field | What to capture |
|---|---|
| Input | Stable file identifier, version and source relationship |
| Operation | Software, settings, transformations and manual work |
| Reasoning | Constraint addressed and assumptions introduced |
| Outcome | Output identifier, known limits and review status |
| Alternatives | Competing proposals and reasons for retaining or rejecting them |
For AI-assisted work, retain prompts where relevant, input selections, model identifiers, available generation settings and subsequent edits. Do not promise exact reproducibility when a changing service cannot provide it. Instead, explain the missing information and preserve the actual output used. Review whether storing prompts or source images introduces personal, confidential or culturally restricted information.
Keep alternatives in the record
Rejected interpretations reveal how constraints were tested. Preserve enough information to explain why a mirrored feature, a candidate join or a generated completion was set aside. Distinguish “contradicted by evidence” from “not selected for this display.” Those are different judgments, and future research may revisit the latter without invalidating the original project.
Review should be attributable and bounded. Record who assessed geometry, who considered historical interpretation and who approved publication permissions. A technical reviewer may not be qualified to endorse iconography, while a subject specialist may not have validated measurement accuracy. Do not use a general approval label to imply expertise or agreement beyond what was actually provided.
Use standards as connecting frameworks
The London Charter and the Seville Principles provide useful guidance for transparent computer-based visualization of cultural heritage. CIDOC CRM offers a conceptual framework for expressing relationships among cultural heritage entities and events. These resources can help structure documentation, but adopting a vocabulary does not itself make an interpretation correct or its evidence sufficient.
For digital preservation, the OAIS reference model, published as ISO 14721, can inform institutional thinking about information packages and long-term responsibilities. PREMIS can support preservation metadata, while Dublin Core can help with basic descriptive discovery. Choose a proportionate approach that fits the repository and staff capacity. A clear, maintained record is preferable to a complex schema no one can sustain.
Publish layers and preserve dependencies
Keep a present-state model separate from measured derivatives and interpretive additions. Package textures, material files, units, coordinate conventions and a readable manifest with the geometry. Include checksums where appropriate and verify that files can be opened independently of a particular workstation. Test links and filenames after transfer; dependencies often break when a project leaves its original folder.
Rights should be explicit for each component. Ownership of the object does not automatically settle copyright in photographs, scans or drawings. A reconstruction may incorporate several permissions with different conditions. Do not apply a blanket open license to material you cannot authorize. Explain which files may be reused and how contributors and sources should be credited.
Plan for correction
Publish a version identifier and retain earlier releases when feasible. If new evidence changes a proposal, explain the change rather than silently replacing the model. Provide a contact route for corrections and keep a record of substantive responses. The goal is not to freeze an interpretation; it is to make its development understandable and its revision accountable.