HMAM — Harm Mitigation Action Module
OOF® Origin Open Foundation®
Independent Methodological Authority
Canonical Definition
The HMAM — Harm Mitigation Action Module governs how an established HarmMitigation Need is translated into a defined, targeted, proportionate,
authorized, executable, timely, and traceable intervention intended to
materially reduce existing governed Harm or its consequences.
HMAM determines what Mitigation action is appropriate for the governed
Mitigation Objective, whether that action can materially reach the Harm
condition it is intended to change, what dependencies and conditions are
required for execution, how multiple actions must be coordinated, and how
intervention-induced Harm or materially relevant trade-offs remain
visible.
It establishes the transition:
Governed Harm Mitigation Need → Mitigation Objective → Action Selection →
Action Reachability → Action Authorization → Action Execution → Governed
Harm Mitigation Action
Its central question is:
What intervention can materially reach and reduce the existing Harm
condition identified by the Governed Harm Mitigation Need?
- Operational Role
The operational role of HMAM is:
to translate an established Harm reduction requirement into an executable
intervention without confusing selection or execution of that intervention
with actual Harm reduction.
HMNM establishes:
what Harm should materially improve.
HMAM establishes:
what action will attempt to produce that improvement.
HMAM does not establish that the improvement actually occurred.
Therefore:
Mitigation Action Executed ≠ Harm Mitigated
- Position Within HMS
The HMS governance flow is:
Mitigation Need → Mitigation Action → Mitigation Effect → Mitigation
Outcome → Mitigation Verification
HMAM governs the second stage:
Mitigation Action
It receives:Governed Harm Mitigation Need
including relevant:Mitigation Target
Mitigation Baseline
Mitigation Objective
Mitigation Priority
Mitigation Urgency
Mitigation Window
and:Harm Reducibility State
It produces:Governed Harm Mitigation Action
for Mitigation Effect governance.- Governed Object
The primary governed object is:
Intervention Intended to Materially Reduce Existing Harm or Its
Consequences
HMAM governs the intervention as a Harm Mitigation object.
It does not govern every operational detail of the underlying system.
The action remains connected to:
the Harm
the Mitigation Need
the Mitigation Target
and:
the Mitigation Objective
- Foundational Action Principle
The foundational rule is:
A Mitigation action is legitimate only when it is materially connected to
the Harm condition it is intended to reduce.
Therefore:
Available Intervention ≠ Appropriate Mitigation Action
and:
Operational Activity ≠ Harm Mitigation Action by Default
The existence of an available intervention does not establish its
relevance.
- Need-to-Action Traceability
Every material Mitigation Action should remain traceable through:
Governed Harm → Mitigation Need → Mitigation Target → Mitigation Objective
→ Mitigation Action
This prevents action selection from becoming detached from the Harm
condition that justified intervention.
Canonical principle:
Every Mitigation Action must answer an established Mitigation Need.
- Action Selection
HMAM governs selection of an action capable of addressing the Mitigation
Objective.
Selection should consider materially relevant:
expected Harm relevance
reachability
timing
operational feasibility
dependencies
scope
reversibility
known limitations
and:
potential additional Harm
Selection should not be based merely on familiarity, availability,
convenience, or institutional habit.
- Action Reachability
A Mitigation Action must be capable of materially reaching the Harm
condition it is intended to reduce.
For example, an intervention affecting:
System A
does not establish Mitigation relevance if the existing Harm is nowmaterially located in:
System B
or:the affected subject rather than the originating mechanism.
Canonical principle:
An action that cannot reach the Harm condition cannot materially mitigate
it.
Therefore:
Action Availability ≠ Harm Reachability
- Mechanism Reach ≠ Harm Reach
An action may successfully reach the mechanism that produced Harm without
reaching the Harm already produced.
For example:
repairing the originating system
may prevent future malfunction while doing nothing to reduce:
existing physical damage
existing digital corruption
existing financial loss
or:
existing environmental consequence
Therefore:
Mechanism Intervention ≠ Existing Harm Mitigation by Default
This distinction preserves the boundary between Containment and
Mitigation.
- Mitigation Target Alignment
The action must remain aligned with the specific Mitigation Target.
If the target is:
functional impairment
an action addressing only:
the originating technical defect
may not be sufficient.
If the target is:
persistent downstream consequence
an action addressing only:
the immediate Harm manifestation
may not be sufficient.
HMAM therefore requires:
Action ↔ Target Alignment
- Action Scope
HMAM determines the operational scope within which the action must
operate.
Scope may concern:
affected subjects
Harm components
systemslocations
domains
organizations
infrastructure
or:
environmental areas
Action scope must be sufficient for the Mitigation Objective.
Canonical distinction:
Action Scope ≠ Harm Boundary by Default
- Proportionality
Mitigation Action should remain proportionate to:
the Harm being reduced
the expected benefit
the affected scope
the urgency
the intervention burden
and:
the possibility of intervention-induced Harm
An intervention should not create unjustified additional Harm merely
because it can reduce the original Harm.
Proportionality does not mean minimum action.
It means:
sufficient and justified action relative to the governed Harm condition.
- Action Timing
A technically appropriate action may become inadequate if applied too
late.
HMAM must therefore preserve:
Mitigation Window
urgencyexecution timing
and:
material consequences of delay
where relevant.
Canonical principle:
Correct Action at the Wrong Time May Be an Ineffective Mitigation Action
- Action Authorization
Capability to perform a Mitigation Action does not automatically establish
authority to perform it.
HMAM should preserve materially relevant authorization requirements.
Therefore:
Capability ≠ Authority
Where emergency conditions permit accelerated intervention, the basis for
that action should remain governable and traceable.
HMAM does not replace GOA™ authority governance.
- Action Executability
An action must be operationally executable under the actual conditions in
which Mitigation must occur.
Executability may depend on:
resources
access
technical capability
human capability
infrastructure
permissions
coordination
time
or:
external dependencies
An action that exists only conceptually cannot be treated as executed
Mitigation.
- Action Dependencies
Mitigation Action may depend on multiple supporting conditions.
Conceptually:
Action → Dependency₁ + Dependency₂ + Dependency₃ → Execution
A missing dependency may:
delay
reduce
prevent
or:
alter
the intervention.
Dependencies must therefore remain visible where materially relevant.
- Action Sequencing
Multiple Mitigation Actions may need to occur in a defined order.
For example:
Action A → Action B → Action C
may produce a different result from:
Action C → Action A → Action B
Therefore:
Correct Actions in Wrong Sequence ≠ Correct Mitigation Execution
HMAM should preserve sequencing where it materially affects Harm
reduction.
- Coordinated Mitigation Action
Complex Harm may require coordinated actions across:
teams
organizations
systems
agents
providers
locations
or:
domains
HMAM must preserve the complete Mitigation Objective across distributed
execution.
Operational fragmentation must not fragment the governed Harm reduction
objective.
- Composite Mitigation Action
A Mitigation Objective may require several actions whose combined effect
is necessary.
Conceptually:
Action₁ + Action₂ + Action₃ → Composite Mitigation Action
Success of one component does not establish complete execution of the
composite intervention.
Therefore:
Component Action Completed ≠ Composite Mitigation Action Completed
- Distributed and Autonomous Execution
Mitigation may be performed through autonomous or distributed systems.
HMAM must preserve the Mitigation Objective across:
delegation
task decomposition
agent execution
sub-agent execution
tool changes
provider changes
and:
derived operational tasks
Canonical principle:
A Mitigation Objective does not become ungoverned by being divided into
smaller actions.
The objective must remain traceable through execution.
- Action Substitution
An originally selected action may become unavailable or inappropriate.
HMAM may permit replacement where the substitute remains aligned with the
same governed Mitigation Objective.
Therefore:
Action Substitution ≠ Mitigation Objective Change by Default
If the substitute materially changes what Harm is being targeted, the
Mitigation Need or Objective may require reassessment.
- Action Adaptation
Actions may need adaptation during execution because:
Harm conditions change
dependencies failnew information emerges
the affected scope changes
execution becomes infeasible
or:
initial intervention proves insufficient
Adaptation must remain traceable to the governed Mitigation Objective.
Canonical principle:
Mitigation may adapt operationally without losing methodological
continuity.
- Intervention-Induced Harm
A Mitigation Action may itself create Harm.
HMAM must therefore preserve materially relevant:
known intervention risks
new exposure
secondary Harm
redistributed Harm
or:
new affected subjects
Canonical principle:
Preventing or reducing one Harm does not make Harm created by the
intervention methodologically invisible.
New Harm must enter the appropriate HAGA™ lifecycle where applicable.
- Harm Transfer
An intervention may reduce Harm for one subject while shifting it to
another.
Conceptually:
Subject A Harm ↓ → Subject B Harm ↑
This cannot automatically be represented as successful overall Mitigation.
Therefore:
Harm Transfer ≠ Harm Reduction by Default
HMAM must preserve materially relevant transfer risk during action
governance.
- Harm Substitution
An intervention may replace one harmful condition with another.
Conceptually:
Harm₁ ↓ + Harm₂ ↑
HMAM must not assume that the action is appropriate merely because Harm₁
is targeted successfully.
The complete consequence remains relevant to later Effect and Outcome
governance.
- Action Reversibility
Where materially relevant, HMAM should identify whether the intervention
is:
Reversible
Partially Reversible
Conditionally Reversible
or:Irreversible
Irreversible actions may require stronger justification where theireffects cannot later be withdrawn.
Reversibility does not determine appropriateness by itself.
- Action Constraints
Mitigation Action may require constraints defining:
what the action may do
where it may operate
how far it may extend
what it must not affect
when it must stop
or:
what conditions require escalation
These constraints should remain attached to materially derived execution.
Canonical principle:
Delegation of Mitigation Execution ≠ Delegation Away of Mitigation
Constraints
- Action Monitoring
HMAM may require sufficient monitoring of action execution to determine:
whether execution began
whether required steps occurred
whether dependencies remained available
whether constraints were respected
whether execution completed
and:
whether adaptation occurred
However:
Action Monitoring ≠ Harm Reduction Measurement
Effect belongs to the next HMS stage.
- Action States
HMAM may represent action through states such as:
Proposed
Selected
Authorized
Ready
Executing
Partially Executed
Executed
Blocked
Failed
Withdrawn
or:Superseded
These are:Mitigation Action States
They are not:Mitigation Outcome States
- Action Failure
Action Failure may occur where the selected intervention:
cannot be executed
cannot reach the Harm
loses required authorization
loses dependencies
cannot meet timing requirements
violates essential constraints
or:
becomes operationally unsuitable
Action Failure should trigger appropriate reassessment.
Canonical distinction:
Mitigation Action Failure ≠ Harm Mitigation Failure by Default
Another action may still achieve the Mitigation Objective.
- Action Completion
An action is complete when its governed execution requirements have been
satisfied.
Completion establishes:
the intervention occurred
It does not establish:
the Harm decreased
Therefore:
Action Completed ≠ Mitigation Effect Established
This is the principal handoff boundary to HMEM.
- Evidence of Execution
HMAM should preserve sufficient information to establish materially
relevant action execution.
This may include:
action identity
authorization
timing
scope
execution state
dependencies
material deviations
adaptations
and:
completion state
ADIT® governs evidence and audit structures where applicable.
- Prediction and Simulation
PGA™ may support prediction of expected action effectiveness.
SIMULOS® may test intervention scenarios.
These may inform action selection.
However:
Predicted Action Effectiveness ≠ Actual Mitigation Effect
and:
Successful Simulated Intervention ≠ Successful Operational Mitigation
HMAM governs actual Mitigation Action.
- Operational Reality Boundary
ORA™ may establish what operationally occurred during execution.
HMAM uses relevant operational information to govern Mitigation Action.
But:
Operational Execution ≠ Harm Reduction
HMAM does not replace ORA™, and ORA™ does not replace Harm Mitigation
governance.
- Action-to-Effect Handoff
The principal HMAM output is:
Governed Harm Mitigation Action
This transfers into:HMEM — Harm Mitigation Effect Module
The handoff asks:The action occurred. What did it actually do to the Harm?
That boundary must remain strict.
- Minimum Implementation Framework
A minimum HMAM implementation requires eight capabilities.
- Need-to-Action Traceability
Maintain explicit linkage from Governed Harm Mitigation Need, Target, and
Objective to the selected Mitigation Action.
- Action Selection & Target Alignment
Select an intervention materially capable of addressing the specific Harm
condition identified for reduction.
- Reachability, Scope & Timing Governance
Determine whether the action can reach the relevant Harm, operate across
sufficient scope, and occur within materially relevant timing conditions.
- Authorization & Executability Governance
Establish materially relevant authority, capability, resources,
permissions, dependencies, and operational readiness.
- Composite & Distributed Action Governance
Preserve the Mitigation Objective across multiple actions, systems,
organizations, agents, locations, and delegated execution paths.
- Constraint, Risk & Intervention-Induced Harm Governance
Maintain execution constraints and preserve materially relevant risk of
Harm transfer, substitution, or new Harm created by the intervention.
- Execution, Adaptation & Failure Governance
Track action states, sequencing, material adaptation, substitution,
deviations, completion, blockage, and failure without confusing execution
with Effect.
- Governed Output
Produce a traceable Governed Harm Mitigation Action suitable for
Mitigation Effect governance. 37. Use Case 1 — Technical Repair Does Not
Reach Existing Harm
A technical system defect caused Harm to several downstream systems.
Repairing the originating system prevents further malfunction but does not
restore the already damaged downstream systems.
HMAM distinguishes:
Source Repair
from:Mitigation of Existing Harm
The repair may support Containment while separate Mitigation Actions musttarget the actual existing downstream Harm.
The governing principle is:
Reaching the Harm-producing mechanism does not necessarily mean reaching
the Harm already produced.
- Use Case 2 — Mitigation Action Creates Harm Elsewhere
An intervention materially reduces Harm affecting one operational area but
transfers a significant burden to another affected group.
HMAM does not allow the intervention to be treated as methodologically
harmless merely because it addresses the original Mitigation Target.
The transferred Harm remains visible and enters appropriate Harm
governance.
The governing principle is:
A Mitigation Action cannot hide new Harm behind the Harm it was designed
to reduce.
- Governance Requirements
HMAM requires that:
- every Mitigation Action remain traceable to an established
Mitigation
Need and Objective; - available intervention not automatically qualify as
appropriate action; - action reachability be assessed against existing
Harm rather than only the originating mechanism; - action remain aligned
with the Mitigation Target; - scope be sufficient for the governed
objective; - proportionality remain explicit where materially relevant; -
timing and Mitigation Window be preserved; - capability remain
distinguishable from authority; - operational executability and
dependencies remain visible; - action sequencing remain governable where
material; - composite and distributed actions preserve the complete
Mitigation Objective; - autonomous delegation not detach execution from
Mitigation constraints; - action substitution and adaptation remain
traceable; - intervention-induced Harm remain visible; - Harm transfer and
Harm substitution not automatically qualify as reduction; - action
reversibility be preserved where materially relevant; - action execution
remain monitorable; - Action State remain distinct from Mitigation
Outcome; - failure trigger appropriate reassessment; - action completion
remain distinct from Mitigation Effect; - predicted or simulated
effectiveness not be treated as actual Harm reduction; - the handoff from
Action to Effect remain explicit.
- Governance Logic
HMAM applies the following logic:
Does a Governed Harm Mitigation Need exist?
If no:
→ no governed Mitigation Action should be established through HMAM.
If yes:
→ identify the Mitigation Target and Objective.
Then ask:
What intervention can materially reach that Harm condition?
→ identify candidate action.
Is the action aligned with the Mitigation Objective?
If no:
→ reject or reassess the action.
Can it reach sufficient Harm scope?
Can it operate within the relevant Mitigation Window?
Is it authorized?
Is it operationally executable?
Are required dependencies available?
Does it require multiple coordinated actions?
What constraints must remain attached?
Can the intervention create, transfer, or substitute Harm?
→ establish appropriate action governance.
Then:
Authorize → Execute → Monitor → Adapt where necessary → Establish Action
State
If execution fails:
→ reassess action selection, dependencies, timing, or Need.
If execution succeeds:
→ establish:
Governed Harm Mitigation Action
Then transfer:Governed Harm Mitigation Action → Mitigation Effect Governance
Throughout:
Available Intervention ≠ Appropriate Action
Mechanism Reach ≠ Harm Reach
Capability ≠ Authority
Action Execution ≠ Harm Reduction
Action Completion ≠ Mitigation Effect
Action State ≠ Mitigation Outcome
- Governance Outputs
HMAM may produce:
Governed Harm Mitigation Action
Mitigation Action Identity
Action-to-Need Relationship
Action-to-Target Relationship
Action Scope
Action Reachability State
Action Authorization State
Action Executability State
Action Timing State
Action Dependency State
Composite Mitigation Action
Distributed Mitigation Action
Action Constraint Set
Action Adaptation
Action Substitution
Intervention-Induced Harm Signal
Harm Transfer Signal
Action Failure
and:Mitigation Action State
The principal output is:Governed Harm Mitigation Action
- Critical Distinctions
Available Intervention ≠ Appropriate Mitigation Action
Operational Activity ≠ Harm Mitigation Action
Mitigation Mechanism ≠ Mitigation Target
Action Availability ≠ Harm Reachability
Mechanism Intervention ≠ Existing Harm Mitigation
Action Scope ≠ Harm Boundary
Capability ≠ Authority
Correct Action at Wrong Time ≠ Effective Mitigation Action
Component Action Completed ≠ Composite Action Completed
Delegation of Execution ≠ Delegation Away of Constraints
Harm Transfer ≠ Harm Reduction
Harm Substitution ≠ Harm Mitigation
Action Monitoring ≠ Harm Reduction Measurement
Action State ≠ Mitigation Outcome
Action Failure ≠ Harm Mitigation Failure
Action Completed ≠ Mitigation Effect Established
Predicted Action Effectiveness ≠ Actual Mitigation Effect
Successful Simulation ≠ Successful Operational Mitigation
- Canonical Boundary
The HMAM — Harm Mitigation Action Module governs how an established
Governed Harm Mitigation Need is translated into a defined, targeted,
proportionate, authorized, executable, timely, constrained, coordinated,
and traceable intervention intended to materially reduce existing Harm or
its consequences. It governs action selection, target alignment,
reachability, scope, timing, authorization, executability, dependencies,
sequencing, distributed and composite execution, constraints, adaptation,
substitution, intervention-induced Harm, action states, and action
failure. HMAM does not determine whether Harm originally exists, establish
the original Mitigation Need, determine Mitigation Effect or Outcome,
perform final Mitigation Verification, establish Recovery or Residual
Harm, determine Resolution or Finality, govern the underlying operational
system as its primary object, determine general causation, or assign
accountability, responsibility, or liability.
- Canonical Closing Statement
Mitigation does not begin with whatever intervention is easiest to
perform. It begins with an action capable of reaching the Harm that
actually needs to change.
The originating mechanism may be repaired while existing Harm remains
untouched, and an intervention may be executed perfectly while producing
no meaningful reduction—or creating new Harm elsewhere.
HMAM keeps the action connected to its Harm, objective, scope, authority,
constraints, and execution reality without claiming an effect before that
effect exists.
The action is what Mitigation does. The effect is what Harm actually
experiences.