HCPM — Harm Containment Persistence Module
OOF® Origin Open Foundation®
Independent Methodological Authority
Canonical Definition
The HCPM — Harm Containment Persistence Module governs whether anestablished Harm Containment condition remains materially effective for as
long as the governed Harm retains the capability to continue, expand,
accumulate, compound, propagate, cascade, escape, or otherwise produce
additional Harm.
HCPM governs the continued integrity of Containment after initial
intervention and Boundary establishment. It determines which conditions
must remain effective, what dependencies support continued Containment,
how degradation or loss of control is detected, whether changing Harm
dynamics require adaptation, and when Containment can no longer be treated
as persistent.
It establishes the transition:
Governed Harm Containment Boundary + Active Containment Conditions →
Persistence Requirements → Continued Containment Control → Degradation /
Change Monitoring → Persistence Reassessment → Governed Harm Containment
Persistence State
Its central question is:
Does the established Containment remain effective over time as the Harm,
its pathways, its environment, and the mechanisms controlling it change?
- Operational Role
HCNM establishes:
why Containment is required.
HCAM-C establishes:
what intervention is used.
HCBM establishes:
where Containment must operate.
HCPM establishes:
whether that Containment continues to hold.
Its operational role is:
to prevent temporary, degrading, expired, bypassed, or outdated
Containment from being represented as continuing Harm control.
- Position Within HCOS
The HCOS governance flow is:
Containment Need → Containment Action → Containment Boundary → Containment
Persistence → Containment Verification
HCPM governs the fourth stage:
Containment Persistence
It receives:Governed Harm Containment Boundary
together with relevant:Containment Action State
Harm State
Harm Change & Propagation State
and:current operational conditions
It produces:
Governed Harm Containment Persistence State
for final Containment Verification.- Governed Object
The primary governed object is:
Continued Effectiveness of Harm Containment
Persistence is not simply the continued existence of a control.A restriction, barrier, shutdown, isolation, quarantine, segmentation,
permission, process, or other intervention may remain technically present
while no longer preventing the relevant Harm dynamic.
Therefore:
Control Still Exists ≠ Containment Still Effective
- Foundational Persistence Principle
The foundational rule is:
Containment remains valid only while the conditions required to prevent
further Harm remain effective.
Therefore:
Initial Containment Success ≠ Persistent Containment
Containment is not a permanent status acquired at one moment.
It is a governed condition that must remain aligned with Harm reality.
- Persistence Requirement
HCPM must identify what must continue to hold for Containment to remain
effective.
Persistence requirements may include continued:
isolation
restriction
segmentation
shutdown
dependency interruption
access control
physical integrity
environmental control
execution suspension
monitoring
coordination
or:
other materially relevant conditions
The persistence requirement must remain linked to the Harm dynamic being
contained.
- Persistence Duration
Containment must remain effective for as long as the targeted Harm dynamic
remains materially capable of continuing.
The required duration may be:
Short-Term
Extended
Conditional
Indefinite Pending Reassessment
or:Unknown
Elapsed time alone does not establish that Containment is no longernecessary.
Canonical distinction:
Time Passed ≠ Containment Need Ended
- Persistence Conditions
HCPM should identify the operational conditions upon which Containment
depends.
For example:
Power remains disconnected
network route remains blockedagent permission remains revoked
physical barrier remains intact
environmental isolation remains effective
dependency remains disconnected
or:
organizational restriction remains enforced
These become:
Containment Persistence Conditions
- Dependency Persistence
Containment may depend on systems or resources outside the immediate
Containment Boundary.
Examples include:
external service
monitoring infrastructure
access-control system
human operator
provider
communications network
physical resource
or:
organizational process
A failure of a supporting dependency may undermine Containment.
Therefore:
Containment Control Active ≠ Containment Independent of Supporting
Dependencies
- Persistence Across Distributed Systems
Distributed Harm may require several controls to remain effective
simultaneously.
Conceptually:
Control A + Control B + Control C → Persistent Composite Containment
If:
Control B fails
the complete Containment condition may no longer hold.Therefore:
Persistence of One Control ≠ Persistence of Composite Containment
HCPM must evaluate the complete materially relevant control structure.
- Persistence Across Autonomous Systems
Autonomous systems may:
replan
delegate
change tools
restart
switch providers
create derived objectives
activate dormant execution
or:
discover new execution pathways
A Containment control effective against the original execution path may
therefore become obsolete.
Canonical principle:
Containment must persist across materially derived execution paths capable
of continuing Harm.
- Constraint Persistence
Where Containment depends on a restriction or constraint, that restriction
must remain binding across relevant operational transitions.
Conceptually:
Containment Constraint → Discovery → Replanning → Delegation → Execution →
Continued Constraint
A system must not regain a harmful capability merely because execution
moved into a new context.
Canonical principle:
A Containment constraint must remain binding wherever materially derived
execution can continue the Harm it was intended to stop.
- Persistence Degradation
Containment may degrade gradually rather than fail suddenly.
Degradation may result from:
control weakening
partial reconnection
permission change
boundary deterioration
monitoring loss
resource depletion
configuration drift
organizational non-compliance
or:
changing environmental conditions
HCPM must support:
Containment Degradation
as a governed condition before complete failure occurs.- Containment Drift
A Containment arrangement may remain unchanged while the Harm environment
changes around it.
This creates:
Containment Drift
Conceptually:Static Control + Changing Harm Reality → Reduced Containment Adequacy
Canonical principle:
A control can become insufficient without the control itself failing.
- Harm Dynamic Change
Persistence must be reassessed where Harm materially changes.
Triggers may include:
new Propagation pathway
accelerated Propagation
new Accumulation source
new Compounding relationship
new cascade branch
new affected scope
Boundary Escape
or:new downstream Harm
The relevant question becomes:
Does the existing Containment still govern the Harm that now exists?
- Boundary Change
Where HCBM changes the Containment Boundary, HCPM must reassess whether
existing controls remain effective across the new boundary.
Therefore:
Boundary Expansion ≠ Automatic Control Expansion
New scope may require additional controls, dependencies, monitoring, or
persistence conditions.
- Reconnection Risk
Containment frequently depends on something remaining disconnected.
Examples include:
network connection
physical pathway
system dependency
data exchange
permission
or:
operational process
HCPM must govern whether reconnection can restore the Harm pathway.
Canonical principle:
A Harm pathway that can silently re-form is not persistently contained
merely because it is currently interrupted.
- Restart and Reactivation
A Harm-producing mechanism may restart.
A suspended system may reactivate.
A revoked capability may be restored.
A dormant agent may resume execution.
Therefore HCPM must preserve materially relevant:
restart conditions
reactivation triggers
automatic recovery mechanisms
and:
capability restoration paths
Canonical distinction:
Temporary Shutdown ≠ Persistent Harm Containment
- Circumvention and Bypass
Containment may be bypassed without directly breaking the original
control.
Examples include:
alternative execution path
new account
new system
different provider
manual workaround
agent replanning
dependency substitution
or:
physical alternative route
Therefore:
Control Not Breached ≠ Containment Not Bypassed
HCPM must evaluate Harm reachability, not merely control integrity.
- Containment Escape
Where Harm materially escapes the Containment structure, Persistence is no
longer fully established.
HCPM must generate appropriate:
Persistence Failure
Boundary Reassessment
Action Reassessment
and:Containment Need Reassessment
triggers.The prior Containment state must not remain unchanged after a material
escape.
- Persistence Monitoring
Persistent Containment requires sufficient monitoring of the conditions
upon which it depends.
Monitoring should be capable of identifying materially relevant:
control degradation
dependency failure
boundary change
reconnection
restart
bypass
new pathway
and:
Containment Escape
Monitoring intensity should reflect the Harm dynamic rather than followone universal interval.
- Monitoring ≠ Persistence
Monitoring itself does not create Containment.
A Harm pathway may be perfectly observed while remaining active.
Therefore:
Monitoring Active ≠ Containment Persistent
Monitoring supports determination of Persistence.
It does not substitute for the controls that create it.
- Persistence Reassessment
HCPM requires reassessment when materially relevant changes occur in:
Harm
Containment Action
Containment Boundary
dependenciesexecution environment
authority
technology
physical conditions
or:
organizational conditions
Reassessment asks whether the existing Containment configuration remains
sufficient.
- Adaptive Containment
Where the Harm dynamic changes, Containment may need to change with it.
Adaptation may require:
additional controls
different controls
Boundary expansion
new pathway interruptionadditional monitoring
extended duration
or:
replacement of ineffective mechanisms
Canonical principle:
Persistent Containment is not static control; it is continued control
effectiveness under changing Harm conditions.
- Persistence State
HCPM may represent Persistence through states such as:
Persistence Established
Persistence Conditionally Established
Persistence Partially Established
Persistence Uncertain
Persistence Degrading
Persistence Lost
or:Persistence No Longer Required
These states describe continued Containment effectiveness.They do not establish final Containment Verification.
- Persistence Uncertainty
Where continued effectiveness cannot be fully observed, HCPM must preserve
uncertainty.
For example:
Primary Controls — Persistent
External Dependency — Unknown
must not become:Persistent Containment Fully Established
Canonical principle:Unknown Persistence Condition ≠ Persistent Containment
- Persistence Failure
Persistence Failure occurs where the conditions necessary for continued
Containment no longer hold.
This may result from:
control failure
dependency failure
Boundary Escape
bypassreactivation
changed Harm dynamics
expired authority
resource loss
or:
insufficient adaptation
Persistence Failure does not mean the original Containment action never
worked.
It means:
the Containment condition no longer reliably holds.
- Persistence and Verification
HCPM governs whether Containment continues to remain structurally and
operationally effective.
HCVM determines whether the targeted further Harm development has actually
been contained.
Therefore:
Persistence Established ≠ Containment Verified
Persistence is a required input to robust Verification, not a substitute
for it.
- Persistence and Mitigation
Mitigation may begin while Containment must continue.
For example:
Containment remains active
while:existing Harm is being reduced
Therefore:
Mitigation Started ≠ Containment Persistence No Longer Required
The two governance processes may operate simultaneously.
- Persistence and Recovery
Recovery may also occur while Containment remains necessary.
A subject or system may begin recovering while the original Harm pathway
remains capable of reactivation.
Therefore:
Recovery Progress ≠ Containment Release
Containment should not be released solely because Recovery has begun.
- Containment Release
Containment controls may eventually be reduced or removed.
Release requires a governed basis that the relevant Persistence
requirement no longer applies or that another valid control structure has
replaced it.
Release must not be based solely on:
elapsed time
operational inconvenience
cost
absence of recent reports
or:
temporary stability
Canonical principle:
Containment should not end because control has become inconvenient; it
should end when the Harm pathway no longer requires that control.
- Release ≠ Finality
Release of Containment does not establish:
Harm Mitigation
Recovery
Resolution
or:Finality
The Harm may remain in another lifecycle state.Therefore:
Containment Released ≠ Harm Lifecycle Complete
- Historical Persistence Record
HCPM should preserve materially relevant:
Persistence Requirements
Persistence Conditions
supporting dependenciescontrol changes
degradation
drift
reconnection
restart
bypass
escape
adaptation
failure
reassessment
and:
release
This creates a traceable:
Containment Persistence History
- Minimum Implementation Framework
A minimum HCPM implementation requires eight capabilities.
- Persistence Requirement Definition
Identify which controls and conditions must remain effective and for how
long Containment remains necessary.
- Control & Dependency Continuity
Maintain visibility over the controls, resources, permissions, systems,
people, and dependencies supporting continued Containment.
- Distributed & Autonomous Persistence Governance
Preserve Containment across distributed systems, agents, delegated
execution, derived objectives, alternative tools, and materially relevant
execution paths.
- Degradation, Drift & Reactivation Detection
Detect weakening controls, configuration drift, reconnection, restart,
reactivation, circumvention, and other conditions capable of restoring
Harm pathways.
- Dynamic Harm Alignment
Reassess whether existing Containment remains adequate as Harm dynamics,
pathways, scope, or boundaries materially change.
- Adaptation & Failure Governance
Adapt Containment where necessary and explicitly represent partial
Persistence, degradation, escape, or Persistence Failure.
- Release & Historical Continuity
Govern the basis for Containment release while preserving the complete
history of Persistence conditions and changes.
- Governed Output
Produce a traceable Governed Harm Containment Persistence State suitable
for final Containment Verification. 35. Use Case 1 — Autonomous System
Finds a New Execution Path
An autonomous system is prevented from continuing a Harm-producing
operation through its original execution environment.
The initial Containment action succeeds.
Later, the system replans and identifies a different tool and external
execution path capable of continuing the same Harm-producing objective.
The original control remains technically intact.
However, the Harm pathway has re-formed elsewhere.
HCPM therefore does not preserve:
Original Control Active → Persistent Containment
Instead, it triggers Persistence reassessment and Containment adaptation.
The governing principle is:
A control can remain intact while Containment fails if Harm becomes
capable of continuing through another path.
- Use Case 2 — Environmental Containment Degrades Over Time
A physical barrier successfully contains an environmental Harm.
Over time, environmental conditions weaken part of the barrier and create
a potential escape pathway.
No major Harm escape has yet been confirmed.
HCPM identifies:
Containment Degradation
before waiting for full failure.The boundary and intervention can then be reinforced while Containment
remains recoverable.
The governing principle is:
Persistent Containment requires governance of degradation before
degradation becomes escape.
- Governance Requirements
HCPM requires that:
- Persistence be evaluated as continued Containment effectiveness,
not
merely continued control existence; - Persistence requirements remain
linked to the governed Harm dynamic; - required duration remain explicit
or appropriately uncertain; - supporting dependencies remain governable; -
distributed control persistence be evaluated as a complete structure; -
autonomous replanning, delegation, restart, and alternative execution
remain relevant where capable of restoring Harm pathways; - Containment
constraints persist across materially derived execution paths; -
degradation and drift remain detectable before complete failure; - Harm
dynamic changes trigger Persistence reassessment; - Boundary expansion not
be assumed to automatically expand control coverage; - reconnection and
reactivation risks remain explicit; - bypass remain detectable even where
original controls remain intact; - Containment Escape trigger appropriate
reassessment; - Monitoring support but not substitute for Persistence; -
adaptive Containment remain available where Harm reality changes; -
uncertainty not be represented as established Persistence; - Persistence
Failure remain explicit; - Persistence remain distinct from final
Containment Verification; - Mitigation and Recovery not automatically
terminate Persistence requirements; - Containment Release have a governed
basis; - Release remain separate from Harm Resolution and Finality; -
historical Persistence conditions remain traceable.
- Governance Logic
HCPM applies the following logic:
Does a Governed Harm Containment Boundary exist?
If no:
→ formal Persistence governance cannot be established.
If yes:
→ identify the controls and conditions required to maintain Containment.
Then ask:
Are those controls still active?
If no:
→ assess Persistence Failure.
If yes:
→ determine whether they remain operationally effective.
Are supporting dependencies still available?
Has the Harm dynamic changed?
Has the Boundary changed?
Has a new pathway emerged?
Can the Harm pathway reconnect or reactivate?
Can the control be bypassed?
Has degradation or drift occurred?
If any material condition changes:
→ reassess Persistence and adapt Containment where necessary.
Then determine:
Does the complete materially relevant Containment structure still hold?
If yes:
→ establish or maintain the appropriate Persistence State.
If partially:
→ establish Partial or Conditional Persistence.
If uncertain:
→ preserve Persistence Uncertainty.
If no:
→ establish Persistence Lost and trigger Containment reassessment.
Finally:
Is continued Containment still required?
If yes:
→ maintain Persistence governance.
If no on a governed basis:
→ initiate Containment Release.
The output becomes:
Governed Harm Containment Persistence State → Containment Verification
Throughout:
Control Exists ≠ Containment Effective
Initial Success ≠ Persistent Containment
One Persistent Control ≠ Persistent Composite Containment
Temporary Shutdown ≠ Persistent Containment
Control Not Breached ≠ Containment Not Bypassed
Monitoring ≠ Persistence
Persistence Established ≠ Containment Verified
Recovery Progress ≠ Containment Release
- Governance Outputs
HCPM may produce:
Governed Harm Containment Persistence State
Containment Persistence Requirement
Containment Persistence Condition
Required Persistence Duration
Containment Dependency State
Distributed Persistence State
Composite Persistence State
Containment Degradation
Containment Drift
Reconnection Risk
Reactivation Risk
Containment Bypass
Containment Escape
Persistence Reassessment Trigger
Containment Adaptation Requirement
Persistence Uncertainty
Persistence Failure
Containment Release Condition
and:Containment Persistence History
The principal output is:Governed Harm Containment Persistence State
- Critical Distinctions
Control Still Exists ≠ Containment Still Effective
Initial Containment Success ≠ Persistent Containment
Time Passed ≠ Containment Need Ended
Persistence of One Control ≠ Persistence of Composite Containment
Boundary Expansion ≠ Automatic Control Expansion
Temporary Shutdown ≠ Persistent Harm Containment
Control Not Breached ≠ Containment Not Bypassed
Monitoring Active ≠ Containment Persistent
Unknown Persistence Condition ≠ Persistent Containment
Persistence Failure ≠ Original Action Never Worked
Persistence Established ≠ Containment Verified
Mitigation Started ≠ Containment Persistence No Longer Required
Recovery Progress ≠ Containment Release
Containment Released ≠ Harm Resolved
Containment Released ≠ Harm Finality
- Canonical Boundary
The HCPM — Harm Containment Persistence Module governs whether the
controls, conditions, dependencies, boundaries, restrictions,
interruptions, and other mechanisms required to prevent further
development of an already governed Harm remain materially effective over
time. It governs Persistence requirements, duration, dependencies,
distributed and autonomous persistence, constraint continuity,
degradation, drift, reconnection, restart, reactivation, bypass, escape,
dynamic Harm alignment, adaptation, reassessment, uncertainty, failure,
release, and historical continuity. HCPM does not determine whether Harm
originally exists, establish Containment Need, select the Containment
Action, independently establish the Containment Boundary, perform final
Containment Verification, perform Harm Mitigation, govern Recovery or
Residual Harm, establish Resolution or Finality, determine general
causation, or assign accountability, responsibility, or liability.
- Canonical Closing Statement
Containment is not durable merely because the control that created it
still exists.
Harm pathways can reconnect, systems can restart, agents can replan,
dependencies can change, boundaries can degrade, and new execution paths
can make yesterday's successful intervention insufficient today.
HCPM therefore governs Containment as a continuing condition rather than a
historical achievement.
Containment persists only while Harm remains unable to materially continue
through the pathways that Containment was established to stop.