{
  "schema": "leumas.docs.page/1",
  "id": "skill:leumas-studio#domains/medicine",
  "slug": "skills/leumas-studio/domains/medicine",
  "kind": "tools",
  "bucket": "skill",
  "title": "Medicine — what you can do",
  "name": "Medicine",
  "eyebrow": "what you can do",
  "chip": null,
  "summary": "<!-- GENERATED by ops/tools/skill-sync — do not edit by hand. Run pnpm skills:sync. -->",
  "keywords": [
    "leumas-studio",
    "fetch remember",
    "skill-sync",
    "pnpm",
    "skills",
    "edit",
    "hand",
    "generated"
  ],
  "audience": "both",
  "funnel": {
    "product": null,
    "cta": null
  },
  "body": "<!-- GENERATED by ops/tools/skill-sync — do not edit by hand. Run `pnpm skills:sync`. -->\n\n# Medicine — what you can do\n\n`/admin/d/medicine` · pillar `ai`\n\nRun gated drug-discovery investigations — a typed biology graph, an append-only claim ledger, four scores that are never blended, and a human decision at every gate.\n\n## Fetch this, never remember it\n\nThese change per install and per release. Call for them - a list written here would be a future lie.\n\n| What | Call | Why |\n|---|---|---|\n| the closed vocabularies this engine works in | `POST /api/adapters/medicine-engine/vocabulary` | relations, entity classes, claim kinds, evidence tiers, the four score fields, the autonomy levels and the operations. A value outside these resolves to NOTHING and the failure is silent — an empty result reads as \"no answer\", not \"wrong word\". |\n| what each autonomy level actually permits | `POST /api/adapters/medicine-engine/explainGate` | the whole permission table as data. Two operations are REFUSED at every level including the highest, because they assert something happened outside this process — that is not the top of a scale, it is a different state. |\n| what would happen if a proposal were made | `POST /api/adapters/medicine-engine/judgeProposal` | judges one operation through schema, scientific and permission layers WITHOUT writing. A surface or an agent should be able to show the decision before asking for it. |\n| the investigations on this install | `POST /api/adapters/medicine-engine/listInvestigations` | each row carries `simulated` and its record rollup. A run in status `awaiting` is asking a person for a decision — that is a result, not a failure. |\n| an investigation's claims | `POST /api/adapters/medicine-engine/listClaims` | ALWAYS narrowed by investigationId — the ledger is append-only and grows with use, so an unnarrowed read is refused rather than allowed to scan. Each row carries its own provenance and its `refId` (what it is about, as distinct from the row's own id). |\n| what the agents actually did | `POST /api/adapters/medicine-engine/listAgentRuns` | one row per stage, FAILED TURNS INCLUDED — a timeline of successes cannot explain a gap. It carries a capped summary and counts, never the model's prose and never a chain of thought. |\n\n## How to actually do things here\n\nWritten by hand, because the order and the traps are the part no file can derive.\n\n### Start an investigation\n\n1. `explainGate` first — read what the autonomy level you are about to pass actually permits.\n2. `startInvestigation` with an investigationId, a plan (discovery · repurposing · target-validation) and that level.\n3. `getInvestigation` to see where it stopped and what it is waiting for.\n\n**Trap:** It STOPS at its gates and returns `status: \"awaiting\"`. Report that as an answer and ask the user — do not retry with a higher autonomy level to make it continue.\n\n### Approve or reject a gate\n\n1. `getInvestigation` — read `awaiting` to see whether a STAGE or its WRITES need the decision.\n2. Ask the user. Their answer is the decision; yours is not.\n3. `decideGate` with the investigationId, approved, and the USER'S name in decidedBy.\n\n**Trap:** NEVER put your own name in decidedBy. A gate exists so a person takes responsibility; an agent approving on its own behalf is the failure the gate was built to prevent. Approving a parked write APPLIES it; rejecting drops it and records the rejection.\n\n### Explain why the system believes something\n\n1. `listClaims` for the investigation, narrowed by kindOf when you know which kind you want.\n2. `listAgentRuns` for what produced them, including the turns that failed.\n3. Report the four scores separately, and say which values are simulated.\n\n**Trap:** There is no overall score and there will not be. Report confidence, evidenceStrength, modelConfidence and experimentalValidation SEPARATELY. Averaging them hides the zero, and the zero is usually experimentalValidation — the one a reader most needs.\n\n### Say what is real and what is not\n\n1. Read `simulated` on the ROW itself, never a badge or a label a surface chose to render.\n2. Check the run's `mode`: `mock` means every row it wrote is simulated.\n\n**Trap:** The default mode is mock, so on a fresh install EVERYTHING is simulated. Never restate a simulated value without saying so — the claim validator refuses a simulated record carrying a real DOI precisely so an echoed example cannot become a finding.\n\n## Tabs\n\nEvery one is a real URL. A tab with its own section below carries a real job.\n\n| Tab | Path | Group | What it is for |\n|---|---|---|---|\n| `dashboard` | - | The work | What needs you today — gates waiting, model warnings, and what each run has produced. |\n| `investigations` | - | The work | Every question this install is asking, and how far each has got. |\n| `discover` | - | The work | Start an investigation: pick a plan, pick an autonomy level, and read what each permits. |\n| `graph` | - | The science | Diseases, pathways, genes, proteins and candidates as one typed network. |\n| `diseases` | - | The science | The subjects under investigation, and what is asserted about each. |\n| `targets` | - | The science | Proteins and pathways proposed as points of intervention, and why each is one. |\n| `candidates` | - | The science | Interventions under evaluation, judged on separate dimensions — never one score. |\n| `evidence` | - | The evidence | Sources, appraised. Tiers are reported separately and never summed. |\n| `simulations` | - | The evidence | Computational runs. Everything here is SIMULATED and each row says so. |\n| `experiments` | - | The evidence | The bench half — proposed only. Nothing here runs an experiment. |\n| `agents` | - | The machine | Who ran what, when, and whether it worked. Failed turns included. |\n| `autonomy` | - | The machine | The permission table: what each level actually permits, refuses and gates. |\n| `settings` | - | The machine | The vocabularies this engine works in, and the boundaries it will not cross. |\n\n## API\n\nMounted prefixes that serve this domain: `/api/medicine`\n\nThe full route table is `leumas-capabilities/reference/api-routes.md`.\n\n",
  "source": {
    "path": ".claude/skills/leumas-studio/reference/domains/medicine.md",
    "blobSha": "",
    "commit": "",
    "committedAt": "",
    "provenance": "no-git",
    "bytes": 6179,
    "hash": "afc63a32948d91755f0083b8ce3862c2a2b08560"
  },
  "urls": {
    "html": "/p/skills/leumas-studio/domains/medicine",
    "json": "/docs/skills/leumas-studio/domains/medicine.json",
    "md": "/docs/skills/leumas-studio/domains/medicine.md"
  },
  "links": {
    "composes": [],
    "usedBy": [],
    "product": [],
    "howTo": [],
    "skills": []
  }
}
