An archive management system helps an organisation describe, preserve and retrieve material whose continuing value extends beyond everyday editing. Separate 3 needs: archival description, digital preservation and controlled access. They overlap, but a searchable folder or backup alone does not establish that all three are covered.
Start with the collection and the people who need to use it. Physical records, born-digital documents and mixed collections present different requirements. Decide what must remain understandable, which rights or restrictions apply and what evidence is needed to trust a retrieved object before selecting a system.
How do archival management and digital preservation differ?
Archivematica’s product introduction describes processing digital objects through preservation workflows and producing archival information packages using recognised metadata approaches. ArchivesSpace’s project documentation describes accessioning, arrangement, description, rights and collection-management information. These are related roles, not interchangeable promises.
| System or approach | Documented emphasis | Requirement to investigate |
|---|---|---|
| Archivematica | Digital-object ingest and preservation processing | How objects and preservation information are retained and verified |
| ArchivesSpace | Archival description and collection administration | How material is described, related and made discoverable |
| Ordinary file storage | Keeping files available in a storage location | Which description, rights and preservation functions remain elsewhere |
| Backup | Restoring a copy after a failure or loss | Whether the restored collection remains understandable and complete |
The final two rows are conceptual distinctions, not product evaluations. A backup can support an archive’s recovery without supplying archival description. A catalogue can describe an object without itself being the storage and preservation environment for every digital file.
The official descriptions support investigating both Archivematica and ArchivesSpace where their roles fit. They do not establish that a particular installation complies with Zambian retention law or that the products integrate automatically in every configuration. Verify the actual workflow and responsibilities.
What should the collection record contain?
Begin with identity and provenance. Record what the material is, where it came from and how it relates to other material. An unexplained filename is a weak substitute for a stable reference and useful description. Keep relationships understandable when a file is moved or a display name changes.
Describe the level at which information applies. A collection, series, folder and individual item may need different descriptions. Repeating the same broad statement on every file can obscure important differences, while describing everything only at collection level may make retrieval difficult.
Record rights and access restrictions separately from physical or digital location. Knowing where an object is stored does not determine who may see it. A public catalogue description can coexist with restricted content, but the actual system must demonstrate how that boundary is enforced.
Preserve the meaning of dates. Creation, receipt, processing and publication can refer to different events. Do not silently replace an unknown creation date with the date a file was uploaded. Record uncertainty explicitly where the evidence does not establish a precise date.
How do you test retrieval and preservation workflows?
Choose representative material, including awkward examples. A collection may contain unusual file formats, incomplete descriptions or several versions of a document. A demonstration using only a tidy folder of modern PDFs will not establish how those cases are handled.
Ask the operator to trace an object from intake to its stored form and retrieval route. Identify what processing occurred and which information records it. Archivematica describes user decision points in preservation processing; those decisions should be understandable in the proposed operating workflow.
Use this original archival accession-to-access ledger:
| Stage | Evidence to retain | Question to answer |
|---|---|---|
| Receipt | Source, reference and transfer context | What arrived and from whom? |
| Description | Appropriate collection and item relationships | Can someone understand the material later? |
| Rights | Permission and restriction record | Who may access which part? |
| Processing | Actions and relevant results | What changed during ingest or preservation? |
| Storage | Identifiable object and associated metadata | Where is the retained material? |
| Retrieval | Search or reference route | Can an authorised person find the intended object? |
| Recovery | Checked restoration of the relevant package or system | What survives a failure? |
| Disposal or transfer | Applicable authorised decision | Who may approve an irreversible action? |
The ledger is an original evaluation artefact. It does not supply a legal retention schedule or authorise deletion. Those decisions need the organisation’s applicable obligations and accountable approval.
What should access testing include?
Test with different authorised roles. A description being visible does not mean the underlying object should be downloadable by everyone. Check both the public or ordinary-user route and the staff interface where relevant. Do not infer access control from a hidden menu alone.
Inspect the retrieved object’s identity and context. The user should be able to distinguish an original, a derivative and a later revision where the workflow creates them. A file opening successfully is not complete evidence that it is the intended version.
Test a missing or restricted object. The system should explain the available route without exposing confidential information unnecessarily. Staff need to understand whether the problem concerns permissions, storage, description or an object that was never received.
How do you select an operating model?
Open-source software still needs hosting, maintenance, updates and support ownership. Identify who operates the application and who owns collection decisions. The technical administrator should not have to invent archival policy to complete a configuration.
Keep preservation and recovery responsibilities explicit. A system can have a reliable catalogue while the digital-object storage is poorly protected, or the reverse. Map the components and test the outcome that matters: a retrievable object with the information required to understand it.
Document the limits of the first implementation. It may cover a defined collection while other material remains in an existing process. State that boundary honestly rather than calling the whole organisation archived because one import completed.
See web development for related information-system work. To explain an archive requirement, get started with collection types, access needs and the evidence that must remain available over time.
Give references a documented meaning that survives a filename change. A person citing an archived item should be able to distinguish the collection reference from a temporary storage path or a newly generated download name. Test that distinction during retrieval rather than discovering it when someone needs to reproduce an earlier citation.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.