Hunter Storm Records Management System (HSRMS) Data Dictionary

HSRMS Data Dictionary

Hunter Storm Records Management System (HSRMS)

HSRMS Data Dictionary defines the metadata structure, terminology, field semantics, relationships, and data-governance conventions used by the Hunter Storm Records Management 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.

Relationship to Controlled Vocabularies and Authorities

The HSRMS Data Dictionary defines the semantic structure of the HSRMS artifact database. It establishes what each field means, why the field exists, its applicable cardinality and requirements, and how it relates to other HSRMS metadata.

The HSRMS Controlled Vocabularies and Authorities establish the controlled values, codes, classifications, designations, and relationship types used by those fields.

The Data Dictionary therefore defines the field, while the applicable vocabulary or authority defines the permitted semantic values.

For example:

Artifact Type is defined by the Data Dictionary as an HSRMS field; its permitted values are governed by the applicable controlled vocabulary.
Classification Type is defined by the Data Dictionary as a classification field; its values and classification semantics are governed by the applicable Hunter Storm classification authority.
Record Status is defined by the Data Dictionary as the field representing the current operational state of a record; its permitted status values are governed by the HSRMS Record Lifecycle and Operational State Model.

Where an established Hunter Storm authority already governs a concept, HSRMS references that authority rather than creating a duplicate vocabulary.

These resources are therefore complementary:

The Data Dictionary defines the structure and semantics of the record. The applicable vocabulary or authority defines the controlled semantic values used within that structure.

2. HSRMS Database Architecture

The HSRMS artifact schema contains 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.

3.5 Applicability, Requirements, and Cardinality

HSRMS distinguishes between field applicability and field requirements. A field may be conditionally applicable to an artifact. When the condition that makes the field applicable exists, the corresponding value is required unless the governing vocabulary or schema explicitly permits another value.

Accordingly:

Required means the field must contain a valid value for every record to which the field applies.
Not applicable means the semantic condition for the field does not exist for that artifact.
Optional when applicable is not the default interpretation of a conditionally applicable field.
A date field associated with a publication, event, verification, or other defined occurrence is required when that occurrence exists.
A field that does not apply to an artifact may legitimately remain unpopulated.

Cardinality defines the number of values permitted when a field applies:

1 — exactly one value is required.
0..1 — zero or one value is permitted, subject to applicability.
1+ — one or more values are required.
0..* — zero, one, or many values are permitted.

The combination of applicability, requirements, and cardinality therefore governs whether a field must be populated, rather than the presence or absence of a generic value alone.

3.6 Current HSRMS Field Inventory

The current HSRMS artifact database contains 48 fields. The inventory below provides the authoritative field names, their current database order, and the governing metadata for each field.

The detailed definitions that follow are organized by functional area rather than by field order. This inventory therefore serves as the concise reference for the current physical schema, while the functional sections provide the fuller interpretive definitions.

Independent Third-Party VerificationNo0..1Person or organization nameIdentifies the verifying authorityIndependent Third-Party Verification TitleNo0..1Person or organization nameIdentifies the verifying authorityIndependent Third-Party Verification URLNo0..1Person or organization nameIdentifies the verifying authority

#	HSRMS Field	Required	Cardinality	Vocabulary / Format	Primary Function
1	Artifact Title	Yes	1	Controlled title	Identifies the artifact
2	Artifact Title (Hyperlinked)	Yes	1	The artifact’s title presented as a hyperlink to the referenced artifact. The title corresponds to Artifact Title, while the hyperlink provides direct access to the artifact.	Identifies the artifact
3	Canonical URL	Yes	1	Canonical URL	Provides the authoritative web address
5	Version	Yes	1	Version identifier	Identifies the artifact version
6	Author	Yes	1+	Person or organization name	Identifies the creator or responsible author
7	Resource / Representation Type	Yes	1	Controlled resource-type vocabulary	Identifies the represented resource or format
8	Artifact Type	Yes	1	Controlled artifact-type vocabulary	Identifies the broad class of artifact
9	Artifact Code	Yes	1	Controlled code	Provides the artifact’s formal code
10	Artifact Subtype	No	0..1	Controlled subtype vocabulary	Provides a more specific artifact classification
11	Role	Yes	1	Identifies the function or position an artifact occupies within its applicable organizational, operational, or system context.	Identifies the artifact
12	System Name	No	1	Identifies the system associated with the artifact for system-level organization, retrieval, and cross-referencing.	Identifies the governing corpus
13	Corpus Name	No	1	Controlled corpus name	Identifies the governing corpus
14	Corpus Name 1	No	1	Records an additional corpus association beyond Corpus Name when an artifact belongs to multiple recognized corpora.	Identifies the governing corpus
15	Series Name	No	0..1	Controlled series name	Identifies the artifact series
16	Series Name 1	No	0..1	Records an additional series association beyond Series Name when an artifact belongs to multiple established series.	Identifies the artifact series
17	Property Name	Yes	1	Controlled property name	Identifies the governed property
18	Property ID	Yes	1	Controlled property identifier	Provides the property’s formal identifier
19	Property Name (External)	Yes	0..1	Controlled property identifier	Identifies the external governed property
20	Artifact Number	Yes	1	Artifact identifier	Provides the current artifact number
21	Previous Artifact Number	No	0..1	Artifact identifier	Records the prior artifact number
22	Subject	Yes	1+	Controlled subject vocabulary	Identifies the artifact’s subject matter
23	Classification Type	Yes	1	Controlled classification vocabulary	Identifies the primary classification type
24	Classification Type 1	No	0..1	Controlled classification vocabulary	Records an additional classification type
25	Classification Type 2	No	0..1	Controlled classification vocabulary	Records a second additional classification type
26	Classification Type 3	No	0..1	Controlled classification vocabulary	Records a second additional classification type
27	Classification Type 4	No	0..1	Controlled classification vocabulary	Records a second additional classification type
28	Classification System Code	Yes	1	Controlled classification code	Provides the primary classification-system code
29	Classification System Code 1	No	0..1	Controlled classification code	Provides an additional classification-system code
30	Classification System Code 2	No	0..1	Controlled classification code	Provides an additional classification-system code
31	Classification System Code 3	No	0..1	Controlled classification code	Provides an additional classification-system code
32	Classification System Code 4	No	0..1	Controlled classification code	Provides an additional classification-system code
33	Operational Designation	No	1	Controlled operational-designation vocabulary	Identifies the primary operational designation
34	Operational Designation 1	No	0..1	Controlled operational-designation vocabulary	Records an additional operational designation
35	Operational Designation 2	No	0..1	Controlled operational-designation vocabulary	Records an additional operational designation
36	Information Classification	Yes	1	Controlled information-classification vocabulary	Records the current information classification
37	Previous Information Classification	No	0..1	Controlled information-classification vocabulary	Records the prior information classification
38	Access Restrictions	Yes	1	Controlled access vocabulary	States applicable access limitations
39	Origin / Source	Yes	1+	Controlled source or provenance reference	Records the artifact’s origin or source
40	Parent / Source Artifact	No	0..1	Artifact reference	Identifies the parent or source artifact
41	Related Artifact	No	0..*	Artifact reference	Links related artifacts
42	Contextual Artifact	Yes	1	Canonical URL	Identifies an artifact that provides background, explanation, or other context useful for interpreting the current artifact. Identifies the artifact.
43	Verified By	No	0..1	Person or organization name	Identifies the verifying authority
44	Independent Third Party Verification	No	0..1	Verification statement or reference	Records independent verification status
45	Independent Third Party Verification Title	No	0..1	Artifact title text	Identifies the independent verification artifact
46	Independent Third Party Verification URL	No	0..1	URL	Provides the independent verification URL
47	Cited By	No	0..*	Artifact reference	Identifies artifacts that cite this artifact
48	Cited By: Title	No	0..*	Artifact title text	Records the titles of citing artifacts
49	Cited By: URL	No	0..*	URL	Provides the URLs of citing artifacts
50	Date of Event	Yes	1	ISO 8601 date	Records the date on which the event occurred, distinct from the artifact’s creation date and any separately recorded dates.
51	Date of Incident	Yes	1	ISO 8601 date	Records the date on which the documented incident occurred, distinct from the artifact’s creation date and any separately recorded event date.
52	Date Created	Yes	1	ISO 8601 date	Records the artifact creation date
53	Date of AI Publication	Yes	0..1	ISO 8601 date	Records the AI-publication date
54	Date Published on WordPress	Yes	0..1	ISO 8601 date	Records the WordPress publication date
55	Date Published in Book or Media	Yes	0..1	ISO 8601 date	Records publication in a book or other media
56	Date Published in External Repository	Yes	0..1	ISO 8601 date	Records publication in an external repository
57	Record Status	No	0..1	Current operational state of the record	Records an additional operational designation
58	Retention	Yes	1	Controlled retention vocabulary	States the retention requirement
59	Disposition	Yes	1	Controlled disposition vocabulary	States the authorized disposition action
60	Supersedes / Superseded By	No	0..*	Artifact reference	Records supersession relationships
61	Notes	No	0..*	Artifact reference

Schema note: Field order identifies the current database schema; functional sections elsewhere in this Data Dictionary group fields according to their semantic purpose. These two organizational views are complementary and are not required to use the same order.

Cardinality note: 1 means exactly one value; 0..1 means zero or one value; 1+ means one or more values; and 0..* means zero, one, or many values.

Vocabulary note: “Controlled” indicates that values should be selected from an approved HSRMS vocabulary, code list, or authority file. “Artifact reference” indicates a reference to another HSRMS artifact, normally by artifact number, canonical URL, or both.

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.

Artifact Title (Hyperlinked)

Purpose: Provides the artifact’s human-readable title as a hyperlink to the artifact itself.

The displayed title identifies the artifact, while the hyperlink enables direct access to its referenced location. The title should remain consistent with the corresponding Artifact Title field, and the hyperlink should resolve to the intended artifact.

This field is distinct from Canonical URL, which records the artifact’s authoritative web address as a separate value. The hyperlinked title provides a navigable representation of the artifact within the RMS.

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.

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.

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.

Role

Purpose: Identifies the role an artifact occupies within its applicable organizational, operational, or system context.

Role describes the artifact’s function or position within the relevant structure rather than its general subject, broad artifact type, or classification. It provides information about how the artifact functions in relation to the system or process in which it participates.

Role should be interpreted according to the applicable HSRMS definitions and controlled values, where established. It should not be treated as interchangeable with Author, Artifact Type, or Artifact Subtype.

Cardinality: Optional single, unless the governing schema permits multiple roles.

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?

System Name

Purpose: Identifies the system with which an artifact is associated.

System Name records the applicable system identity, enabling artifacts to be associated with the systems that govern, organize, support, or implement their documented functions. The field supports system-level identification, retrieval, and cross-referencing across the Hunter Storm ecosystem.

System Name is distinct from Property Name, which identifies the associated property or structural object. A property may contain or represent multiple systems, and a system may have relationships with artifacts across different properties.

Cardinality: Optional single, unless the governing schema permits multiple system associations.

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.

Corpus Name 1

Purpose: Records an additional corpus association for an artifact.

Corpus Name 1 allows an artifact to be associated with an additional formally identified corpus beyond the association recorded in Corpus Name. It supports artifacts that legitimately belong to more than one recognized body of records.

The value must identify a corpus recognized under the applicable corpus-governance rules. This field does not establish a new corpus or a different type of corpus merely because it is numbered separately.

Cardinality: Optional single.

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.

Series Name 1

Purpose: Records an additional formal series association for an artifact.

Series Name 1 identifies an additional established records series to which the artifact belongs, beyond the series recorded in Series Name. It accommodates artifacts that legitimately participate in multiple formally defined series.

The value must represent an established series under the applicable series-governance rules. It must not be used as a substitute for Subject, Artifact Type, Artifact Subtype, or an informal category.

Cardinality: Optional single.

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.

Property Name (External)

Purpose: Identifies the property using the name assigned by the external organization or source system.

Vocabulary / Format: External property name; authoritative name of the property as identified by its source organization or external system.

Primary Function: Identifies the external property associated with the artifact, preserving the source system’s property name for accurate identification, cross-referencing, and interoperability.

Required: No

Cardinality: Optional single.

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?

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.

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

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

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.

7. Information Governance

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

They answer:

How should this information be handled?

Information Classification

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

Cardinality: Optional single.

The field should use the applicable controlled classification vocabulary.

Previous Information Classification

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

This preserves classification history.

Cardinality: Optional.

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.

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.

Related Artifact

Purpose: Identifies other artifacts that have a relevant relationship to the current artifact.

Related Artifact may identify artifacts that provide supporting information, additional context, related evidence, or connections to the same subject or system.

Cardinality: Optional or repeatable.

Related Artifact does not, by itself, establish a parent-child relationship or indicate that one artifact was derived from another.

Parent / Source Artifact

Purpose: Identifies the parent artifact from which the current artifact derives, or the source artifact from which it was created, obtained, or developed.

Parent / Source Artifact establishes a direct provenance relationship between the current artifact and its parent or source.

Cardinality: Optional; a single parent or source artifact.

Parent / Source Artifact is distinct from Related Artifact, which records relevant relationships without necessarily establishing derivation or source lineage.

Verified By

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

Cardinality: Optional or repeatable.

Verified 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 Artifact

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 Artifact should be used for genuine relationships rather than as a catch-all for every

connection.

Contextual Artifact

Purpose: Identifies an artifact that provides context necessary or useful for interpreting the current artifact.

A contextual artifact may establish background, explain circumstances, clarify terminology, or provide additional information that helps a reader understand the current artifact’s significance or meaning.

This field is distinct from Parent / Source Artifact, which identifies a parent or source relationship, and Related Artifact, which records other meaningful relationships that do not qualify as parent, source, citation, or supersession relationships. Contextual Artifact specifically identifies the contextual function of the referenced artifact.

Cardinality: Optional; repeatable where multiple contextual artifacts apply.

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.

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 Incident

Purpose: Records the date on which the documented incident occurred.

Date of Incident establishes the temporal reference for an incident associated with the artifact. It supports chronology, incident reconstruction, evidence correlation, and cross-referencing with other records concerning the same incident.

This field is distinct from Date of Event, which records the date associated with an event documented by the artifact, and Date Created, which records when the artifact itself was created. An incident may occur before the artifact documenting it is created or published.

Where the exact incident date is unknown, the value should not be fabricated. Any permitted treatment of approximate, partial, or unknown dates must follow the applicable HSRMS date-handling rules.

Cardinality: Optional.

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.

Record Status

Purpose: Identifies the current operational state of the HSRMS record within its managed lifecycle.

Record Status identifies the current operational state of an HSRMS record within its managed lifecycle. Every HSRMS record has a current Record Status. The field therefore has a cardinality of 1 and uses a controlled HSRMS record-status vocabulary.

Record Status distinguishes the current state of a record from its version, publication history, verification, information classification, retention, disposition, and supersession relationships.

The value is assigned from the controlled HSRMS record-status vocabulary and represents the record’s current state at the time of management or publication.

Vocabulary / Format: Controlled record-status vocabulary.

Record Status describes the current state of the record itself. It is not a substitute for publication status, verification status, information classification, retention, disposition, version, or supersession.

Cardinality: Required single.

Governing Distinctions

Record Status is distinct from related lifecycle and governance metadata:

Field / Concept	Governs
Version	Version identity of the artifact
Supersedes / Superseded By	Relationship between successive or replacement artifacts
Retention	How long the record is governed for retention purposes
Disposition	Authorized action at the end of the applicable lifecycle
Information Classification	Information-classification level
Verified By	Authority associated with verification
Independent Third Party Verification	Independent verification status or evidence
Date Published on WordPress	Publication occurrence on WordPress
Date Published in Book or Media	Publication occurrence in book or other media
Date Published in External Repository	Publication occurrence in an external repository

A record may therefore be published, verified, classified, retained, or superseded without those conditions being treated as interchangeable with its Record Status.

Controlled Vocabulary

Record Status values are governed by the HSRMS Record Lifecycle and Operational State Model.

The authorized vocabulary defines the recognized operational states of an HSRMS record and, where applicable, the permitted transitions between states.

Record Status values are controlled values and must not be created as arbitrary free-text descriptions.

Applicability and Requirements

Record Status applies to every HSRMS artifact record.

Because every managed record occupies a current operational state, Record Status is:

Required: Yes
Cardinality: 1
Vocabulary: Controlled HSRMS record-status vocabulary

Historical State

Record Status identifies the current state.

Historical changes in record state are governed through the HSRMS lifecycle and change-governance architecture rather than by overwriting the semantic definition of the field with multiple historical values.

Where historical state transitions must be preserved, they are treated as lifecycle or audit events rather than additional Record Status values in the current artifact record.

Relationship to Supersession

Record Status does not itself establish that an artifact has been superseded.

Supersession is represented through the Supersedes / Superseded By relationship.

An artifact may therefore have a Record Status indicating its current operational state while independently maintaining a supersession relationship with another artifact.

Relationship to Disposition

Record Status does not determine disposition.

Retention establishes the applicable retention requirement, while Disposition identifies the authorized disposition action. Record Status identifies the record’s current operational state within that broader lifecycle framework.

Record Status Governance

The HSRMS Data Dictionary defines the semantic meaning and field requirements of Record Status. The HSRMS Record Lifecycle and Operational State Model governs the authorized status vocabulary, state definitions, transition rules, and lifecycle behavior.

The HSRMS Database Schema Governance framework governs changes to the field itself, including its definition, cardinality, applicability, vocabulary authority, and validation requirements.

This separation preserves a clear distinction between:

What the field means — Data Dictionary
What values are permitted and how states behave — Record Lifecycle and Operational State Model
How the database field is governed — Database Schema Governance

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.

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 Artifact

Those fields represent different relationships.

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 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 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, Verified 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.