{"schema_version":"v1","name_for_human":"The Last Economy Wire","name_for_model":"last_economy_wire","description_for_human":"Real-time intelligence on AI-era capital flows (MIND), medical-progress signals (Hope, Trends) and a worldwide deduplicated clinical-trial index built from the primary registries ClinicalTrials.gov and ISRCTN. Free, open data with full provenance.","description_for_model":"Free, open intelligence API (version 1) with 20 documented endpoints in two domains:\nSIGNALS — MIND (AI-economy capital flows across Money, Infrastructure, Networks, Data), Hope (medical-progress index) and Trends (feed shape plus a crypto-launch lens), plus a batch endpoint that returns several signals in one call.\nWORLD CLINICAL TRIALS — a deduplicated index of distinct real-world trials drawn from the primary registries ClinicalTrials.gov and ISRCTN, with search, canonical records, raw registry payloads, duplicate-registration analysis, derived landscape analytics, registry coverage and per-registry sync provenance.\n\nENDPOINTS:\n- GET /api/v1/mind — A single trailing-window read on where capital, compute, and conscience are flowing: the four capitals (M·I·N·D), a sparkline, the conscience index, and the cure pulse. USE WHEN The question is about money, compute, networks or data flowing through the AI economy — funding momentum, infrastructure build-out, concentration of attention.\n- GET /api/v1/hope — Global active-trial counts, a per-disease breakdown, the latest curated cure research (paginated), and platform stats. Also carries a `world` block summarising the multi-registry trial index. USE WHEN You want the headline state of cure progress — how much active trial activity exists, per disease, plus the latest curated research reading.\n- GET /api/v1/trends — The live shape of the Wire (volume, 7-day momentum, where attention concentrates) plus the 2026 crypto TGE list read through the Cure Protocol distribution lens. USE WHEN You need attention dynamics — what is accelerating or decelerating in coverage — or the crypto capital-distribution reading.\n- GET /api/v1/batch — Fetch mind, hope, and trends together in a single request. Each signal is returned as its own sub-envelope so a partial upstream failure never fails the whole call. USE WHEN You want a broad orientation on the platform in one call, or you are rate-limit sensitive — batch costs ONE rate-limit slot instead of three.\n- GET /api/v1/trials/search — Search the deduplicated multi-registry trial store. Sources are primary registries only — ClinicalTrials.gov (US NIH) and ISRCTN (UK) — never secondary aggregators. A trial registered twice is returned once. Every result carries normalized fields, its source registries, source URLs and a quotable citation block. USE WHEN You need actual trial RECORDS — a list of studies matching a clinical question, with provenance you can cite.\n- GET /api/v1/trials/{canonicalId} — One canonical trial plus every source record behind it: registry, source id, source URL, retrieval timestamp, payload checksum and the raw registry payload. USE WHEN You have a canonicalId and need the complete record, or you need to inspect the untouched registry payload to verify a claim.\n- GET /api/v1/trials/{canonicalId}/related — The published research attached to one trial: the publications the registry itself declares, the Europe PMC records whose indexed text mentions the trial’s registration identifiers, and the OTHER registry identifiers those publications mention — each flagged with whether we hold it. A read-only sidecar: nothing it returns enters the index, any count, or deduplication. USE WHEN You have a trial in the index and need the evidence published around it — results papers, secondary analyses, protocol papers — or you want to discover sibling and follow-on registrations recorded in other registries through the literature.\n- GET /api/v1/trials/coverage — How many DISTINCT trials exist for a condition across every registry in the index, how many are the same trial registered more than once, which trials are exclusive to each registry, and the count inflation you would suffer by querying each registry separately and adding the results. USE WHEN Before you state a worldwide count. This is the endpoint that tells you whether a number is a true distinct count or an inflated sum.\n- GET /api/v1/trials/landscape — The derived shape of research on a condition: phase, status and study-type mix, sponsor concentration, enrollment scale, the completed-but-unreported results gap, momentum over 30/90/365 days, and a real diff against a stored earlier snapshot. Reports per-registry field completeness so a distribution built from one registry is never mistaken for a world-scale fact. USE WHEN You need the SHAPE of a field rather than its members — where the phase mass sits, who sponsors it, whether it is accelerating, how much of it went unreported.\n- GET /api/v1/trials/registrations — Given any registry identifier, every registry in which that same real-world trial is registered, the exact identifier evidence linking them, and which registries it is absent from. USE WHEN You have one identifier from an outside source and need to know whether it is the same study as another identifier you are holding.\n- GET /api/v1/trials/stats — Source-record count, deduplicated canonical trial count, active count, the curated topic list, and per-registry attribution. Counts are never summed across registries. USE WHEN First call when orienting on the trial corpus: how big it is, which registries contribute, and what topic ids exist for filtering.\n- GET /api/v1/sources — Every upstream registry: base URL, API type, licence, last successful sync, record count, whether the source is currently degraded, and the live contract-test verdict. USE WHEN Before presenting trial evidence as current or worldwide. This endpoint tells you which registries are healthy, when each last synchronised, and which are degraded.\n- GET /api/v1/status — Operational status, dependency health, the live endpoint catalog, and rolling SLO compliance per route. USE WHEN A call failed and you need to know whether the platform is degraded before retrying or reporting an error.\n- GET /api/v1/contract — Machine-readable proof that the discovery inventory, OpenAPI spec, MCP tool catalog, A2A skills, generated SDK and on-site documentation all describe the same capabilities. Returns 200 when they agree, 500 with the exact disagreements when they do not. USE WHEN You want to trust the documentation before building against it, or you are diagnosing a mismatch between the spec and real behaviour.\n- GET /api/v1/openapi.json — Full machine-readable schema for every endpoint. Import into Postman, generate SDKs, or feed to a codegen tool. USE WHEN You want typed access or want to generate your own client.\n- GET /api/v1/sdk — Download a ready-to-use TypeScript client generated from this capability catalog. Zero dependencies, works in Node and the browser. USE WHEN You are writing TypeScript and want method-per-capability access without hand-rolling fetch calls.\n- POST /api/v1/mcp — Streamable-HTTP MCP endpoint. Exposes every signal and the complete world-trials workflow as callable tools, plus a self-describing capability tool. USE WHEN You are an LLM client that speaks MCP. This is the lowest-friction way in — no key, read-only.\n- POST /api/v1/keys — Mint a personal API key to raise your rate-limit quota. The raw key is returned exactly once. USE WHEN You are being rate-limited as an anonymous caller and want a higher quota.\n- POST/GET/DELETE /api/v1/webhooks — Register a URL to receive an HMAC-signed POST when a signal changes. Delivery is retried up to three times with exponential backoff. USE WHEN You want to be told when a signal changes instead of polling.\n- GET/PATCH /api/v1/keys/usage — GET returns per-key call volume, error rates, and latency over 7- and 30-day windows plus your current rate-limit state. PATCH lets you tune your key's rate limit (120–10 000) or rename it. USE WHEN You need to know your own consumption or want to raise your own rate limit.\n\nMULTI-STEP WORKFLOWS:\n- Find every currently active human trial worldwide plausibly attempting a functional cure for a disease, separate the therapeutic modalities, and rank what looks most promising.\n  1. GET /api/v1/sources (Establish scope honesty first: which registries are covered, when each last synchronised, and whether any is degraded. This decides whether your answer may be called worldwide or must be called partial.)\n  2. GET /api/v1/trials/coverage?q=type+1+diabetes&status=active (Get the DISTINCT worldwide count before quoting any number, plus how many records are the same trial registered twice and how badly summing the registries would have inflated the total.)\n  3. GET /api/v1/trials/landscape?q=type+1+diabetes&status=active (Get the shape — phase mass, sponsor concentration, momentum, reporting gap — and read fieldCompleteness so you know which distributions are safe to quote.)\n  4. GET /api/v1/trials/search?q=type+1+diabetes&status=active&intervention=islet&pageSize=100 (Pull the records for ONE modality. Repeat with intervention=stem+cell, gene+edit, encapsulation, xenotransplant, immune+reset — one search per modality is how you build a comparison instead of one undifferentiated list.)\n  5. GET /api/v1/trials/search?...&include=eligibilityText (Add the eligibility prose only for the shortlist, when you must reason about a requirement that lives in free text — for example whether chronic immunosuppression is required.)\n  6. GET /api/v1/trials/{canonicalId}?includeRaw=true (For each shortlisted trial, verify the fields you are about to assert against the untouched registry payload and its checksum.)\n  7. GET /api/v1/trials/registrations?id=NCT07093359 (Confirm you are not double-counting a study that appears under two identifiers.)\n  Reporting rule: Report registry FACTS (phase, status, sponsor, enrollment, countries, endpoints, dates, identifiers, URLs) separately from your own INFERENCE (which approach looks most promising, and why). Quote each trial's citation.text. Name the denominator and the registries behind every count, and label the answer partial if any registry was degraded or absent.\n- How many trials exist worldwide for a condition?\n  1. GET /api/v1/trials/coverage?q=<condition> (Returns the distinct count, the cross-registry overlap and the inflation you would have introduced by adding registries together.)\n  2. GET /api/v1/sources (Qualify the number with each registry's last successful sync and degraded state.)\n  Reporting rule: Quote the distinct count with its registry attribution. Never sum per-registry totals.\n- What can this platform tell me?\n  1. GET /api/v1/batch (All three signals in one rate-limit slot.)\n  2. GET /api/v1/trials/stats (Corpus size, registry attribution and the curated topic ids for filtering.)\n  Reporting rule: The signals describe published attention and announced capital; the trial endpoints describe registry records. They are different kinds of evidence.\n- Someone cited a trial at me — is the claim true?\n  1. GET /api/v1/trials/registrations?id=<their identifier> (Resolve their identifier to a canonical trial and see every registration of it.)\n  2. GET /api/v1/trials/{canonicalId}?includeRaw=true (Read the untouched registry payload and its checksum, then compare field by field.)\n  Reporting rule: Quote citation.text and the verifyAt URL so the reader can check it themselves.\n- What has actually been published about this trial, and is there related work elsewhere?\n  1. GET /api/v1/trials/search?q=<condition>&resultsAvailable=true (Start from trials that declare results, so you are reading about studies that reported rather than studies that merely registered.)\n  2. GET /api/v1/trials/{canonicalId}/related (Registry-declared publications first (kind=results is the strongest evidence a trial reported), then the Europe PMC records mentioning its registration identifiers.)\n  3. GET /api/v1/trials/{canonicalId}/related?include=crossref (Surface OTHER registry identifiers co-cited with this trial in the literature — sibling and follow-on registrations in registries this index does not ingest. Check inIndex before you say anything about them.)\n  4. GET /api/v1/trials/{canonicalId}?includeRaw=true (Verify any registry field you are about to assert against the untouched payload.)\n  Reporting rule: Separate the three layers explicitly. Registry-declared publications are the registry’s own statement. Europe PMC hits are identifier MENTIONS, which may be citations or secondary analyses rather than results reports. Cross-registry mentions with inIndex=false are literature discoveries only — this index holds no record for them, so never present them as trials it contains or fold them into any count.\n\nCONTRACT: every success is {\"data\":…,\"_meta\":…}; every failure is {\"error\":{code,message,hint}}. _meta carries the schema version, a correlation id, the filters actually applied, pagination (with the exact next URL), provenance (which registries were consulted and the deduplication method), freshness (when each registry last synchronised and whether any is degraded) and discovery links.\nHONESTY RULES: never present a trial count as worldwide when _meta.provenance.worldwide is false or _meta.degraded is true — state which registries the number came from. Registry facts and your own analytical inference (rankings, plausibility judgements) must be reported separately. This API returns registry metadata only; it is not medical advice and contains no patient data.\nACCESS: no API key required (120 requests/minute per IP). An optional key raises quotas via X-Api-Key or Authorization: Bearer <key>.\nSTART HERE: GET /api/v1 is the canonical capability inventory; the same inventory is available over MCP as the list_capabilities tool.","auth":{"type":"none","instructions":"No authentication is required for anonymous access (120 requests/minute per IP). For higher quotas, include an API key via the X-Api-Key header or Authorization: Bearer <key>."},"api":{"type":"openapi","url":"https://negativeresistance.com/api/v1/openapi.json","is_user_authenticated":false},"mcp":{"type":"streamable-http","url":"https://negativeresistance.com/api/v1/mcp","description":"Model Context Protocol (MCP) endpoint exposing 13 callable tools: get_mind_signal, get_hope_signal, get_trends_signal, get_batch_signals, search_world_trials, get_world_trial, get_trial_related_research, get_trial_coverage, get_trial_landscape, find_trial_registrations, get_trial_stats, get_registry_sources, list_capabilities. Call list_capabilities first to get the full inventory, parameter vocabulary and recommended workflows.","tools":["get_mind_signal","get_hope_signal","get_trends_signal","get_batch_signals","search_world_trials","get_world_trial","get_trial_related_research","get_trial_coverage","get_trial_landscape","find_trial_registrations","get_trial_stats","get_registry_sources","list_capabilities"]},"a2a":{"type":"agent-card","url":"https://negativeresistance.com/.well-known/agent.json","description":"Agent2Agent (A2A) Agent Card describing this agent's identity and skills for peer-agent discovery."},"discovery":{"discovery":"https://negativeresistance.com/api/v1","openapi":"https://negativeresistance.com/api/v1/openapi.json","mcp":"https://negativeresistance.com/api/v1/mcp","agentCard":"https://negativeresistance.com/.well-known/agent.json","aiPlugin":"https://negativeresistance.com/.well-known/ai-plugin.json","sdk":"https://negativeresistance.com/api/v1/sdk","status":"https://negativeresistance.com/api/v1/status","provenance":"https://negativeresistance.com/api/v1/sources","contract":"https://negativeresistance.com/api/v1/contract","documentation":"https://negativeresistance.com/embed","connect":"https://negativeresistance.com/connect"},"logo_url":"https://negativeresistance.com/icons/icon-192.png","contact_email":"scarecrow@regan.studio","legal_info_url":"https://negativeresistance.com/about"}