Study Knowledge Base — no GUI REFERENCE SKELETON

This is the no-GUI equivalent of the old Copilot/Outlook wiki's "when a new email arrives in the study folder → file it" Power Automate flow. The difference: the trigger is a scheduled local script, not a cloud flow. Point it at your study mail once (an Outlook rule into a folder, or a subject/sender filter) and it files the entire study automatically — there is no flow to build, no SharePoint pages to click, and no AI Builder/Copilot credits. Dragging individual emails is only an ad-hoc fallback for the odd message that lives outside the study folder.

▶ Watch it work — a guided tour

At a glance

Try it — a 60-second interactive demo

A sandboxed simulation of the automatic loop. Your inbound Outlook rule decides what enters the CP-101 folder; the scheduled job reads that folder and files the whole batch at once — not one at a time. Watch the red item in the Inbox — a restricted lab-portal email your rule excepts by source: it stays put while the ops mail files itself. Press ▶ Run scheduled job, then add more mail and run again.

idle — press ▶ Run to simulate the next 15-min run

Illustrative only — it mimics the flow; it never runs PowerShell or touches a mailbox. The job files everything in the CP-101 folder — it doesn't read content for sensitivity. The control is your inbound rule, and it routes by source: the ops contacts land in the folder; the lab-portal item (a sensitive channel) is excepted by the rule, so it stays in the Inbox and is never filed. A rule can't classify content — it's a coarse filter, backed by ops-only policy and your review.

How it works

On each run the script connects to your already-open classic Outlook, reads the study folder(s) you named (or sweeps the Inbox by subject/sender), and files every message it hasn't filed before. It remembers what it's done in .state\seen.json (Outlook EntryIDs), so re-runs are idempotent and your mailbox is only ever read — nothing is moved, deleted, or marked. (EntryIDs are per-store, so mail you later move to an archive/PST can re-file as a harmless duplicate note — never data loss; the seen.json set is the idempotence key, so keep it.) OneDrive does the SharePoint upload, so there's no Graph/connector/API.

Set it up once

About ten minutes, once — then it runs itself. The screens below match classic Outlook for Windows; your version may look slightly different, but the option names are the same. You'll do three things:

① put the script in the synced folder  ·  ② make one Outlook rule so study mail lands in a folder  ·  ③ schedule the script. Step ② is the only fiddly part, so it's drawn out screen by screen.

You'll customize just four things. Decide them now and reuse them throughout (fill the middle column in — this page prints, too):

Wherever the steps below show CP-101 or C:\Users\you\Study Knowledge Base, use your values from this table.

Quick-start checklist — click each as you finish it (full details for every line are below):

• Copy Update-StudyKB.ps1 into your synced library folder
• Make a CP-101 folder in Outlook (right-click Inbox → New Folder)
• Create the rule: from your ops senders → move to CP-101, except sensitive channels / subjects
• Schedule it — paste the schtasks command
• Run it once — confirm [StudyKB] root = … then + Notes\… lines
• Open index.html in that folder — your searchable wiki

① Put the script where the wiki will live

② Make one Outlook rule (so study mail lands in a "CP-101" folder)

This keeps the knowledge base fed automatically and keeps participant data out — you route mail by who sent it into a folder the script reads.

No folder rule possible? You can instead point the script straight at your Inbox by sender: add -SenderContains "cro-bioanalytics" (a known ops distro/domain) when you schedule it. Prefer that over -SubjectContains "CP-101" — a subject tag also matches a participant email about CP-101. This path has no exceptions, so use it only when study mail comes from a clean, known sender.

③ Make the script run automatically

schtasks /Create /TN "StudyKB Update" /SC MINUTE /MO 15 /IT /F ^
  /TR "powershell.exe -NoProfile -ExecutionPolicy Bypass -File \"C:\Users\you\Study Knowledge Base\Update-StudyKB.ps1\" -StudyFolders CP-101"

powershell -NoProfile -ExecutionPolicy Bypass -File "C:\Users\you\Study Knowledge Base\Update-StudyKB.ps1" -StudyFolders CP-101

On new Outlook or a Mac? The automatic rule path needs classic Outlook. There, drag study emails into the _Inbox folder instead — see Ad-hoc capture and the README.

Ad-hoc capture (the exception, not the routine)

Almost everything files itself through the rule above. This is only for a one-off that never reaches the study folder — e.g. a thread someone forwards you from outside the study. Operations content only — never drop a participant-level, unblinded, or sponsor-restricted email in here. You put the email in the _Inbox folder and the next scheduled run files it. Two ways — Way 1 needs no setup.

Way 1 — Drag it into the _Inbox folder  (no setup · recommended)

Way 2 — A one-click toolbar button  (optional · needs Outlook macros)

Same engine either way — the drop folder just handles the messages automation can't see because they never reach the study folder. Ops content only — never drop a participant-level / unblinded / sponsor-restricted email in here.

Folder layout (auto-created)

<SyncedLibrary>\
  Notes\               <- one .html note per email (this is the KB content)
  index.html           <- the searchable wiki (rebuilt every run)
  _Inbox\              <- ad-hoc drop folder (the exception path)
  _Inbox\_processed\   <- ad-hoc originals moved here after filing
  .state\seen.json     <- which messages are already filed (EntryIDs)

A worked example (synthetic)

End to end on a made-up but realistic study-operations email for the placeholder study CP-101. Everything here is illustrative — no real study, no PHI.

1 · A study-ops email lands in the CP-101 folder

A bioanalytical CRO sends a logistics update; your one-time rule files it into the CP-101 Outlook folder. It's operational — timelines, a data transfer, the database-lock target — exactly what the KB is for.

From:    Jordan Lee <jordan.lee@cro-bioanalytics.example>  (Bioanalytical Project Lead)
Sent:    Fri 2026-06-19 16:42
To:      CP-101 Study Team
Subject: CP-101 — PK assay re-validation complete; transfer Mon, DBL on track

Hi team — re-validation of the CP-101 plasma PK assay is complete
(incurred-sample reanalysis passed, %CV within spec). We'll push the final
concentration transfer to the EDC on Monday 22-Jun. No change to the
database-lock target of Thu 25-Jun. Ping me if you want the validation memo.
— Jordan

2 · The next scheduled run files it — automatically

You do nothing. Within ~15 minutes the job reads the folder and files every new message (here, this one plus two others that arrived since the last run):

PS> .\Update-StudyKB.ps1 -StudyFolders CP-101     # (what the scheduler runs)
[StudyKB] reading Outlook folder "CP-101"
[StudyKB]  + Notes\20260619_164200__CP-101_PK_assay_re-validation_complete_transfer__7f3a9e21.html
[StudyKB]  + Notes\20260620_091500__CP-101_monitoring_visit_report_filed_2_action__b042c8d5.html
[StudyKB]  + Notes\20260618_173000__CP-101_EDC_extract_delivered_for_the_19-Jun__3e9170aa.html
[StudyKB] 3 new from Outlook, 0 from drop-folder; 47 total. Wiki: ...\index.html  ·  mail left untouched in Outlook

Illustrative — generated from the code path, not a recorded run. The real note name is yyyyMMdd_HHmmss__subject-slug__ + an 8-hex MD5 fragment of the Outlook EntryID. First adoption step is a supervised dry-run on one machine against a test folder.

3 · The note it writes

One self-contained HTML note lands in Notes\ — the email's metadata on top, the body below, ready to read or search:

4 · It shows up in the searchable index

Every run rebuilds index.html. Open it and search (Ctrl-F or the built-in filter) for DBL, assay, or CP-101 — alongside everything else the study has accumulated:

5 · Optionally, ask the KB (on-device, no cloud)

Point the on-prem model from tlf_interpret at Notes\ and you can ask in plain language — grounded only on the notes, on-device:

Q: When is the CP-101 database lock, and is it still on track?
A: Thu 25-Jun, on track. The PK assay re-validation finished 19-Jun
   (incurred-sample reanalysis passed); the final concentration transfer
   is Mon 22-Jun.            [source: 2026-06-19 note · Jordan Lee]

The model is constrained to quote and cite a note, and is used only for operational recall — any reported or regulated value always comes from the validated system, never from a note or the model, even when the model surfaces one.

Ask the knowledge base with a local model OPTIONAL · LATER PHASE

Not part of the core skeleton — the deliverable above is a deterministic file-mover with no AI. This is a later add-on; skip it in a first demo. That said: Notes\ is a small, clean corpus — good for an on-device assistant so you can ask questions over the whole study without any cloud. The flow: strip the HTML tags → embed → ask, all locally. A minimal recipe:

1. Plain-text the notes (one .txt per note). PowerShell, no extra tools:

   New-Item -Type Directory -Force "$Root\.rag" | Out-Null
   Get-ChildItem "$Root\Notes\*.html" | ForEach-Object {
     $t = (Get-Content -Raw $_) -replace '<[^>]+>',' ' -replace '&nbsp;',' ' -replace '\s+',' '
     Set-Content "$Root\.rag\$($_.BaseName).txt" $t.Trim() -Encoding UTF8
   }

2. Point your local model at .rag\ — the same on-prem GGUF used in tlf_interpret (llama.cpp / its server, with a small local embedding model). Retrieve the top notes for the question, pass them as context, and require the answer to quote and cite the note it used.
3. Keep it grounded: the model may only restate what's in the notes; a reported or regulated number is never sourced from a note or its summary — it comes from the validated system. (The notes already de-duplicate: one note per message, by EntryID.)

Fidelity & honest caveats

• Needs classic Outlook, open and signed in (the automation path). New Outlook / Mac → use the drop-folder or rule-export path instead.
• The script doesn't judge content. It files whatever is in the target folder/filter — so governance is in what you point it at. Keep participant-level mail out of the KB folder.
• Not validated software, structure-verified (not executed) in authoring — run/parse it on your Windows machine first.

If a script won't run (IT policy)

Preferred (production posture): have IT code-sign the script — or allowlist its path — which also satisfies change control. -ExecutionPolicy Bypass is the unsigned quick-start; note that ExecutionPolicy is an execution-convenience setting, not a security boundary (per Microsoft), so the signature/allowlist is the real control. If a run is blocked: Unblock-File .\Update-StudyKB.ps1 first; if still blocked, ask IT for the signature/allowlist. If your org blocks programmatic access to Outlook (the prompt never clears), the clean fix is to code-sign the script and trust that publisher in Trust Center ▸ Programmatic Access — keeping the object-model guard ON for everything unsigned — or fall back to the drop-folder path. No admin rights are otherwise needed.

If it's not working — quick fixes

Still stuck? Run the script by hand (the test in step ⑩) and read the [StudyKB] / WARNING lines — they say exactly what it did and didn't do.

Governance (unchanged)

Operations content only — no PHI, no participant-level data, no unblinded/sponsor-restricted material in the knowledge base. The auto-ingest files whatever reaches the study folder, and an Outlook rule can only filter by source and keywords — not by understanding content. So keep participant data out with a layered control, not one clever rule: (1) you review what's filed, and the KB is ops-only by policy; (2) route the folder from your operational senders/distros and except the sensitive channels (safety/PV, EDC/IVRS/randomization, unblinded-stats, lab portals); (3) it assumes a blinded operational mailbox — sensitive channels can reach a blinded inbox, so the except-list is a precondition, not a nicety; if the operator is unblinded by role, don't auto-ingest their Inbox. Reported or regulated numbers always come from validated tools, never from notes or an LLM summary of them.

What we're asking for

Not budget, not a new system, not production use — just approval to run a small, governed pilot:

• Scope: this tool, on one operator's blinded ops mailbox, one study — starting against a test folder. Operations content only.
• Footprint: nothing new to buy or stand up — it runs on the Microsoft 365 tenant and classic Outlook the team already has.
• Governance: IT signs/allowlists the script; a restricted, ops-scoped SharePoint site; a named owner reviews what's filed; validated tools still own every reported number.
• Decision: a go/no-go gate at the end of the window, judged on three things — the team can find the study's operational history, nothing participant-level ever lands in it, and no data-residency surprises.

It's the lowest-risk piece of the program — governed, reversible, and self-contained — which makes it the right place to prove the operating pattern (pilot → gate → decide) that the rest of the program follows. The wins it's after are shared team memory (the study's history survives someone being on leave), consistency (one searchable record instead of scattered inboxes), and speed of recall — with sensitive data kept in-tenant.

Browse the code

Scripts

Docs