Update to Intelligo

{
  "name": "intelligo-compare-reports",
  "description": "Compare Intelligo background-check reports and report what changed or what overlaps. Use this skill whenever the user wants to compare, diff, or cross-reference Intelligo reports or profiles — including \"what changed since the last report\", \"refresh comparison\", \"compare this profile's new and old report\", \"what's common between these two profiles\", \"do these subjects share anything\", or comparing every profile in an Intelligo project against each other. Trigger on phrases like \"compare reports\", \"what's new in this refresh\", \"diff these profiles\", \"shared connections between profiles\", \"what did the upgrade add\", \"compare the two report levels\", and on any request that names two or more Intelligo profiles/reports and asks how they relate. Three modes: REFRESH (same profile over time, same level), LEVEL CHANGE (same profile, two different report levels — upgrade or interim), and CROSS-PROFILE (two or more distinct profiles, including a whole project). Read-only — never writes back to Intelligo.",
  "included_files": [
    {
      "relative_path": "references/profile-resolution.md",
      "size_in_bytes": 7440
    }
  ],
  "skill_md_contents": "---\nname: intelligo-compare-reports\ndescription: >-\n  Compare Intelligo background-check reports and report what changed or\n  what overlaps. Use this skill whenever the user wants to compare, diff, or\n  cross-reference Intelligo reports or profiles — including \"what changed since the\n  last report\", \"refresh comparison\", \"compare this profile's new and old\n  report\", \"what's common between these two profiles\", \"do these subjects share\n  anything\", or comparing every profile in an Intelligo project against each other.\n  Trigger on phrases like \"compare reports\", \"what's new in this refresh\",\n  \"diff these profiles\", \"shared connections between profiles\", \"what did the\n  upgrade add\", \"compare the two report levels\", and on any request that names\n  two or more Intelligo profiles/reports and asks how they relate. Three modes:\n  REFRESH (same profile over time, same level), LEVEL CHANGE (same profile, two\n  different report levels — upgrade or interim), and CROSS-PROFILE (two or more\n  distinct profiles, including a whole project). Read-only — never writes back\n  to Intelligo.\n---\n\n# Compare Intelligo Reports\n\nCompare Intelligo background-check reports and explain — in plain\nlanguage, facts only — what changed or what overlaps. Picking the right *kind* of\ncomparison is the first decision, so start there.\n\n## The three modes\n\n**Refresh — same subject, same level, different points in time.** One profile, a\nnewer report and an older one at the same report level. Question: *what changed\nsince last time?* Same person/entity and same coverage scope, so you align records\none-to-one and report **transitions** — findings newly present, findings gone,\nflags escalated or cleared, new dated hits since the prior report.\n\n**Level Change — same subject, two different report levels.** One profile, two\nreports at different levels (e.g. Now → Advantage, Advantage L1 → Advantage L2/3).\nThis covers both **upgrades** (moving to a higher level for deeper coverage) and\n**interim runs** (running a lower level to cover a time gap before the deal closes).\nQuestion: *what did the level change add or remove — in coverage and in findings?*\nCoverage scope changed, so findings can appear or disappear simply because the new\nlevel covers more (or less) — not because the subject changed. You must separate\ncoverage-driven differences from genuine finding changes, and always run a coverage\ndiff via `compareCoverage`.\n\n**Cross-profile — different subjects, compared as peers.** Two or more distinct\nprofiles (or every profile in a project). Question: *what do they share, and where\ndo they diverge?* No time axis — you compute **set intersection and difference**:\nshared employers, addresses, associates, companies, legal entities, and what's\nunique to each. Overlap is usually the signal the analyst wants (hidden or\nundisclosed connections).\n\n**Deciding which:**\n- Same subject, same level → **Refresh**.\n- Same subject, different levels → **Level Change** (see detection logic below).\n- Different subjects → **Cross-profile**.\n- A project, or \"all profiles in X\" → **Cross-profile**, N-way.\n\nIf genuinely ambiguous, state your inferred mode in one line and proceed — don't\nstall on a question you can answer by checking whether the subject and level match.\n\nThis skill compares reports the user already has in mind or that live in a named\nproject. It is **not** the account-wide \"who is connected to X\" screening search —\nthat's a separate operation.\n\n## Report scope — background checks by default\n\nIntelligo profiles can hold several report types (background check, social media\nanalysis, credit check, others). **Compare background-check reports by default**;\nwhen a profile or project has more than one type, pick the background check\nwithout asking.\n\nIf the user explicitly asks for another type, don't silently ignore it and don't\nrefuse: tell them other types exist and that this skill is built around background\nchecks, then default to background checks unless they confirm they want the other\ntype — so they stay aware of what's being compared.\n\n**Social media and credit reports are PDFs**, not structured data, so you can only\ncompare them if you can actually read the PDF content. If it isn't available, ask\nthe user to upload it (both for a refresh, all of them for a cross-comparison). If\nyou still can't read it, **stop — don't guess from a filename or metadata and\ndon't fabricate.** A missing PDF is a hard stop. Once you have the content, the\nmode logic and facts-only output below apply unchanged.\n\n## Tools\n\nRelies on the Intelligo MCP connector.\n\n- **Resolving who/what the user means →** don't do your own lookup. Follow\n  `references/profile-resolution.md`. It handles searching profiles and projects\n  in parallel, the case where **one name matches both a profile and a project**,\n  reusing a subject already resolved earlier in the conversation, disambiguating\n  duplicates, and the never-silently-combine rule. It uses `get_profiles`,\n  `get_projects`, and `get_profile`.\n- **Fetching a report →** `get_report_content`, one call per report (the heavy\n  call). The resolved profile/project objects tell you a profile's available\n  reports and a project's members — rely on what the connector returns, never\n  invent fields.\n- **Fetching coverage diff →** `compareCoverage`, used in Level Change mode only.\n  Call it with both report levels to get what coverage was added, removed, or\n  changed between the two levels. Run this before fetching report content so the\n  coverage picture is ready when you interpret findings.\n\n<!-- TODO-verify on first run: exact tool names/params and the report payload\nshape — status values, section names, flag representation, and the date / level /\njurisdiction fields. Call each tool once, look at the real output, then proceed.\nThe workflow depends only on the capabilities, not the spellings. -->\n\n\n## How to identify reports when talking to the user\n\nEvery time you reference a report in a question, list, or output — use the three\nthings the user actually recognizes:\n\n1. **Subject name** — the person or company name as it appears in the profile\n   (e.g. \"John Smith\", \"Acme Capital LLC\"). Never substitute a profile ID.\n2. **Report level** — the exact level name returned by the connector\n   (e.g. \"Now\", \"Advantage\", \"Advantage L2/3\"). Never write \"level 1\" or \"L2\"\n   unless that's literally what the connector returns.\n3. **Published date** — the date the report was completed/published, not\n   \"latest\" or \"previous.\" Format as day-month-year (e.g. \"14 Feb 2026\").\n\nCombine them like this whenever you list a report for the user to choose from or\nreference one in output:\n\n> **John Smith** — Advantage · 14 Feb 2026 · US + UK\n\nThis format applies everywhere: selection lists, confirmation dialogs, diff\nheaders, and any inline reference in a summary.\n\n## Workflow\n\n1. **Resolve inputs** via `references/profile-resolution.md` — into one profile\n   (Refresh / Level Change) or several profiles / a project (Cross-profile).\n2. **Select which reports** to compare — see the selection rules in each mode.\n3. **Detect Level Change** — if the same profile has two reports at different\n   levels, apply the Level Change detection logic before proceeding.\n4. **Fetch coverage diff** (Level Change only) — call `compareCoverage` before\n   fetching report content.\n5. **Fetch** each report with `get_report_content`.\n6. **Check status** before comparing (see Report status gate).\n7. **Parse into sections** so you compare like with like. Expect areas such as:\n   employment, education, legal/court records, regulatory/compliance,\n   sanctions/watchlists, adverse media/news, personal background, and associated\n   companies/people. Flags are red (material) and yellow (caution).\n8. **Run the mode comparison** and **write the summary** (templates below). Output\n   is a structured chat summary — no file unless asked.\n\n## Report status gate (both modes)\n\nA report is only safe to compare once it's final. Check every report's status\nfirst:\n\n- **In progress / pending submission** → **stop.** Not ready; a comparison would\n  be meaningless. Say which report isn't ready.\n- **Preliminary** → **get explicit user approval first.** Explain that a\n  preliminary report may differ from the final and can carry unverified content\n  that produces a **false positive**. If approved, label every preliminary-sourced\n  finding `(preliminary — unverified)` and repeat the caveat in the summary.\n- **Final / complete** → proceed.\n\n## Mode A — Refresh (what changed)\n\n### Which two reports\n\nA profile can have **more than two** reports — don't assume \"latest vs the one\nbefore.\"\n\n- Exactly two → newer = current, older = baseline.\n- Three or more, user named which two → use those.\n- Three or more, unspecified → list them with subject name, level, published date,\n  and jurisdiction(s) — one line per report — and ask before fetching. Use this\n  exact format for each line:\n  > **[Subject name]** — [Level name] · [Published date] · [Jurisdiction(s)]\n  This is the one place in Refresh worth a question — the wrong baseline silently\n  produces a misleading diff.\n\nIf the two reports differ in **level**, stop — this is a **Level Change** scenario,\nnot a Refresh. Apply the Level Change detection logic below before proceeding.\n\nIf the reports differ in **jurisdictions covered** (but same level), an apparent\n\"new\" or \"removed\" finding may just be different coverage, not a real change. Note\nthe mismatch at the top of the output and flag coverage-driven differences as such.\n\n### Judge meaning, not wording\n\nA useful diff is about what changed *substantively*, not which words moved. Don't\nflag rewordings; don't miss a real shift hidden behind similar wording. Match\nrecords by a stable identifier (case number, employer, license, article) rather\nthan by position, then for each candidate change ask what it *means*:\n\n- **A status resolved** — a legal case open → closed, a regulatory action\n  resolved, a sanction lifted. Capture the outcome as stated (dismissed,\n  acquitted, convicted, settled).\n- **New substance on a rolling matter** — for things that develop over time (an\n  investigation, ongoing litigation, an evolving story), the test isn't \"is the\n  text different\" but \"is there new substance on the same item.\"\n- **Genuinely new details** — a new party, amount, role, or date on an item that\n  already existed. New substance is worth surfacing; cosmetic restatement isn't.\n\n### Classify each change\n\n- **New** — present now, absent in baseline. Most important, especially new\n  red/yellow flags and new legal/regulatory/sanctions hits.\n- **Changed** — same record, moved state. Report as `[old state] → [new state]`,\n  outcome as stated — one transition, not two findings. This includes **flag\n  changes**: if a finding's flag level changed (e.g. 🟡 → 🔴, or 🔴 → cleared),\n  that is a change and must be reported — it's often the most important signal\n  in a refresh.\n- **Removed** — in baseline, gone now (source dropped it, record corrected,\n  coverage changed). Note it; lower urgency.\n- **Unchanged** — don't enumerate; just confirm the section was reviewed.\n\n**Always show the current flag** (🔴 / 🟡 / ⚪ unflagged) alongside every\nfinding in the output. Never omit the flag — even if the finding hasn't changed,\nthe flag is part of its identity.\n\nLead with what's material. A refresh where nothing changed is a valid, valuable\nanswer — say so plainly rather than padding.\n\n### News / adverse media — match on the event, not the article\n\nA refresh almost always pulls in new articles, so news needs the legal lens: is\neach new article a **genuinely new event**, or **another copy of one already in\nthe baseline?**\n\n- New event → surface it like any new finding.\n- Same event, different source → not a change by default. Surface it only if it\n  **adds substance** (new facts, party, outcome, amount, correction — note as new\n  detail on the existing event) or the **source itself carries weight** (coverage\n  moving from an obscure blog to a major outlet can change prominence/credibility:\n  \"same event, now also reported by [outlet]\"). Otherwise it's a duplicate — omit.\n\nGroup news by underlying event — \"one event, N sources,\" not N findings. Signal,\nnot length.\n\n### Output format\n\nUse this structure. Drop any section that has nothing to show — don't include empty\nheaders. Every finding gets its own row or bullet; no prose blocks inside sections.\n\n---\n\n**🔄 Refresh — [Subject name]**\n📅 Baseline: [date · level · jurisdiction(s)] → Current: [date · level · jurisdiction(s)]\n\n---\n\n**📊 Change summary**\n\n| Category | New | Flag changed | Changed | Removed |\n|---|---|---|---|---|\n| Legal / Court | # | # | # | # |\n| Regulatory | # | # | # | # |\n| Sanctions / Watchlists | # | # | # | # |\n| Adverse Media | # | # | # | # |\n| Employment | # | # | # | # |\n| [other sections with changes] | # | # | # | # |\n\n_(Only include rows with at least one non-zero count. \"Flag changed\" counts findings\nwhere only the flag level changed — escalated or cleared — with no other state change.\nIf nothing changed at all, replace the table with: \"No changes found across all sections.\")_\n\n---\n\n**🆕 New findings**\n_(Present in current report, absent in baseline. Lead with red flags, then yellow.)_\n\n🔴 **[Section]** — [finding, stated factually]\n🟡 **[Section]** — [finding, stated factually]\n⚪ **[Section]** — [finding with no flag]\n\n---\n\n**🔀 Changed**\n_(Same record, moved state — including flag escalations and clearances.)_\n\n- **[Section]** 🟡→🔴 — [finding] · [old state] → [new state] · Outcome: [as stated]\n- **[Section]** 🔴→⚪ — [finding] · [old state] → [new state] · Outcome: [as stated]\n\n_(Show the flag transition as `[old flag]→[new flag]` before the finding text when the flag changed. If the flag didn't change, show only the current flag: `🔴 **[Section]** — ...`)_\n\n---\n\n**🗑 Removed since baseline**\n_(In baseline, gone now — lower urgency.)_\n\n- **[Section]** — [finding]\n\n---\n\n**📝 What this means**\n[2–3 factual sentences: counts by category, the notable transitions. No risk\nverdict unless the user explicitly asks.]\n\n---\n\n## Mode A2 — Level Change (upgrade or interim)\n\n### Detection\n\nWhen a profile has two background-check reports at **different levels**, detect\nthis automatically and ask the user to confirm the intent before proceeding:\n\n> \"I can see two reports for **[Subject name]** at different levels:\n> - **[Exact level name A]** — published [date] · [jurisdiction(s)]\n> - **[Exact level name B]** — published [date] · [jurisdiction(s)]\n>\n> Was this an **upgrade** (moving to a higher level for deeper coverage) or an\n> **interim run** (running a lower level to cover the time gap before the deal)?\n> This affects how I frame the comparison.\"\n\nUse the subject's actual name and the exact level names from the connector — never\n\"level 1 / level 2\" or \"old / new.\" Wait for the user's answer. Do not infer intent from the level order alone — a\nlower-level report dated *after* a higher one is a strong signal for interim, but\nstill ask. Once confirmed, label the mode clearly in the output header.\n\n### Coverage diff — always run it\n\nCall `compareCoverage` with both report levels before fetching report content.\nPresent the coverage diff as its own section in the output, before findings.\nOrganize it as:\n\n- **Coverage added** — data sources, check types, or jurisdictions present in the\n  new level but not the old.\n- **Coverage removed** — present in the old level but not the new (relevant for\n  interim runs; rare for upgrades).\n- **Coverage unchanged** — briefly confirm what was the same, so the analyst\n  knows the shared baseline.\n\nThis section is factual and mechanical — list what changed, not why it matters.\nThe findings section below is where coverage changes get applied.\n\n### Separating coverage-driven findings from genuine changes\n\nA finding that appears only in the higher-level report may exist because:\n1. The new level covers a source or jurisdiction the old one didn't, **or**\n2. Something genuinely changed about the subject in the intervening period.\n\nYou must distinguish these. For every new finding in the higher-level report, ask:\n*\"Is this in a section or jurisdiction that `compareCoverage` shows was added?\"*\n\n- If yes → label it `[new coverage]`. It's a real finding, but its absence from\n  the prior report means nothing about the subject's history — it was simply\n  outside scope before.\n- If no (same coverage scope) → treat it as a genuine change, same as Refresh\n  mode. Label it `[new finding]`.\n- If a finding from the lower-level report is **absent** from the higher-level\n  report and the coverage is the same → label it `[removed]` and note it; may\n  warrant checking.\n\nFor **interim runs** (lower level run after a higher one): the lower level will\nnaturally have fewer findings. Don't treat missing findings as \"removed\" — they're\noutside the interim report's scope. Focus on what the interim period *added*:\nnew findings present in the lower-level report that weren't in the higher-level\nbaseline, within the overlapping coverage.\n\n### Output format\n\nUse this structure. Drop any section with nothing to show. Every item gets its own\nline — no prose blocks inside sections.\n\n---\n\n**⬆️ Level Change — [Subject name]** · [Upgrade / Interim run]\n📅 Baseline: [date · level · jurisdiction(s)] → New report: [date · level · jurisdiction(s)]\n\n---\n\n**📦 Coverage changes**\n\n| | Details |\n|---|---|\n| ➕ Added | [source / check type / jurisdiction], [source / check type / jurisdiction] |\n| ➖ Removed | [source / check type / jurisdiction] _(mainly interim runs)_ |\n| ✅ Unchanged | [brief list of shared baseline checks] |\n\n---\n\n**📊 Findings summary**\n\n| Category | New coverage 🆕 | Genuine new | Changed | Removed |\n|---|---|---|---|---|\n| Legal / Court | # | # | # | # |\n| Regulatory | # | # | # | # |\n| Sanctions / Watchlists | # | # | # | # |\n| Adverse Media | # | # | # | # |\n| Employment | # | # | # | # |\n| [other sections with changes] | # | # | # | # |\n\n---\n\n**🆕 New findings — expanded coverage**\n_(Findings that appear because the new level covers sources/jurisdictions the old one didn't.\nTheir absence from the prior report says nothing about the subject — they were simply out of scope.)_\n\n🔴 **[Section]** — [finding] `· new coverage: [source/jurisdiction]`\n🟡 **[Section]** — [finding] `· new coverage: [source/jurisdiction]`\n⚪ **[Section]** — [finding] `· new coverage: [source/jurisdiction]`\n\n---\n\n**⚠️ Genuine changes** _(within overlapping coverage)_\n\n**Added**\n🔴 **[Section]** — [finding, stated factually]\n🟡 **[Section]** — [finding, stated factually]\n\n**Flag escalated / cleared**\n- **[Section]** 🟡→🔴 — [finding] _(flag escalated)_\n- **[Section]** 🔴→⚪ — [finding] · Outcome: [as stated] _(flag cleared)_\n\n**Changed**\n- **[Section]** — [old state] → [new state] · Outcome: [as stated]\n\n**Removed**\n- **[Section]** — [finding]\n\n---\n\n**📝 What this means**\n[2–4 factual sentences: what the level change added in scope, count of new-coverage\nfindings vs genuine changes, and any notable genuine transitions. No risk verdict.]\n\n---\n\n### Judge meaning, not wording\n\nA useful diff is about what changed *substantively*, not which words moved. Don't\nflag rewordings; don't miss a real shift hidden behind similar wording. Match\nrecords by a stable identifier (case number, employer, license, article) rather\nthan by position, then for each candidate change ask what it *means*:\n\n- **A status resolved** — a legal case open → closed, a regulatory action\n  resolved, a sanction lifted. Capture the outcome as stated (dismissed,\n  acquitted, convicted, settled).\n- **New substance on a rolling matter** — for things that develop over time (an\n  investigation, ongoing litigation, an evolving story), the test isn't \"is the\n  text different\" but \"is there new substance on the same item.\"\n- **Genuinely new details** — a new party, amount, role, or date on an item that\n  already existed. New substance is worth surfacing; cosmetic restatement isn't.\n\n### Classify each change\n\n- **New** — present now, absent in baseline. Most important, especially new\n  red/yellow flags and new legal/regulatory/sanctions hits.\n- **Changed** — same record, moved state. Report as `[old state] → [new state]`,\n  outcome as stated — one transition, not two findings. This includes **flag\n  changes**: if a finding's flag level changed (e.g. 🟡 → 🔴, or 🔴 → cleared),\n  report it — flag escalations are often the most actionable signal.\n- **Removed** — in baseline, gone now (source dropped it, record corrected,\n  coverage changed). Note it; lower urgency.\n- **Unchanged** — don't enumerate; just confirm the section was reviewed.\n\n**Always show the current flag** (🔴 / 🟡 / ⚪ unflagged) alongside every\nfinding in the output. Never omit the flag.\n\nLead with what's material. A refresh where nothing changed is a valid, valuable\nanswer — say so plainly rather than padding.\n\n### News / adverse media — match on the event, not the article\n\nA refresh almost always pulls in new articles, so news needs the legal lens: is\neach new article a **genuinely new event**, or **another copy of one already in\nthe baseline?**\n\n- New event → surface it like any new finding.\n- Same event, different source → not a change by default. Surface it only if it\n  **adds substance** (new facts, party, outcome, amount, correction — note as new\n  detail on the existing event) or the **source itself carries weight** (coverage\n  moving from an obscure blog to a major outlet can change prominence/credibility:\n  \"same event, now also reported by [outlet]\"). Otherwise it's a duplicate — omit.\n\nGroup news by underlying event — \"one event, N sources,\" not N findings. Signal,\nnot length.\n\n### Output (a guide — adapt to what surfaced; drop empty blocks)\n\n```\n# Refresh comparison — [Subject name]\nBaseline: [date, level, jurisdiction(s)]  →  Current: [date, level, jurisdiction(s)]\n\n## What's new\n- [section] [red/yellow flag if labeled]: [finding, stated factually]\n\n## Changed\n- [section]: [old state] → [new state], outcome: [as stated]\n\n## Removed since baseline\n- [section]: [finding]\n\n## Summary of changes\n[1–3 sentences, factual: what changed, e.g. counts by category and the notable\ntransitions. No verdict on whether risk rose or fell.]\n```\n\n## Mode B — Cross-profile (overlap and divergence)\n\n\n\n### Which reports, and how many profiles\n\nUse each profile's **most recent** report by default (no need to ask unless the\nuser names a specific one). When the input is a project:\n\n- **Up to 12 profiles** → list them by name and ask whether to compare all or a\n  subset; comparing all is fine, but let the user choose.\n- **More than 12** → don't auto-compare. List the profiles and ask which to\n  compare before fetching — an N-way comparison across many profiles is expensive\n  and hard to read.\n- **Very large (≈300+)** → show only the **30 most recent**, say how many total\n  (\"showing 30 of 312\"), and let the user pick or name others. Don't dump the\n  whole list.\n\n### Compute overlap and divergence\n\nTreat the profiles as peers: for each attribute type, take the intersection across\nprofiles and the per-profile remainder. The strongest connection signals: shared\nemployers/companies, addresses, associated people, overlapping legal entities or\ncase parties, shared directorships. Surface softer overlaps (same city, same\neducation) but rank them lower.\n\nFor a project (N profiles), report each overlap as \"shared by [which profiles]\" so\nthe analyst sees *who* is connected through *what*. Highlight overlaps involving a\nred/yellow-flagged entity (the flag is the report's, a fact) so they're easy to\nspot.\n\n### Output format\n\nOrganize around what you found — add, drop, or rename sections based on what\nactually surfaced. Every item gets its own line. No prose blocks inside sections.\nKeep constant: the header, overlaps first, divergence second, summary last.\n\n---\n\n**🔗 Cross-profile — [Profile A] · [Profile B]** _(or: Project [name] · N profiles)_\n\n---\n\n**📊 Overlap summary**\n\n| Attribute | Shared value | Profiles | Flag |\n|---|---|---|---|\n| Employer | [company name] | A, B | 🔴 / 🟡 / — |\n| Address | [city, country] | A, C | — |\n| Associate | [name] | A, B | 🟡 |\n| Legal entity | [entity name] | B, C | 🔴 |\n| [other attribute] | [value] | [which] | — |\n\n_(Only include attribute types that actually surfaced. If no meaningful overlap:\n\"No shared employers, addresses, associates, or legal entities found.\")_\n\n---\n\n**↔️ Notable divergence**\n\n| Profile | Attribute | Flag | Detail |\n|---|---|---|---|\n| [Profile A] | [type] | 🔴/🟡/— | [unique finding] |\n| [Profile B] | [type] | 🔴/🟡/— | [unique finding] |\n\n---\n\n**📝 What this means**\n[2–3 factual sentences: what's shared and through what, where they diverge. No\nstrength rating or verdict.]\n\n---\n\n_(If internet expansion was accepted, add a clearly separated section:)_\n\n**🌐 External leads** `[unverified — not Intelligo data]`\n- [co-mention / shared filing / other web finding] · Source: [outlet/URL]\n_(Treat as leads to verify, not facts.)_\n\n---\n\n### Optional internet expansion\n\nAfter the Intelligo comparison, you may offer to extend the search to the internet\nfor connections the reports don't capture (co-mentions in news, shared filings).\nOpt-in — ask first. If the user accepts, state plainly why this data is weaker:\nit is **not human-verified** the way Intelligo content is, **and** an LLM searching\nthe open web is materially less accurate than Intelligo's own automated data\ncollection — wrong-entity matches, stale or low-quality sources, and missed\ncontext are all likely. So mark every non-Intelligo finding **`[external data —\nunverified]`**, keep it visually distinct, and treat such findings as leads to\nverify, never as facts. Intelligo data is the trusted baseline; internet results\nare a lead, not a conclusion.\n\n## Guardrails\n\n- **Structured output, always.** Every comparison result must use the mode's\n  output format — headers, tables, labeled bullets, emoji status markers. Never\n  return findings as a block of prose. If a section is empty, drop it entirely\n  rather than writing \"nothing to report here.\" The goal is a result the analyst\n  can scan in 30 seconds, not read in 5 minutes.\n- **Speak in human terms, never IDs.** Users don't recognize profile/report/\n  project IDs — use them only for tool calls, never in output. Identify a subject\n  by their actual name, a report by its **exact level name, published date, and\n  jurisdiction(s)**, and a project by its project name.\n  - ✅ \"**Jane Doe** — Advantage L2/3 · 12 Mar 2026 · US + UK\"\n  - ❌ \"profile_abc123 · report_789 · level 2\"\n  - ❌ \"the latest report\" or \"the previous report\" (always use the actual date)\n  If two reports look identical in a list, add a distinguishing detail rather than\n  falling back to an ID.\n- **Facts, not opinions.** Present what the reports say and what changed or\n  overlaps — never a verdict, recommendation, or risk opinion. State the concrete\n  change (\"status: open → closed, outcome: dismissed\"), not a characterization\n  (\"reassuring\" / \"raises risk\"). You may highlight Intelligo's own red/yellow flags\n  (those are facts); don't add your own risk read. If the user explicitly asks for\n  your read, give it separately from the factual comparison.\n- **Read-only.** Never create, edit, or write anything back to Intelligo.\n- **Sensitive data.** These reports hold sensitive personal data — keep it within\n  the comparison, don't send it anywhere the user didn't ask, don't put it in URLs.\n- **Don't invent findings.** If a section is missing, say it wasn't present rather\n  than assuming it's clean.\n"
}