APiM Galaxy

WHEN TO USE — a BACK-COMPAT / advanced path. The DEFAULT terminal step is now compile_report (hand the server LOOSE content; it assembles the envelope for you). Reach for render_branded_report ONLY if you already hold a fully hand-built {graph, report, meta} envelope you want rendered directly. It SELF-GATES (never gate on 'is this user Pro?'); the server RE-RUNS the source firewall on your JSON: it re-fetches every page you cited and derives, itself, which ties have both companies named on the page they cite — it does not read your `verified` flags. A tie whose source checks out is drawn solid whether or not you flagged it; one whose source does not is drawn dashed, keeping its text. Solid means the source names both companies, not that the tie is confirmed. It self-gates on the caller's account: a Pro account gets the private ?r= link + the downloadable PDF; any other account gets a short notice saying the tool works when signed in with an existing Pro account — and the prose report you wrote is the deliverable. Do NOT hand-roll your own markdown/PDF. On schema/firewall failure it returns {ok:false, errors:[…]} — fix and retry. (Prefer compile_report — the loose path avoids the strict hand-assembly.)

render_branded_report

WHEN TO USE — a BACK-COMPAT / advanced firewall check on a HAND-BUILT graph-JSON + report-JSON. The DEFAULT delivery path no longer needs it: compile_report (the terminal step) assembles the envelope from your LOOSE content and runs the SAME firewall internally, returning the graph_block and verification_block for you. Reach for validate_report only if you are working with a hand-built envelope and want to check it before rendering. It checks your graph-JSON + report-JSON against the frozen output contract, deterministically downgrades any fact whose source did not verify (pass your verify_claim verdicts), and returns: valid, errors (with a `fix` on each), coerced (what it auto-normalized), verification_summary {confirmed, flagged_recheck, no_evidence} — context for you, NOT a sentence for you to write: the server states the count itself in the block below, so reference that line rather than restating any number from this summary — a ready-to-paste `verification_block {text, empty}` you PASTE VERBATIM as the report's 'what I could and couldn't verify' section (the same way you paste graph_block for the map; it already LEADS with the tally and lists one line per flagged / no-evidence item — do not re-author it) — a `deliver_nudge` string reminding you that, when you deliver the report, compile_report is your closing step (always attempt it; it self-gates) — and a ready-to-paste graph_block {mermaid, ascii, legend} you PASTE verbatim as the report's relationship map (mermaid if your host renders diagrams, ascii on a plain terminal; do not re-draw or skip it, and never conclude the graph isn't worth pasting). ALSO pass entry_path — the recommended path as an ordered list of 2-4 short labels (focal/target -> channel/reseller -> end-customer segment); the tool draws it as dashed 'proposed' edges so a market-entry or honest-negative case is never an empty map. REQUIRED SHAPES (the tool is forgiving — it auto-normalizes case/hyphens/aliases, wraps a plain-string item, fills a missing authority, and reports EVERY remaining problem at once with a fix — so getting close passes in 1-2 tries; it never crashes on bad input). Use these shapes: graph = {focal:<node-id>, nodes:[{id:<kebab>, label, type:target|user|peer|partner|competitor|gatekeeper|warm-path, degree:<int>}], edges:[{source:<id>, target:<id>, type:partnership|acquisition|investment|supply|customer|ownership|competition|other, label, source_url, verified:<bool>}]}. Exactly ONE node must have type 'user' (your own company; on a target-segment report the focal IS the user). focal must be a node id; every edge endpoint must be a node id. report = {report_type:target-approach|target-segment|target-prospecting, verdict, coverage_label:High|Medium|Low, coverage_basis, sections:[{id:diagnose|map|set-rationale|choose|sequence|execute|govern, title, items:[{text, kind:fact|analysis|unverified, source_url, year}]}], sources:[{title, url, authority:primary|press|low-authority}], not_found, funnel:{covered:[str], needs_consulting:[str], cta}, next_leads:[{label, action:target-approach|change-objective|target-segment|focus-country|change-intent|change-business-line|hand-to-apim, ref}]}. verifications = [{entity_a, entity_b, url, status}] straight from verify_claim — pass its ECHOED entity_a/entity_b with each verdict (status is 'fact' or 'unverified'). The firewall matches each verdict to ITS OWN edge by (entity pair + url): a url that verified 'fact' for one pair (A↔B) does NOT confirm a DIFFERENT pair (A↔C) that reuses the same url — reusing one source's url to cite an unproven adjacent tie draws that tie DASHED, never solid. Omitting the entity pair grounds nothing (the edge draws dashed). 🔴 kind:'fact' REQUIRES a real source_url you confirmed with verify_claim — a fact without one is auto-downgraded to 'unverified', and a verified edge with no source_url draws dashed. Never invent a source. Loop until valid:true. REPORT OBLIGATIONS the server also checks for, returning a NUMBERED `revision` list naming the exact field and what to write (fix only those items, keep everything else, resubmit): a "choose" section when you rank 2+ targets (WHICH to start with, on what criterion, what would change it) · one diagnose item beginning "Premise:" and one beginning "If this is wrong:" (topic leads in the user's language, kind analysis — not source-status prefixes) · the reader's OWN company named rather than a placeholder · every target_table row id resolving to a graph node id · no node left with neither a relationship nor a mention in the text · table cells short enough to typeset. The delivery step asks once and then publishes anyway, marking whatever is still missing in the report itself.

validate_report

WHEN TO USE — call this on any business-development question (who to sell to / partner with / reseller / distribute / channel with, which customers, targets, or accounts to pursue, who owns or is locked up in a space, who's captive to a competitor, where to enter a market, who to source a supplier from, a rival's lock-ups — any B2B relationship or go-to-market question), before you state a company relationship or a hard number. It fetches the cited page and checks that the named companies actually appear in its body, so a stated relationship carries the source it was checked against, and the ones that could not be confirmed stay visible rather than being dropped. Call it on every cited relationship and sort the result into three levels, never a yes/no: (i) CONFIRMED — returns status:"fact" (the page body names both companies) → citable as fact; (ii) COULDN'T-CONFIRM — it didn't (one side missing, or the page spells a name differently) → retry a better source, then keep it visible as 'worth re-checking', never dropped, never a fact; (iii) NO-EVIDENCE. Pass the spelling the page likely uses (legal suffix / abbreviation / local-language form) so a true tie isn't lost to spelling. Also call with entity_b=null to confirm a single company's identity before you anchor a report on it. Do it on every load-bearing claim, never from memory — including any quantitative claim you asserted (funding, valuation, acquisition price, date, ownership, market share); for a batch of these use verify_claim_batch before you finalize. The verdict ECHOES entity_a/entity_b — carry them into validate_report's `verifications` so each verdict is matched to its OWN edge (a url proved for A↔B does not confirm a different tie A↔C that reuses it).

verify_claim

WHAT IT DOES — for each entry, opens the url you cite and checks (a) that both named companies actually appear in the page body and (b), when your `claim` carries a hard figure, that the figure appears there too. status:"fact" means exactly that: the cited page opened and it names them. It is NOT a finding that the relationship is real, current, or of the kind you described — it confirms the source, not the claim. A page that is a hub/list/directory, is blocked, or does not name them comes back "unverified". WHEN TO USE — TWO cases, both before you finalize a BD report. (1) You have MANY cited relationships to check (a whole candidate shortlist) — check them here in one call rather than firing many verify_claim round-trips. (2) PROACTIVE SELF-CHECK — before you deliver ANY report, batch-check EVERY quantitative or hard claim you asserted WITHOUT opening a source this turn: funding amounts, valuations, acquisition prices, dates, ownership / parent, market-share or rank percentages. Never state such a number from memory; a figure you did not put through this check is at most 'couldn't confirm', and if the page you cite does not carry the figure, correct it to what the source says. Check MANY entries in ONE call (bounded concurrency, fail-closed). Each entry is {url, entity_a, entity_b?, claim?}; returns a results array aligned 1:1 with your input (each the same shape as verify_claim) plus a summary. Each result also carries `claim_checked` — false means we confirmed the source names the companies and did not read your sentence. State a claim as confirmed ONLY as far as its entry goes: status:"fact" supports "the source I cite names both companies", not "the relationship is verified".

verify_claim_batch

The TERMINAL step of EVERY BD report: give your finished BD research as LOOSE, TYPED fields and the server assembles + delivers the branded report. Fill the fields directly (each is documented in this tool's input schema) — write ALL prose in the user's language, give every `targets[]` its `fit` (why THIS company) and `tie` (NAME the third party), a full `plays` for every beachhead, a report-level `synthesis`, a `title` that says what this report answers (no claim about what was verified), and one `ties[]` entry per relationship you checked (NAME the two companies + the exact URL you opened). Do NOT build the graph, node ids, edge wiring, or the {graph,report,meta} envelope — the SERVER assembles all of that from your ties (it never invents a relationship you did not assert) and re-runs its own source firewall (a tie whose page names both companies is drawn solid, the rest dashed). It SELF-GATES: a Pro caller gets back the private report link + PDF PLUS a ready-to-paste `graph_block` (the relationship + entry-path map with its legend, solid/dashed already set) and `verification_block` (the source-check tally) — PASTE both VERBATIM to end the report. It self-gates on the caller's account: a Pro account gets the private ?r= link + the downloadable PDF; any other account gets a short notice saying the tool works when signed in with an existing Pro account — and the prose report you wrote is the deliverable. Also returns `probe` assembly stats.

compile_report

WHEN TO USE — reach for this on any 'how do I get in / who do I know there / can anyone introduce me / what's my warm path / how do I reach [company]' question. Find deterministic reach routes from MY COMPANY to a target over the relationship graph you supply. Returns routes (with each hop's source_url), the broker intermediaries, a structural reading, and flags routes that survive only through a megahub as weak — plus an honest-thin caveat when reach is cold ('no warm path found' is a real, valuable answer, never invented around). This scoring is internal; translate it into plain language for the user, never quote the numbers or the words 'megahub'/'centrality'/'salience'.

find_warm_paths

WHEN TO USE — call this on any BD / go-to-market / partnering / sourcing / market-entry question, before you write the recommendation. WHAT IT RETURNS — analysis heuristics relevant to this objective: warm-path and structure reads, sequencing, the playbook lead for this objective, and the points where a person rather than a report should decide. Those are returned on every tier. Pass `domain` when the company or target is in a covered domain — "geospatial" (mapping/imagery/GIS/nav), "mobility" (auto/OEM/AV/EV/ADAS/robotaxi), or "b2b-tech" (SaaS/API/dev-tools/platform) — to also request that domain's industry-depth section. The industry-depth section is included with Pro: a caller without Pro access gets the general heuristics; the domain-specific depth is included with a Pro account sign-in. Omit `domain` for any other industry — an unrecognised industry adds nothing either way. (The legacy `geospatial=true` flag == domain="geospatial".) Weave the few that fit as kind:"analysis" — NEVER as fact; any real-world fact you assert while applying one still needs a verify_claim URL.

get_expert_principles

WHEN TO USE — reach for this on any 'who should I go after / who should I sell to / rank these targets / which of these first / who's the best beachhead' question, once you have a candidate list. Order candidate target companies by deterministic business fit (relationship-type weight + in-graph connectivity + objective fit), penalising megahub-only ties (salience ≠ fit). Returns a tiered ordering (beachhead / expansion / coverage) with a basis per row. This scoring is internal; translate it into plain language for the user, never quote the numbers or the words 'megahub'/'centrality'/'salience'. Give ONE plain-language line per staged placement in the prose saying WHY a company is 1단계 vs 2단계 vs 3단계 / step 1 vs 2 vs 3 — never the methodology word 'Wave' — (a named tie, a clear demand account, a blocker that pushes it later) — the score stays hidden and the reason is shown, so the user can audit the ordering. An empty or thin ranking here is NOT a signal to skip the map — the relationship map comes from validate_report's graph_block, not from this tool, so always call validate_report and paste the map regardless of how ranking came out. It ALSO returns a `target_table` array — the SAME ranked rows already shaped for `report.target_table[]` (rank / id / company / country / segment / tier + a short tie label); PASTE those rows straight into your report_json's target_table (then add each row's fit / blocker and, for 1단계 (where-to-start) rows, the per-lead `plays`) rather than re-deriving the ranking in prose — validate_report's B4 check nudges you if a ranked report ships a thin target_table.

rank_targets

WHEN TO USE — when a signed-in Pro user gives reusable context about their own company (company name, usual objective, differentiators, reference customers, deal shape) so later BD reports don't re-ask it. Save the signed-in Pro user's reusable BD profile — my_company, objective, focus, differentiators, reference_customers, deal_size, deal_timeline, deal_constraints, decision_structure. Stored server-side keyed to the account; saved fields auto-fill as DEFAULTS on later calls (an explicit tool argument always overrides a stored default). Only the fields you pass are updated. It self-gates on the caller's account: a Pro account saves the profile; any other account gets a short notice saying the tool works when signed in with an existing Pro account.

set_profile

WHEN TO USE — call this FIRST on any who-to-sell-to / partner / reseller / sourcing / market-entry question, to scope MY COMPANY to ONE real business line or offering before you research counterparties. The right counterparties differ sharply by line, so an unscoped run returns generic targets. WHAT IT RETURNS — this tool takes no arguments, and every caller gets a decomposition INSTRUCTION rather than a list: break MY COMPANY into its distinct offerings yourself, name them in plain words, pick the one this report is about, and scope everything downstream to it. No fixed business-line list is served here, so do not wait for one and never assume geospatial. For a signed-in Pro caller the result ALSO carries their saved company profile (company name, what they sell, reference customers, deal shape) — treat that as MY COMPANY instead of asking again; if it reports no saved profile, you may offer ONCE to create one. Use the plain line NAME in the report, never a code.

get_business_lines