Hunter Storm Records Management System (HSRMS) Data Dictionary

HSRMS Data Dictionary

Hunter Storm Records Management System

HSRMS Data Dictionary defines the metadata structure, terminology, field semantics, relationships, and data-governance conventions used by the Hunter Storm Records System (HSRMS).

HSRMS is the records-management and information architecture underlying the Hunter Storm digital ecosystem. It is designed to identify, classify, contextualize, preserve, relate, verify, and publish artifacts as durable records rather than treating individual webpages or files as isolated pieces of content.

This Data Dictionary provides the semantic contract for the current HSRMS artifact database.

It defines what each field means, why it exists, how it relates to other fields, and how the information should be interpreted.

The database is the system of record. Individual exports, timelines, indexes, research views, publication registries, and other applications are representations or derived views of that underlying record structure.

1. Purpose

The HSRMS Data Dictionary exists to prevent ambiguity.

A records-management system becomes increasingly difficult to maintain as the corpus grows unless every field has a defined purpose and a consistent interpretation. A field name that appears self-explanatory to its creator may become ambiguous to another researcher, administrator, developer, archivist, or future maintainer.

The Data Dictionary therefore establishes a common vocabulary for HSRMS.

It is intended to support:

consistent data entry;
records identification;
classification;
provenance tracking;
information governance;
artifact relationships;
verification;
lifecycle management;
future database development;
search and discovery;
interoperability;
derived reports and applications;
long-term preservation and interpretation.

The definitions in this document should be treated as the authoritative semantic definitions of the corresponding HSRMS fields.

2. HSRMS Database Architecture

The current HSRMS artifact schema contains 47 fields organized into seven functional areas:

Artifact Identity
Organizational and Contextual Structure
Classification
Information Governance
Provenance and Verification
Relationships
Lifecycle and Temporal Metadata

The organization is intentional, because an artifact must first be identifiable. Its organizational context can then be established, followed by classification, governance information, provenance, relationships, and lifecycle history.

The field order therefore reflects the logical structure of a record rather than the order in which information happened to be collected.

3. Data Dictionary Conventions

3.1 Artifact

An artifact is a discrete documented information object represented within HSRMS.

An artifact may be a webpage, publication, presentation, research product, project record, media item, document, event-related record, system artifact, or other formally recognized information object.

An artifact is not necessarily synonymous with a file.

A single conceptual artifact may have multiple representations or publication locations.

3.2 Record

A record is an artifact formally represented and managed within HSRMS.

The terms artifact and record may therefore overlap in ordinary usage, but HSRMS uses artifact when describing the information object and record when emphasizing its management within the records system.

3.3 Cardinality

Cardinality describes how many values a field may legitimately contain.

Possible values include:

Single — one value.
Optional single — zero or one value.
Repeatable — multiple values may be associated with the artifact.
Conditional — populated only when a defined condition applies.

The current flat database may represent repeatable relationships in a single field for practical reasons. The eventual relational implementation may normalize those relationships into separate tables.

3.4 Controlled Values

Some fields may use controlled vocabularies, classification systems, codes, or standardized values.

Where a controlled vocabulary exists, values should be entered consistently rather than created ad hoc.

Controlled vocabularies should be documented separately where their complexity warrants an independent glossary or authority list.

4. Artifact Identity

Artifact identity establishes the basic identity and persistence of the record.

These fields answer: What is this?

Artifact Number

Purpose: Human-facing identifier assigned to the artifact within HSRMS.

The Artifact Number provides a stable, recognizable record reference for human users, citations, indexes, and administrative workflows.

The Artifact Number should not be treated as synonymous with an internal database primary key.

Cardinality: Single.

Example: HS-000001

Architectural Note

The eventual relational implementation should maintain an immutable internal system identifier separately from the human-facing Artifact Number. This permits human-facing numbering conventions to evolve without breaking database relationships.

Previous Artifact Number

Purpose: Records the previous HSRMS artifact number associated with the artifact when a numbering or record-history transition has occurred.

This field preserves numbering lineage.

It is distinct from Supersedes / Superseded By, which describes an artifact relationship rather than merely a record-number transition.

Cardinality: Optional single or repeatable as defined by numbering policy.

Artifact Title

Purpose: Official or canonical title of the artifact.

The Artifact Title provides the principal human-readable name by which the artifact is identified.

Titles should be sufficiently descriptive to distinguish the artifact from other records.

Cardinality: Single.

Canonical URL

Purpose: Identifies the authoritative web location of the artifact.

The Canonical URL distinguishes the primary representation of an artifact from duplicate, derivative, mirrored, or secondary locations.

Cardinality: Optional single.

Where an artifact does not have a public web representation, the field may be blank or handled according to the applicable HSRMS representation policy.

Version

Purpose: Identifies the version or revision state of an artifact.

Version information distinguishes materially different iterations of the same artifact.

Cardinality: Optional single.

Versioning should not be confused with Artifact Numbering. A revised artifact may retain its conceptual identity while acquiring a new version.

Author

Purpose: Identifies the person, organization, or other recognized creator responsible for the artifact.

Cardinality: Single or repeatable depending on artifact type.

Author should not automatically be interpreted as publisher, verifier, source, or owner. Those roles may be represented elsewhere in HSRMS.

Artifact Type

Purpose: Identifies the broad category of artifact represented by the record.

Artifact Type establishes the principal class to which the artifact belongs.

Examples may include:

Profile
Publication
Presentation
Project
Research
Event
System
Timeline
Media
Record

The authoritative HSRMS classification vocabulary should determine permitted values.

Cardinality: Single.

Artifact Code

Purpose: Provides the standardized code associated with the Artifact Type or artifact classification.

Artifact Code provides machine- and human-readable shorthand for an artifact category.

Cardinality: Single or conditional.

The code should be governed by the applicable HSRMS controlled vocabulary.

Artifact Subtype

Purpose: Provides a more specific classification beneath Artifact Type.

Artifact Subtype permits artifacts sharing the same broad type to be distinguished according to their more specific function or representation.

Cardinality: Optional single.

5. Organizational and Contextual Structure

These fields establish where an artifact belongs within the broader Hunter Storm information architecture.

They answer:

Where does this artifact belong, and what does it concern?

Corpus Name

Purpose: Identifies the corpus or broad body of records to which the artifact belongs.

A corpus represents a significant collection of related information maintained as a recognizable body of records.

Cardinality: Optional single or repeatable as defined by corpus policy.

Series Name

Purpose: Identifies a formally named records series to which the artifact belongs.

A Series Name is not a generic topic, category, organizational function, or convenient label.

It should be used only where a genuine, intentionally defined series exists.

Cardinality: Optional single or repeatable as defined by series policy.

Important Rule

Series Name must not become a dumping ground for miscellaneous categories.

If a value describes what an artifact concerns rather than a formally established series, it belongs elsewhere—typically Subject or an applicable classification structure.

Property Name

Purpose: Identifies the named property, entity, or structural object associated with the artifact.

Property represents a defined element of the broader Hunter Storm ecosystem or information architecture.

Cardinality: Optional single or repeatable as appropriate.

Property ID

Purpose: Provides the identifier associated with the Property Name.

Property ID allows a property to be referenced consistently even where names change or are displayed differently.

Cardinality: Optional single.

Property ID should be treated as an identifier rather than as descriptive prose.

Subject

Purpose: Identifies what the artifact concerns.

Subject describes the principal subject, topic, function, activity, organizational concern, or substantive area addressed by the artifact.

Subject is intentionally broader than a narrowly defined intellectual-topic taxonomy.

Examples may include:

Communications
Publishing
Contributions
Governance
Leadership
Archives
Membership
Community
Website Governance
Standards

Important Distinction

Series Name identifies a formal collection.

Subject identifies what the artifact concerns.

These concepts must not be conflated.

6. Classification

Classification provides structured ways to categorize artifacts beyond their basic identity and subject.

These fields answer:

How is this artifact classified within HSRMS?

Classification Type

Purpose: Identifies the primary classification type applied to the artifact.

Cardinality: Optional single.

Classification Type should be interpreted according to the HSRMS classification system rather than inferred solely from the field name.

Classification Type 1

Purpose: Records an additional classification type or classification dimension defined by the HSRMS classification architecture.

Cardinality: Optional.

The precise semantic distinction between Classification Type, Classification Type 1, and Classification Type 2 is governed by the HSRMS classification vocabulary.

Classification Type 2

Purpose: Records another classification dimension where applicable.

Cardinality: Optional.

Classification Type 2 must not be treated as a duplicate of Classification Type unless the classification dictionary explicitly defines them as equivalent.

Classification System Code

Purpose: Identifies the principal code assigned under an applicable classification system.

Cardinality: Optional.

Classification System Code provides a controlled identifier rather than a free-form descriptive label.

Classification System Code 1

Purpose: Records an additional classification-system code associated with the artifact.

Classification System Code 2

Purpose: Records an additional classification-system code associated with the artifact.

Classification System Code 3

Purpose: Records an additional classification-system code associated with the artifact.

Classification System Code 4

Purpose: Records an additional classification-system code associated with the artifact.

Classification Code Principle

The multiple code fields should not be interpreted as redundant merely because they share the same prefix.

They exist because an artifact may participate in multiple classification dimensions or levels.

The HSRMS classification glossary should define the hierarchy, ordering, and permitted values.

Operational Designation

Purpose: Identifies the principal operational designation applied to an artifact.

Operational Designation describes the artifact from an operational or systems perspective rather than merely describing its subject.

Cardinality: Optional.

Operational Designation 1

Purpose: Records an additional operational designation where applicable.

Cardinality: Optional.

The relationship between Operational Designation and Operational Designation 1 should be explicitly defined in the classification dictionary.

Resource / Representation Type

Purpose: Identifies the form in which the resource or information object is represented.

This field is distinct from Artifact Type.

Artifact Type answers what category of artifact the record represents.

Resource / Representation Type describes the nature or representation of the resource itself.

Cardinality: Optional single or repeatable.

7. Information Governance

Information governance fields establish how information associated with an artifact is managed.

They answer:

How should this information be handled?

Previous Information Classification

Purpose: Records the preceding information-classification state when the artifact’s classification has changed.

This preserves classification history.

Cardinality: Optional.

Information Classification

Purpose: Identifies the artifact’s current information-classification state.

Cardinality: Optional single.

The field should use the applicable controlled classification vocabulary.

Access Restrictions

Purpose: Identifies restrictions governing access to the artifact or information represented by the artifact.

Restrictions may arise from policy, rights, confidentiality, contractual obligations, legal requirements, or other defined controls.

Cardinality: Optional.

Access Restrictions should not be interpreted as a substitute for copyright, licensing, or rights metadata where those concepts require separate treatment.

Retention

Purpose: Defines the applicable retention requirement or retention status for the record.

Retention describes how long a record should be maintained under the applicable records-management policy.

Cardinality: Optional.

Disposition

Purpose: Defines the authorized disposition or disposition status of the record at the end of its applicable retention period.

Disposition may include preservation, transfer, destruction, archival retention, or another authorized outcome.

Cardinality: Optional.

Retention and Disposition are related but distinct:

Retention = how long the record is kept.

Disposition = what happens to it afterward.

8. Provenance and Verification

Provenance establishes where information originated and how its reliability or authenticity may have been evaluated.

These fields answer:

Where did this come from, and how was it verified?

Origin / Source

Purpose: Identifies the origin, source, or originating context of the information represented by the artifact.

Origin / Source may identify a person, organization, repository, system, document, event, or other source.

Cardinality: Optional or repeatable.

Origin / Source should not automatically be interpreted as the artifact’s author.

Verification By

Purpose: Identifies the person, organization, system, or process responsible for verification represented by the record.

Cardinality: Optional or repeatable.

Verification By is distinct from Independent Third Party Verification.

Independent Third Party Verification

Purpose: Identifies or records the independent third-party verification associated with the artifact.

This field represents corroboration or verification external to the artifact’s originating authority.

Cardinality: Optional.

The exact permitted values and semantics should be governed by the verification vocabulary.

Independent Third Party Verification Title

Purpose: Identifies the title of the independent verification source or resource.

Cardinality: Optional.

Independent Third Party Verification URL

Purpose: Provides the web location of the independent verification source or resource.

Cardinality: Optional.

9. Relationships

Relationship metadata describes how an artifact connects to other artifacts.

These fields are especially important because HSRMS is intended to become more than a flat catalog.

It is designed to support a network of related records.

Parent / Source Artifact

Purpose: Identifies the parent, originating, or source artifact from which the current artifact is structurally or substantively derived.

This relationship is stronger and more specific than simply being related.

Cardinality: Optional or repeatable depending on relationship model.

Related Artifacts

Purpose: Identifies artifacts that have a meaningful relationship to the current artifact but do not qualify as its parent, source, citation, or superseding/superseded artifact.

Cardinality: Repeatable.

Related Artifacts should be used for genuine relationships rather than as a catch-all for every

connection.

Cited By

Purpose: Identifies artifacts that cite the current artifact.

Cardinality: Repeatable.

Citation is a specific relationship and should not be collapsed into Related Artifacts.

Cited By: Title

Purpose: Records the title of the artifact identified in Cited By.

This provides human-readable context in the flat database representation.

Cited By: URL

Purpose: Records the URL of the citing artifact where available.

In a normalized relational implementation, these fields may eventually resolve through artifact identifiers rather than repeated descriptive values.

Supersedes / Superseded By

Purpose: Records the formal succession relationship between artifacts.

This field indicates that one artifact replaces, updates, or succeeds another artifact according to the applicable HSRMS versioning or records policy.

It is distinct from:

Previous Artifact Number
Version
Parent / Source Artifact
Related Artifacts

Those fields represent different relationships.

10. Lifecycle and Temporal Metadata

Lifecycle fields preserve the temporal history of an artifact and its representations.

They answer:

When did this artifact or event exist, occur, or become publicly represented?

Date Created

Purpose: Records the date on which the artifact was created.

Cardinality: Single where known.

Date Created should not automatically be interpreted as publication date.

Date of Event

Purpose: Records the date associated with an event documented by the artifact.

An artifact may be created long before or after the event it documents.

Cardinality: Optional.

Where an event spans multiple dates, the eventual relational/event model may represent the event separately.

Date of AI Publication

Purpose: Records the date on which the artifact was published through the applicable AI-assisted publication process or representation.

The Data Dictionary should preserve the exact HSRMS definition of AI Publication rather than allowing future users to infer its meaning.

Date Published on WordPress

Purpose: Records the date on which the artifact was published through WordPress.

This is a platform-specific publication date and is intentionally distinct from Date Created.

Date Published in Book or Media

Purpose: Records the date on which the artifact was published in a book or other media representation.

Where multiple publication events exist, the eventual relational implementation may represent them as separate publication relationships.

Date Published in External Repository

Purpose: Records the date on which the artifact was published or deposited in an external repository.

Examples may include:

Library of Congress
MITRE
NIST
organizational portals
institutional repositories
other recognized external repositories

The external repository itself should be identifiable through provenance or authority metadata where necessary.

11. Evidence Architecture

Evidence is not a simple yes/no attribute

HSRMS should not reduce evidence to a field such as:

Evidence = Yes

That approach loses important distinctions.

An artifact may:

document an event;
support an assertion;
corroborate another record;
contradict an assertion;
provide primary evidence;
provide secondary evidence;
establish provenance;
provide contextual evidence.

Therefore, evidence is better modeled as a typed relationship between an artifact and an assertion, event, claim, record, or other evidentiary object.

Conceptual Model

Artifact

→ supports → Assertion

Artifact

→ documents → Event

Artifact

→ corroborates → Artifact

Artifact

→ contradicts → Assertion

This permits HSRMS to support evidence-oriented applications without contaminating the core artifact metadata with a simplistic Evidence field.

Evidence and the Federal Whistleblower Timeline

Specialized evidence-oriented outputs, including the Federal Whistleblower Timeline, should ultimately be treated as derived views or applications of HSRMS rather than independent competing systems of record.

This architecture permits the same underlying artifact to participate in multiple views without duplicating the authoritative record.

For example:

HSRMS artifact → evidence relationship → event/assertion → Federal Whistleblower Timeline entry

The timeline becomes a presentation of the underlying record relationships.

12. Future Relational Architecture

The current 47-field database is an effective comprehensive artifact record.

As HSRMS evolves into a fully relational application, certain concepts should become separate entities or relationship tables rather than repeated text values.

Potential future components include:

Artifact Registry

The authoritative artifact records.

Relationship Registry

Typed relationships among artifacts.

Examples:

cites
cited by
related to
derived from
parent of
child of
supersedes
superseded by
corroborates
supports
contradicts

Evidence / Assertion Registry

Assertions, events, claims, and their supporting or contradicting artifacts.

Agent Registry

People, organizations, systems, repositories, or other entities associated with artifacts.

Potential relationships include:

authored by
verified by
sourced from
published by
maintained by

Classification Registry

Controlled classification types, systems, codes, and designations.

Audit / Change History

A chronological record of changes made to metadata or relationships.

The audit layer should be capable of answering:

what changed;
when it changed;
who or what changed it;
what the previous value was;
what the new value became;
and, where applicable, why the change occurred.

Publication / Representation Registry

Future normalization of multiple publication and representation events where a single artifact has multiple external representations.

These are architectural extensions, not replacements for the current 47-field artifact record.

13. Immutable System Identifier

The future relational implementation should maintain an internal immutable system identifier separate from the human-facing Artifact Number.

This distinction is important.

Artifact Number

Human-facing, citable, and understandable.

HSRMS Record ID

Machine-facing, immutable, and suitable as a database primary identifier.

Separating these identifiers allows HSRMS to evolve its human-facing numbering scheme without breaking internal relationships.

14. Data Integrity Principles

HSRMS should be governed by the following principles.

14.1 One field, one semantic purpose

A field should not silently perform multiple unrelated functions.

14.2 Relationships should remain relationships

Where two records have a meaningful relationship, the relationship should eventually be represented explicitly rather than inferred from free text.

14.3 History should be preserved

Where a value changes in a way that matters to the record’s history, the prior state should not simply disappear.

14.4 Classification is not subject

Classification and Subject serve different purposes.

14.5 Series is not a miscellaneous category

Series Name should identify a genuine named series.

14.6 Provenance is not authorship

Author, Origin / Source, Verification By, and Independent Third Party Verification represent different roles.

14.7 Publication is not creation

An artifact may be created, published, represented, deposited, or associated with an event at different times.

14.8 Artifact number is not the database primary key

Human-readable identifiers and machine identifiers should remain conceptually separate.

14.9 Derived views should not become competing sources of truth

Specialized timelines, indexes, registries, and applications should derive from HSRMS wherever practical.

15. HSRMS as a System of Record (SOR)

The purpose of HSRMS is not simply to maintain a spreadsheet. The artifact database provides the authoritative metadata layer from which specialized representations can be produced.

Conceptually:

HSRMS Core

→ Artifact Registry
→ Classification
→ Provenance
→ Relationships
→ Evidence
→ Lifecycle
→ Audit History

From that foundation, HSRMS can produce:

public artifact registries;
evidence views;
timelines;
publication indexes;
research indexes;
project records;
citation networks;
classification browsers;
search interfaces;
future HSRMS applications.

This architecture allows one artifact to participate in many contexts without duplicating its authoritative metadata.

16. Schema Governance

The HSRMS schema should be changed deliberately. Before adding, removing, merging, or renaming a field, the proposed change should be evaluated for:

semantic necessity;
duplication;
relationship implications;
historical compatibility;
effect on existing records;
effect on derived views;
effect on search and indexing;
effect on future relational implementation;
effect on interoperability;
effect on the Data Dictionary.

A field should not be added merely because a current application happens to need a temporary display value. Likewise, a field should not be removed merely because its current values are sparse. Sparse data can be legitimate data.

17. Schema Freeze

Once the current schema and Data Dictionary have been reviewed and approved, the schema should be treated as a controlled structure.

Future changes should be documented as schema revisions rather than silently changing field meaning.

A change to a field’s semantic definition should be treated as significant even if the field name remains unchanged.

Similarly, changing the meaning of an existing controlled value should be documented.

18. Summary of the Current HSRMS Model

The current HSRMS artifact database provides seven principal metadata layers:

Layer	Function
Identity	Establishes what the artifact is
Context	Establishes where it belongs and what it concerns
Classification	Establishes how it is categorized
Information Governance	Establishes how information is managed
Provenance & Verification	Establishes origin and verification
Relationships	Establishes connections among artifacts
Lifecycle	Establishes creation, event, publication, and representation history

Together, these layers transform an otherwise disconnected collection of webpages, documents, publications, projects, events, and other information objects into a structured record corpus.

19. The Principle Behind HSRMS

HSRMS is designed around a simple premise:

Information becomes more useful when its identity, context, provenance, relationships, classification, and history remain attached to it.

The system therefore treats documentation as infrastructure.

The goal is not merely to preserve individual artifacts.

The goal is to preserve the relationships and context that allow those artifacts to be understood, verified, searched, connected, and reused over time.