Lab blueprint · AI safety in practice

VA Claims Record Workflow
Organize STRs and medical files without defaulting to public chat

A personal lab guide for veterans sorting hundreds of pages of service treatment records, private medical files, and claim notes. Local vault first. Then AI only at the security level you can actually run and afford.

Safety bar (absolute)

Humans decide. Models draft and retrieve. You and your accredited representative own what gets filed.
Cite the page. Prefer answers that point back to a file, date, and passage, not a confident summary with no source.
If it is not in the records, say so. Do not let a model invent service history, diagnoses, or ratings.
This is not legal or medical advice and not a guarantee of claim outcomes. It is a document handling pattern.

A VA disability claim often means hundreds or thousands of pages: Service Treatment Records (STRs), Blue Button exports, imaging, private care notes, and your own timeline. Language models are good at organizing that pilnd terrible at being trusted without a paper trail.

Pasting full medical packets into a consumer chatbot is usually the worst option: the text leaves your machine under terms you may not have read. The better habit is: build a local registry of facts you can check, then use AI at the strongest tier your hardware and budget allow.

Run as secure as you can afford

Not everyone has a GPU workstation. That is fine. Security is a ladder, not a purity test. Climb as high as you can; do not pretend a home tier tool is the same as fully offline.

TIER 1 · FREE / LOW COST · RECOMMENDED BASE

Local vault only (no AI required)

Keep everything in a folder on an encrypted drive (Obsidian or plain markdown). Search with built in find. Zero model risk. This alone beats a shoebox of PDFs. Do this first no matter which AI tier you pick later.

TIER 2 · HOME / BUDGET · DATA STILL LEAVES THE BOX

Careful hosted tools (when offline hardware is not realistic)

If you cannot run a local model, prefer developer style products with clear data terms over casual consumer chaor example Google AI Studio or similar large context tools used under the current nontraining / developer settings (verify the terms yourself; they change). Still: the text is processed off your machine. Treat it as a tradeoff, not “private.”

Set temperature to 0 for extraction work.
Upload the smallest chunk that answers the question, not your entire life in one paste.
Ask for structured markdown with file and date references you can verify.
Copy outputs into your local vault; do not keep the “source of truth” only in a chat history.

TIER 3 · BEST WHEN YOU CAN RUN IT · HIGHER HARDWARE COST

Offline / local LLM (Ollama, LM Studio, etc.)

After models are downloaded, embedding and chat can stay on your machine for daily use. 7B-8B class open weight models often need a capable GPU (roughly mid range NVIDIA with enough VRAM) or patience on CPU with lots of RAM. If you have that hardware, this is the stronger default for PHI. If you do not, Tier 1 + careful Tier 2 is still better than unthinking consumer chat.

The architecture

Raw records (STRs / Blue Button / imaging / private care)

  │

  ▼

Local vault (markdown folders you control)

  │

  ├── Tier 2: careful hosted model (optional, data leaves box)

  └── Tier 3: local LLM (optional, stays on machine after download)

  │

  ▼

Structured notes with [[wiki links]] + human review

  │

  ▼

What you actually file (you + accredited rep)

The vault is the product. The model is optional assistance.

Phase 1: Build the local registry

Create a folder such as VA_Claims_Registry on an encrypted volume. Prefer not putting it in a shared family cloud folder.
Subfolders that work well: 01_Timeline, 02_Conditions, 03_Exposures, 04_Claims, 05_Source_PDFs.
Group source files into logical packs (e.g. STR_History.pdf, Labs.pdf, Service_Chronology.pdf) before any AI step.
Open the folder as an Obsidian vault (or use any plain text editor). Cross link with [[Double_Brackets]].

Phase 2: Extraction prompt (any tier)

Whether you use a careful hosted tool or a local model, use a skeptical extraction prompt. Require structure you can check:

You help organize medical and service records. You do not invent facts.
If something is not in the provided files, write "NOT IN RECORDS"; never guess.

For the attached files only:
1. Build a service chronology (dates, units, locations) with source page refs.
2. List claimed or treated conditions vs. what appears in the problem list / notes.
3. Summarize lab trends only where numbers appear; cite the lab date.
4. Flag gaps a reviewer might care about (missing periods, intervening injuries, thin documentation), as questions to research, not conclusions.
5. Output markdown suitable for Obsidian, with [[wiki links]] for each condition and exposure.

Temperature: 0. Do not write claim language for the VA. Draft notes only.

Temperature 0 reduces (does not eliminate) creative drift. You still verify every important line against the PDF.

Phase 3: Human review before anything is “real”

Spot check dates, diagnoses, and lab values against the source PDFs.
Treat model “correlations” (e.g. exposures vs. labs) as hypotheses to research with your care team or rep, not proof.
Keep the registry under your control; chat history is not a filing system.

What this pattern is for

Finding contradictions, missing periods, unrated problems that show up in treatment notes, and weak spots a rater might probe, so you can gather the right pages. It is not a promise of ratings, and it is not a substitute for an accredited VSO, claims agent, or attorney when you need one.