<!-- ARTICLE_BODY_START -->
The part that survives the selection
Choosing what knowledge deserves a place in a vault is the appealing part. The less glamorous question is what, exactly, will be placed there. A title is not a manual. A link is not an acquired file. A file is not necessarily a usable explanation. And an explanation that depends on unavailable instruments, missing diagrams, or an unnamed prerequisite may preserve the appearance of knowledge while losing the ability to pass it on.
There is a useful current prompt for asking these questions carefully. The National Digital Stewardship Alliance reports that version 2.1 of its Levels of Digital Preservation was released in March 2026 with a focus on environmental sustainability. Preservation is not simply accumulation; it involves choices about resources and continuing care. That update is verified here as a dated development, not presented as an announcement made this morning. NDSA's version history
This article proposes a design for knowledge packages in Austin Little's commissioned vault exercise. The accompanying selection contract calls for two fresh inventories of 2,000 proposed packages each. Those targets are not evidence that 4,000 packages have been acquired, licensed, assembled, or tested. The design below deliberately separates selection from preservation. Its examples are hypothetical design examples, not results from a completed recovery trial. The central question is practical: what would a future reader need in addition to a promising entry in a list?
Give the package a job
A package should begin with a bounded learning or reference purpose. Preserving knowledge about microscopes is too broad to be an acceptance criterion. Preserving an introductory explanation of optical magnification, a labeled account of component relationships, a calibration exercise using a harmless printed target, and a troubleshooting guide for common image problems is more concrete. It identifies what the reader should be able to understand and what the package does not promise.
The purpose should name its assumed audience. A technician who already understands lenses needs a different entry point from a student encountering focal length for the first time. Neither is served by a document that quietly changes its assumed level halfway through. A short prerequisites section can make that mismatch visible before the reader spends hours discovering it.
The package should also state the kind of success it supports. Is the goal recognition, explanation, calculation, comparison, supervised practice, or independent operation? Those are not different labels for the same achievement. A reader may correctly identify a component without being qualified to repair equipment containing it. A historical account may be valuable precisely because it is not current operational guidance.
This is the first design boundary: a package promises a specific contribution to understanding, not universal self-sufficiency. That boundary helps an editor choose material, helps a reviewer judge completeness, and helps a later reader decide whether the contents fit the problem actually in front of them.
Keep proposal status separate from possession
The selection record and the preservation record should be different objects. A selection record explains why a topic merits space and what an ideal package would contain. A preservation record identifies the files actually held, the permission basis considered, the checks performed, and the gaps still open. Combining them too early makes planned contents look like acquired contents.
Consider a hypothetical entry that proposes a diagram set, a reference table, three exercises, and an accessible transcript. The package is not complete because its description lists those four things. Each needs a separate status. The diagram might be acquired, the table merely located, the exercises newly authored but unreviewed, and the transcript not started. A single green completion field would erase the useful distinctions.
A small status vocabulary can do much of the work: proposed, source located, acquired, rights reviewed, technically checked, content reviewed, and usability tested. These states should be supported by evidence rather than treated as an inevitable ladder. A file can pass a technical check while its reuse permission remains unresolved. A well-licensed file can still be unreadable.
The point is not to create a ceremonial workflow. It is to keep the catalog honest. If someone searches for resources available offline, a promising acquisition lead must not appear as a locally available manual. The package design should make that mistake difficult even when an interface tries to simplify the collection into a single count.
Describe dependencies as things that can be missing
A prerequisite list becomes useful when its entries are specific enough to fail. Understanding basic arithmetic is a prerequisite. Having a powered computer with a compatible reader is another. Access to a particular calibration reference may be a third. These dependencies belong to different categories and should not be compressed into a vague statement that some equipment is required.
For the proposed design, dependencies would be divided into conceptual, physical, computational, and institutional requirements. Conceptual requirements point to prior learning. Physical requirements name the materials or instruments assumed. Computational requirements describe software, formats, fonts, or execution environments. Institutional requirements identify the qualified supervision, permissions, or external services without which an activity should not proceed.
The dependency graph should preserve direction. An introductory optics package may require a basic geometry package, but the geometry package should not require the advanced optics explanation merely because both cite the same diagram. Cycles are not automatically wrong; they can signal mutually reinforcing study. They do, however, need an entry route that does not assume the conclusion of the other package.
A missing dependency should degrade the package's claim explicitly. The reader might still learn the theory without being able to perform a measurement. That is a useful partial capability. Pretending the package is either wholly usable or wholly useless hides the middle ground where preservation often has its greatest value.
Preserve the explanation around the diagram
The hypothetical microscope package illustrates why images cannot be treated as decorative extras. A diagram may encode a spatial relationship that several paragraphs only gesture toward. If the image is removed, compressed until its labels blur, or separated from its key, the file count can remain unchanged while the lesson becomes incomplete.
The proposed package would retain an original image where lawful and appropriate, a readable access copy, a caption explaining its purpose, and a textual account of the relationships a learner should notice. Any scale claim would be explicit. A diagram intended only to show component order should not invite measurement from the printed page. A drawing with a scale bar should keep that bar and its unit attached.
The exercise would be chosen to test the stated learning goal without importing an unrelated hazard. A harmless printed target can support discussion of calibration and resolution without suggesting that an introductory package qualifies someone to interpret biological samples. The materials list would distinguish a teaching model from an instrument suitable for professional measurement.
The acceptance question becomes precise: can a reader connect each diagram label to the explanation, identify what is schematic, and understand what the exercise can and cannot establish? A visually attractive page that fails those checks is not rescued by a high-resolution image. Preservation must retain the relation among the parts, not merely the parts themselves.
Make the human route obvious
A future reader should not need the original catalog application to discover where to start. The proposed package would include a short opening document explaining its purpose, contents, prerequisites, restrictions, and reading order. It would identify the preferred access copy while keeping the original separate. It would also say which files are machine-readable metadata and which are intended for study.
A simple internal arrangement could place explanatory material, source originals, diagrams, data, exercises, rights notes, and validation evidence in clearly named areas. That arrangement is an editorial proposal, not a claim of conformance to any preservation standard. The names matter less than their consistency and the presence of an explanation that survives outside the application that generated them.
The opening document should be modest enough to inspect in a basic text reader. It should not rely on a remote stylesheet to reveal a warning or on a script to expand the only contents list. If a richer interface is included, the plain route remains available underneath it.
This is not an argument against good interfaces. A well-designed viewer can make a collection dramatically easier to use. It is an argument against making that viewer the only map. The package should remain intelligible when separated from the dashboard, account system, search index, and person who originally assembled it.
Use a transfer wrapper for a bounded job
BagIt offers a concrete way to distinguish a collection of transferred files from an unstructured directory. The October 2018 informational RFC describes a payload directory, a declaration, and checksum manifests. It separates completeness from validity: having the required files is not the same as successfully checking their recorded digests. BagIt 1.0 tools must support SHA-256 and SHA-512. These are packaging and verification conventions, not a guarantee that the contents are accurate or teachable. RFC 8493
For this proposed vault, a transfer package could carry one knowledge unit or a documented group of units. The important decision is the recovery boundary. If an export contains a thousand interdependent lessons, receiving only half should not leave the recipient guessing which ones remain usable. A manifest of package relationships would identify the intended set and the components actually included.
The transfer check should occur after the recipient has copied the material to its destination, not only before the sender begins. A successful source-side check establishes something about the source copy. It does not establish that the destination received the same bytes.
The design should resist inflating that result. A valid transfer can deliver an incomplete explanation perfectly. Conversely, a useful explanation may arrive with a missing image. Transport integrity and intellectual completeness need separate tests because they fail in different ways and require different remedies.
A digest answers a narrow question
NIST's August 2015 Secure Hash Standard describes algorithms that produce message digests for detecting changes. That is the relevant foundation for fixity checks here. It does not make a stored digest an independent witness to the truth or authorship of a document. FIPS 180-4 publication record
Suppose, hypothetically, that a package contains a mistaken table and a digest calculated from that mistaken table. Rechecking the digest can show consistency with the recorded bytes; it cannot correct the table. If an adversary can replace both the file and the unprotected manifest, a newly consistent pair does not by itself establish an authorized change. The trust question concerns how the reference record is protected and who is allowed to revise it.
The proposed design would therefore keep evidence of the accepted version separately from ordinary working files. Changes would create a new documented state rather than silently overwrite the basis of comparison. Where signatures are used, verification instructions and the basis for trusting the relevant keys would need preservation too. A signature that future custodians cannot interpret is not a complete trust mechanism.
There is a useful discipline in keeping the question narrow. Fixity asks whether the checked bytes match the recorded reference. Content review asks whether those bytes say something reliable. Provenance asks where they came from. None of the three should be marketed as a substitute for the others.
Record actions, not just a final label
A file's history should explain important transformations. Was it downloaded, scanned, transcribed, translated, converted, redacted, or corrected? A final label saying preserved does not tell a later reader which version of the object they are seeing or which kinds of change might explain a discrepancy.
PREMIS provides a useful conceptual vocabulary. Its version 3.0 data model distinguishes Objects, Events, Agents, and Rights, and its event descriptions support recording preservation-relevant actions and their outcomes. The model is a resource for designing interoperable records, not a reason to pretend a custom spreadsheet automatically conforms to the full standard. PREMIS 3.0 Data Dictionary
In the proposed package, an optical-character-recognition event would name the input, output, tool version where known, date, and review status. A later correction would identify the affected passage and the reason for the correction. The original scan would remain distinguishable from the corrected transcription.
This history helps with ordinary mistakes as well as sophisticated disputes. A reader who finds a missing negative sign should be able to determine whether it appears in the original, arose during recognition, or entered through later editing. Without that chain, the archive may contain several plausible versions and no way to understand their relationship. The history is therefore part of the usable knowledge, not merely administrative evidence for the institution holding it.
Make derivation legible
A knowledge package often combines material from several places. An editor may write a new explanation, redraw an illustration, translate a caption, and include a reference dataset. The package's title cannot carry all those relationships. Each component needs a clear account of its origin and the changes made to it.
The W3C's 2013 PROV overview describes provenance in terms of entities, activities, and the people involved in producing things or data. That framing is useful because it asks how an output came into existence rather than merely which website appeared in a bibliography. W3C PROV overview
For this design, a redrawn diagram would point to its source and identify whether the redraw changed scale, labels, arrangement, or emphasis. A translation would identify the source edition and the status of review by someone competent in the relevant languages and subject. A synthesized table would identify the constituent sources rather than imply that the combined artifact existed as an original publication.
These relationships should survive when a component is reused elsewhere. Otherwise, a diagram detached from its package can lose the qualification that made it intelligible. The package can include a convenient combined credit page, but the important contextual notes should also travel with the component. Reuse is not an exceptional event to design around later; it is one of the reasons to preserve knowledge in the first place.
Version the object without confusing its names
An identifier should remain stable enough to connect versions, while a version designation should make change visible. A package title can improve without turning the revised package into an unrelated object. Conversely, two distinct lessons should not become one merely because their titles resemble each other. Identity, display name, and current version serve different purposes.
The Oxford Common File Layout offers an application-independent approach to repository objects with inventories and versioned states. The 1.1 specification consulted here is dated October 2022 and updated November 2024. Its structured inventory and digest requirements illustrate how repository layout can remain understandable outside a particular management application. This article does not claim that the proposed vault already implements OCFL. OCFL 1.1 specification
A practical design decision would be to distinguish content changes from catalog corrections while recording both. Fixing a broken cross-reference may not alter the lesson's argument, but it changes the package a reader receives. Replacing an obsolete safety note is more consequential and should be visibly explained.
The revision history should support a simple question: what changed between the version someone studied and the version now recommended? A large undifferentiated replacement makes that question expensive. A stable identity with a readable change note allows a reader to update their understanding without rereading an entire collection in search of hidden differences.
Choose formats by the property that matters
No single format preserves every useful property. A page image may retain layout while making text difficult to search. An editable transcription may support access and correction while losing the exact appearance of the source. A flattened diagram may look right but discard the layers needed for later modification.
The Library of Congress describes format sustainability through factors including disclosure, adoption, transparency, self-documentation, and external dependencies. It also emphasizes that significant characteristics differ by content type. Those factors provide questions for a format decision, not a universal ranking that can be applied without inspecting the material. Library of Congress sustainability factors
The proposed design would state which properties matter for each representation. For a historical page, layout may be part of the evidence. For a numerical table, preserving values, units, column meaning, and missing-data conventions may matter more than reproducing the original typography. For an interactive demonstration, a video capture can document appearance but cannot replace the ability to change inputs.
Keeping more than one representation can be justified when their functions differ. It should not become an automatic excuse to accumulate every export a tool can produce. Each retained version should explain what it preserves that the others do not, and what test would reveal that the property has been lost.
Units belong to the data
A table of numbers without units is an unfinished explanation. So is a dataset whose blank cells might mean zero, not measured, not applicable, or withheld. These distinctions can change the conclusion a reader reaches even when every digit survives transfer perfectly.
Consider a hypothetical teaching table of lengths. One column uses millimeters and another uses centimeters. A later editor merges them under a single heading without converting the values. The resulting file may be well formed, easy to search, and protected by a valid digest. It is still wrong for the intended calculation. The error lies in the relationship between value and meaning.
The proposed package would therefore include a data dictionary alongside any reusable table. It would explain units, measurement conventions, categories, missing values, and the scope of the observations. If a conversion is applied, the transformation and rounding choices would be recorded. An example calculation would demonstrate how the fields are intended to be used.
The test should include a deliberately chosen edge case. Can a reader distinguish a measured zero from an unavailable measurement? Can they reconstruct a displayed total from the underlying entries? A small worked example often reveals more than a large statement that the data is clean. The aim is not to guarantee that every future analysis will be correct. It is to preserve enough meaning for errors to be detectable rather than silently inherited.
Accessibility is part of the recovery route
A knowledge vault that can be read only by people with one set of sensory and motor abilities has lost part of its intended audience before any storage failure occurs. Accessibility should therefore be designed into the package, not added as a decorative compliance label after the files are assembled.
WCAG 2.2's non-text-content criterion provides a useful baseline for web presentations: non-text content generally needs a text alternative serving an equivalent purpose, subject to specified exceptions. Applying one criterion does not establish full WCAG conformance. WCAG 2.2, non-text content
For the proposed package, an image description would explain the relationship necessary to understand the lesson, not merely announce that an image exists. A transcript would preserve meaningful spoken content and identify relevant nonverbal information. Tables would have understandable headings, and reading order would be checked rather than assumed from visual placement.
The same work improves resilience. Search, translation, printing, low-bandwidth delivery, and basic text access can all benefit from explicit structure. Those benefits should not erase the primary reason for accessibility: readers deserve usable access in their own right. They do show that designing for more than one mode of reading can help a package survive more than one kind of technical loss.
The acceptance test would involve the actual access route, not only inspection of the source editor's settings. An exported document can lose useful structure even when the working file appears correct.
Build an offline route that does not assume its own success
Offline usability should be tested with the network unavailable, not inferred from the presence of a download button. A document may contain remote images, a viewer may need an account, and an exercise may fetch a dependency only when first opened. These are ordinary design possibilities that a preservation plan should expose before an emergency does.
The proposed offline test would begin from a fresh environment with only the documented prerequisites. The tester would open the starting document, follow the reading route, inspect every required image, and attempt the designated benign exercise. Any unexpected request for a network service would be recorded as a dependency, not bypassed and forgotten.
A software-dependent package needs a bootstrap explanation. If its preferred reader is unavailable, what simpler representation remains? If an interpreter is required, is the required environment described and lawfully available? Source code alone may be valuable, but it does not prove that a future reader can build or execute the program under the stated conditions.
The fallback should degrade honestly. A static explanation can preserve a simulation's concepts without preserving its interactive behavior. A transcript can preserve an interview's words without reproducing every aspect of delivery. Labeling the fallback's limits is better than pretending it is either identical to the original experience or entirely worthless. The reader needs a route through partial capability, not a promise that nothing can ever go missing.
Rights metadata must describe the actual component
An openly accessible webpage is not necessarily an openly licensed source. Nor does a collection-level statement automatically settle the rights status of every image, excerpt, or contributed component. The package should record the permission basis considered for the material actually included, together with the evidence supporting that assessment.
Creative Commons Attribution 4.0 is a useful concrete example, not a license assigned by this article to any inventory item. Its conditions include retaining specified attribution information when supplied, indicating modifications, and identifying the license when sharing covered material. The license also distinguishes rights it does not grant. A package should not reduce those terms to a generic open label. CC BY 4.0 legal code
The proposed design would separate the status of newly authored explanation from the status of borrowed components. A permission note for a diagram would not silently authorize an accompanying photograph. Unresolved material would remain clearly marked and outside any distribution bundle that lacked an adequate basis for sharing it.
This is a preservation design principle, not jurisdiction-specific legal advice. Where the permission basis is uncertain or the intended use is consequential, qualified review is needed. The useful technical contribution is to keep the evidence attached: source location, relevant notice, date checked, component scope, and recorded decision. Future custodians should not have to reconstruct a rights assessment from a dead link and a reassuring adjective.
Cultural context cannot be replaced by a license field
Some knowledge requires a relationship of stewardship that a conventional copyright field cannot express. A recording, story, or practice may have community-specific conditions around who should access it, when it should circulate, and how it should be described. A vault should not treat the ability to copy bytes as authority to flatten those conditions.
Local Contexts describes Traditional Knowledge Labels as tools through which Indigenous communities can communicate local protocols and responsibilities for access and use. Their purpose includes carrying community context into digital settings where material may already be circulating outside those relationships. Local Contexts TK Labels
For this proposed design, the practical implication is to preserve the community's own description and the scope of any authorization, rather than invent a label on its behalf. An acquisition lead might identify material worth discussing with a steward without making it appropriate for unrestricted collection. Some packages may properly contain a contextual record and a referral rather than the cultural material itself.
This is not a deficit to hide from a completeness metric. A respectful boundary can be part of what the package teaches. The archive's job is not to turn every form of knowledge into an interchangeable asset. It is to keep enough context for future readers to understand that access, interpretation, and authority are not always held by the same person or institution.
Safety belongs in the learning claim
A vault that values practical knowledge will encounter medicine, electrical systems, structures, environmental hazards, and other subjects where an incomplete explanation can cause harm. The preservation goal does not remove the need for boundaries. It makes those boundaries more important because the future circumstances of use may be unknown.
The proposed package would distinguish historical knowledge, conceptual education, professional reference, and operational instruction. It would state where qualified supervision or current authoritative guidance is required. A collection of medical history should not be presented as a substitute for contemporary clinical care. A diagram of an electrical system should not imply that a reader is qualified to work on energized equipment.
Safety review should focus on what a reader could reasonably infer, not only on whether a warning appears somewhere in the files. A confident imperative in the main lesson can undermine a vague caution buried in an appendix. The editor should look for missing assumptions, omitted protective conditions, and obsolete claims that have acquired an undeserved appearance of authority through preservation.
The selection contract for this exercise excludes weapon construction, harmful biological protocols, and other high-hazard operational material. That boundary should remain visible in acquisition decisions rather than being diluted by a general desire for comprehensiveness. Preserving knowledge does not require preserving every possible instruction in the most actionable form. Sometimes the responsible package explains the subject, its history, and the need for expert institutions without providing a dangerous procedure.
Test recovery as a reader's task
A restore test that ends when files reappear on a disk is incomplete for this project. The preserved object is a knowledge package, so the test should ask whether a reader can recover its intended meaning and use the supported access route. That does not require pretending every lesson can be fully validated in one session.
A proposed test would separate several outcomes. The files were located. Their recorded digests matched. The preferred representation opened. The required components were present. The reading route made sense. The designated exercise could be attempted under its stated conditions. Each outcome would have evidence and a limit.
A reviewer unfamiliar with the package is especially valuable because the assembler may unconsciously supply missing context. If the tester asks which diagram is meant, where a unit is defined, or whether a result should be approximate, the question reveals something the package did not make explicit. The response should improve the material rather than merely coach the tester past the gap.
Failed tests should remain part of the record. A corrected package can then show what changed and why. The project should not report a successful recovery trial until the relevant trial has actually occurred. In this article, the test remains a proposed method. No inventory count, polished description, or standards citation converts that proposal into evidence that the current collection has passed it.
Design copies around different failures
Multiple copies help only to the extent that the losses affecting them are not all the same loss. Three directories on one device do not address the failure of that device. Copies under one account may share an access problem. A synchronized deletion can propagate faster than a custodian notices it. These are design scenarios to examine, not measured incidents in this exercise.
The proposed preservation plan would identify the failure each copy is meant to address. One copy might support convenient access, another recovery from an editing mistake, and another continuity when a particular location or service is unavailable. The plan would document who can alter each copy and how a recovery copy is checked without silently making it an ordinary working copy.
Encryption introduces a related dependency. Protecting sensitive material can be essential, but losing the means to decrypt it can make intact storage unusable. The design needs an authorized recovery arrangement for keys, an account of who may use it, and a test that does not expose secrets unnecessarily. This article does not prescribe a particular security architecture for unknown threat conditions.
The important question is whether the recovery story survives the loss it claims to address. If the instructions, credentials, inventory, and only knowledgeable custodian all depend on the same unavailable service, an additional data copy has solved only part of the problem. The package and the means of understanding it need coordinated, but not carelessly identical, protection.
Count the maintenance burden before expanding
A large selection can create a misleading sense that the main work is finished. Every acquired package may introduce formats to monitor, rights questions to revisit, dependencies to retain, and representations to check after migration. The proposed design should therefore record a maintenance profile alongside the content profile.
A static text lesson with a few diagrams has a different burden from an interactive environment requiring a particular operating system and remote service. That difference should inform preservation effort without automatically deciding cultural or educational value. A difficult object may deserve extraordinary care; an easy object may still add little to the collection.
The March 2026 sustainability emphasis in NDSA's revised Levels is relevant here as a prompt to make resource choices explicit, not as a formula dictating how many copies or formats this vault should keep. The project would need its own measured storage, labor, and recovery requirements before making such decisions. NDSA Levels 2.1
A useful review asks what each retained representation contributes, what would be lost without it, and what recurring work it creates. It also asks whether an acquisition fills a real gap or merely increases the item count. The goal is not the smallest possible archive. It is a collection whose promises remain proportionate to the resources available to honor them.
Keep obsolete knowledge without disguising its status
Preservation and recommendation are different acts. An older manual can remain important evidence of how a practice developed even after it should no longer guide current work. Deleting it may damage the historical record. Presenting it without qualification may mislead the reader. The package design needs a way to do neither.
The proposed approach would preserve the original's identity and date while attaching a separate, clearly attributed status note. If a later resource supersedes it for a particular purpose, the relationship should name that purpose. A newer publication is not automatically a complete replacement for every use of an older one.
Corrections should be visible as corrections. Quietly rewriting a historical source can destroy the evidence that a mistake once existed. A corrected access copy may be useful, but it should remain linked to the original and explain the intervention. A reader studying the history of a concept needs a different view from someone seeking the currently recommended explanation.
This also applies to the vault's own writing. An editorial synthesis can become outdated or reveal an error. Its version history should be as legible as that of material acquired elsewhere. The package should not acquire permanent authority merely because it was created specifically for preservation. Longevity increases the need to distinguish enduring evidence from advice whose applicability depends on time and circumstances.
Start with a complete small loop
Before scaling assembly, the proposed project should complete the full preservation loop on a small, deliberately varied pilot. The sample should include different kinds of challenge: a mostly textual lesson, a diagram-dependent explanation, a reusable table, an audio or visual item where permitted, and a software-dependent demonstration. These are proposed test categories, not a claim that such a pilot has already been run.
Each pilot package would move from selection rationale through acquisition, rights assessment, assembly, technical checking, content review, offline access, and an independent usability attempt. The review would record both successes and unresolved gaps. A package that cannot be responsibly acquired would remain a selection proposal rather than being filled with an invented substitute.
The pilot's value is diagnostic. It can reveal that the metadata fields are too vague, that a dependency category is missing, or that the chosen access format loses crucial content. Those findings should revise the design before thousands of records inherit the same weakness.
The stopping condition for the pilot would be stated in advance: the team can show what each package contains, why it may be held and shared in the intended way, which checks passed, what a reader could do, and what remains unsupported. That is a much stronger basis for expansion than a beautifully formatted list whose entries all claim completeness by default.
Preserve the route back to understanding
A knowledge vault should not be judged only by whether its files survive or its categories sound comprehensive. It should be judged by the route it leaves from those files back to understanding. Can a reader discover the starting point, identify the assumptions, follow the evidence, recognize the limits, and learn something that the package actually supports?
That route includes details that are easy to omit when selecting grand subjects: a diagram key, a unit, an explanation of a blank cell, a translation note, a rights boundary, a missing prerequisite, an account of a failed test. None is as impressive as a claim to preserve civilization. Together they determine whether a less extravagant promise can be kept.
The two proposed inventories in this commissioned exercise can provide a disciplined starting point. Their item counts should remain counts of editorial selections until evidence establishes something more. A package becomes acquired when its contents are actually held. It becomes checked when a defined check has occurred. It becomes usable for a stated purpose when that purpose has been examined under stated conditions.
The ambition need not shrink when the language becomes more exact. A vault can preserve science, practical craft, literature, humor, play, and ordinary dignity without pretending that every entry is a self-contained reconstruction kit. Its strongest achievement would be to leave future readers not only things worth knowing, but a clear, honest way to begin knowing them again.
<!-- ARTICLE_BODY_END -->