Hunter Storm Evidence Repository (HSER) Data Model and Relationship Architecture

HSER Data Model and Relationship Architecture

Defines the information objects and relationships used by HSER to represent occurrences, evidence, sources, provenance, classification, and associated HSRMS records.

The Hunter Storm Evidence Repository (HSER) is designed to represent not only evidence, but the occurrences, events, incidents, sources, relationships, and associated records that give evidence its meaning and context.

HSER operates within the broader Hunter Storm Records Management System (HSRMS) architecture. HSRMS remains the authoritative records-management layer, while HSER provides the specialized information architecture required to document what happened and preserve the evidentiary relationships surrounding it.

1. Purpose

The purpose of the HSER Data Model and Relationship Architecture is to define the information objects and relationships required to represent occurrences and the evidence associated with them without collapsing distinct concepts into a single record or field.

An occurrence is not the same thing as the evidence documenting it.
An evidence artifact is not necessarily the source from which the information originated.
A source is not necessarily the author of an artifact.
A classification is not an attribution.
An evidence status is not a conclusion about truth.

HSER therefore preserves these distinctions explicitly.

The model is intended to support documentation across physical, cyber, human, organizational, environmental, infrastructure, and other domains without requiring every occurrence to fit a narrowly defined criminal, technical, or institutional model.

2. Architectural Context

HSER is a specialized component of the Hunter Storm systems architecture.

The relationship among the principal systems is:

HSRMS → manages the record

HSER → represents occurrences and evidence

HSCS → classifies the information

External authorities → provide recognized terminology and classification crosswalks

Applications and views → present the resulting information

HSER does not replace HSRMS.

An HSER object that constitutes a managed record remains subject to HSRMS identity, metadata, lifecycle, access, retention, disposition, and governance requirements.

The purpose of HSER is to provide the additional structure necessary when the question being documented is not simply:

What is this artifact?

but:

What happened, what evidence documents it, where did that evidence come from, and how are the pieces related?

3. Core Information Objects

HSER distinguishes several related information objects.

Occurrence

An Occurrence is a documented instance of something having happened, existed, changed, been observed, or otherwise taken place. Occurrence is the broadest neutral concept in the HSER model.

An occurrence may involve:

a physical event;
a cyber event;
an interaction;
an environmental condition;
property damage;
unauthorized access;
an organizational action;
an exposure;
a threat;
an incident;
or another documented happening.

Occurrence does not, by itself, establish why something happened, who caused it, whether it was intentional, or whether it constituted a violation of law or policy.

Incident

An Incident is an occurrence that has been recognized and represented as a distinct incident within the applicable operational or analytical context.

Incident is therefore a more specific representation than the neutral concept of occurrence.

The term may be used where an event or set of events constitutes a discrete matter requiring documentation, analysis, response, or tracking.

HSER does not require every occurrence to be characterized as an incident.

This distinction prevents the system from imposing an incident-response interpretation on every documented occurrence.

Event

An Event is a temporally identifiable happening or activity represented within HSER.

An event may form part of an incident, constitute an occurrence independently, or provide temporal context for other records.

Events may include:

a single action;
a change in condition;
a communication;
a publication;
a system activity;
an environmental occurrence;
or another temporally bounded happening.

Where multiple events comprise a broader incident, HSER may represent the relationship among them rather than flattening them into one undifferentiated record.

Evidence

Evidence is an information object that provides support, documentation, corroboration, contradiction, or other evidentiary relevance to an occurrence, event, incident, assertion, or related record.

Evidence may include:

photographs;
screenshots;
documents;
emails;
system logs;
recordings;
reports;
physical documentation;
witness accounts;
public records;
technical artifacts;
or other preserved information.

Evidence is not synonymous with proof. Its evidentiary significance depends on provenance, context, integrity, corroboration, and other applicable factors.

Source

A Source identifies the origin from which information, evidence, or an assertion was obtained. A source may be:

a person;
an organization;
a system;
a repository;
a publication;
a document;
a recording;
a public record;
or another recognized origin.

Source and Evidence are deliberately distinct:

An evidence artifact may have a source.
A source may produce or contain multiple evidence artifacts.
A source does not automatically establish the reliability or truth of the information it provides.

Record

A Record is an artifact formally represented and managed within HSRMS. HSER may associate occurrences, incidents, events, evidence, and sources with HSRMS records.

The HSRMS record remains governed by the HSRMS Data Dictionary, lifecycle model, controlled vocabularies, and applicable records-management requirements. This permits HSER to extend the semantic structure around a record without creating a competing system of record.

4. Relationships

HSER represents relationships explicitly wherever doing so improves meaning, provenance, retrieval, or analytical integrity.

Examples include:

Occurrence → has evidence → Evidence

Evidence → derived from → Source

Occurrence → documented by → Record

Incident → contains → Event

Event → part of → Incident

Evidence → supports → Assertion

Evidence → corroborates → Evidence

Evidence → contradicts → Assertion

Occurrence → classified as → Classification

Relationships should identify the nature of the connection rather than merely placing two objects in the same category. The eventual relational implementation may represent these relationships through dedicated relationship tables rather than repeated text fields.

5. Occurrence–Evidence Relationships

The relationship between an occurrence and its evidence is central to HSER. An occurrence represents what is documented as having happened.

Evidence represents the information that documents, supports, corroborates, or otherwise bears upon that occurrence.

A single occurrence may have multiple evidence objects.
A single evidence object may be relevant to multiple occurrences.

The relationship itself may therefore require metadata describing its role. For example:

documents;
supports;
corroborates;
contradicts;
contextualizes;
identifies;
or otherwise relates to.

This prevents HSER from treating every evidence relationship as equivalent. The model also permits an occurrence to exist as a documented object even when evidence is incomplete. Likewise, evidence may be preserved when its relationship to an occurrence remains unresolved.

6. Evidence–Source Relationships

Evidence should retain information about its origin wherever that information is known and appropriate to preserve.

An evidence object may be:

created by a source;
obtained from a source;
published by a source;
generated by a system;
observed directly;
or derived from another information object.

The relationship between Evidence and Source should therefore not automatically be interpreted as authorship. For example, a system log may originate from a system while being reviewed or preserved by another party.

A public document may originate from an organization while being preserved as evidence by HSER. Maintaining the distinction allows provenance to remain accurate without assigning roles that the evidence does not establish.

7. Provenance

Provenance records the origin and history necessary to understand where an information object came from and how it entered the HSER environment.

Provenance may include:

source identity;
acquisition or observation context;
date and time;
original location;
publication context;
chain of custody where applicable;
transformations or processing;
associated records;
verification activity;
and other relevant history.

Provenance is not merely a citation. A citation identifies a source or reference. Provenance describes the history and context of the information object and its relationship to its source. Where provenance is incomplete, HSER should preserve what is known without filling gaps through assumption.

8. Classification

HSER uses the Hunter Storm Classification System (HSCS) to classify occurrences, incidents, events, evidence, and associated records where applicable.

Classification describes what an object is, what occurred, or how the information should be categorized within the applicable classification architecture.

Examples of Event Class terminology may include:

Assault
Attack
Cyber attack
Exposure
Intrusion
Harassment
Malicious cyber activity
Property damage or tampering
Sabotage
Theft
Threat
Unauthorized access

These terms are used as classification vocabulary where applicable. Their presence in an HSER record does not, by itself, establish criminality, intent, motive, attribution, jurisdiction, investigation, or legal conclusion.

External government or industry terminology may be incorporated through controlled crosswalks to improve interoperability and interpretation.

9. Evidence Status

Evidence Status describes the epistemic or evidentiary condition of an evidence object or evidentiary relationship.

It may distinguish conditions such as:

corroborated;
independently verified;
partially corroborated;
unverified;
disputed;
or otherwise defined by the applicable controlled vocabulary.

Evidence Status is not a substitute for the evidence itself. It also does not convert an unresolved matter into a resolved one.

The purpose of the field or relationship is to communicate the current evidentiary condition while preserving the underlying evidence and provenance from which that assessment was derived. Evidence Status should therefore be capable of changing as additional evidence, corroboration, contradiction, or verification becomes available.

10. Attribution Status

Attribution Status describes the state of attribution associated with an occurrence, incident, event, or related assertion.

Attribution is distinct from classification.

Classification may establish that an occurrence fits a category such as Cyber attack or Unauthorized access.

Attribution addresses a different question:

Who or what is responsible?

An HSER classification should therefore never be interpreted as an attribution merely because a classification term describes an action.

Attribution may remain:

unknown;
unresolved;
disputed;
supported by evidence;
independently corroborated;
or otherwise represented according to the applicable controlled vocabulary.

The absence of attribution is itself different from evidence that attribution is impossible. HSER preserves the distinction so that classification can remain useful without forcing unsupported conclusions about responsibility.

11. Identity and HSRMS Integration

HSER objects that constitute managed records should receive and retain HSRMS identity.

The HSRMS architecture provides the authoritative record-management layer, including:

Artifact Number;
System Name;
Corpus Name;
Series Name;
Record Status;
classification;
provenance;
lifecycle;
retention;
disposition;
and related metadata.

HSER therefore does not create an independent numbering universe merely because an occurrence or evidence relationship requires specialized representation.

The relationship is:

HSRMS Record Identity

↓

HSER Occurrence / Evidence Structure

↓

HSCS Classification and External Crosswalks

This permits specialized evidentiary modeling while maintaining one authoritative records-management architecture.

12. External Classification Crosswalks

HSER may use recognized external classification systems and terminology through controlled crosswalks. The purpose of a crosswalk is interoperability. An external authority may define a term, code, taxonomy, or classification structure that corresponds to an HSCS concept.

The crosswalk may therefore preserve relationships such as:

equivalent;
broader;
narrower;
related;
mapped;
or otherwise defined by the applicable authority.

A crosswalk should preserve the identity and version of the external authority and, where appropriate:

framework or taxonomy name;
term or code;
HSRMS / HSCS concept;
relationship type;
version or issuance;
effective date;
source.

Use of an external classification term does not imply affiliation, endorsement, certification, investigation, jurisdiction, or access to non-public information associated with the external authority. The purpose is to use recognizable vocabulary accurately and make HSER information more interoperable with established information environments.

13. Lifecycle and Governance

HSER information objects and relationships are governed as part of the broader HSRMS lifecycle architecture.

Changes may occur to:

occurrence descriptions;
evidence relationships;
source information;
provenance;
classification;
Evidence Status;
Attribution Status;
verification;
or relationship types.

Where changes materially affect interpretation, the prior state should remain recoverable through applicable HSRMS audit and change-history mechanisms.

HSER follows several governing principles:

Preserve observations

Document what was observed or established without silently converting it into an interpretation.

Preserve uncertainty

Unresolved relationships and incomplete evidence should remain explicitly unresolved.

Preserve provenance

The origin and history of evidence should remain attached to the information object wherever known.

Separate classification from attribution

Describing an occurrence does not establish who caused it.

Separate evidence from conclusion

Evidence may support, contradict, or contextualize an assertion without itself being equivalent to the assertion.

Preserve relationships

The meaning of evidence often depends upon its relationship to an occurrence, source, record, or other evidence.

Maintain HSRMS authority

HSER extends HSRMS rather than becoming a competing system of record.

14. Derived Views and Applications

HSER data may support specialized views and applications without duplicating the underlying record structure.

Examples may include:

occurrence timelines;
evidence indexes;
incident views;
event chronologies;
evidence logs;
provenance views;
classification browsers;
relationship maps;
research interfaces;
investigative or analytical views;
and other authorized applications.

The Hunter Storm Federal Whistleblower Timeline, for example, may present occurrences, events, evidence references, actors, and associated records in chronological form while relying upon the underlying HSRMS and HSER architecture.

A derived view may organize information for a particular purpose without becoming the authoritative source of that information.

The underlying objects, relationships, provenance, and lifecycle history remain governed by HSRMS and HSER.

15. Related HSRMS Architecture

HSER operates as part of a larger information architecture.

HSRMS Data Dictionary defines the semantic meaning of the HSRMS record fields.

HSRMS Controlled Vocabularies and Authorities defines approved terminology, codes, classifications, relationship types, Record Status values, and other controlled values.

HSRMS Record Lifecycle and Operational State Model defines record states, transitions, versioning, supersession, retention, disposition, and related lifecycle controls.

Hunter Storm Classification System (HSCS) provides the classification architecture used to describe and categorize occurrences, artifacts, and associated information.

HSER provides the specialized model for occurrences, incidents, events, evidence, sources, provenance, and their relationships.

Together, these components establish a layered architecture:

Identify → Manage → Classify → Document → Relate → Preserve → Interpret

The purpose of HSER is not to determine what a reader must believe.

Its purpose is to preserve enough structure, evidence, provenance, context, and relationship information that what is known, what is documented, what remains uncertain, and how the pieces connect can be evaluated without losing the underlying record.

We do not speculate. We preserve the evidence.

Hunter Storm