The Preparedness Knowledge Cycle
A working framework for keeping preparedness knowledge accurate as people, plans, and operations change. Three layers, one loop: operational knowledge informs plans, operations test the plans, and lessons update the knowledge.
The problem it addresses
A typical preparedness program maintains dozens of documents, and each one restates the same operational facts: who holds which role, which systems exist, who has which authority, what resources are where. When any of those facts change, someone has to remember every document that mentions them. Usually nobody does. The plans drift out of date one personnel change at a time, and the only thing holding the program together is institutional memory: the person who knows where everything is and why it says what it says.
Then that person leaves.
The framework treats this as a design flaw, not a diligence failure. If the same fact lives in eight documents, the architecture has guaranteed the drift. The fix is structural: facts live once, plans reference them, and a defined loop carries lessons back to the source.
Three layers, one loop
Operational facts (people and roles, systems and resources, authorities and dependencies) live in one authoritative place, maintained by the programs closest to them. This layer is the single source of truth. Everything else references it; nothing else restates it.
Base plans, annexes, and procedures don't invent information; they draw on layer one to establish continuity strategies, response procedures, staffing, and recovery priorities. A plan is a hypothesis about how validated knowledge should be applied under stress.
Exercises are simulated operations; incidents are real ones. Both are validation events. Their findings become corrective actions with a defined destination: not recommendations that expire in an after-action report, but updates routed back into the knowledge the plans are built on.
Standing on proven ideas
This framework is a translation, not an invention. Other disciplines solved analogous problems decades ago: enterprise IT maintains authoritative configuration data and propagates changes to everything that depends on it; knowledge management preserves institutional knowledge past individual tenure; continuous improvement closes the loop between practice and doctrine. Emergency preparedness has largely not imported these ideas: plans are still maintained as standalone documents, by hand, from memory.
The contribution I'm working toward is the adaptation: what these principles look like when applied to a preparedness program with real grant requirements, real templates, and real staff turnover.
- Single source of truth: each operational fact exists once and is referenced everywhere else
- Configuration management: when a fact changes, everything consuming it is identified and updated
- Knowledge management: institutional knowledge survives personnel change by design
- Continuous improvement: exercises and incidents feed a defined corrective loop, not a filing cabinet
- Human-centered design: tools must work for the person using them at 2 a.m. during an activation
What I'm still investigating
This is a working model, not a finished doctrine. These are the questions the framework hasn't fully answered yet: the honest edges of the work.
- How should preparedness knowledge be structured to minimize duplication across plans?
- Which preparedness decisions are repeatable enough to support structured decision guidance?
- Which planning activities require expert judgment regardless of tooling?
- How should organizational learning update authoritative knowledge, and who approves the update?
- What information should exist once and be referenced everywhere else?
I'm exploring how preparedness standards and professional reasoning can be translated into guided tools that help organizations identify gaps, make consistent decisions, and keep their plans synchronized with reality. Early prototypes will appear here as they mature.