v0.5.7 to v0.7.0

---

name: scholion

type: extension

runtime: python3

entry: plugin.py

plugin_api: "2.0"

os: any

permissions: [tool, fs, net, subprocess, widget, route]

env_from_settings: []

install_specs:

- kind: pip

when_to_use: The owner asks about their own medical data — check a new prescription as a second opinion (pharmacogenetics, interactions with the current regimen, monitoring labs), review laboratory results and trends, look up a locus or clinically significant ClinVar findings in their VCF, polygenic scores, longevity findings, sleep and lifestyle metrics, movement toward a health goal, which tests to take next, or a pre-visit summary.

timeout_sec: 120

---

# Scholion — a second opinion over your own medical data, locally

Scholion reads one person's genome (a full VCF), years of laboratory forms,

prescriptions and wearable exports **against each other** and shows where every

statement came from. It states plainly what the data **cannot** support — a

negative answer is qualified by coverage, not implied by silence.

**Not a medical device.** It does not diagnose, does not start or stop

therapy, does not adjust doses. Everything it produces is material for the

owner's own study and for a conversation with a physician.

## What the agent gets

- `check_prescription` — a new drug as a second opinion: pharmacogenetics,

interactions with the current regimen, monitoring labs, open questions for

the physician; its gene list comes through the body system the drug acts on

- `check_drug_gene` / `analyze_labs` / `suggest_tests` — the classic trio

- `system` — one body system as one card: laboratory now and its movement,

the genetic half and how much of it was read, prescriptions acting on it,

the clinician's target, what to test, what to ask; `screen` — a class of

disease gene by gene, never «clear» where a gene was not read

- `genome_lookup`, `clinvar_findings`, `acmg`, `prs`, `longevity`,

`lipid_genetics`, `array` — the genome layer, always with read-vs-assumed

status

- `overview`, `second_opinion`, `limits`, `radar`, `brief`, `focus`,

`phenoage`, `lifestyle`, `health_metrics`, `goal`, `goal_suggest`,

`provenance`, `flag_rate`, `sources` — the living picture and its honest

boundaries

than anything a model concluded: `ingest_labs` transcribes the owner's own

laboratory PDFs from a folder they named (never the current directory);

`focus_log` records what the person said happened on a day; `lab_draw`

records why one day holds two draws; `marker_propose` files a marker name as

so a background rebuild would die unfinished. It says so and names the command

- `version` / `update` — the installed build and whether PyPI has a newer one

(asked at most once a day). On this host the host installs the package, so

`update` installs nothing: it says that the host's catalogue brings the newer

build, rather than running pip in the host's interpreter. While a newer build

is out, one answer a day ends with a one-line note about it.

- The package starts local programs when they are installed — `bcftools` for

the genome, `pdftotext` / `pdftoppm` / `tesseract` for PDF forms — hence the

`subprocess` permission.

- `rules` — the safety canon this product is operated under, in full. A model

reaching Scholion through the tool interface is handed a list of tools and no

relaying anything from the other tools.

`limits` deserves a special mention: it answers "what can this data NOT say,

and what would close the gap" — call it before making any negative claim.

## Reaching it another way

**There is no key, token, account or credential for any of them**, and nothing

to authenticate against — the analysis runs on the machine that holds the data.

If a host asks for a Scholion credential, it is a host that assumes every tool

server is remote; leave the fields empty. The build answers this itself:

`scholion capabilities --json` carries an `access` block with every door and a

list, derived from its own source, of the environment variables it reads — none

of which is a secret. The full instructions are in

`scholion doc connecting-an-agent`.

## Setup

the first question a new owner has — where their files go:

- it names the data directory the host gave this skill, and the exact folder

for laboratory forms and for the genome;

- a button lays out that directory — empty templates plus a README in every

folder saying what belongs in it. It never overwrites anything that exists;

- if the owner's files already live somewhere, a field points at that folder

instead of copying them.

The layout it creates:

<data directory>/

profile/ the distilled state — written by the tools, not by hand

raw/lab/ laboratory forms, PDF or DOCX exactly as they arrived

raw/wearables/ the export archive from a watch

work/ archive/

The agent should point the owner at that tab rather than at a shell: on this

host the CLI the rest of this file mentions may not be on anybody's PATH.

To look around before bringing real data, the owner can run

`scholion init --demo` — a fictional person, deliberately imperfect. To keep the

data somewhere else, set `SCHOLION_REPO_DIR` (whole layout) or

`SCHOLION_PROFILE_DIR` (profile only) in the host environment; either one is

respected and the skill will not move anything.

## Network and privacy

## Safety rules