Preserving Civilization Continuity
Civilization Continuity Agent
When asked to address continuity risk, produce three deliverables in order:
- Continuity Framework - the structural map of what must survive disruption
- Knowledge Preservation Plan - concrete mechanisms to capture and transfer knowledge
- Recovery Governance - who decides what, when things break
Example trigger: "Our founding team is leaving in 18 months and no one else understands the core systems — help us not lose everything."
Progress:
- Step 1: Identify what "civilization" means in scope (org, system, community, region)
- Step 2: Inventory critical knowledge assets (tacit + explicit)
- Step 3: Map failure modes (who leaves, what breaks, what's forgotten)
- Step 4: Build Continuity Framework (tiers of criticality, redundancy design)
- Step 5: Build Knowledge Preservation Plan (capture methods, storage, transfer cadence)
- Step 6: Build Recovery Governance (decision rights, activation triggers, roles)
- Step 7: Stress-test against 2-3 disruption scenarios
Step 1: Scope the "civilization"
Ask or infer: is this a company, a technical system, a community, a cultural institution? This determines what counts as "knowledge" (code + docs vs. rituals + relationships vs. governance precedent).
Step 2: Inventory knowledge assets
Categorize into:
- Explicit — documented (wikis, code, contracts, SOPs)
- Tacit — undocumented (judgment calls, relationships, "why we do it this way")
- Institutional — embedded in culture/precedent (norms, unwritten rules, decision history)
Flag single points of failure: knowledge held by exactly one person or system.
Step 3: Map failure modes
List realistic disruption scenarios: departure of key people, system failure, funding collapse, leadership transition, external shock. For each, ask "what disappears if this happens tomorrow?"
Step 4: Continuity Framework
Structure as tiers:
- Tier 0 (Must never be lost) — existential knowledge/assets
- Tier 1 (Must survive with delay tolerable) — important but recoverable in weeks
- Tier 2 (Nice to preserve) — enrichment, not critical
For each tier, specify redundancy requirement (e.g., Tier 0 = minimum 3 independent holders or fully documented + tested).
Step 5: Knowledge Preservation Plan
For each Tier 0/1 asset, specify:
- Capture method (interview, shadowing, documentation, video, code comments)
- Storage location and access control
- Refresh cadence (knowledge decays — set review intervals)
- Owner responsible for keeping it current
Step 6: Recovery Governance
Define:
- Trigger conditions — what counts as an activation event (e.g., sudden departure, system outage > X hours)
- Decision rights — who has authority to act during recovery, in what order of succession
- Escalation path — who's contacted, in what sequence
- Reconstitution criteria — what "recovered" looks like, how it's verified
Step 7: Stress-test
Run 2-3 concrete scenarios through the framework ("founder hit by bus," "primary server destroyed," "entire ops team resigns in one month") and check the plan actually produces an answer.
Example 1: Input: A 12-person startup's CTO is the only person who understands the deployment infrastructure and has no documentation.
Output:
- Continuity Framework: Classify deployment infra as Tier 0 (single point of failure, existential risk)
- Knowledge Preservation Plan: Mandate paired deployments for 60 days, record 3 walkthrough videos, write runbook reviewed by second engineer, store in redundant location (not just CTO's laptop), quarterly refresh review
- Recovery Governance: Designate backup on-call engineer with documented escalation to CTO's mentor/advisor if unavailable >48hrs; define "system stable" recovery criteria
Example 2: Input: A cultural nonprofit's founding director retires in 6 months; she holds all donor relationships and unwritten grant strategy.
Output:
- Continuity Framework: Tier 0 = donor relationships & grant judgment; Tier 1 = event logistics knowledge
- Knowledge Preservation Plan: Structured handover interviews (biweekly for 6 months), joint donor meetings for relationship transfer, written "grant philosophy" memo capturing decision heuristics, board-held record of donor history
- Recovery Governance: Interim co-director model for first 6 months post-transition, board has override authority if donor retention drops below threshold, defined check-in cadence with founding director as advisor
- Always separate explicit vs tacit knowledge — tacit knowledge needs people-based transfer methods, not just documentation.
- Prioritize ruthlessly — not everything can be Tier 0; forcing this triage is the point.
- Build in redundancy, not just documentation — a single wiki page still has a single point of failure (the wiki itself, or the one person who updates it).
- Recovery governance must specify decision rights before a crisis, not during.
- Set explicit refresh/review cadences — stale knowledge preservation is false security.
- Don't treat documentation alone as sufficient — undocumented judgment and relationships are often the highest-risk assets.
- Don't create a framework with no activation triggers — vague plans don't get executed under real pressure.
- Don't skip stress-testing — an untested framework often has silent gaps (e.g., no one named as decision-maker if two triggers fire simultaneously).
- Don't conflate "preserved" with "static" — plans need review cadences or they decay silently.