Open Documentation Package¶
Knowledge artifact — instantiates Dependency-Capture Exit Design
Externalizes the tacit knowledge a role depends on into open, portable artifacts so the function no longer lives in one person's head.
Much capture rests on a single fact: the crucial knowledge exists only inside one person, undocumented and therefore unmovable. Open Documentation Package attacks that fact directly by turning tacit, in-the-head knowledge into explicit, open, portable artifacts — runbooks, architecture notes, decision records, credentials inventories, reproducible build and data — that anyone qualified can pick up. Its defining property is that it makes the knowledge itself independent of any particular carrier: it does not certify that a chosen successor can do the job, it removes the reason the job needs a specific person at all. The package is the difference between "only Priya knows how the deploy works" and "the deploy is documented well enough that a competent stranger could run it." It is content and portability, not a competence sign-off on named individuals.
Example¶
A widely-used open-source cryptography library has, for years, effectively one maintainer who holds the release keys, the mental model of the codebase, and the informal knowledge of which tests are load-bearing. The project's bus factor[n1] is one, and downstream companies are nervous. Rather than recruit a single anointed heir, the maintainer builds an Open Documentation Package: a written architecture overview, a step-by-step release runbook (including key custody and rotation), an annotated map of the fragile subsystems, recorded design-decision records explaining why odd choices exist, and a reproducible build that runs from a clean machine.
The test of the package is deliberately impersonal: a contributor who has never done a release follows the runbook cold and cuts a valid release candidate without messaging the maintainer once. Where they get stuck, the docs get fixed. The point is not that this contributor is now the successor — it is that the knowledge now lives in the open, so any number of contributors could step in, and no single person can hold the project hostage.
How it works¶
- Externalize the tacit into artifacts. The work is to surface what the incumbent does automatically — the unwritten steps, the "everyone knows" gotchas, the reasons behind odd choices — and commit it to durable, findable documents rather than memory or chat history.
- Make it open and portable. Artifacts live where the whole organization or community can reach them, in formats not tied to one person's tools or accounts, so access itself is not a chokepoint.
- Test by a cold read, not by the author. The package is validated when someone who did not write it can act from it unaided; author walk-throughs hide exactly the gaps that matter.
- Sever the mapped knowledge pathway. Each documented artifact is aimed at a specific pathway of dependence identified as "only they know this," converting a sole-carrier route into an open one.
Tuning parameters¶
- Coverage breadth — happy-path only vs. full failure-mode and rationale documentation. Documenting the why and the edge cases is what actually breaks dependence but is the most effort and the fastest to rot.
- Externalization medium — wiki vs. in-repo docs vs. recorded walkthroughs. In-artifact docs stay closer to the truth and age with the work; separate stores are tidier but drift out of date.
- Cold-read bar — how unfamiliar the test reader must be. A true stranger exposes the most gaps but is expensive to arrange; a semi-familiar reader is cheaper and more forgiving.
- Freshness discipline — how tightly docs are bound to change (e.g., updated as part of the work vs. periodically). Tight coupling prevents rot but taxes every change; loose coupling is cheap until the docs quietly become fiction.
When it helps, and when it misleads¶
Its strength is that it removes dependence at the root: unlike transferring competence into one chosen successor (which can simply relocate the bottleneck), open artifacts make the function available to many, and they persist after any individual leaves. They are also the substrate every other exit mechanism leans on — you cannot train, second-source, or rotate against knowledge that has never been written down.
Its failure mode is documentation that exists but does not work: voluminous, out-of-date, or happy-path-only pages that pass a glance and fail a real incident, giving false confidence that the dependency is gone. Worse, a captured incumbent can produce impressive-looking docs that omit precisely the load-bearing tacit steps, preserving indispensability behind a facade of openness. The guard is the impersonal cold-read test under realistic conditions, and binding documentation freshness to the work itself so the package cannot silently decay into fiction.
How it implements the components¶
capability_and_knowledge_transfer_plan— it is the knowledge-transfer artifact: the externalized runbooks, rationale, and maps that move know-how out of one head.substitute_or_second_source_path— by making the knowledge open and portable, it enables any qualified party to become an alternative carrier, creating a de-facto second source.dependency_pathway_map— it targets and documents the specific "only they know this" pathways, converting each sole-carrier route into an open one.
It does not verify that a named successor can perform the tasks unaided, nor gate and bound the handoff itself (handoff_and_sunset_trigger, residual_support_boundary) — that's Capability Handoff Checklist; this package makes the knowledge open and carrier-independent, rather than certifying particular people against it.
Related¶
- Instantiates: Dependency-Capture Exit Design — supplies the externalized-knowledge substrate the rest of the exit builds on.
- Sibling mechanisms: Capability Handoff Checklist · Dependency-Reduction Scorecard · Exit-Readiness Review · Fixed-Term or Sunset Mandate · Independent Needs Assessment · Outcome-Based Contract · Post-Exit Dependency Audit · Rotation or Term Limit · Second-Source Review
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Open Documentation Package operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it externalizes the tacit knowledge a role depends on into open, portable artifacts so the function no longer lives in one person's head.
Independent corroboration: The frozen evidence defines Open Documentation Package as 'Externalizes the tacit knowledge a role depends on into open, portable artifacts so the function no longer lives in one person's head', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Open Documentation Package is most directly rooted in library and information science's traditions of classification, metadata, retrieval, preservation, and archival stewardship. The lineage fits its defining practice: Externalizes the tacit knowledge a role depends on into open, portable artifacts so the function no longer lives in one person's head.
Related originating lineages:
- Computer Science & Software Engineering — Open Documentation Package also draws materially on computer science and software engineering's formal and practical treatment of computation, interfaces, data, and reliable systems, which shaped this mechanism rather than merely adopting it as an application.
- Organizational & Management Science — Open Documentation Package also draws materially on organizational and management science's practice of coordinating people, authority, strategy, knowledge, and work, which shaped this mechanism rather than merely adopting it as an application.
Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of library information science. SKOS Simple Knowledge Organization System Reference — W3C documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis describes the historical relationship among lineages.
Attribution caveat: The exact package is a synthesized artifact rather than a historically standardized method.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
The cold-read test is what separates a genuine Open Documentation Package from documentation theater. Documentation that only its author can follow has not externalized anything; it has just written down the shape of the dependency. Insisting that a stranger act from it unaided — and treating every place they get stuck as a defect in the package rather than in the reader — is the single discipline that keeps this mechanism honest.
[n1] Bus factor — the number of people who would have to be lost (proverbially, hit by a bus) before a project stalls for lack of irreplaceable knowledge. A bus factor of one is the paradigmatic knowledge-capture risk this package is built to raise. ↩