HDCM — Harm Domain Context Module
OOF® Origin Open Foundation®
Independent Methodological Authority
Canonical Definition
The HDCM — Harm Domain Context Module governs how the domain orcombination of domains within which Harm may meaningfully exist is
identified, differentiated, related, qualified, updated, and preserved
without treating domain identification as proof that Harm exists or
forcing complex Harm into a single predefined category.
HDCM establishes the transition:
Governed Harm Context + Harm Subject Map → Potential Harm Domain → Domain
Qualification → Multi-Domain / Cross-Domain Relationship → Governed Harm
Domain Context
Its central question is:
Within which domain or combination of domains must Harm be understood for
the Harm lifecycle to be governed correctly?
- Operational Role
Harm does not have the same meaning in every domain.
A physical interaction may create physical and medical consequences.
A digital event may affect information, financial interests, operational
systems, organizations, and people.
An environmental condition may create ecological, physical, medical,
financial, infrastructural, and societal consequences.
An AI interaction may create cognitive or digital Harm that later produces
financial, organizational, physical, or societal effects.
If Harm is forced into the first visible domain, downstream governance may
miss material consequences.
If every remotely connected domain is included, Harm governance becomes
unbounded.
HDCM resolves this problem by establishing which Harm domains are
materially relevant and how their relationships must be represented.
Its responsibility is:
to ensure that Harm is governed within the domains in which its
consequences meaningfully exist without allowing domain labels to
predetermine Harm.
- Position Within Harm Context Standard (HCS)
The internal flow is:
Harm Context Mapping → Harm Subject Mapping → Harm Domain Context → Harm
Temporal Context → Harm Context Relationships
HCM establishes the broader context.
HSM identifies who or what may be affected.
HDCM establishes the domain structure within which those potentially
affected subjects or objects must be understood.
- Governed Object
The governed object is the Harm Domain Context.
It represents the domain or combination of domains materially necessary to
understand potential, emerging, recognized, or existing Harm.
A Harm Domain Context is not merely a label.
It establishes the domain-specific interpretive environment within which
downstream HAGA™ governance operates.
- Domain Context Trigger
HDCM activates when Harm Context requires one or more substantive domains
to be distinguished for legitimate downstream governance.
The trigger may arise because:
- different types of effects are possible
- multiple subjects are affected differently
- Harm may move between domains
- domain-specific interpretation is necessary
- one domain alone cannot represent the Harm
- new information reveals an additional domain
Domain Context Trigger ≠ Harm Determination
- Domain Identification
HDCM identifies domains according to the nature of the Harm-relevant
condition and its potentially affected subjects or objects.
The initial HAGA™ domain model supports:
Physical Harm
Medical / Health Harm
Digital Harm
Financial Harm
Property Harm
Environmental Harm
Organizational Harm
Cognitive Harm
Societal Harm
These are governed domain contexts.They are not separate HAGA™ architectures or Parent Standards.
- Domain Model Boundary
The HAGA™ domain model must remain sufficiently stable for
interoperability while remaining extensible where genuinely different Harm
requires another domain.
New domain creation must not be driven merely by industry, technology,
legal regime, or organizational convenience.
For example:
AI Harm
is not automatically a separate Harm domain merely because AI produced theHarm.
AI may create physical, cognitive, digital, financial, organizational, or
other Harm.
Technology Source ≠ Harm Domain
- Physical Harm Context
Physical Harm Context concerns Harm-relevant effects upon physical bodies,
physical objects, material structures, or other physically instantiated
subjects or objects.
Relevant mechanisms may include:
- impact
- force
- pressure
- movement
- heat
- contamination
- deformation
- physical degradation
- physical interference
The existence of physical interaction does not establish Physical Harm.
Physical Interaction ≠ Physical Harm
- Medical / Health Harm Context
Medical / Health Harm Context concerns Harm-relevant effects upon health,
bodily functioning, clinical condition, treatment outcome, or other
appropriately governed health state.
It may arise from medical activity or from non-medical conditions.
Therefore:
Medical Mechanism ≠ Required Medical Harm Context
and:
Medical Context ≠ Established Medical Harm
HDCM identifies the domain.
It does not perform medical diagnosis or establish clinical causation.
- Digital Harm Context
Digital Harm Context concerns Harm-relevant effects upon digital objects,
information, digital functionality, digital access, digital environments,
or other digital interests capable of being harmed.
Digital Harm need not produce a physical consequence to become governable.
Non-Physical Harm ≠ Non-Real Harm
- Financial Harm Context
Financial Harm Context concerns Harm-relevant effects upon financial
position, financial resources, economic interests, monetary access, or
other appropriately governed financial conditions.
HDCM does not equate every negative financial movement with Harm.
Financial Loss ≠ Established Harm by Default
Market movement, ordinary commercial risk, contractual outcome, or Value
change may require separate governance before Harm can legitimately be
determined.
- Property Harm Context
Property Harm Context concerns Harm-relevant effects upon physical or
digital property interests where damage, destruction, impairment, loss of
use, deprivation, or another property-specific consequence may be
relevant.
Property Harm must remain distinguishable from the Value consequences
associated with property.
Property Harm ≠ Value Loss
- Environmental Harm Context
Environmental Harm Context concerns Harm-relevant effects upon
environmental systems or objects, including ecosystems, habitats, air,
water, soil, biodiversity, or other sufficiently governed environmental
structures.
Environmental Harm does not require immediate human injury.
No Immediate Human Victim ≠ No Environmental Harm Context
- Organizational Harm Context
Organizational Harm Context concerns Harm-relevant effects upon an
organization's operation, capability, functioning, institutional
integrity, or other appropriately defined organizational condition.
Organizational Harm must not be reduced automatically to financial loss or
Harm experienced by individual employees.
Organizational Harm ≠ Aggregate Individual Harm
- Cognitive Harm Context
Cognitive Harm Context concerns Harm-relevant effects upon cognition,
interpretation, reasoning, belief formation, attention, decision capacity,
or other appropriately governed cognitive conditions.
CLIA® governs cognition itself.
HDCM identifies when cognition becomes a Harm domain.
Cognition Governance ≠ Cognitive Harm Governance
- Societal Harm Context
Societal Harm Context concerns Harm-relevant effects that become
meaningful at population, community, institutional, or societal scale.
It must not be used as a vague label for any widespread concern.
A societal domain requires a sufficiently defined societal object or
condition and a materially justified Harm relationship.
Large Scale ≠ Societal Harm by Default
- Domain Relevance
A domain should be included only where it materially affects Harm
interpretation or subsequent governance.
The test is:
Would excluding this domain materially distort understanding of the Harm
lifecycle?
If no:
→ the domain need not be included.
If yes:
→ the domain should enter the Governed Harm Domain Context.
- Primary Domain
Where one domain most directly represents the Harm-relevant condition,
HDCM may identify it as a Primary Domain.
This designation is contextual.
It does not establish that other domains are secondary in importance or
consequence.
Primary Domain ≠ Most Important Harm
- Additional Domain
Additional domains may be represented where Harm-relevant consequences
extend beyond the Primary Domain.
For example:
Physical + Medical
Digital + Financial
Environmental + Medical
Cognitive + Societal
The additional domain must be materially justified.
- Multi-Domain Harm Context
A single Harm lifecycle may legitimately involve multiple domains
simultaneously.
Conceptually:
One Harm-Relevant Condition → Domain A + Domain B + Domain C
HDCM must preserve these domains without forcing the Harm into one
artificial category.
One Harm Lifecycle ≠ One Harm Domain
- Cross-Domain Harm Context
Cross-Domain Harm occurs where the Harm-relevant lifecycle moves between
domains or where one domain materially affects another.
For example:
Digital → Financial
Physical → Medical
Environmental → Medical
Cognitive → Financial
Organizational → Societal
HDCM governs the contextual relationship between domains.
It does not automatically establish causal propagation.
- Domain Coexistence
Domains may coexist without one producing another.
For example, the same event may independently create:
Physical Harm Context + Property Harm Context
HDCM must therefore distinguish:
Domain Coexistence
from:Domain Transition
and:Cross-Domain Propagation
- Domain Transition
A Harm lifecycle may begin within one domain and later become relevant
within another.
Conceptually:
Domain A → Material Effect → Domain B
HDCM preserves the domain transition.
Detailed Harm propagation belongs downstream within HAGA™.
- Domain Expansion
New information may reveal that the Harm Domain Context is broader than
initially understood.
Example:
Digital → Digital + Financial → Digital + Financial + Organizational
Domain expansion must preserve the historical state.
Current Domain Context ≠ Original Domain Context
- Domain Contraction
A domain initially considered relevant may later be excluded when
sufficient governance demonstrates that the relationship is unsupported or
immaterial.
The exclusion must remain traceable.
Domain Removal ≠ Historical Non-Relevance
- Domain Uncertainty
The relevant Harm domain may initially be uncertain.
HDCM may represent:
Established Domain
Probable Domain
Possible Domain
Disputed Domain
Insufficient Basis
Unable to Determine
Domain uncertainty must not be converted into false certainty merely tosimplify downstream governance.
- Competing Domain Interpretations
Different interpretations may place the same Harm-relevant condition
within different domains.
For example, an effect may initially appear:
Operational
but later become relevant as:Organizational Harm
or:Digital Harm
HDCM may preserve competing interpretations until sufficient contextsupports resolution.
- Domain and Mechanism Separation
The mechanism producing a Harm-relevant condition must remain separate
from the domain in which Harm exists.
Examples:
AI System → Cognitive Harm
Human Action → Digital Harm
Autonomous System → Physical Harm
Organizational Process → Financial Harm
Environmental Condition → Medical Harm
Therefore:
Harm-Producing Mechanism ≠ Harm Domain
This is a foundational HAGA™ distinction.
- Domain and Technology Separation
Technology categories must not become Harm domains merely because they are
technologically distinct.
There is no methodological requirement for:
AI Harm
Robot Harm
Algorithmic Harm
Autonomous Harm
as separate domains where existing Harm domains already govern theconsequence.
The architecture remains technology-neutral.
- Domain and Industry Separation
Industries are not automatically Harm domains.
Healthcare, banking, construction, transportation, insurance,
manufacturing, education, or public administration may provide context.
They do not automatically create separate Harm lifecycle categories.
Industry ≠ Harm Domain
- Domain and Legal Category Separation
Legal classifications must not automatically define the Harm domain.
A legal system may classify consequences according to
jurisdiction-specific rules.
HDCM governs methodological Harm Domain Context independently.
Legal Category ≠ Harm Domain by Default
- Domain and Claim Separation
A claimant may describe Harm using a particular domain.
That description may be relevant.
It does not automatically establish the domain.
Claimed Harm Domain ≠ Governed Harm Domain
- Domain and Evidence Separation
Evidence may support the inclusion or exclusion of a Harm domain.
ADIT® may govern that evidence.
HDCM governs the domain interpretation supported by the Harm Context.
Evidence Type ≠ Harm Domain
- Domain and Classification Boundary
CLA™ may govern classification methodology where applicable.
HDCM governs which Harm domains are relevant to the Harm lifecycle.
It must not become a universal classification system for Harm.
Domain Governance ≠ General Classification Governance
- Domain and Integrity Boundary
INTEGROS® may govern integrity conditions or integrity failures.
An integrity failure may create Harm-relevant context.
It does not automatically establish a Harm domain or Harm itself.
Integrity Failure ≠ Harm
- Domain and Operational Reality Boundary
ORA™ may establish relevant Operational Reality.
HDCM consumes that reality to determine which Harm domains are materially
relevant.
The relationship is:
Governed Operational Reality → Harm Context → Harm Domain Context
not:
HDCM → Operational Reality Determination
- Domain and AI Behavior Boundary
AIG® governs AI behavior.
Where AI behavior creates a Harm-relevant consequence, HDCM determines the
domain in which that consequence must be understood.
AI Behavioral Failure ≠ Harm Domain
- Domain and Autonomous Operation Boundary
ASGA™ governs autonomous operation.
A robot, autonomous vehicle, drone, agent, or other autonomous system may
create consequences across several Harm domains.
HDCM governs the consequence domain, not autonomous execution.
Autonomous Operational Failure ≠ Harm Domain
- Domain and Cognition Boundary
CLIA® governs cognition.
Cognitive processes may become relevant to Harm when they produce or
experience a Harm-relevant cognitive effect.
HDCM governs the Harm Domain Context.
It does not govern cognition itself.
- Domain and Value Boundary
VFM® governs the Value lifecycle.
A Harm may produce Value degradation, nullification, restoration
requirements, or other Value consequences.
HDCM does not govern those Value states.
Harm Domain ≠ Value Domain
Harm ≠ Value Loss
- Domain and Tax Boundary
A Harm-relevant consequence may later become relevant to a Tax-Relevant
Event.
TREGA™ governs that Event lifecycle.
Tax treatment does not determine the Harm domain.
Tax Consequence ≠ Harm Domain
- Domain and Accountability Boundary
AGA™ may govern accountability surrounding Harm.
Accountability structures do not define the domain in which Harm exists.
Accountability Domain ≠ Harm Domain
- Domain and Liability Boundary
Legal liability may depend upon jurisdiction-specific legal categories.
HDCM does not organize Harm around potential liability.
The domain must be determined according to the Harm itself.
Liability Category ≠ Harm Domain
- Domain-Specific Context Requirements
Different domains may require different contextual information.
Physical Harm may require physical interaction context.
Medical Harm may require health-state context.
Digital Harm may require digital-object or system context.
Environmental Harm may require environmental conditions and persistence.
Cognitive Harm may require cognition-relevant context.
HDCM identifies which contextual requirements become necessary.
It does not own the specialized methodology used to establish every
underlying fact.
- Domain-Specific Harm Meaning
The same observable change may have different Harm meaning across domains.
For example:
Loss of Access
may concern:Digital Harm
Financial Harm
Organizational Harm
or multiple domains depending upon what is affected.HDCM therefore requires domain interpretation to follow the governed
object and consequence rather than surface terminology.
- Cross-Domain Subject Effects
One subject may experience Harm across multiple domains.
Likewise, one condition may affect different subjects in different
domains.
Conceptually:
Condition → Subject A / Physical → Subject B / Financial → System C /
Digital
HDCM must preserve this structure without forcing domain uniformity across
subjects.
- Domain Relationship Mapping
Where multiple domains are present, HDCM should preserve their
relationship.
Possible relationships include:
Coexisting
Sequential
Dependent
Potentially Propagating
Conditionally Related
Disputed
This relationship structure supports downstream Harm governance.- Domain Propagation Boundary
HDCM may identify that a domain-to-domain relationship exists or may
exist.
It does not determine the complete propagation lifecycle.
That belongs to the Harm Change & Propagation Standard (HCPS).
Therefore:
Cross-Domain Relationship ≠ Established Harm Propagation
- Domain Persistence
A domain may remain relevant after the mechanism producing the original
Harm-relevant condition has stopped.
For example:
Digital Mechanism Stops → Financial Harm Context Persists
or:
Physical Exposure Stops → Medical Harm Context Persists
The governing principle is:
Termination of the Originating Mechanism ≠ Termination of the Harm Domain
- Domain Evolution
The Harm Domain Context may evolve throughout the lifecycle.
Conceptually:
D₁ → D₁ + D₂ → D₂ + D₃ → D₃
HDCM must permit this evolution without rewriting earlier domain states.
- Domain Reassessment
Reassessment may be required where:
- new consequences emerge
- additional subjects are discovered
- latency becomes visible
- Harm propagates
- earlier domain interpretation is corrected
- a suspected domain is excluded
- cross-domain effects become material
Reassessment must preserve the basis and history of change.
- Historical Domain Continuity
The Harm Domain Context should remain historically reconstructable.
If a situation was originally understood as:
Physical Harm Context
and later became:Physical + Medical + Financial Harm Context
the historical sequence must remain visible.
Current Domain Understanding ≠ Historical Domain Understanding
- Domain Sufficiency
Domain governance is sufficient when the domain structure adequately
supports the next intended Harm-governance step without materially
excluding relevant consequences or introducing unsupported domains.
The governing test is:
Would the Harm lifecycle be materially misunderstood if the current domain
structure were used downstream?
If yes:
→ further domain governance is required.
- Domain Proportionality
Domain mapping must remain proportionate.
A simple physical Harm context does not require every possible Harm domain
to be evaluated exhaustively.
A complex distributed Harm may legitimately require several domains.
Domain Breadth Should Follow Harm Reality
not:
Maximum Domain Coverage by Default
- Technology-Neutral Domain Governance
HDCM must produce the same methodological result regardless of whether the
relevant mechanism is:
Human
Organization
Mechanical System
Digital System
AIAutonomous System
Human-AI System
Multi-Agent System
Environmental Condition
Technology may change the mechanism, speed, scale, evidence, orpropagation.
It does not change the fundamental purpose of Harm Domain governance.
- Enterprise Application
HDCM can be applied across:
- healthcare
- industrial operations
- workplace environments
- financial services
- digital platforms
- AI systems
- autonomous systems
- robotics
- transportation
- infrastructure
- environmental governance
- public administration
- organizational governance
- human-AI interaction
- multi-agent and multi-system environments
Its function remains constant:
determine the domain or combination of domains in which Harm must be
understood without confusing the mechanism producing Harm with the domain
in which Harm exists.
- Minimum Implementation Framework
A minimum implementation of HDCM should provide eight capabilities:
- Governed Input
Receive an identifiable Governed Harm Context and applicable Harm Subject
Map.
- Domain Identification
Determine which Harm domain or domains are materially relevant.
- Domain Qualification
Represent whether each domain is established, probable, possible,
disputed, insufficiently supported, or unable to determine where
qualification is required.
- Multi-Domain Representation
Permit more than one domain without forcing one Primary Domain where
reality does not justify one.
- Domain Relationship Representation
Record whether domains coexist, transition, depend upon one another, or
may be related through downstream Harm propagation.
- Boundary Control
Keep Harm domains separate from technology type, industry, legal category,
evidence type, accountability, liability, Value, and Tax-Relevant Event
governance.
- Reassessment & Historical Continuity
Permit domain addition, removal, qualification, and relationship change
while preserving earlier governed states.
- Governed Output
Produce a traceable Governed Harm Domain Context suitable for subsequent
HAGA™ governance.
A system that merely assigns one static Harm category without supporting
multi-domain relationships, uncertainty, change, and historical continuity
does not fully implement HDCM.
- Use Case 1 — One Harm-Relevant Condition Across Multiple Domains
An operational condition produces a physical effect upon a person,
disrupts a digital system, creates medical consequences, and causes
subsequent financial effects.
A simplistic Harm system selects:
Physical Harm
and treats all later effects as secondary metadata.HDCM instead establishes:
Physical Harm Context + Medical Harm Context + Digital Harm Context +
Financial Harm Context
and preserves the relationship between those domains.
It does not automatically determine that every consequence constitutes
established Harm.
It ensures that downstream HAGA™ governance does not lose material
consequences merely because one domain appeared first.
The governing principle is:
One Harm Lifecycle ≠ One Harm Domain
- Use Case 2 — AI-Related Harm Without an “AI Harm” Category
An AI system produces information that materially affects a user.
The initial response labels the case:
AI Harm
HDCM tests what is actually being harmed.The relevant consequences may concern:
Cognitive Harm Context
Digital Harm Context
Financial Harm Context
Organizational Harm Context
or a combination of them.The fact that AI produced the relevant output identifies an operational
mechanism.
It does not establish a new Harm domain.
The correct governance transition is:
AI Behavior / Operational Mechanism → Harm-Relevant Consequence → Harm
Domain Context
not:
AI Involvement → AI Harm Category
This preserves HAGA™ as a technology-neutral architecture.
Technology Source ≠ Harm Domain
- Governance Requirements
HDCM requires that:
- Harm domains be identified according to materially relevant
consequences rather than technology source; - Physical, Medical / Health,
Digital, Financial, Property, Environmental, Organizational, Cognitive,
and Societal Harm remain supportable; - domain identification remain
distinct from Harm Determination; - new Harm domains not be created merely
from industry, technology, legal terminology, or organizational
convenience; - multi-domain Harm Context remain supportable; - domain
coexistence remain distinguishable from domain transition; - cross-domain
relationships remain governable; - Primary Domain designation not erase
additional domains; - domain uncertainty remain explicitly representable;
- competing domain interpretations remain preservable; - domain expansion
and contraction remain traceable; - mechanism remain distinguishable from
Harm domain; - industry remain distinguishable from Harm domain; - legal
category remain distinguishable from Harm domain; - claims and evidence
remain distinguishable from domain determination; - cross-domain
relationship remain distinct from established Harm propagation; - domain
context remain distinguishable from Operational Reality, AI behavior,
autonomous operation, cognition, Value, accountability, liability, and
Tax-Relevant Event governance; - historical domain states remain
reconstructable; - Domain Sufficiency be established before downstream
reliance.
- Governance Logic
HDCM applies the following logic:
Is Harm Domain Context required for the governed Harm situation?
If no:
→ preserve the reason domain differentiation is not materially necessary.
If yes:
→ identify potentially relevant Harm domains.
Which domain or domains correspond to the potentially affected subjects,
objects, or consequences?
→ establish candidate domains.
Is each candidate domain materially relevant?
If no:
→ exclude or qualify it.
If yes:
→ include it in the Governed Harm Domain Context.
Are multiple domains simultaneously relevant?
If yes:
→ preserve Multi-Domain Harm Context.
Do the domains coexist, transition, or have a potential propagation
relationship?
→ represent the appropriate relationship without fabricating causation.
Is a proposed domain merely the technology, industry, legal category,
mechanism, or source of Harm?
If yes:
→ reject it as a Harm domain unless a genuinely distinct Harm object
exists.
Is domain interpretation uncertain or disputed?
If yes:
→ preserve qualification rather than manufacturing certainty.
Has the domain structure materially changed?
If yes:
→ reassess while preserving historical states.
At every stage:
Mechanism ≠ Harm Domain
Domain ≠ Harm Determination
Cross-Domain Relationship ≠ Established Propagation
- Governance Outputs
HDCM may produce:
- Governed Harm Domain Context
- Primary Harm Domain
- Additional Harm Domain
- Multi-Domain Harm Context
- Cross-Domain Harm Context
- Domain Relationship Record
- Domain Coexistence State
- Domain Transition State
- Domain Uncertainty State
- Competing Domain Interpretation
- Domain Expansion Record
- Domain Contraction Record
- Domain Reassessment Record
- Historical Harm Domain Context
- Domain Sufficiency State
The principal output is:
Governed Harm Domain Context
linked to the Governed Harm Context and applicable Harm Subject Map.- Critical Distinctions
Domain Context Trigger ≠ Harm Determination
Technology Source ≠ Harm Domain
Physical Interaction ≠ Physical Harm
Medical Context ≠ Established Medical Harm
Non-Physical Harm ≠ Non-Real Harm
Financial Loss ≠ Established Harm by Default
Property Harm ≠ Value Loss
No Immediate Human Victim ≠ No Environmental Harm Context
Organizational Harm ≠ Aggregate Individual Harm
Cognition Governance ≠ Cognitive Harm Governance
Large Scale ≠ Societal Harm by Default
Primary Domain ≠ Most Important Harm
One Harm Lifecycle ≠ One Harm Domain
Domain Coexistence ≠ Domain Transition
Harm-Producing Mechanism ≠ Harm Domain
Industry ≠ Harm Domain
Legal Category ≠ Harm Domain by Default
Claimed Harm Domain ≠ Governed Harm Domain
Evidence Type ≠ Harm Domain
Domain Governance ≠ General Classification Governance
Integrity Failure ≠ Harm
AI Behavioral Failure ≠ Harm Domain
Autonomous Operational Failure ≠ Harm Domain
Harm Domain ≠ Value Domain
Harm ≠ Value Loss
Tax Consequence ≠ Harm Domain
Accountability Domain ≠ Harm Domain
Liability Category ≠ Harm Domain
Cross-Domain Relationship ≠ Established Harm Propagation
Termination of the Originating Mechanism ≠ Termination of the Harm Domain
Current Domain Understanding ≠ Historical Domain Understanding
- Canonical Boundary
The HDCM — Harm Domain Context Module governs the identification,
qualification, combination, relationship, evolution, reassessment, and
historical preservation of the domain or domains within which Harm may
meaningfully exist. It supports Physical, Medical / Health, Digital,
Financial, Property, Environmental, Organizational, Cognitive, Societal,
Multi-Domain, and Cross-Domain Harm Context while preventing technology
type, industry, operational mechanism, legal category, evidence type,
accountability structure, liability category, Value consequence, or Tax
consequence from being misrepresented as the Harm domain itself. It does
not determine that Harm exists, determine Harm severity or state, govern
the underlying operational mechanism, establish cross-domain causation,
govern Harm propagation, establish Operational Reality, classify objects
generally, assign accountability, determine liability, govern Value, or
determine Tax-Relevant Events.
HCM establishes the broader Harm Context.
HSM establishes who or what may be affected.
HDCM establishes within which domain or combination of domains that Harm
must be understood.
The Harm Temporal Context Module subsequently establishes the temporal
structure within which that Harm Context must be governed.
- Canonical Closing Statement
Harm should be governed according to what is harmed, not according to the
technology, industry, organization, or mechanism that produced the
consequence.
The HDCM — Harm Domain Context Module prevents complex Harm from being
trapped inside the first visible category while also preventing every
connected consequence from becoming an uncontrolled new Harm domain.
A single Harm lifecycle may cross bodies, systems, finances,
organizations, environments, cognition, and society. HDCM preserves those
domains without confusing where Harm exists with how Harm was produced.