### Import War Diaries ###

War diaries are uploaded into the system via the Frame 44 UI or Frame 44 plugin. Before uploading, the user is responsible for ensuring pages are in the correct order and that the diary has been separated by month. A warning is displayed at upload reminding the user of these requirements.

**Inputs:**
- PDF or JPEG of a war diary, separated by month

**Process:**
- User uploads the document via the Frame 44 UI or Frame 44 plugin
- JPEG uploads are assembled into a single PDF; user confirms page order is correct before proceeding
- User assigns the document to an existing unit or creates a new unit record
- User records provenance metadata: archive source, unit ID, date range, and digitisation quality
- User is presented with a thumbnail gallery of all pages and tags the narrative page range (e.g. pages 7–35)
- Document and metadata are stored server-side

**Outputs:**
- PDF stored server-side with status set to "pending OCR"
- Provenance metadata record linked to the document
- Narrative page range tag stored as metadata, to be used downstream to split and classify document content

**Desired Result:**
- Every document entering the pipeline has a clean, confirmed page order, known provenance, and a human-verified narrative boundary before any automated processing begins

### OCR War Diaries ###

Once a document is imported and the narrative page range is confirmed, the system automatically processes the full document through an OCR pipeline. The OCR pipeline has one job: extract accurate text from every page.

Human verification of OCR output is a critical quality gate for narrative pages. Raw OCR, however accurate, will contain errors that only a human reviewer with historical context can reliably identify and correct — misspelled place names, misread rank abbreviations, ambiguous handwriting. The OCR editor (described in the next step) is where this verification happens. Verified OCR is the foundation everything downstream depends on — RAG quality, position extraction accuracy, and report generation all degrade if the underlying text is wrong.

Non-narrative pages follow a separate track. These pages — appendices, patrol reports, message logs, and similar documents — are useful as supporting context even without human verification and proceed directly to classification and RAG chunking without a human verification gate.

**Inputs:**
- PDF with confirmed page order
- Narrative page range metadata

**Outputs:**
- Raw OCR text per page stored in the database
- Narrative pages set to status "pending review" and queued for the OCR editor
- Non-narrative pages set to status "pending classification" and queued for document classification and RAG chunking

**Desired Result:**
- Every page in the document has a raw OCR text record in the database
- Narrative and non-narrative pages immediately split into their respective tracks and proceed in parallel
- Narrative pages do not enter downstream processing until human verified
- Non-narrative pages begin contributing to the RAG pipeline without delay

### Document Classification ###

Non-narrative pages — everything outside the narrative page range tagged at import — are automatically classified into document types after OCR. Narrative pages are already classified at import and do not pass through this step.

Document type determines how a page is processed downstream. Patrol reports, message logs, and sitreps are highly relevant for mapping and semantic search. Nominal rolls and casualty returns are primary sources for personnel extraction. Appendices and traces provide supporting spatial context. Each document type follows a processing path appropriate to its content and relevance.

Classification confidence is scored automatically. Low-confidence classifications are flagged for human review. Human-verified classifications feed back into the system to improve automated classification accuracy over time.

**Inputs:**
- Non-narrative pages as defined by the narrative page range tag from import
- Page images for visual classification where OCR text alone is ambiguous

**Outputs:**
- Document type tag per page (message log, intel report, newsletter, Part 1 Orders, nominal roll, appendix, sitrep, patrol report, trace, etc.)
- Confidence score per classification
- Low-confidence pages flagged for human review
- Verified classifications fed back into the system to improve future accuracy

**Desired Result:**
- Every non-narrative page has a document type tag before entering the RAG pipeline
- Document type metadata travels with each page through all downstream processing, enabling filtered search and type-appropriate chunking
- Classification accuracy improves continuously as human-verified examples accumulate

### OCR Editor ###

Verified narrative OCR is the quality gate that all downstream processing depends on. The OCR editor is a human-facing tool that allows reviewers to compare the original page image with the raw OCR text and make corrections before the page is released to downstream processing.

The editor presents a work queue of narrative pages with status tracking — pending, in progress, and verified. Reviewers can see the overall progress of each war diary and pick up work from where they or another reviewer left off. Changes are tracked per user for basic version control.

A page is not released to downstream processing until it is marked verified by a reviewer.

**Inputs:**
- Raw OCR text of narrative pages with status "pending review"
- Original page images for side-by-side comparison

**Outputs:**
- Verified OCR text per page stored in the database
- Narrative pages set to status "verified" and queued for entity extraction and RAG chunking
- Edit history per page tracking which user made which changes

**Desired Result:**
- Every narrative page has been reviewed and corrected by a human before entering downstream processing
- Reviewers have a clear view of what needs to be done and can collaborate without duplicating effort
- Verified OCR text is the single source of truth for all downstream steps including entity extraction, RAG chunking, and report generation

### Entity Extraction — Personnel ###

After OCR is verified, the system extracts personnel names and ranks mentioned in the narrative text and stores them as structured records linked to the source diary entry.

**Inputs:**
- Verified OCR text of narrative pages

**Outputs:**
- Structured record per mention containing: name, rank (where present), context snippet, source diary entry, date, unit
- Unresolved or ambiguous names flagged for human review

**Desired Result:**
- A descendant or researcher can search by surname and retrieve every diary mention of that person across the corpus, with date and unit context
- Personnel records are linked to the source diary entry, enabling the full narrative passage to be surfaced alongside the structured record

### Entity Extraction ###

After narrative pages are verified in the OCR editor, and after non-narrative pages are classified, the system automatically extracts structured entities from both tracks. Entity extraction runs without a human gate on both tracks — non-narrative pages proceed automatically after classification, narrative pages proceed automatically after verification.

Extracted entities are the structured layer that sits between raw text and downstream products. Every entity record is linked to its source page and RAG chunk, enabling any downstream product to surface the full source passage alongside the structured record.

The following entity types are extracted:

- **Personnel** — names and ranks mentioned in the text, linked to source diary entry, date, and unit
- **Place names** — locations mentioned in the text, passed to the gazetteer for resolution to modern coordinates
- **Grid references** — WWII map grid references extracted from text, passed to grid reference extraction and verification for coordinate resolution
- **Unit mentions** — references to friendly, allied, and enemy units, linked to source diary entry and date
- **Events** — operationally significant events such as attacks, patrols, reliefs, casualties, and objectives

Low-confidence or ambiguous extractions are flagged for human review across all entity types.

**Inputs:**
- Verified OCR text of narrative pages
- Classified non-narrative pages (nominal rolls, casualty returns, patrol reports, message logs, etc.)

**Outputs:**
- Structured entity records per extraction containing: entity type, value, context snippet, source page, source RAG chunk, date, and unit
- Ambiguous or low-confidence extractions flagged for human review

**Desired Result:**
- Every entity mentioned across the full corpus — personnel, places, grids, units, and events — has a structured record in the database linked to its source
- Entity records are the primary input for the gazetteer, grid reference verification, and all downstream search and report generation
- Non-narrative pages contribute entities to the corpus immediately after classification without waiting for human verification

### Gazetteer ###

As place names are extracted from verified narrative text, the system builds a gazetteer — a controlled reference list of place names encountered in the diaries, resolved to modern coordinates and standardised spellings. The gazetteer grows and improves as more diaries are processed, and feeds back into improving future place name extraction across the corpus.

Place name candidates are spatially constrained against known unit positions on the date of the diary entry, and corroborated across multiple diary entries from different units. Low-confidence matches are flagged for human review by volunteers.

**Inputs:**
- Extracted place name records from entity extraction
- Known unit positions with date and confidence level
- Modern GIS place name datasets (OpenStreetMap, GeoNames, national topographic data)

**Outputs:**
- A gazetteer record for each resolved place containing: all variant spellings encountered, resolved modern coordinate, confidence score, and source diary entries that corroborate the match
- Unresolved place names flagged for human review

**Desired Result:**
- A living reference dataset that grows and improves as more diaries are processed
- Variant and archaic spellings (phonetic, French, Flemish, German) are all linked to a single canonical modern place, so a user searching any variant surfaces the same results
- Gazetteer feeds back into improving future place name extraction across the corpus

### RAG Pipeline ###

The RAG pipeline is the core retrieval infrastructure that powers all downstream products and search capabilities. It ingests verified narrative text and classified non-narrative pages as two separate tracks, chunks them into searchable segments, and stores them in a GIS-enabled Postgres database with vector search capabilities. All downstream products — descendant reports, semantic search, museum portals, battlefield tours — query this single system to retrieve relevant content.

Both tracks arrive with metadata from earlier pipeline steps: document type, unit, date, confidence level, and entity extraction records. This metadata is stored alongside each chunk and enables precise filtered retrieval — by unit, date range, document type, personnel name, or any combination. Spatial capabilities are enriched further in the grid reference verification step described later in the pipeline.

**Inputs:**
- Verified narrative OCR text with entity extraction records
- Classified non-narrative pages with document type tags

**Outputs:**
- Chunked and embedded text segments stored in Postgres with pgvector and PostGIS
- Each chunk carries metadata: source document, page, unit, date, document type, confidence level, and linked entity records
- Chunks are retrievable by semantic similarity, metadata filter, spatial query, or any combination in a single query

**Desired Result:**
- The full corpus — narrative and non-narrative, verified and classified — is queryable in a single system
- Any question about a unit, date, location, person, or event can be answered by retrieving the most relevant chunks across the entire corpus
- Semantic search, spatial search, and metadata filtering operate together in a single query without requiring separate systems
- All downstream products query a single pipeline, ensuring consistency across reports, search, and mapping outputs

### Grid Reference Extraction and Verification ###

Grid references and place names identified during entity extraction are resolved to real world coordinates and plotted as positions. Positions are linked to the RAG chunk they came from via a foreign key relationship, enabling map and text to be navigated together — a position on the map surfaces the diary passage it came from, and a search result can surface its position on the map.

**Extraction — Automated**

Grid references extracted from verified narrative text and classified non-narrative pages are automatically resolved to coordinates using WWII map projections and the known 100,000m grid square the unit was operating in at the time.

**Inputs:**
- Grid reference and place name records from entity extraction
- Known unit positions with date

**Outputs:**
- Candidate positions stored in Postgres with PostGIS, linked to source RAG chunk
- Each position carries: coordinate, source diary entry, date, unit, position type, confidence level, and relevance category
- Unverified positions set to status "pending verification"

**Verification — Human**

Positions are not always accurate at extraction and require human verification before they are considered reliable. A reviewer confirms or corrects each candidate position against reference materials. Verified positions are released for use on the web map and in downstream products.

Positions carry a confidence tier:
- **Level 1** — verified by a human
- **Level 2** — high confidence, not yet human verified
- **Level 3** — low confidence, requires human verification

Positions are categorised by type — end of day position, patrol position, enemy position, objective, etc. — and by relevance — whether the position describes the unit's own activity or references another unit or location.

**Outputs:**
- Verified positions stored in Postgres with PostGIS, linked to source RAG chunk
- Position type and relevance category tags
- Confidence tier updated to Level 1 on verification

**Desired Result:**
- Every grid reference and place name in the corpus has a candidate position in the database
- Verified positions are spatially accurate and linked back to their source diary entry
- Positions are filterable by type, confidence, relevance, unit, and date
- The map and the text are mutually navigable via the foreign key relationship between positions and RAG chunks 

### Document Versioning and Corpus Expansion ###

The corpus is never static. Better quality scans of existing documents are found over time, and new documents belonging to existing units and date ranges are discovered across different archives and digitisation projects. This section describes how both scenarios are handled.

**Scenario 1 — Higher Quality Scan of an Existing Document**

When a better quality scan of an existing war diary is found, the stored source image is replaced with the new scan. No downstream data is affected — OCR text, entity extraction records, RAG chunks, and positions are all untouched. The link between the text and the source image is updated to point to the new scan.

Source image quality matters because users can read the original documents page by page alongside the verified narrative text, and may download the original scans for their own research. A higher quality scan improves that experience without requiring any re-processing.

**Inputs:**
- Higher quality scan of an existing document (PDF or JPEG)
- Existing document record in the database

**Outputs:**
- Source image updated in the database
- All downstream records remain intact and unchanged

**Scenario 2 — New Documents Found**

New documents belonging to an existing unit and date range — a separately filed patrol report, a message log from a different archive, a second copy of a war diary with different appendices — enter the pipeline via the standard import step. They are assigned to an existing unit and appended to the corpus. No replacement occurs and no existing records are affected.

**Inputs:**
- New document uploaded via the standard import pipeline
- Assigned to an existing unit record

**Outputs:**
- New document processed through the full pipeline from import onwards
- All outputs appended to existing unit records in the database

**Desired Result:**
- The corpus improves continuously as better scans and new documents are found
- Users can always access the highest quality version of the original source document
- Users can read original documents page by page alongside verified narrative text and download scans for their own research
- New documents discovered across archives slot cleanly into the existing corpus without disrupting any existing data

### Secondary Sources ###

Secondary sources — published histories, regimental histories, and operational studies — are ingested as a distinct document class alongside primary war diary material. They provide authoritative contextual reference that enriches RAG retrieval and report generation, particularly for operational context that individual unit war diaries do not capture.

Secondary sources are clearly attributed in every record so downstream products always distinguish between primary source material and secondary literature.

Where a secondary source exists as clean digital text it proceeds directly to entity extraction and RAG chunking without OCR. Where only a scanned copy exists it passes through the OCR pipeline before proceeding, without a human verification gate.

Secondary sources are assigned to the theatre and formations they cover rather than to a specific unit. For example, Stacey's *Victory Campaign* covers II Canadian Corps and all child formations for Northwest Europe, while the Italian theatre corpus covers I Canadian Corps exclusively. This assignment ensures RAG retrieval correctly surfaces secondary sources when querying any unit within the relevant formation and theatre.

Entity extraction runs on all secondary sources, capturing place names, personnel, unit mentions, and events. Extracted place names and grid references feed into the gazetteer and grid reference verification steps, providing additional corroboration alongside primary source extractions.

Unit relationship mapping — the parent/child hierarchy between formations — is handled by Project '44's existing unit infrastructure and is outside the scope of this pipeline.

**Inputs:**
- Clean digital text of published secondary sources, or scanned copies where digital text is unavailable
- Theatre and formation assignment

**Outputs:**
- Secondary source records ingested into the RAG pipeline, attributed as secondary literature
- Entity extraction records for personnel, place names, unit mentions, and events
- Extracted place names and grid references passed to the gazetteer and grid reference verification steps

**Desired Result:**
- Every RAG query can draw on both primary war diary material and relevant secondary literature in a single retrieval pass
- Secondary sources provide operational and contextual depth that individual unit war diaries cannot supply on their own
- Attribution is always clear — users and downstream products always know whether a source is a primary diary or secondary literature

### Semantic Search ###

Semantic search is the capability layer that sits between the RAG pipeline and all customer-facing products. It powers every downstream use case — descendant reports, museum portals, battlefield tours, academic research, and more. It can also be exposed directly as a standalone product for researchers, institutions, and internal use.

Semantic search combines natural language vector search with structured SQL filtering and spatial queries in a single pass against the Postgres database. A query is never purely semantic or purely structured — all filters operate together, returning results that are both contextually relevant and precisely constrained.

Users can enter the corpus from multiple starting points:

- **Natural language** — "Calgary Highlanders crossing the Leopold Canal October 1944"
- **Unit-first** — browse or filter by unit, formation, or theatre
- **Date-first** — filter by date range across any unit or theatre
- **Location-first** — draw a bounding box on a map or search by place name to return everything that happened in a geographic area, regardless of unit
- **Person-first** — search by surname to surface every mention of a specific individual across the corpus

Results are returned as both narrative text and mapped outputs. A search result surfaces the relevant text chunk with full source attribution alongside mapped positions, period map overlays, referenced reports, and related records such as photographs. Users who know military history can search unit-first; users who only know a place can search spatially. Both entry points return the same richness of output.

Access tiers control what each customer type can search, filter, and export. Public users, authenticated researchers, and institutional customers operate within different permission levels.

**Inputs:**
- Natural language query
- Structured filters: unit, date range, theatre, document type, confidence level
- Spatial input: bounding box or place name
- Any combination of the above

**Outputs:**
- Relevant text chunks with source attribution: document, page, unit, date, document type
- Mapped positions linked to returned chunks
- Period map overlays applicable to the search area and date range
- Referenced reports and related records surfaced alongside results

**Desired Result:**
- Any question about any unit, person, place, or event across the entire corpus can be answered in a single query
- A researcher who knows a unit name and a civilian who only knows a place name both get equally rich results from different entry points
- Text and map are always returned together, giving every result both narrative and spatial context
- The same search infrastructure powers every downstream customer product consistently

### Access Tiers ###

Access to the corpus is controlled by subscription tier. Every customer product — museum portals, descendant reports, academic research, battlefield tours — operates within the corpus scope defined by the customer's tier. Higher tiers unlock broader search scope, richer outputs, and greater export capability.

Report and output quality is never deliberately constrained by tier. The system always produces the best possible output given available data. Output richness is a function of input completeness — a customer who can provide unit, date range, and surname will always receive a richer result than one who can only provide a theatre and a year. Tiers control scope, not quality.

**Tier 1 — Unit Scoped**
Search and outputs are limited to a single unit and directly related formations. Designed for regimental associations, unit museums, and organisations focused on a specific unit's history.

**Tier 2 — Theatre or Campaign Scoped**
Search and outputs are limited to a defined theatre or campaign. Designed for general museums, regional heritage organisations, and customers with a broader but still geographically constrained focus.

**Tier 3 — Full Corpus Access**
Search and outputs span all units, all theatres, and all date ranges. Designed for academic institutions, government bodies, and high value commercial customers requiring unrestricted access to the full corpus.

**Tier 4 — Full Corpus Plus Export and API Access**
All Tier 3 capabilities plus bulk export, GeoJSON export, and API access for integration into third party products and platforms. Designed for institutional partners and Frame 44 commercial products.

**Desired Result:**
- Every customer operates within a corpus scope appropriate to their use case and subscription
- No customer receives a deliberately degraded product — scope is constrained, quality is not
- Tier 4 enables Frame 44 and institutional partners to build their own products on top of the platform

### Token Cost Estimates by Customer Type ###

All customer interactions with the platform consume computational resources in two forms: database compute (semantic search, spatial queries, filtering) and LLM token usage (retrieval context and report generation). Database compute costs are minimal and consistent regardless of query complexity. Token costs vary significantly based on how much corpus material is retrieved and how much is generated in response.

**Cost per interaction type:**
- Simple semantic search, no generation: ~$0.01–0.03
- Search with short generated summary: ~$0.03–0.08
- Full narrative report with sourced retrieval: ~$0.10–0.25
- Full report with extensive cross-corpus retrieval: ~$0.25–0.50
- Map and position queries: database compute only, negligible token cost

---

**Project '44 Community Users**
High search frequency, low report generation. Community users browse, search, and follow threads of interest. They generate short summaries occasionally and full reports rarely.

- Estimated interactions per month: 20–50 searches, 2–5 short summaries, 0–1 full reports
- Estimated monthly token cost per user: $0.50–$2.00
- Subscription viability: viable at $5–10/month with query caps on full report generation

---

**Relative Research**
Low total interaction volume but report-heavy. A descendant typically conducts a focused research session, generates one or two full reports, and returns occasionally for follow-up searches. This is largely a one-time high-value interaction rather than a recurring high-volume use.

- Estimated interactions per session: 5–10 searches, 1–2 full reports
- Estimated cost per session: $0.50–$1.50
- Estimated lifetime cost per customer: $1.00–$3.00
- Subscription viability: viable as a one-time purchase or low monthly subscription with report generation limits

---

**Museum Staff Admin Panel**
Moderate regular usage. Staff run searches frequently to support exhibit development and research enquiries but generate full reports less often. Usage is spread across the working week rather than concentrated in single sessions.

- Estimated interactions per month: 50–100 searches, 5–10 short summaries, 2–5 full reports
- Estimated monthly token cost per staff user: $2.00–$5.00
- Subscription viability: viable at institutional subscription pricing, cost absorbed across staff team

---

**Museum Visitor Kiosk**
High volume, low cost per interaction. Visitors run a single focused search and receive a short generated summary. No full reports are generated at the kiosk — the full report is saved to Project '44 for home access. Volume can be very high at busy museums.

- Estimated cost per visitor interaction: $0.03–0.08
- Estimated daily visitor interactions at a busy museum: 50–200
- Estimated daily token cost: $1.50–$16.00
- Subscription viability: viable as a flat monthly institutional fee with per-interaction cost absorbed into the subscription cap

---

**Academic Research**
High volume, high complexity. Academic users run deep cross-corpus queries, retrieve large amounts of source material, and generate detailed attributed reports. This is the most token-intensive customer type.

- Estimated interactions per month: 100–300 searches, 10–20 full reports, frequent bulk retrieval
- Estimated monthly token cost per user: $10.00–$30.00
- Subscription viability: viable at Tier 3/4 institutional pricing, with API rate limits and query caps for bulk access

---

**UXO Search**
Low volume, spatially constrained, export-heavy. UXO professionals run focused geographic queries and export results. Interactions are infrequent but high value. Report generation is minimal — raw results and exports are the primary output.

- Estimated interactions per project: 10–30 spatial queries, 2–5 short summaries, minimal full reports
- Estimated cost per project: $0.50–$2.00
- Subscription viability: viable as a per-project or annual institutional subscription

---

**Media Research**
Moderate volume, report-heavy. Media researchers chase specific stories and generate narrative reports to support their work. Usage is project-based — intensive during production, dormant between projects.

- Estimated interactions per project: 20–50 searches, 5–10 full reports
- Estimated cost per project: $2.00–$8.00
- Subscription viability: viable as a per-project subscription or annual access for organisations with ongoing production

---

**Historical Mystery and Artifact Research**
Unpredictable volume, potentially very high retrieval cost. Cross-corpus aggregation queries pull large amounts of material from many sources. This is the hardest use case to cost-cap reliably.

- Estimated interactions per investigation: 50–200 searches, extensive cross-corpus retrieval, 5–15 full reports
- Estimated cost per investigation: $5.00–$25.00
- Subscription viability: viable at Tier 3/4 with query complexity caps and rate limiting to prevent runaway costs

---

**Key Principle:**
Subscription tiers control corpus scope. Query and report generation caps control token cost exposure. No customer type should be able to generate unbounded token costs within a fixed subscription — every tier includes defined limits on full report generation and bulk retrieval, with overage pricing for high volume users.

### Project '44 Community ###

**Actor:** Amateur historians, local heritage organisations, Dutch and Belgian community groups, Faces to Graves volunteers, students, and anyone with a general interest in WWII history who is not necessarily researching a specific relative.

**Need:** To explore, research, and contribute to a living archive of WWII primary source material. Community users approach the corpus from many different angles — following a specific battle, researching a local area, verifying a grave identification, or simply browsing out of historical curiosity. Many are also the volunteer contributor base that verifies OCR, confirms positions, and improves data quality across the platform.

**How They Use It:**
- Community users run natural language searches, browse by unit, date range, theatre, or geographic area
- Spatial search allows local community groups to find all documented military activity in their town, village, or region
- Faces to Graves volunteers can search by personnel name to find diary mentions of specific individuals and corroborate grave identifications
- Community users can contribute to the platform by verifying OCR text, confirming position classifications, and tagging document types — improving data quality for all users
- Premium and Patreon subscribers unlock deeper report generation, broader cross-corpus search, and higher query limits
- All community interactions are token-capped at the community tier to keep subscription costs viable

**Outputs:**
- Search results with source attribution across the corpus within community tier limits
- Short generated summaries for community tier users
- Full generated reports for premium and Patreon subscribers
- Contributor actions — verified OCR, confirmed positions, document tags — recorded and attributed to the contributing user

**Desired Result:**
- Project '44 becomes the go-to public resource for anyone interested in the WWII history of Northwest Europe and Italy
- Local communities in the Netherlands, Belgium, and Italy can explore what happened in their specific area during the war
- The community contributor base continuously improves data quality across the platform — OCR accuracy, position confidence, and document classification all improve as volunteer engagement grows
- Premium and Patreon tiers provide a sustainable revenue stream while keeping basic access open to the broader community
- The community layer feeds the commercial products — a community user who finds a reference to their relative becomes a Relative Research customer.
- 
### Relative Research ###

**Actor:** A family member or descendant researching a relative who served in a WWII unit covered by the corpus.

**Need:** To understand what their relative experienced during the war — where they were, what they did, what happened around them, and what the broader context of their service was. The customer may know very little about their relative's service or quite a lot. The system works with whatever they can provide.

**How They Use It:**
- Customer provides whatever information they have about their relative: name, unit, date range, service number, theatre, or any combination
- The system searches the corpus for mentions of the individual by name, and retrieves all relevant narrative, non-narrative, and secondary source material for the unit and date range provided
- A report is generated drawing on all retrieved material, placing the relative's unit in operational context and surfacing any direct mentions of the individual by name
- A map is generated alongside the report showing unit positions, patrol routes, objectives, and operational area for the relevant period
- Report and map are saved to the customer's profile for future reference
- Customer can order a printed version of the report and map through a drop shipping integration

**Outputs:**
- Generated narrative report with full source attribution
- Generated map with unit positions, routes, and operational context for the relevant period
- Applicable period map overlays
- Direct name mentions surfaced and highlighted within the report where found
- Report and map saved to customer profile
- Printable report and map available for drop shipping

**Desired Result:**
- Any descendant regardless of how much or how little they know about their relative's service can receive a meaningful, accurate, and personal account of what their relative's unit experienced
- Customers who provide more information receive richer, more personalised outputs
- The experience feels personal and specific — not a generic unit history but a account centred on the customer's relative and their unit's experience
- Customers have a permanent record of their research saved to their profile that they can return to, share, or have printed

### Museum Research ###

**Actor:** A military museum, regimental museum, or heritage organisation using the platform to support both internal staff research and visitor-facing experiences.

**Need:** Staff need a research tool to support exhibit development, historical enquiries, and institutional knowledge. Visitors need an engaging, accessible experience that connects them personally to the museum's unit or theatre without requiring prior military history knowledge.

**How They Use It — Staff Admin Panel:**
- Staff access an admin panel scoped to the museum's subscription tier
- Staff can run natural language queries, filter by unit, date range, and document type, and retrieve narrative and non-narrative material relevant to their research
- Staff can generate reports drawing on all corpus material within their tier scope
- Staff can save and organise research for internal reference and exhibit development

**How They Use It — Visitor Touchscreen:**
- Visitors interact with a touchscreen interface scoped to the museum's unit or theatre
- Visitors enter whatever information they have about a relative — name, unit, approximate dates — and the system searches the corpus for relevant material
- A report and map are generated and displayed in full on the touchscreen
- Visitors can save their results by entering their email address
- Saved results are stored on Project '44 and the visitor receives an email prompting them to create an account and access their report at home

**Outputs:**
- Staff: generated reports, search results, and saved research within tier scope
- Visitors: full generated report and map displayed on the touchscreen
- Visitors: results saved to Project '44 and emailed with an account creation prompt

**Desired Result:**
- Museum staff have a powerful internal research tool scoped to their collection focus
- Visitors have a personal, engaging experience that connects them to the museum's unit history through their own family connection
- Every visitor who saves their results becomes a potential Project '44 customer — the touchscreen experience is a direct acquisition funnel
- The museum delivers a richer, more personalised visitor experience without building or maintaining the underlying platform themselves

### Academic Research ###

**Actor:** An academic researcher, historian, graduate student, or university institution conducting research using primary and secondary WWII source material.

**Need:** Access to a deep, fully attributed corpus of primary and secondary source material that can be searched, queried, and cited with confidence. Academic users require complete provenance on every result — every chunk of text must be traceable to its source document, archive, unit, and date.

**How They Use It:**
- Researcher runs natural language queries or structured filtered searches across the full corpus
- Results are returned with full source attribution — document, archive, unit, date, and document type — suitable for academic citation
- Researcher can search spatially using a bounding box to find all activity in a geographic area across any unit or date range
- Researcher can search by personnel name to surface all mentions of a specific individual across the corpus
- Researcher can combine filters — unit, date range, theatre, document type — to narrow results to a precise research question
- Results can be saved to a research profile and organised by project or topic
- Tier 4 customers can export results and access the corpus via API for bulk queries and integration into their own research tools

**Outputs:**
- Search results with full source attribution suitable for academic citation
- Generated reports drawing on retrieved material with attributed sources
- Saved research organised by project or topic
- Tier 4: bulk export and API access

**Desired Result:**
- Researchers can answer precise historical questions across the full corpus in a fraction of the time traditional archival research would require
- Every result is fully attributed and citable — the platform is trustworthy as an academic research tool
- Spatial, temporal, unit, and natural language search entry points allow researchers to approach the corpus from any angle their research requires
- The platform surfaces connections across units, theatres, and date ranges that would be impossible to find manually across fragmented archival sources

### UXO Search ###

**Actor:** A UXO disposal company, military engineer, government body, or heritage organisation responsible for identifying, assessing, or clearing unexploded ordnance in formerly contested areas.

**Need:** To quickly locate all documented military activity, bombardments, mine laying, and munitions references within a specific geographic area, supported by primary source evidence traceable to its origin.

**How They Use It:**
- User defines a geographic area of interest using a bounding box on the map
- The system returns all positions, grid references, and diary passages referencing military activity within that area — artillery positions, mine laying, bombardments, defensive works, and similar activity
- Results are displayed as mapped positions with attached narrative passages from the source diary entries
- User can filter by activity type, date range, unit, and confidence level
- Position confidence tiers are clearly displayed — verified Level 1 positions are distinguished from unverified Level 2 and Level 3 positions
- Full source attribution on every result allows the user to trace findings back to the original primary source document
- Results can be exported for use in field assessments and official reports

**Outputs:**
- Mapped positions of all relevant military activity within the defined area
- Source diary passages attached to each position
- Confidence tier clearly displayed per position
- Full provenance on every result — document, archive, unit, date
- Exportable results for field assessment and reporting

**Desired Result:**
- UXO professionals can rapidly identify areas of documented military activity that may present ordnance risk, without manually searching fragmented archival sources
- Primary source evidence with full provenance supports official assessments and reporting requirements
- Position confidence tiers allow professionals to distinguish between verified and unverified locations and prioritise accordingly
- A tool that could directly contribute to public safety in formerly contested areas across Northwest Europe and Italy

### Media Research ###

**Actor:** A journalist, documentary filmmaker, author, or media organisation researching WWII events for publication, broadcast, or production.

**Need:** To find specific, vivid, well-attributed primary source material that supports a narrative they are developing. Media researchers are often chasing a specific story, event, or person rather than conducting broad historical research. They need compelling source material quickly and need to be able to cite it accurately.

**How They Use It:**
- Researcher runs natural language queries describing the story, event, or person they are researching
- Results surface relevant narrative passages, non-narrative documents, and secondary source material with full attribution
- Researcher can narrow results by date range, theatre, unit, or geographic area as their research develops
- Spatial search allows the researcher to find all documented activity around a specific location relevant to their story
- Personnel search surfaces all mentions of specific individuals across the corpus
- Generated reports can be produced drawing on retrieved material, providing a structured narrative overview with cited sources
- Results and reports are saved to a research profile and organised by project

**Outputs:**
- Search results with full source attribution suitable for publication citation
- Generated narrative reports with attributed primary and secondary sources
- Mapped positions and period overlays relevant to the story or event being researched
- Saved research organised by project

**Desired Result:**
- Media researchers can find compelling, specific, well-attributed primary source material in a fraction of the time traditional archival research would require
- The platform surfaces stories, events, and individuals that would be impossible to find manually across fragmented archival sources
- Every result is fully attributed — researchers can cite primary sources with confidence
- The corpus becomes a go-to resource for any media organisation producing WWII content covering the Northwest Europe and Italian theatres

### Historical Mystery and Artifact Research ###

**Actor:** A researcher, investigator, historian, or organisation attempting to locate specific objects, resolve undocumented historical events, or trace activities that have no clear archival resolution.

**Need:** To aggregate fragmentary references across a large corpus that individually appear insignificant but collectively point toward a resolution. No single diary entry solves the mystery — the value is in surfacing and connecting partial references across multiple units, dates, and locations that a manual researcher could never feasibly cross-reference.

**How They Use It:**
- Researcher runs natural language queries describing the subject of their investigation — an object, an event, a location, a unit action
- Results surface all relevant references across the full corpus regardless of unit or date, including passing mentions in non-narrative documents that a traditional researcher would never find
- Spatial search allows the researcher to constrain results to a geographic area of interest and map all documented activity within it
- Cross-unit search surfaces what neighbouring units were doing at the same time and place, providing corroborating or contradicting context
- Researcher can follow threads across the corpus — a reference in one unit's diary leads to a patrol report in another, leads to a message log in a third
- Results and generated reports are saved to a research profile and organised by investigation

**Outputs:**
- Aggregated search results across the full corpus with full source attribution
- Mapped positions of all relevant activity within a defined area
- Generated reports drawing on retrieved material with attributed sources
- Saved research organised by investigation topic

**Desired Result:**
- Researchers can surface and connect fragmentary references across the full corpus that would be impossible to find and aggregate manually
- The platform transforms the corpus from a collection of isolated unit histories into a connected, queryable record of everything that happened across an entire theatre
- Investigations that would take years of manual archival research can be conducted in days
- Every finding is fully attributed to primary sources, giving investigations an evidential foundation