How to Organize True Crime Research into a Case File

Organize true crime research as a linked case-file system: keep a case overview plus separate person, event, claim, source, and supporting material records, each with a stable, unique record ID. Cross-reference those IDs with explicit relationship labels and source locators, keep uncertainty visible, and preserve revision history so changes remain traceable without treating organization or citation as proof.

Case-file organization provides the record structure for research; source discovery, claim verification, chronology construction, and research-error auditing remain separate tasks. The sections below show how to build and maintain that structure.

Table of Contents⌄

Build the Core Structure of the Case File

The case-file record architecture works by separating research into distinct record classes while linking those classes through stable identifiers.

In this structure, a practical core consists of six record classes: the case overview, person record, event record, claim record, source record, and supporting material record.

Each record class stores information for one organizational function, which makes retrieval more precise and reduces the need to duplicate the same detail across the case file.

A stable record ID provides the reference point needed for traceability between related records.

The record classes form one connected system rather than six isolated collections.

The case overview holds the file's scope and identifying context, while the other record classes store people, occurrences, claims, sources, or supporting material according to their function.

Cross-references connect related records, allowing information to remain separated by function while still being retrievable through the wider case-file structure.

Record class	What it stores	Linked records	Retrieval or traceability purpose
Case overview	Case identity, scope, and current organizational context	People, events, claims, sources, and supporting material	Provides the common case-level reference for the file
Person record	Identity and documented relationship information	Events, claims, sources, and other person records	Keeps one person reference available across related records
Event record	A discrete occurrence and its recorded time, place, or descriptive details	People, claims, sources, and supporting material	Allows the occurrence to be retrieved and referenced without repeating it elsewhere
Claim record	A specific assertion and its recorded status or context	Sources, people, events, and supporting material	Allows the claim to be traced to the records that report, support, contradict, or otherwise relate to it
Source record	Source identity and location information	Claims, events, people, and supporting material	Provides a stable source reference that multiple records can reuse
Supporting material record	Documents, images, files, or other retained material	Claims, events, people, and sources	Provides a retrievable location for material associated with another record

Linked records should reference one another by record ID rather than copying complete content into every connected entry.

A claim record can reference a source record, for example, while the source record remains the single place that stores that source's identifying information.

This separation keeps each record class functionally distinct while preserving the cross-reference needed to retrieve related material.

For example, a hypothetical event record E-014 could reference person record P-003, claim record C-021, and source record S-008 without reproducing all three records inside the event entry.

The case-file structure organizes those relationships; finding sources, evaluating claims, constructing the broader chronology, and diagnosing research mistakes remain separate research tasks.

Case Overview and Research Scope

The case overview record is the anchor record that defines the scope of a true crime case file before subordinate records are added.

It records the case identity and the conditions that determine which people, events, claims, and materials belong within the file.

The case identifier and jurisdiction establish the file's identity, while the time range, research objective, inclusion boundary, and research status define its operating limits.

Recording these attributes explicitly makes inclusion depend on the stated scope rather than on a loose association with the case topic.

• Case identifier: use one stable, case-specific identifier so records can be retrieved and associated with the correct file.
• Jurisdiction: record the relevant jurisdiction or jurisdictions; material outside that geographic or legal scope belongs only when the research objective explicitly includes it.
• Time range: record the period covered by the research; events outside that range are excluded unless they are necessary to understand an included event or condition.
• Research objective: state the specific question or informational purpose the file is intended to support; records should contribute directly to that objective.
• Inclusion boundary: state which people, events, claims, and material qualify for inclusion and which related information remains outside the file.
• Research status: record the file's current state, such as active, paused, or closed for the present research objective, so later updates can be interpreted in the correct context.

For example, if a file covers events within a defined jurisdiction and time range, an associated person or event outside those limits does not enter the file merely because it is connected to the same case topic; it needs a documented reason within the research objective or inclusion boundary.

The case overview therefore controls inclusion and exclusion rather than serving as a narrative summary of the case.

People and Relationship Records

A person record identifies each relevant individual once and keeps that person's documented identity attributes and record links in one place.

The person record can then connect the individual to a role, relationship, event, claim, or source without repeating the full identity profile in every related record.

The canonical name provides the main working identity for the record, while each alias should remain separately recorded when the research material uses another name.

A role or relationship should carry the documented value or status supported by the relevant source, including an uncertain or disputed status when the material does not support a single settled description.

A recorded relationship is therefore a documented relationship state, not an inference about motive, guilt, or legal status.

Stable record IDs and source references connect these identity attributes to the records in which they are relevant.

• Canonical name: record the main working name used to identify the person consistently across the case file.
• Alias: record each documented alternate name or spelling separately and retain uncertainty when an alias is disputed or not fully established.
• Role: record the role attributed to the person by the relevant material, with its status qualified when different sources describe that role differently.
• Relationship: record the documented relationship type and its status rather than inferring an unstated personal, legal, or causal relationship.
• Related record IDs: cross-reference the event, claim, person, or other record IDs connected to the individual instead of copying those records into the person record.
• Source references: retain the source reference supporting each material identity attribute, role, or relationship so its documented status remains traceable.

For example, a hypothetical person record P-003 could reference event E-014, claim C-021, and source S-008 while keeping the person's canonical name, aliases, role, and documented relationships only in P-003.

Those cross-references connect the individual to several records without creating duplicate person profiles throughout the case file.

Event Records and Timeline References

An event record stores one discrete occurrence with its own event ID, date or time state, location, event description, and references to related records.

The event record can link the occurrence to a person, claim, source, or supporting material without copying those records into the event entry.

A source reference should remain attached to the recorded details so the event's attributes and uncertainty can be traced back to the material from which they were taken.

The date or time attribute should state its level of temporal precision rather than presenting uncertain information as exact.

An exact state records a specific supported date or time, an approximate state indicates that the occurrence is placed near a reported point in time, a ranged state records a bounded period, and an unknown state records that the available material does not establish the time.

These states affect how confidently the event can later be positioned in chronological order while preserving the uncertainty recorded in the event itself.

Time state	Recorded condition	Timeline implication
Exact	A specific date or time is supported by the recorded source reference	The event can be placed at that stated point in chronological order
Approximate	The date or time is reported only approximately	The timeline reference should retain that approximation rather than imply exact placement
Ranged	The occurrence is bounded between two recorded temporal limits	The event can be placed within that range without assigning an unsupported single timestamp
Unknown	The available record does not establish a usable date or time	The event remains chronologically unplaced until a supported temporal value becomes available

An event record and a case timeline therefore serve different functions: the event record stores the occurrence and its attributes, while a timeline reference places that event among other events according to the available temporal information.

For example, event record E-014 could retain a ranged time state, location, event description, related record IDs, and source reference even if the broader timeline cannot assign it one exact position.

This section records event data and its temporal precision without reconstructing or resolving the wider chronology.

Claim and Source Records

A claim record and a source record should remain separate but linked so each statement can be traced to the material associated with it.

The claim record stores the claim and its claim ID, while the source record stores the source's identifying information under a source ID.

The claim-source link then records the relevant source location and relationship status without treating the existence of a citation as proof.

A source location should identify the precise part of the material relevant to the claim, such as a page, section, timestamp, or other available locator.

The reporting status can distinguish material that merely reports a claim from material recorded as providing support, contradiction, or other relevant context.

A source that reports a statement is not necessarily supporting that statement; the relationship status records what the source does in relation to the claim.

Keeping that distinction explicit improves traceability without making a separate judgment about the source's overall reliability.

Claim ID	Claim text	Source ID and source location	Relationship status	Notes
C-021	Hypothetical claim A	S-008, specific locator recorded in the source	Reports	The source contains the claim but the link alone does not establish support
C-021	Hypothetical claim A	S-012, specific locator recorded in the source	Supports	A second source reference is linked to the same claim
C-022	Hypothetical claim B	S-008, separate locator recorded in the same source	Contradicts	The same source record can link to more than one claim

This hypothetical many-to-many relationship allows one claim to reference multiple sources and one source record to reference multiple claims without duplicating either complete record.

Each link retains its own source location, reporting status, and relevant notes, so the organizational result is traceability between claims and source material rather than an assumption that a linked source proves the claim.

Evidence and Supporting Material Records

A supporting material record catalogs each supporting item so it can be located and connected to the claim, person, or event it informs without treating storage as proof of factual status.

Each record should give the material a stable item ID and retain the descriptive, origin, storage, linkage, and provenance information needed for retrieval.

• Item ID: assign one stable identifier to the supporting material so other records can reference the same item without duplicating it.
• Material type and date: record the type of material and any documented creation, publication, capture, or receipt date, retaining uncertainty when the date is not established.
• Origin: record where the item came from or the documented party, collection, system, or location from which it was obtained.
• Description and status: describe what the item is and record any known organizational status without implying authenticity, admissibility, or factual truth.
• Provenance note: document the available provenance, source note, transfer history, or uncertainty needed to understand the item's recorded origin and context.
• Storage location: record the physical or digital location needed to retrieve the item while avoiding unnecessary duplicate copies.
• Related record IDs: link the supporting material to the relevant claim, person, event, or other record by its related record ID.

The supporting material record therefore organizes an item's identity, origin, storage location, related record IDs, provenance, and status while keeping those attributes separate from conclusions about what the material establishes.

A source record identifies material used as a research source, whereas a supporting-material record catalogs a retained or referenced item that needs its own retrieval and linkage metadata; where the same material serves both functions, cross-references can prevent duplicate storage.

Cataloguing an item does not by itself authenticate it, establish legal admissibility, or prove the claim, person relationship, or event to which it is linked.

Use Consistent Naming Conventions and Record IDs

A consistent naming convention and stable record ID system make records easier to retrieve, sort, cross-reference, and update without relying on memory.

A file name can remain descriptive for human retrieval, while a record ID acts as the stable identifier that should continue to reference the same record even when descriptive names change.

Set up both parts of the system in a fixed sequence so the same rules can be applied to new and existing records.

The exact separator, capitalization style, date format, and descriptive fields may vary, but consistency and portability should govern the choice.

1. Choose the descriptive fields. Include only attributes that materially distinguish the record, such as subject, record type, date, sequence, or version. Check: each selected field should help distinguish or retrieve the file rather than add redundant wording.
2. Define the field order and separator. Put the chosen fields in one repeatable order and use a consistent separator, such as a hyphen or underscore, that works reliably in the intended storage environment. Check: comparable file names should display the same fields in the same order.
3. Standardize date and version notation. Choose one date format and one version pattern when those attributes are relevant; for example, a system might use YYYY-MM-DD for dates and v01, v02, v03 for successive versions. Check: the same type of date or version should not appear in competing formats within the same naming system.
4. Assign a persistent record ID. Give each record a unique stable identifier that does not depend on its descriptive file name, such as EV-014 for an event record. Check: changing a subject label, date description, or file version should not require changing the record ID.
5. Apply and verify the convention. Use the naming convention and record ID together whenever a record is created, renamed, cross-referenced, or updated. Check: confirm that the file name follows the chosen pattern and that every cross-reference still points to the same stable ID.

Descriptive fields can change when a clearer subject label, corrected date, or new version makes the file name more useful, but the record ID should remain persistent so existing references do not have to be rewritten.

For example, a hypothetical file-label pattern could be case-a-event-note-2025-04-12-v02.txt, using subject, record type, date, and version separated by hyphens, while its independent record-ID pattern could remain EV-014.

Those examples illustrate one workable structure rather than a universal standard; the governing requirement is consistent execution across the case file.

Keep File Names Descriptive, Consistent, and Easy to Retrieve

A descriptive file name should identify and group a file without requiring it to be opened.

Include only stable, meaningful fields that help distinguish the record, and apply the same naming pattern consistently so retrieval does not depend on remembering an individual filename.

Select fields according to what users need to scan or sort, then keep their order predictable across comparable files.

Use a separator consistently rather than treating any one character as mandatory, and keep the date format and version notation consistent when those fields materially distinguish records.

Where files move between systems, simple machine-readable characters and limited special characters can improve portability, subject to the requirements of those systems.

Avoid names that become excessively long or repeat information that does not improve identification or retrieval.

• Case identifier: include it when the file must be grouped with other material from the same case, giving related files a shared identity during retrieval.
• Subject: use a person, topic, location, or other concise subject label when it materially distinguishes the file from similar records in the same case.
• Material type: identify the record content, such as an interview note, image, transcript, or document, so files can be grouped by function without opening them.
• Date: include a date when chronological sorting or identification depends on it, and use one consistent date format within the naming convention.
• Version: use a clear version value when successive forms of the same file must remain distinguishable; a version such as v02 is more informative than an ambiguous label such as final.
• Separator and characters: use one predictable separator and readable character set that works across the intended storage systems, avoiding unnecessary special characters that may reduce portability.

More explicit

CASE-A_person-x_interview-note_2026-03-14_v02.docx

Case identifier, subject, material type, date, and version are visible, making the file easier to identify, sort, and retrieve.

Less specific

person-x-notes-final.docx

The case identifier and date are absent, the material type is broad, and final does not show where the file sits in a version sequence.

Assign Stable IDs for Cross-Referencing

A stable record ID is the persistent identifier for a record: it remains unchanged when the filename, descriptive label, or other editable details change, so later cross-references still resolve to the same record.

For example, a hypothetical event record could use EV-014, while claim record C-021 stores EV-014 as its cross-reference. The identifier identifies the linked record; it does not prove, validate, rank, or establish the evidentiary status of its contents.

Track Each Claim, Its Source, and Its Research Status

A claim register records what is being asserted, where the claim came from, and its current research status while keeping the underlying source trail recoverable.

Each claim should have its own claim ID linked to the relevant source ID and source location so later review can return to the exact material behind the entry.

The register supports traceability and follow-up rather than treating a status label as a statement of final truth.

For each claim, record concise claim text, the linked source ID or IDs, the precise source location available for each reference, the current research status, any unresolved issue, and the date last reviewed.

A research status should describe a documented condition: for example, unresolved when the available material does not yet support a clear assessment, supported when linked material currently supports the recorded claim, or contradicted when linked material conflicts with it.

Each state should lead to an explicit follow-up action rather than implying certainty from the label alone.

The claim register can therefore expose both the current state and the remaining research work.

Claim ID	Claim text	Source ID and location	Research status	Unresolved issue	Last reviewed	Follow-up
C-031	Hypothetical claim about an event detail	S-014, recorded page or section locator	Unresolved	Only one reporting source is currently linked	2026-09-28	Locate additional relevant material and review the claim again
C-032	Hypothetical claim with linked supporting material	S-018 and S-022, separate recorded locators	Supported	No specific contradiction is currently recorded	2026-09-29	Retain the source trail and review if new material changes the documented condition
C-033	Hypothetical claim with conflicting material	S-025, recorded locator	Contradicted	The linked material conflicts with the recorded assertion	2026-09-29	Flag the conflict for further review without rewriting the earlier record history

When new information changes the documented condition of a claim, update its current research status while retaining the earlier revision so the previous state remains recoverable.

For example, a hypothetical claim may move from unresolved to supported after a second source ID and precise source location are added, while the earlier unresolved entry remains part of the revision history.

The last-reviewed date and unresolved issue should be updated at the same time so the next follow-up reflects the latest record state.

This preserves traceability through status changes without presenting the register itself as a verification method.

Connect Each Claim to Its Supporting Source

Each claim-to-source link should connect a claim ID to the exact source ID and, where available, a precise source locator such as a page, paragraph, timestamp, record entry, or other retrievable location.

Recording both the source reference and locator gives another reader a direct path back to the relevant material, improving retrieval, review, and traceability without treating the citation itself as verification.

• Reported by: use this reporting relationship when the source contains or repeats the claim, without implying that the source independently supports its accuracy.
• Supported by: use this relationship when the source contains material that supports the recorded claim under the current research conditions.
• Corroborated across sources: use this relationship only when multiple source records independently support the same relevant assertion; if a source conflicts with it, record that source as contradicting rather than hiding the disagreement.

For example, hypothetical claim C-041 could point to source S-017 at page 12, paragraph 3 with the relationship reported by, while source S-024 points to timestamp 00:18:42 with the relationship supported by.

If both sources independently support the same assertion, the claim record can note corroboration across those source links; if S-024 instead conflicts with the claim, its relationship should be recorded as contradicted while the S-017 reporting link remains intact.

Keeping each source ID, source locator, and relationship state separate preserves the full traceability of agreement and conflict without turning source linkage into a source-quality judgment.

Record Unresolved Information and Research Gaps Separately

An unresolved information record should keep every unresolved issue or research gap separate from settled case notes so uncertainty remains visible rather than being absorbed into the case narrative.

Use it for a conflicting account, missing record, uncertain date, unverified association, or other open question, and link the item to each affected claim, event, person, or source through its related record ID.

Missing information means the record is not currently available; it is not evidence that the record or event did not exist.

Each gap record should identify what is known, why the issue remains unresolved, what evidence is needed, and the next research action that could change its status.

A missing-information status indicates that required material has not been located, a conflicting-information status records incompatible accounts or records, and an uncertain status indicates that available information permits more than one interpretation or level of precision.

These classifications document the present condition without converting speculation into fact or treating an unresolved status as a conclusion.

Gap ID	Unresolved issue	Related record IDs	Reason unresolved	Status	Evidence needed	Next research action
G-012	Hypothetical event date cannot yet be placed precisely	E-014, C-041	Two linked records give different dates	Conflicting information	A dated record or another source that clarifies the event date	Review additional dated material connected to E-014
G-013	Hypothetical referenced document has not been located	C-044, S-027	The source mentions the document but the document itself is unavailable in the current file	Missing information	The referenced document or a reliable record of its contents and origin	Trace the reference through the linked source record and update the gap if the document is found
G-014	Hypothetical association between two records remains unclear	P-006, E-019	The available material shows a possible connection but does not establish its nature	Uncertain	Additional material that clarifies whether and how the records are related	Keep the association qualified and review newly linked material

For example, an open question about the date of event E-014 can remain under gap ID G-012 while also linking to claim C-041, allowing both records to show that the date is still unresolved.

If later material resolves the conflict, update the gap's status and retain the earlier condition so the change remains traceable.

The status should change only when new information justifies a different documented condition.

Cross-Reference People, Events, Claims, and Evidence

A cross-reference connects distinct records so a researcher can move from a person, event, claim, or source to the directly related records without duplicating their full content.

Each link should use the relevant record ID and an explicit relationship label that states how the two records are connected.

This preserves each record's separate function while making the case file easier to navigate, retrieve, and review.

A cross-reference should be based on a documented relationship rather than similarity, narrative convenience, or an inferred association.

Use stable record IDs as the endpoints of each cross-reference, and choose a relationship label that describes the stored connection precisely, such as involved person, related event, supports claim, contradicts claim, or derived from source.

Where practical and supported by the file structure, a bidirectional reference can let each linked record point back to the other, reducing retrieval friction during later review.

The reverse link should describe the same documented relationship from the appropriate record perspective rather than inventing a second relationship.

If a record is updated, the stable IDs allow the reference to remain intact without copying the changed content into every linked record.

From-record ID	Relationship label	To-record ID	Retrieval implication
P-006	Related event	E-019	The person record can retrieve the documented event connection without duplicating the event record
E-019	Related claim	C-044	The event record can retrieve the claim associated with that occurrence
C-044	Derived from source	S-027	The claim can be traced to the source record from which the recorded statement or material was taken

In this hypothetical chain, person P-006 links to event E-019, the event links to claim C-044, and the claim links to source S-027.

Each relationship remains explicit and separately reviewable, so another researcher can follow the chain in either supported direction without treating proximity between records as proof of guilt, causality, or any undocumented association.

The result is stronger traceability and retrieval while keeping the underlying records auditable and non-duplicative.

Keep the Case File Current as Research Changes

A case-file update routine should apply new information only to each affected record while keeping the prior state recoverable.

Treat every maintenance update as a controlled revision: identify what changed, which record ID is affected, what the revised state becomes, and the documented reason for that change.

1. Intake the new information: record the new material and identify the specific claim, event, gap, source, or relationship it may affect. Check: confirm that the material has been associated with the correct case before changing any existing record.
2. Identify affected record IDs: list each affected record before editing so the update remains limited to records whose attributes or relationships may change. Check: unrelated records should remain outside the revision scope.
3. Update or add the necessary record: revise the affected attribute or relationship, or add a new record when the new information represents a genuinely distinct entity, event, claim, source, or supporting item. Check: preserve the prior state so the earlier record condition remains recoverable.
4. Review claim or gap status: revise a status only when the new information justifies a different documented condition; otherwise retain the existing uncertainty. Check: the revised state should match the available information rather than assume resolution.
5. Refresh cross-references: update the relevant cross-reference when the new information changes how records relate to one another. Check: every affected link should still point to the correct record ID and relationship.
6. Record the revision: document the prior state, revised state, affected record IDs, and documented reason for the change. Check: another reviewer should be able to distinguish the new information from the earlier interpretation without reconstructing the entire file.

For example, a newly found source might justify revising one claim's status and adding a new reference to one event while leaving unrelated people, claims, and supporting records unchanged.

The maintenance check is therefore not whether the whole case file changed, but whether every affected record reflects the new information, preserves its prior state, and retains consistent cross-references.

Log Revisions Without Overwriting Earlier Research States

A revision log preserves the history of a record by documenting what changed, when the change was made, and the documented basis for the revision while retaining the previous state.

This allows later review to reconstruct the sequence of corrections and status changes without assuming that the log provides safeguards beyond the way the case file is maintained.

Revision date	Record ID	Changed attribute	Previous state	New state	Reason	Source reference
2026-09-30	E-014	Event date	2026-04-12	2026-04-13	Hypothetical newly reviewed source records a different date	S-032, recorded locator

Each revision entry should identify the revision date and record ID, name the changed attribute, preserve the previous state, record the new state, and document the reason and source reference supporting the change.

The previous value or status should remain recoverable so another reviewer can distinguish the earlier research state from the later correction.

In this hypothetical example, event record E-014 retains its earlier recorded date while the revision history shows that the event date changed because source S-032 supplied the documented basis for the correction.

The revision log therefore preserves traceability by keeping both states and the reason for the change available for review.

Review the Case File for Completeness and Traceability

A case-file completeness and traceability review checks whether the organizational system can retrieve records and trace important claims without relying on memory.

It verifies observable structural conditions such as identifiers, links, maintenance records, and retrieval paths; passing these checks supports organizational usability rather than establishing factual accuracy.

Evaluate each condition as a pass or a targeted follow-up.

A failed structural check should identify the specific record, missing link, or maintenance issue that needs correction rather than reopening the broader research or corroboration process.

• Stable IDs: confirm that every record has a stable ID and that referenced record IDs still resolve to the intended records. Pass: each identifier is unique and retrievable. Follow-up: assign or correct the affected identifier and repair references that point to the wrong record.
• Consistent filenames: confirm that comparable files follow the established consistent filename pattern for the case file. Pass: filenames use the expected fields, order, and notation. Follow-up: rename only the inconsistent files while preserving their stable record IDs.
• Claim-source links: confirm that each material claim-source link connects the claim to its source record and available source locator. Pass: the claim can be traced directly to the linked source material. Follow-up: add or repair the missing source reference or locator.
• Connected people and events: confirm that each documented person-to-event, event-to-claim, or other connected record relationship uses an explicit relationship label. Pass: directly related records can be retrieved through their documented links. Follow-up: add the missing cross-reference or correct an unsupported relationship label.
• Unresolved items: confirm that every unresolved item remains explicitly marked with its current status, related records, reason for uncertainty, and required follow-up. Pass: uncertainty is visible rather than folded into settled notes. Follow-up: create or update the gap record without converting the unresolved condition into a factual conclusion.
• Revision history: confirm that material changes are represented in the revision log with the previous state, new state, record ID, reason, and source reference where applicable. Pass: earlier research states remain recoverable. Follow-up: restore the missing revision entry or document the change basis before further editing.
• Retrievability: confirm that a reviewer can retrieve each important record through its record ID, filename, or documented cross-reference without depending on personal memory. Pass: the retrieval path is explicit and repeatable. Follow-up: repair the identifier, filename, storage reference, or record link that blocks retrieval.
• Orphaned records: identify any orphaned record that has no documented connection to the case overview or to another relevant record where such a relationship should exist. Pass: each in-scope record has a justified place in the case-file structure. Follow-up: add the missing documented link, clarify why the record stands alone, or remove it from the case file if it falls outside the defined scope.

Failed checks should trigger targeted corrections to the relevant records and links rather than a wholesale restructure of the case file.