# Information — what you can do # Information — what you can do `/admin/d/information` · pillar `information` Answer questions from open sources - pages, DNS, people, the live world and your own network. ## Fetch this, never remember it These change per install and per release. Call for them - a list written here would be a future lie. | What | Call | Why | |---|---|---| | 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 | | the wider adapter catalogue | `GET /api/adapters/tools` | what else this install can call outside the information allowlist | | 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 | ## How to actually do things here Written by hand, because the order and the traps are the part no file can derive. ### Answer a question about a domain or a web page 1. `GET /api/information/tools` first — it names the verbs this install has. 2. Call one directly: `POST /api/adapters/dns/records`, `POST /api/adapters/scraping/extractContacts`, and so on. 3. Read the result. Nothing is filed and nothing is audited, which is correct for a target the user typed. **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. ### Build a dossier on a person 1. 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. 2. `get_audit_summary` before anything expensive — it shows what was already run today, so a long sweep is not repeated. 3. `run_lookup` for one tool against the subject. It files what it finds and records who asked. 4. `list_findings` and `get_finding` to read the evidence back. **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. ### Search wide instead of asking one question 1. `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. 2. `get_sweep_status` is the poll. The page watches the live stream; a tool cannot hold one open. 3. 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. 4. 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. 5. Enrich is the third fan-out: it derives what to run from what the subject already has, rather than from a handle. **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. ### Correct or confirm what was found 1. `set_finding_status` to mark one verified, disputed or false-positive. Status and notes are the only two fields a human may write. 2. `promote_finding` copies a VERIFIED finding onto the subject record itself. 3. `update_subject` corrects what the dossier is ABOUT — the identity, not the evidence. **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. ### Look at the live world 1. Open World Monitor. It shows live aircraft, the ISS, earthquakes and natural events on a globe. 2. Headless, the same data is `POST /api/adapters/world/traffic`, `/events`, `/search` and `/layers`. 3. `/layers` says which layers this instance can actually serve; optional feeds report themselves as not configured rather than failing. **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. ## Tabs Every one is a real URL. A tab with its own section below carries a real job. | Tab | Path | Group | What it is for | |---|---|---|---| | `scraping` | - | Pages & records | Fetch any page and pull structure out of it — text, tables, contacts, links, feeds and headers. | | `dns` | - | Pages & records | Resolve any domain — records, WHOIS, RDAP, certificates and reverse lookups. | | `osint` | - | People & the planet | Build a dossier on a subject from open sources, one sourced finding at a time. | | `world` | - | People & the planet | Live flights, quakes, natural events and regional feeds on one globe. | | `nmap` | - | This network | Discover devices, ports and services on networks you manage. | | `wireshark` | - | This network | Watch traffic on an interface, or open a capture you already have. | ## Tabs in focus ### `scraping` - Scraping Fetch any page and pull structure out of it — text, tables, contacts, links, feeds and headers. **Read with:** `GET /api/information/tools` **Write with:** `POST /api/adapters/scraping/extractText` | `POST /api/adapters/render/renderText` 1. Pick the verb for the shape you want, not the page you want. 2. If a page renders its content with JavaScript, switch to the headless render — the panel says which produced the output. **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. ### `dns` - DNS Resolve any domain — records, WHOIS, RDAP, certificates and reverse lookups. **Write with:** `POST /api/adapters/dns/records` | `POST /api/adapters/dns/whois` **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. ### `osint` - OSINT Build a dossier on a subject from open sources, one sourced finding at a time. **Read with:** `get_dossier` | `list_findings` | `get_finding` | `list_tools` | `get_audit_summary` | `get_sweep_status` **Write with:** `run_lookup` | `start_sweep` | `add_findings` | `set_finding_status` | `promote_finding` | `update_subject` 1. `get_dossier` for what is known and what is still open. 2. `get_audit_summary` so an expensive run is not repeated. 3. `run_lookup` or `start_sweep` to gather; `list_findings` to read back. 4. `set_finding_status`, then `promote_finding` for anything checked against its source. **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. ### `world` - World Monitor Live flights, quakes, natural events and regional feeds on one globe. **Write with:** `POST /api/adapters/world/traffic` | `POST /api/adapters/world/events` **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. ### `nmap` - Nmap Discover devices, ports and services on networks you manage. **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. ### `wireshark` - Wireshark Watch traffic on an interface, or open a capture you already have. **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. ## Ways in Declared cross-links. Every address is matched against the real route table by `check:huds`. | From | Does | Go to | |---|---|---| | `information/console:scraping` | What it produced | `/admin/dynamic/actions/scraped` | ## Tools an agent can call here These are **live page capabilities**: they exist only while that surface is open, and they call the page's own mutators, so a change made through one is a change the operator can see. A tool missing from this list is not callable — reach for the API or an adapter instead. ### `information:dossier` — Dossier: … Source: `information/model/useDossierCapabilities.js` What the page tells an agent about itself: > The user is investigating a person using OPEN sources only. Everything here is public data filed against a named human being. > > 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. > > 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. > > Every claim you record must carry a source URL. Findings without provenance are capped at low confidence and should be rare. > > 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. > > Never promote a finding you have not verified against its source. Promotion copies a machine-collected observation onto the human-asserted record. > > 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. | Tool | Args | Does | |---|---|---| | `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. | | `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. | | `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. | | `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. | | `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. | | `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. | | `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. | | `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. | | `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. | | `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. | | `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. | | `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. | ## API Mounted prefixes that serve this domain: `/api/information` The full route table is `leumas-capabilities/reference/api-routes.md`. ## Traps Two 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. --- Source: .claude/skills/leumas-studio/reference/domains/information.md Canonical: https://docs.leumas.tech/p/skills/leumas-studio/domains/information