{ "schema": "leumas.docs.page/1", "id": "skill:leumas-studio#domains/information", "slug": "skills/leumas-studio/domains/information", "kind": "tools", "bucket": "skill", "title": "Information — what you can do", "name": "Information", "eyebrow": "what you can do", "chip": null, "summary": "", "keywords": [ "leumas-studio", "fetch remember", "tabs focus", "skill-sync", "pnpm", "skills", "edit", "hand" ], "audience": "both", "funnel": { "product": null, "cta": null }, "body": "\n\n# Information — what you can do\n\n`/admin/d/information` · pillar `information`\n\nAnswer questions from open sources - pages, DNS, people, the live world and your own network.\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| which lookups THIS install can actually run | `GET /api/information/tools` | it is the server allowlist intersected with the packs this deployment loaded, so it differs per install; `missing` names an allowlisted system whose pack is absent, which is a deployment fact rather than an error |\n| the wider adapter catalogue | `GET /api/adapters/tools` | what else this install can call outside the information allowlist |\n| whether the machine-local network tools are present at all | `GET /api/adapters` | on a hosted install the network routes are ABSENT rather than denied, and absent is a different answer from refused |\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### Answer a question about a domain or a web page\n\n1. `GET /api/information/tools` first — it names the verbs this install has.\n2. Call one directly: `POST /api/adapters/dns/records`, `POST /api/adapters/scraping/extractContacts`, and so on.\n3. Read the result. Nothing is filed and nothing is audited, which is correct for a target the user typed.\n\n**Trap:** Getting the argument NAME wrong produces a 400 nobody can act on — the DNS verbs each take their own key, so check the tool before calling it. A headless render that reports a navigation timeout has usually still produced the page: that is normal on a modern app, not a failure.\n\n### Build a dossier on a person\n\n1. Open OSINT and choose or create the subject. `get_dossier` FIRST — it returns what is known and, more usefully, `openQuestions`: the identifier classes with nothing found yet.\n2. `get_audit_summary` before anything expensive — it shows what was already run today, so a long sweep is not repeated.\n3. `run_lookup` for one tool against the subject. It files what it finds and records who asked.\n4. `list_findings` and `get_finding` to read the evidence back.\n\n**Trap:** [critical] A USERNAME MATCH IS AN EXISTENCE SIGNAL, NOT AN IDENTITY. The same handle on two sites is frequently two different people, and a summary that treats a match as established is the difference between a dossier and a defamation. Every claim needs a source URL.\n\n### Search wide instead of asking one question\n\n1. `start_sweep` runs ONE handle, against a SUBJECT, and files every hit as a finding. It answers immediately with an id — it cannot be awaited.\n2. `get_sweep_status` is the poll. The page watches the live stream; a tool cannot hold one open.\n3. For a handle you have NOT yet attributed to anybody, use the OSINT scanners instead: `POST /api/information/osint/:source/scan` takes up to 10 subjects at once, needs no subject record, and files nothing. `:source` is an installed source id — sherlock, maigret, whatsmyname, blackbird — or `all` for the deduplicated union of the USERNAME lists. Plan it first with `GET /api/information/osint/:source/sites`, which makes no requests, and `GET /api/information/osint/sources` says which this install carries AND what each looks up by.\n4. Blackbird takes an EMAIL ADDRESS, not a handle — its `subject` is `email`. A job mixing it with a username source is refused, and it is excluded from `all` for the same reason. Its cheapest call is `emailProfile`, one request for the avatar, MX and disposable signals.\n5. Enrich is the third fan-out: it derives what to run from what the subject already has, rather than from a handle.\n\n**Trap:** Every fan-out is metered on `feature:information.sweep.` — the key carries the source because the lists differ ~6x in size; a single lookup is not metered. Sites are probed CONCURRENTLY (default 12, cap 32) — the count you get back is the plan, not a countdown. A `source: all` run reports how many DUPLICATES it merged, and the total is legitimately less than the sum of the lists. Maigret defaults to its 500 highest-traffic sites — a `topN` run that found nothing is a much weaker statement than a full one, so quote the number actually checked. Blackbird's rows are grouped by `identity`: Gravatar and Libravatar are usually ONE account reached twice, so count identities, not rows. A sweep does not survive an API restart, and a Sherlock job is dropped 15 minutes after it finishes: only the `information_sweeps` row persists, and the stream then reports the run as unknown. Cancelling aborts the requests in flight rather than waiting them out.\n\n### Correct or confirm what was found\n\n1. `set_finding_status` to mark one verified, disputed or false-positive. Status and notes are the only two fields a human may write.\n2. `promote_finding` copies a VERIFIED finding onto the subject record itself.\n3. `update_subject` corrects what the dossier is ABOUT — the identity, not the evidence.\n\n**Trap:** Promotion refuses anything not already verified, and only four of the eleven finding kinds can be promoted at all — the rest are observations that never become subject fields. Never promote something you have not checked against its source: promotion turns a machine observation into a human assertion.\n\n### Look at the live world\n\n1. Open World Monitor. It shows live aircraft, the ISS, earthquakes and natural events on a globe.\n2. Headless, the same data is `POST /api/adapters/world/traffic`, `/events`, `/search` and `/layers`.\n3. `/layers` says which layers this instance can actually serve; optional feeds report themselves as not configured rather than failing.\n\n**Trap:** This is the SAME surface the Media domain mounts — one component, two doors, and a fix lands on both. It is live feeds, not reference data: a question about what a species IS belongs to the Knowledge domain, not here.\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| `scraping` | - | Pages & records | Fetch any page and pull structure out of it — text, tables, contacts, links, feeds and headers. |\n| `dns` | - | Pages & records | Resolve any domain — records, WHOIS, RDAP, certificates and reverse lookups. |\n| `osint` | - | People & the planet | Build a dossier on a subject from open sources, one sourced finding at a time. |\n| `world` | - | People & the planet | Live flights, quakes, natural events and regional feeds on one globe. |\n| `nmap` | - | This network | Discover devices, ports and services on networks you manage. |\n| `wireshark` | - | This network | Watch traffic on an interface, or open a capture you already have. |\n\n## Tabs in focus\n\n### `scraping` - Scraping\n\nFetch any page and pull structure out of it — text, tables, contacts, links, feeds and headers.\n\n**Read with:** `GET /api/information/tools`\n\n**Write with:** `POST /api/adapters/scraping/extractText` | `POST /api/adapters/render/renderText`\n\n1. Pick the verb for the shape you want, not the page you want.\n2. If a page renders its content with JavaScript, switch to the headless render — the panel says which produced the output.\n\n**Trap:** This tab runs on the DIRECT adapter lane: nothing is filed and nothing is audited. That is deliberate for a URL the user typed, and wrong for anything about a person.\n\n### `dns` - DNS\n\nResolve any domain — records, WHOIS, RDAP, certificates and reverse lookups.\n\n**Write with:** `POST /api/adapters/dns/records` | `POST /api/adapters/dns/whois`\n\n**Trap:** Each verb takes its OWN argument key, and the wrong one is an unactionable 400. Also direct-lane: not audited, because filing every MX lookup would bury the rows that matter.\n\n### `osint` - OSINT\n\nBuild a dossier on a subject from open sources, one sourced finding at a time.\n\n**Read with:** `get_dossier` | `list_findings` | `get_finding` | `list_tools` | `get_audit_summary` | `get_sweep_status`\n\n**Write with:** `run_lookup` | `start_sweep` | `add_findings` | `set_finding_status` | `promote_finding` | `update_subject`\n\n1. `get_dossier` for what is known and what is still open.\n2. `get_audit_summary` so an expensive run is not repeated.\n3. `run_lookup` or `start_sweep` to gather; `list_findings` to read back.\n4. `set_finding_status`, then `promote_finding` for anything checked against its source.\n\n**Trap:** This is the one surface whose subject is a person, and the only one on the AUDITED lane. `run_lookup` returns a summary rather than the raw payload — the page holds the blob. `start_sweep` returns an id, never a result. Attempting a login, a password reset, or anything paywalled is out of scope: report a refusal as given.\n\n### `world` - World Monitor\n\nLive flights, quakes, natural events and regional feeds on one globe.\n\n**Write with:** `POST /api/adapters/world/traffic` | `POST /api/adapters/world/events`\n\n**Trap:** Live feeds, NOT reference data — and the same component the Media domain mounts at its own route. Ask it what is happening, not what something is.\n\n### `nmap` - Nmap\n\nDiscover devices, ports and services on networks you manage.\n\n**Trap:** Machine-local only. On a hosted install these routes are ABSENT, not denied — the panel reads that as \"this deployment does not carry them\", which is a different answer from a refusal. Everything about the binaries, the verbs, the limits and the traps is in the `leumas-network` skill; this lane owns only the tab and the gate.\n\n### `wireshark` - Wireshark\n\nWatch traffic on an interface, or open a capture you already have.\n\n**Trap:** The Wireshark GUI is never launched — this prints packet summaries. Captures are bounded by time, packet count and size, whichever comes first. Capture filters and display filters are two different languages. See the `leumas-network` skill.\n\n## Ways in\n\nDeclared cross-links. Every address is matched against the real route table by `check:huds`.\n\n| From | Does | Go to |\n|---|---|---|\n| `information/console:scraping` | What it produced | `/admin/dynamic/actions/scraped` |\n\n## Tools an agent can call here\n\nThese are **live page capabilities**: they exist only while that surface is open, and they\ncall the page's own mutators, so a change made through one is a change the operator can see. A tool\nmissing from this list is not callable — reach for the API or an adapter instead.\n\n### `information:dossier` — Dossier: …\n\nSource: `information/model/useDossierCapabilities.js`\n\nWhat the page tells an agent about itself:\n\n> The user is investigating a person using OPEN sources only. Everything here is public data filed against a named human being.\n>\n> ALWAYS call get_dossier first, and get_audit_summary before running anything expensive — it shows what has already been run today, so you do not repeat a 481-site sweep somebody ran an hour ago.\n>\n> A USERNAME MATCH IS AN EXISTENCE SIGNAL, NOT PROOF OF IDENTITY. The same handle on two sites is frequently two different people. Say so whenever you report one, and never write a summary that treats a handle match as established.\n>\n> Every claim you record must carry a source URL. Findings without provenance are capped at low confidence and should be rare.\n>\n> Findings are append-only. To correct one, set its status to false-positive — never delete it. Deletion is for erasure requests and destroys the reasoning along with the evidence.\n>\n> Never promote a finding you have not verified against its source. Promotion copies a machine-collected observation onto the human-asserted record.\n>\n> Do not attempt logins, password resets, or paywalled and private data. If a tool refuses a target, report the refusal verbatim rather than working around it.\n\n| Tool | Args | Does |\n|---|---|---|\n| `get_dossier` | — | Read the open dossier: the subject header (name, aliases, known identifiers, why they are being researched), finding counts by kind and status, and OPEN QUESTIONS — the identifier classes with nothing found yet, which is what decides what to do next. Call this FIRST. |\n| `list_findings` | `kind` `status` | List findings as { id, kind, label, value, status, confidence, source, url, seenCount, promoted }. Filter by kind or status. Up to ${MAX_LIST} rows. The raw tool payload is NOT included — use get_finding for one. |\n| `get_finding` | `id` | One finding in full, including the raw tool payload and its provenance (source URL, when it was fetched, the HTTP status). Use this to check a claim before verifying or promoting it. |\n| `list_tools` | — | The information tools you may run here, as `system.fn`. Call this before run_lookup rather than guessing a verb — anything outside the list is refused server-side. |\n| `get_audit_summary` | — | What has already been run from this account, most recent first — tool, target, when, and whether it was refused. Check this before an expensive lookup so you do not repeat one. |\n| `get_sweep_status` | `sweepId` | Progress of a running sweep: how many sites checked of how many, hits so far, and whether it is still running. Poll this after start_sweep — do NOT wait on the sweep itself. |\n| `run_lookup` | `tool` `args` | Run ONE allowlisted tool against this subject and file the result as findings. Returns a SUMMARY (how many were new vs already known) — read the findings afterwards with list_findings rather than expecting the payload here. |\n| `start_sweep` | `username` `categories` | Start a username sweep across the site manifest. Returns a sweepId IMMEDIATELY — the run takes minutes. Poll get_sweep_status; never wait on it. Hits are filed against this subject automatically at low confidence. |\n| `add_findings` | `findings` | Record findings you derived yourself — from a search result, a page you read, or a conclusion you drew. Each MUST carry a source URL in `url`; without one it is filed at low confidence. kind must be one of: account, email, phone, domain, dns, address, employer, image, mention, document, note. |\n| `set_finding_status` | `id` `status` `notes` | Mark a finding verified, disputed or false-positive, with a reason in notes. This is how a wrong finding is corrected — never by deleting it. |\n| `promote_finding` | `id` | Copy a VERIFIED finding onto the subject record as a known identifier. Refused server-side unless the finding is already verified — verify it against its source first, and say what you checked. |\n| `update_subject` | `patch` | Edit the subject header: name, aliases, tags, or the summary of what has been established. Identifiers are NOT editable here — use promote_finding, which requires evidence. |\n\n## API\n\nMounted prefixes that serve this domain: `/api/information`\n\nThe full route table is `leumas-capabilities/reference/api-routes.md`.\n\n## Traps\n\nTwo lanes, and the choice is visible in the diff: the AUDITED proxy files findings and records who asked; the DIRECT adapter call does neither. If unsure, use the audited one. An adapter never receives the caller, so it cannot scope anything by who asked — authorisation is decided BEFORE the call, not inside it. Every route on this domain requires a signed-in user; there is no public read. The instance-wide audit needs an admin, the caller's own does not. Findings are corrected by STATUS. Deletion exists as the erasure path, cascades from a subject to every finding about them, and leaves an audit row behind on purpose. The neighbouring domains are not this one: a curated reference library is Knowledge, and an autonomous multi-hop search that writes prose is Research. They share two adapter packs and no routes.\n\n", "source": { "path": ".claude/skills/leumas-studio/reference/domains/information.md", "blobSha": "", "commit": "", "committedAt": "", "provenance": "no-git", "bytes": 15750, "hash": "084575c9258438814032d426f8dc7d435304a0ac" }, "urls": { "html": "/p/skills/leumas-studio/domains/information", "json": "/docs/skills/leumas-studio/domains/information.json", "md": "/docs/skills/leumas-studio/domains/information.md" }, "links": { "composes": [], "usedBy": [], "product": [], "howTo": [], "skills": [] } }