Canonical Definition

The HBIM — Harm Boundary Identification Module governs how the elements
potentially belonging to a recognized Harm object are identified,
structured, associated, differentiated, provisionally included,
provisionally excluded, marked uncertain, and prepared for subsequent
boundary governance without treating initial association as final boundary
inclusion.

HBIM establishes the transition:

Governed Harm Recognition State → Boundary-Relevant Information →
Candidate Boundary Elements → Preliminary Association → Governed Boundary
Identification State

Its central question is:

Which subjects, effects, manifestations, times, domains, locations,
systems, relationships, and downstream consequences must be considered
when establishing the boundary of the recognized Harm?

• Operational Role

HRS establishes:

Harm has become recognized for governance.

HBS must now establish:

what belongs to that Harm.

Before subject, temporal, effect, and downstream boundaries can be
formally governed, the potentially relevant elements must first be
identified.

HBIM performs this first boundary function.

Its operational role is:

to identify the complete candidate boundary space of a recognized Harm
without prematurely deciding that every identified element belongs inside
the final Harm Boundary.

• Position Within HBS

The HBS internal flow is:

Boundary Identification → Subject Boundary → Temporal Boundary → Effect
Boundary → Downstream Boundary

The corresponding Core Module sequence is:

HBIM → HSBM → HTBM → HEBM → HDBM

HBIM receives:

Governed Harm Recognition State

from HRS.

It produces:

Governed Boundary Identification State

for downstream Subject Boundary governance.

• Governed Object

The primary governed object is:

Boundary Identification State

It represents the structured set of elements that may be materially
relevant to the Harm Boundary.

Possible states include:

Not Assessed

Candidate Element

Potentially Boundary-Relevant

Materially Boundary-Relevant

Provisionally Included

Provisionally Excluded

Boundary-Relevance Uncertain

Boundary-Relevance Disputed

Duplicate Element

Separate Harm Candidate

Unable to Determine

These states do not constitute the final Harm Boundary.

• Foundational Identification Principle

The foundational distinction is:

Boundary-Relevant Element ≠ Boundary-Included Element

Identification determines what must be considered.

Later boundary governance determines what legitimately belongs.

• Identification Scope

HBIM must be capable of identifying boundary-relevant elements across:

subjects

objects

effects

manifestations

time

locations

domains

systems

organizations

relationships

downstream consequences

collective structures

distributed structures

The required dimensions depend on the recognized Harm.

• Boundary Candidate

A Boundary Candidate is any element with a materially plausible
relationship to the recognized Harm that requires boundary assessment.

A candidate may ultimately be:

included

excluded

uncertain

merged

split

or:

assigned to another Harm object

Candidate status preserves the question without prejudging the answer.

• Candidate ≠ Inclusion

Canonical distinction:

Candidate Boundary Element ≠ Harm Boundary Inclusion

This protects HBS against premature boundary inflation.

• Identification Basis

Boundary candidates may be identified through:

Recognition Signals

subject information

operational reality

observed effects

historical information

temporal relationships

system relationships

domain relationships

evidence

downstream consequences

collective patterns

distributed execution reconstruction

The basis should remain traceable.

• Recognition Scope as Starting Point

The HRS Recognition Scope may provide the initial candidate set.

However:

Recognition Scope ≠ Final Harm Boundary

HBIM must be capable of identifying additional boundary-relevant elements
not known at Recognition Confirmation.

• Known Element

A Known Element has sufficient support to be explicitly represented in
boundary analysis.

Known does not mean included.

It means the element exists as a governance-relevant candidate.

• Suspected Element

A Suspected Element may have a plausible relationship to the Harm but
insufficient support for stronger classification.

It should remain distinguishable from:

known

and:

unsupported

elements.

• Unknown Element

Governance may know that part of the Harm Boundary remains incomplete
without knowing the missing element itself.

Examples:

unknown additional subjects

unknown duration

unknown downstream effects

unknown domain extension

HBIM should support:

Known Unknown Boundary Element

rather than treating incomplete knowledge as complete scope.

• Unknown ≠ Absent

Canonical principle:

Unknown Boundary Element ≠ Absent Boundary Element

This is especially important during early Harm governance.

• Subject Candidate Identification

HBIM identifies potentially affected:

individuals

multiple individuals

defined groups

organizations

physical objects

digital objects

operational systems

infrastructure

environments

populations

society

HSBM later governs actual Subject Boundary inclusion.

• Primary Subject Candidate

A Primary Subject Candidate is directly associated with the recognized
Harm.

Direct association may make the subject highly relevant.

It does not remove the need for boundary governance.

• Secondary Subject Candidate

A secondary subject may be affected through:

dependency

shared environment

shared system

downstream consequence

collective effect

propagation

Indirect subject relationships must not automatically be excluded.

• Indirect Subject ≠ Irrelevant Subject

Canonical distinction:

Indirect Subject Relationship ≠ Boundary Irrelevance

HSBM later determines whether the subject belongs inside the governed
Harm.

• Collective Subject Identification

Some Harm may concern:

groups

populations

organizations

environments

or:

society

without one individual carrying the complete Harm significance.

Canonical principle:

The absence of a single harmed subject does not preclude governed Harm.

HBIM must therefore support collective candidate identification.

• Effect Candidate Identification

HBIM identifies potentially relevant:

direct effects

indirect effects

functional effects

persistent effects

delayed effects

secondary effects

collective effects

cross-domain effects

downstream effects

HEBM later determines the Effect Boundary.

• Visible Effect Candidate

Visible or immediately observable effects are obvious boundary candidates.

However:

Visibility ≠ Boundary Priority

Less visible effects may be equally relevant.

• Hidden Effect Candidate

Effects may remain:

latent

internal

technically hidden

unreported

distributed

difficult to measure

Hidden effects must remain identifiable where materially plausible.

• Delayed Effect Candidate

An effect may appear after the originating mechanism has ended.

Therefore:

Delayed Effect ≠ Separate Harm by Default

HBIM should identify it for later boundary assessment.

• Manifestation Candidate

A recognized Harm may appear through several manifestations.

Conceptually:

Harm → Manifestation A

Harm → Manifestation B

Harm → Manifestation C

HBIM identifies these without assuming whether they represent one Harm or
multiple Harms.

• Manifestation ≠ Harm Object

Canonical distinction:

Manifestation ≠ Harm Object

One Harm may manifest differently across subjects, domains, and time.

• Temporal Candidate Identification

HBIM identifies potentially relevant temporal markers including:

possible Harm start

manifestation start

signal time

Recognition time

continuation

interruption

recurrence

possible Harm end

HTBM later establishes the governed Temporal Boundary.

• Recognition Time Is Not the Default Boundary Start

Canonical distinction:

Recognition Time ≠ Harm Boundary Start by Default

The boundary candidate timeline must preserve earlier Harm where
supported.

• Exposure Time Candidate

Exposure timing may be relevant to Harm Boundary analysis.

But:

Exposure Time ≠ Harm Time by Default

HES governs Exposure.

HEMS governs Harm Emergence.

• Mechanism Time Candidate

The start or end of a Harm-producing mechanism may be relevant.

But:

Mechanism Start ≠ Harm Start by Default

and:

Mechanism End ≠ Harm End by Default

• Historical Time Candidate

Later information may reveal earlier Harm-relevant periods.

HBIM must support retrospective candidate identification.

Conceptually:

Current Boundary View → Historical Information → Earlier Candidate Period

• Domain Candidate Identification

HBIM identifies potentially relevant Harm domains.

These may include:

Physical

Medical / Health

Digital

Financial

Property

Environmental

Organizational

Cognitive

Societal

One recognized Harm may involve several domains.

• Cross-Domain Candidate

An effect entering another domain should be identified where materially
plausible.

Example:

Digital Effect → Operational Consequence → Financial Effect

Canonical principle:

Domain Transition ≠ New Harm Object by Default

• Location Candidate Identification

Where materially relevant, HBIM identifies:

physical locations

digital environments

infrastructure zones

organizational spaces

environmental regions

system locations

Location provides boundary information.

It does not define the Harm Boundary by itself.

• Shared Location ≠ Shared Harm

Multiple Harms may occur in the same location.

Therefore:

Shared Location ≠ Same Harm Object

• Different Location ≠ Different Harm

One Harm may extend across several locations.

Therefore:

Different Location ≠ Different Harm Object by Default

• System Candidate Identification

HBIM identifies systems materially associated with the Harm.

These may include:

applications

AI models

agents

tools

platforms

networks

control systems

physical systems

infrastructure

The system list does not define the Harm Boundary.

• System Boundary ≠ Harm Boundary

Canonical principle:

System Boundary ≠ Harm Boundary by Default

A consequence may cross system boundaries while remaining one Harm object.

• Organizational Candidate Identification

HBIM may identify relevant:

operators

providers

suppliers

integrators

customers

institutions

third parties

where they form part of the Harm context or effect structure.

Organizational involvement does not establish accountability.

• Organizational Relationship ≠ Accountability

Canonical distinction:

Boundary-Relevant Organizational Relationship ≠ Accountability

AGA™ governs accountability.

• Interface Candidate

Where AI or digital systems are involved, the visible interface may be
boundary-relevant.

However:

Interface Identity ≠ Execution Identity

HBIM should identify the actual execution structure where materially
relevant.

• Execution Candidate Identification

Operational reality may reveal:

execution systems

agents

models

tools

dependencies

not visible at the interface.

ORA™ governs actual execution reality.

HBIM identifies their potential relevance to the Harm Boundary.

• Session Candidate

A Harm lifecycle may span several sessions.

Therefore:

Session Boundary ≠ Harm Boundary

HBIM must support cross-session candidate association.

• Agent Candidate

Multiple agents may participate in one operational objective.

Therefore:

Agent Boundary ≠ Harm Boundary

Agent-level fragmentation must not prevent identification of a composite
Harm candidate.

• Tool Candidate

Several tools may contribute to the same operational outcome.

Therefore:

Tool Boundary ≠ Harm Boundary

• Objective-Level Candidate Identification

Where execution is decomposed, HBIM should identify the shared operational
objective where it materially connects otherwise fragmented Harm elements.

Conceptually:

Task A + Task B + Task C → Shared Objective → Harm-Relevant Outcome

Canonical principle:

A governed objective does not become ungoverned by being divided into
smaller tasks.

• Composite Harm Candidate

A Composite Harm Candidate exists where several individually insufficient
conditions may collectively form one Harm object.

Conceptually:

Condition A + Condition B + Condition C → Candidate Composite Harm

Canonical principle:

Individual Insufficiency ≠ Collective Insufficiency

• Distributed Harm Candidate

A Distributed Harm Candidate may span:

agents

sessions

systems

organizations

locations

subjects

time periods

HBIM must identify the whole candidate structure where material
relationships support doing so.

• Local Harmlessness ≠ Composite Harmlessness

Individual components may appear harmless while the combined outcome
produces Harm.

Therefore:

Local Harmlessness ≠ Composite Harmlessness

HBIM must not stop at local component boundaries.

• Relationship Identification

HBIM identifies relationships among candidate elements.

Relevant relationships may include:

subject-to-effect

effect-to-effect

effect-to-domain

effect-to-time

subject-to-system

system-to-system

manifestation-to-effect

primary-to-downstream consequence

shared-objective relationship

Relationship identification does not establish causation.

• Relationship ≠ Causation

Canonical distinction:

Boundary-Relevant Relationship ≠ Causal Determination

HBS may require sufficient relational association.

It does not become a general causation architecture.

• Direct Relationship

A candidate may have a direct relationship to the recognized Harm.

Directness can strengthen boundary relevance.

It does not automatically establish final inclusion.

• Indirect Relationship

A candidate may be linked through intermediate consequences.

Conceptually:

Recognized Harm → Intermediate Effect → Candidate Element

Indirectness must not automatically result in exclusion.

• Relationship Chain

HBIM may identify:

Harm → Effect A → Effect B → Candidate Effect C

The chain should remain visible so later boundary governance can determine
where inclusion ends.

• Downstream Candidate Identification

HBIM identifies later consequences that may belong to the recognized Harm.

Possible candidates include:

secondary functional effects

additional affected subjects

cross-domain consequences

persistent impairment

dependent-system effects

collective consequences

HDBM later governs the Downstream Boundary.

• Downstream Candidate ≠ Same Harm

Canonical distinction:

Downstream Candidate ≠ Same Harm by Default

Candidate identification preserves the question.

It does not answer it.

• Intervening Condition Identification

HBIM should identify materially relevant intervening conditions between
the recognized Harm and a downstream candidate.

An intervening condition may later support:

continued inclusion

or:

Boundary Break

• Independent Harm Candidate

A later effect may represent a distinct Harm object rather than an
extension of the original Harm.

HBIM should mark:

Separate Harm Candidate

where a materially independent lifecycle appears plausible.

• One Harm vs Multiple Harms

HBIM must support identification of structures where governance needs to
ask:

Are these multiple manifestations of one Harm, or multiple distinct Harm
objects?

It must not force an early answer.

• Potential Harm Merge

Two recognized Harm objects may later appear materially connected.

HBIM may identify:

Potential Merge Relationship

HBS later determines whether boundary unification is justified.

• Potential Harm Split

One recognized Harm object may contain apparently independent lifecycle
structures.

HBIM may identify:

Potential Split Relationship

The historical unified state must remain preserved.

• Duplicate Candidate Identification

The same subject, effect, report, or consequence may appear multiple times
through different information sources.

HBIM must distinguish:

multiple representations

from:

multiple boundary elements

Canonical principle:

Information Duplication ≠ Harm Multiplication

• Candidate Correlation

Boundary candidates may be correlated through:

subject

time

domain

location

system

objective

manifestation

effect

historical continuity

Correlation assists boundary analysis.

It does not establish inclusion.

• Correlation ≠ Boundary Inclusion

Canonical distinction:

Candidate Correlation ≠ Boundary Inclusion

This prevents artificial Harm expansion.

• Candidate Conflict

Information may conflict regarding whether an element belongs to the Harm.

HBIM should preserve:

supporting relationship

contradicting relationship

uncertainty

source differences

Conflict should not be resolved through convenience.

• Conflict ≠ Automatic Exclusion

Canonical principle:

Boundary Conflict ≠ Permission to Default to Exclusion

The appropriate state may be:

Uncertain

or:

Disputed

• Boundary-Relevance Confidence

HBIM may represent confidence that a candidate deserves further boundary
assessment.

Possible states:

High

Moderate

Low

Disputed

Unknown

This confidence concerns relevance for boundary governance.

It does not establish Harm severity.

• Boundary-Relevance Confidence ≠ Harm Severity

Canonical distinction:

Boundary-Relevance Confidence ≠ Harm Severity

• Candidate Priority

Some candidates may require earlier boundary assessment because they
concern:

ongoing Harm

vulnerable subjects

large populations

possible propagation

critical infrastructure

severe potential consequences

Priority determines assessment order.

It does not determine inclusion.

• Visibility Bias

Highly visible candidate elements must not automatically dominate boundary
identification.

Canonical principle:

Visibility ≠ Boundary Significance

Hidden, delayed, distributed, or collective elements may be equally
important.

• Reporting Bias

Boundary identification must not depend exclusively on formal reports.

Therefore:

Reported Element ≠ More Real Boundary Element by Default

and:

Unreported Element ≠ Boundary Irrelevance

• Administrative Boundary Bias

Existing organizational categories may artificially limit candidate
identification.

Examples:

department

case number

incident record

insurance claim

project

system

jurisdiction

HBIM must not treat these administrative structures as automatic Harm
boundaries.

• Incident Boundary Bias

An incident may reveal Harm.

It does not necessarily define its complete scope.

Canonical principle:

Incident Boundary ≠ Harm Boundary

• Claim Boundary Bias

A claim may identify some Harm elements.

But:

Claim Scope ≠ Harm Boundary

Claims may be narrower or differently structured than the Harm itself.

• Liability Bias

Potential liability must not influence whether an element is identified
for boundary assessment.

Therefore:

Potential Liability ≠ Boundary-Relevance Criterion

• Accountability Bias

Potential accountability must not determine candidate identification.

Therefore:

Potential Accountability ≠ Boundary-Relevance Criterion

• Value Bias

Financial or Value consequences may make some effects more visible.

But:

Higher Value Consequence ≠ Greater Boundary Relevance by Default

VFM® governs Value lifecycle.

HAGA™ governs Harm.

• Evidence Availability Bias

Well-documented elements may appear more boundary-relevant simply because
more evidence exists.

Canonical principle:

Evidence Availability ≠ Harm Boundary Reality

HBIM must preserve uncertain candidates where information remains
incomplete.

• Missing Evidence

Where an element is plausible but evidence remains insufficient, HBIM may
classify it:

Boundary-Relevance Uncertain

rather than automatically excluding it.

Canonical distinction:

Insufficient Evidence ≠ Boundary Exclusion

• Historical Candidate Discovery

New information may reveal candidate elements that were absent from the
original boundary analysis.

Examples:

earlier affected subject

earlier Harm period

previously hidden effect

cross-domain consequence

distributed system involvement

Historical discovery must support boundary reopening.

• Candidate State Transition

A candidate may move through:

Potential → Materially Relevant → Provisionally Included

or:

Potential → Insufficiently Supported → Provisionally Excluded

or:

Excluded → New Information → Reopened

State transitions must remain historically traceable.

• Provisional Inclusion

HBIM may provisionally include an element where boundary relevance is
sufficiently strong to require downstream assessment.

Provisional inclusion means:

this element must remain inside the working Harm Boundary until further
boundary governance resolves it.

It does not establish final inclusion.

• Provisional Exclusion

HBIM may provisionally exclude an element where current information does
not materially support its inclusion.

Provisional exclusion must remain reopenable.

• Provisional Exclusion ≠ Permanent Exclusion

Canonical distinction:

Provisional Exclusion ≠ Final Boundary Exclusion

New information may change the state.

• Boundary Identification Reopening

HBIM must support reopening where:

new subjects appear

historical information emerges

new effects become visible

cross-system correlation changes

actual execution identity becomes known

new domains appear

downstream consequences emerge

previously excluded elements gain support

• Boundary Identification Reassessment

Reassessment should occur where the underlying Recognition State or
materially relevant information changes.

The new state must not erase the prior state.

• Historical Identification Integrity

HBIM must preserve:

Identification State₁ → New Information → Identification State₂

including:

candidate element

basis

relationships

confidence

provisional state

conflict

reason for change

Canonical principle:

Current Boundary Identification State ≠ Complete Boundary Identification
History

• HRS Boundary

HRS establishes:

which Harm has become recognized for governance.

HBIM begins from that recognized Harm and identifies the candidate scope
requiring boundary governance.

Therefore:

Recognition Scope ≠ Harm Boundary

• HSBM Boundary

HBIM identifies potential affected subjects.

HSBM determines which subjects belong to the governed Harm.

Therefore:

Subject Candidate ≠ Subject Boundary Inclusion

• HTBM Boundary

HBIM identifies potentially relevant temporal markers.

HTBM establishes the Temporal Boundary.

Therefore:

Temporal Candidate ≠ Harm Temporal Boundary

• HEBM Boundary

HBIM identifies potentially relevant manifestations and effects.

HEBM establishes the Effect Boundary.

Therefore:

Effect Candidate ≠ Effect Boundary Inclusion

• HDBM Boundary

HBIM identifies downstream candidates.

HDBM determines how far downstream the Harm Boundary legitimately extends.

Therefore:

Downstream Candidate ≠ Downstream Boundary Inclusion

• HDS Boundary

HDS later formally determines Harm.

HBIM does not perform formal Harm Determination.

Therefore:

Boundary Identification ≠ Harm Determination

• Causation Boundary

HBIM may identify causal-looking relationships where relevant to boundary
assessment.

But:

Relationship Identification ≠ General Causation Determination

Causation remains outside HBIM except for the limited association
necessary to structure candidate boundary elements.

• Accountability Boundary

HBIM may identify actors or organizations within the operational context.

It does not determine accountability.

Boundary-Relevant Actor ≠ Accountable Actor

• Liability Boundary

HBIM does not determine legal liability.

Boundary-Relevant Element ≠ Liability-Relevant Conclusion by Default

• ORA™ Boundary

ORA™ governs actual operational reality.

HBIM may use:

what happened

where

when

through which system

to identify boundary candidates.

But:

Operational Scope ≠ Harm Boundary

• AIG® and ASGA™ Boundary

AIG® governs AI behavior.

ASGA™ governs autonomous execution.

HBIM may identify behaviors, agents, objectives, execution paths, or
interventions materially associated with Harm.

It does not govern those operational spaces.

• ADIT® Boundary

ADIT® governs evidence.

HBIM uses relevant evidence to identify candidates.

Therefore:

Evidence Object ≠ Boundary Element by Default

• VALIDOS™ and INTEGROS® Boundary

VALIDOS™ governs validation.

INTEGROS® governs integrity.

HBIM may depend on validated or integrity-assessed inputs.

It does not replace those architectures.

• OBIDENITY® Boundary

OBIDENITY® may establish:

subject identity

system identity

execution identity

provenance

capability lineage

HBIM may use these relationships for candidate identification.

Identity itself does not determine Harm Boundary inclusion.

• Minimum Implementation Framework

A minimum HBIM implementation requires eight capabilities.

• Multi-Dimensional Candidate Identification

Identify potentially relevant subjects, effects, manifestations, temporal
periods, domains, locations, systems, relationships, and downstream
consequences.

• Candidate State Governance

Represent Potential, Materially Relevant, Provisionally Included,
Provisionally Excluded, Uncertain, Disputed, Duplicate, and Separate Harm
Candidate states.

• Composite & Distributed Identification

Identify candidate Harm structures across agents, sessions, systems,
tools, organizations, locations, subjects, domains, and time periods.

• Relationship & Correlation Mapping

Preserve direct, indirect, cross-domain, objective-level, downstream, and
historical relationships without converting correlation into causation or
inclusion.

• Boundary Bias Controls

Prevent incident, system, organizational, jurisdictional, claim,
liability, accountability, Value, reporting, visibility, or
evidence-availability boundaries from automatically limiting candidate
identification.

• Uncertainty & Conflict Preservation

Represent unknown, weakly supported, conflicting, hidden, delayed, or
incomplete candidate elements without forcing premature inclusion or
exclusion.

• Reassessment & Historical Continuity

Permit candidates to be added, removed, reopened, reclassified, merged, or
split while preserving previous states and rationale.

• Governed Output

Produce a traceable Governed Boundary Identification State suitable for
Subject, Temporal, Effect, and Downstream Boundary governance.

A system that identifies Harm scope only from the original incident,
report, claim, system, organization, or immediately visible effect does
not fully implement HBIM.

• Use Case 1 — A Recognized Physical Harm Has Wider Candidate Scope

Than the Original Incident

A physical incident initially identifies:

one affected individual

one visible injury

one location

and:

one incident time

Later information indicates:

persistent functional effects

an earlier Harm onset

a secondary affected subject

and:

a downstream financial consequence

HBIM does not automatically include all of these elements.

Instead, it creates:

Subject Candidates

Temporal Candidates

Effect Candidates

and:

Downstream Candidates

for later HBS boundary governance.

The governing principle is:

The incident identifies where Harm became visible; it does not
automatically identify the complete Harm Boundary.

• Use Case 2 — Distributed AI Execution Creates Boundary Candidates

Across Systems

An AI-mediated operational objective is distributed across:

Agent A

Agent B

Tool C

Model D

and:

External System E

The resulting Harm becomes recognized at the composite level.

Local records identify different:

subjects

effects

execution times

system relationships

and:

downstream consequences

HBIM reconstructs the complete candidate boundary space across those
technical partitions.

It does not assume:

Agent Boundary = Harm Boundary

Session Boundary = Harm Boundary

or:

System Boundary = Harm Boundary

The governing principle is:

Technical fragmentation must not determine which parts of a materially
coherent Harm are allowed to enter boundary governance.

• Governance Requirements

HBIM requires that:

• Boundary-Relevant Element remain distinct from Boundary-Included

Element; - candidate status not be treated as final inclusion; - known,
suspected, unknown, uncertain, and disputed candidates remain
distinguishable; - Unknown remain distinct from Absent; - individual and
collective subject candidates remain supportable; - direct, indirect,
hidden, delayed, persistent, and cross-domain effect candidates remain
supportable; - manifestations remain distinct from Harm objects; -
Recognition Time not automatically define temporal candidate start; -
Exposure and mechanism timing remain distinct from Harm timing; -
historical temporal candidates remain supportable; - system, organization,
location, interface, session, agent, and tool boundaries not limit
candidate identification by default; - composite and distributed Harm
candidates remain supportable; - objective-level relationships remain
identifiable; - candidate relationships remain distinct from causation; -
downstream candidates remain distinct from same-Harm conclusions; -
independent Harm candidates remain identifiable; - potential Harm merge
and split remain representable; - duplicate information not create
duplicate Harm elements; - correlation remain distinct from inclusion; -
conflict not automatically result in exclusion; - Boundary-Relevance
Confidence remain distinct from Harm Severity; - visibility and reporting
not determine boundary significance; - administrative, incident, claim,
liability, accountability, and Value boundaries not determine candidate
identification; - insufficient evidence not automatically create boundary
exclusion; - provisional inclusion and exclusion remain revisable; -
reassessment and reopening preserve historical integrity; - HBIM output
remain suitable for subsequent HBS boundary modules.

• Governance Logic

HBIM applies the following logic:

Has HRS produced a Governed Harm Recognition State?

If no:

→ do not manufacture boundary candidates.

If yes:

→ establish the initial recognized Harm reference.

Which subjects may be affected?

→ identify Subject Candidates.

Which manifestations and effects may belong to the Harm?

→ identify Effect and Manifestation Candidates.

Which temporal periods may be relevant?

→ identify Temporal Candidates without using Recognition Time as the
default Harm start.

Which domains and locations may be involved?

→ identify Domain and Location Candidates.

Does the Harm cross systems, organizations, agents, sessions, tools, or
execution environments?

If yes:

→ reconstruct the candidate structure across those boundaries.

Are several individually insufficient elements meaningful collectively?

If yes:

→ establish a Composite or Distributed Candidate Structure.

Are later consequences materially related?

If potentially yes:

→ identify Downstream Candidates.

Does an independent condition suggest a separate Harm lifecycle?

If yes:

→ mark a Separate Harm Candidate.

Are apparent elements duplicates?

If yes:

→ consolidate representations without multiplying Harm.

Is information conflicting or incomplete?

→ preserve Uncertain or Disputed candidate states.

Is the candidate being excluded only because it lies outside an incident,
system, organization, claim, jurisdiction, or reporting boundary?

If yes:

→ reassess methodological relevance.

Is the candidate sufficiently relevant for downstream boundary assessment?

If yes:

→ include it within the Governed Boundary Identification State.

At every stage:

Candidate ≠ Inclusion

Unknown ≠ Absent

Correlation ≠ Inclusion

Relationship ≠ Causation

Technical Boundary ≠ Harm Boundary

Downstream Candidate ≠ Same Harm

• Governance Outputs

HBIM may produce:

• Governed Boundary Identification State
• Candidate Boundary Element Set
• Known Boundary Element State
• Suspected Boundary Element State
• Known Unknown Boundary State
• Subject Candidate Set
• Collective Subject Candidate
• Effect Candidate Set
• Manifestation Candidate Set
• Temporal Candidate Set
• Historical Temporal Candidate
• Domain Candidate Set
• Cross-Domain Candidate
• Location Candidate Set
• System Candidate Set
• Organizational Candidate Set
• Execution Candidate Structure
• Objective-Level Candidate Structure
• Composite Harm Candidate
• Distributed Harm Candidate
• Boundary Relationship Map
• Downstream Candidate Set
• Intervening Condition Record
• Separate Harm Candidate
• Potential Harm Merge
• Potential Harm Split
• Duplicate Candidate State
• Candidate Correlation State
• Boundary-Relevance Conflict State
• Boundary-Relevance Confidence
• Provisional Inclusion State
• Provisional Exclusion State
• Boundary Identification Reopening State
• Historical Boundary Identification Record

The principal output is:

Governed Boundary Identification State

• Critical Distinctions

Boundary-Relevant Element ≠ Boundary-Included Element

Candidate Boundary Element ≠ Harm Boundary Inclusion

Recognition Scope ≠ Final Harm Boundary

Unknown Boundary Element ≠ Absent Boundary Element

Indirect Subject Relationship ≠ Boundary Irrelevance

Visibility ≠ Boundary Priority

Delayed Effect ≠ Separate Harm by Default

Manifestation ≠ Harm Object

Recognition Time ≠ Harm Boundary Start by Default

Exposure Time ≠ Harm Time by Default

Mechanism Start ≠ Harm Start by Default

Mechanism End ≠ Harm End by Default

Domain Transition ≠ New Harm Object by Default

Shared Location ≠ Same Harm Object

Different Location ≠ Different Harm Object by Default

System Boundary ≠ Harm Boundary by Default

Organizational Relationship ≠ Accountability

Interface Identity ≠ Execution Identity

Session Boundary ≠ Harm Boundary

Agent Boundary ≠ Harm Boundary

Tool Boundary ≠ Harm Boundary

Individual Insufficiency ≠ Collective Insufficiency

Local Harmlessness ≠ Composite Harmlessness

Boundary-Relevant Relationship ≠ Causal Determination

Downstream Candidate ≠ Same Harm by Default

Information Duplication ≠ Harm Multiplication

Candidate Correlation ≠ Boundary Inclusion

Boundary Conflict ≠ Permission to Default to Exclusion

Boundary-Relevance Confidence ≠ Harm Severity

Visibility ≠ Boundary Significance

Incident Boundary ≠ Harm Boundary

Claim Scope ≠ Harm Boundary

Potential Liability ≠ Boundary-Relevance Criterion

Potential Accountability ≠ Boundary-Relevance Criterion

Evidence Availability ≠ Harm Boundary Reality

Insufficient Evidence ≠ Boundary Exclusion

Provisional Exclusion ≠ Final Boundary Exclusion

Subject Candidate ≠ Subject Boundary Inclusion

Temporal Candidate ≠ Harm Temporal Boundary

Effect Candidate ≠ Effect Boundary Inclusion

Downstream Candidate ≠ Downstream Boundary Inclusion

Boundary Identification ≠ Harm Determination

• Canonical Boundary

The HBIM — Harm Boundary Identification Module governs the identification
and structuring of subjects, objects, effects, manifestations, temporal
periods, domains, locations, systems, organizations, relationships,
collective structures, composite structures, distributed structures, and
downstream consequences that may be materially relevant to the boundary of
a recognized Harm object. It governs candidate identification, preliminary
association, candidate correlation, uncertainty, conflict, duplication,
provisional inclusion, provisional exclusion, separate-Harm candidacy,
potential merge, potential split, reassessment, reopening, and historical
identification continuity. It does not establish the final Subject,
Temporal, Effect, or Downstream Harm Boundary, formally determine Harm,
establish general causation, assign accountability or responsibility,
determine liability, or replace operational reality, evidence, validation,
integrity, identity, AI behavior, autonomous execution, simulation, Value,
or tax-event governance.

• Canonical Closing Statement

A Harm Boundary cannot be legitimate if governance never looked beyond the
first subject, first report, first system, first visible effect, or first
administrative record through which the Harm became known.

HBIM therefore begins boundary governance by identifying everything that
may materially belong — while refusing to confuse consideration with
inclusion.

The purpose is neither to enlarge Harm nor to minimize it, but to ensure
that no legitimate part of the Harm becomes invisible merely because it
exists outside the boundary through which the Harm was first seen.

Before governance can decide where Harm ends, it must first be capable of
seeing everywhere the Harm may extend.