Sec Beneficial Ownership

Given one 13D/A or 13G/A amendment (issuer + accession_number), find the SAME reporting group's prior filing in the chain and diff what changed: percent of class, aggregate shares owned, sole/shared voting & dispositive power (per reporting owner, matched by CIK or name), and — for 13D — whether the Item 4 purpose text changed. Walks back through the issuer's filing history (bounded, never a bulk crawl) matching on reporting-owner identity, since EDGAR does not carry an explicit "previous accession" link for this form family. Reports `prior_filing_found: false` honestly if no matching prior filing turns up within the scan bound, or if the chain predates the structured-XML rule (diffing free text is not meaningful).

{"accession_number":"0000921895-25-002808","ticker_or_cik":"IMXI"}

Parse ONE Schedule 13D or 13G filing by issuer + accession_number (get the accession_number from sec_13d_filings). Returns every reporting owner (the "group members") with percent of class, sole/shared voting power, sole/shared dispositive power, and aggregate shares owned; for Schedule 13D, also Item 4 — the free-text "Purpose of Transaction", which is where an activist states its intent (board seats, a merger, liquidation, or "no plans"). Filings from before SEC's 2024 structured-XML rule have no machine-readable fields — this returns `structured: false` plus the bounded plain text of the filing instead of silently returning empty data.

{"accession_number":"0001104659-25-086308","ticker_or_cik":"IMXI"}

List Schedule 13D / 13G beneficial-ownership filings (and their amendments, 13D/A and 13G/A) for one issuer — AUTHORITATIVE source for "who owns 5%+ of $TICKER" and "has an activist filed a 13D on this company". Takes a ticker or company name (auto-resolved to CIK) or a CIK directly. Each row flags `structured: true/false` — filings from SEC's 2024 XML rule onward are structured and feed straight into sec_13d_filing; older ones are plain text/HTML only. Use sec_13d_filing on any accession_number returned here to get the actual reporting-owner data (percent of class, voting power, purpose).

{"form_type":"all","limit":10,"ticker_or_cik":"IMXI"}

MARKET-WIDE search of Schedule 13D / 13G beneficial-ownership filings by FILING DATE — no ticker needed. AUTHORITATIVE for "which activist investors filed new 13Ds this month and which companies did they target", "who disclosed a 5%+ stake in anything last week", "new 13G filings since Monday". Returns, per filing: the SUBJECT company (the issuer targeted, with ticker and CIK), the FILERS (investors / reporting persons, with CIK), form, filing date, and whether it is an amendment. By default only NEW filings (amendments excluded; set include_amendments true to add 13D/A and 13G/A). For the first `enrich` structured filings (post-2024 XML rule, default 5, max 10) it also reads the filing itself and adds the reporting owners' percent of class and shares owned, the event date, and — for 13D — the Item 4 "Purpose of Transaction" text (the activist signal). Rows beyond `enrich` carry the index fields only; pass their accession to sec_13d_filing for the full parse. `total_matches` is the true count for the window, `scanned` how many were read (at most 300), and `truncated` says honestly when the window held more than was scanned — narrow the date range rather than assuming completeness. Default window: the last 30 days.

{"end_date":"2026-10-22","enrich":2,"form_family":"13D","limit":5,"start_date":"2026-10-01"}

Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id. Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions). Supported types: "sec_8k" (8-K filings matching ticker + item codes — e.g. items:["5.02"] = officer change), "polymarket_edge" (Polymarket↔Kalshi cross-venue mispricings — params:{topic:"fed"}), "fred_series" (new FRED observations — params:{series_id:"UNRATE"}), "patent_grant" (new USPTO grants for an applicant), "clinical_trial" (new/updated ClinicalTrials.gov studies), "form_d" (new SEC Form D fundraise notices — params:{state?, industry?, min_amount?, exemption?}, all optional), "news_keyword" (GDELT keyword news alerts, metadata+link only — params:{query, lang?, domains?}), "job_post" (new public job-board postings — params:{ats?, board_token?} or {domain?}, plus optional title_query/location_query), "tool_diff" (re-runs any read-only tool on a schedule and fires on change — params:{tool, args?, fields[], schedule}), "new_entity" (new business registrations from a state business-entity registry — params:{state:"CO", name_query?, entity_type?}), "tech_change" (a watched domain's website technology stack adds or drops a technology — params:{domains:["acme.com"], technologies?}). Delivery channels: feed (always on — pull via recent_alerts or GET registry.pipeworx.io/alerts.json), and optionally email (set delivery:{email:"you@x.com"}) or sms (delivery:{sms:"+15551234567"} — phone must be verified at /account first; 10/day cap).

What can I ask Pipeworx? / what is Pipeworx good for? / what can you do? / give me ideas / show me examples / getting started / what data do you have? — the onboarding entry point for an agent that just connected and wants to know what is worth asking. Returns category-bucketed example questions (company financials, drugs & clinical trials, economics, real estate, prediction markets, weather, government & patents, science & academia, news) — each with the exact tool + argument shape that answers it, drawn from the live catalog of thousands of tools. Call with no arguments for the full spread, or pass `topic` (e.g. "finance", "pharma", "betting") to focus. Use this FIRST when you do not yet know what Pipeworx can do for you, or to learn how to call the meta-tools (ask_pipeworx, entity_profile, compare_entities, etc.).

{"topic":"finance"}

Cancel a subscription by id. Ownership is enforced — you can only cancel your own subscriptions. The row is deactivated (not deleted) so its historical events stay available via recent_alerts.

How often two venues settled the SAME 15-minute crypto window differently, over every settled window on record. Compares polymarket.com (Chainlink TWAP) with Kalshi and with Polymarket US (both CF Benchmarks BRTI), and Kalshi with Polymarket US as the same-feed control. Per pair: windows both venues settled, divergent count, the rate with its 95% Wilson interval (withheld under 30 paired windows), which direction they split, and what was excluded (unsettled on a side, 50-50). A HEADLINE RATE IS A CONCENTRATION QUESTION, so every pair also carries `concentration` (UTC days and hours the divergent windows fell in, the busiest day, the top-3-day share, and a plain reading) and `by_how_decided` (the rate by how far the reference venue's mid was from 50 at its last priced minute: the rate is a fraction of a percent for windows that were decided by the end and tens of percent for the ones that were not). `divergent_path` gives the mean Up mid by minute on both venues over the divergent windows only, split by who said Up, so the "early spike that fades" story can be checked rather than assumed. Measured on the archive 2026-10-27 over 30 days of btc: polymarket.com vs Kalshi diverged on 48 of 2,847 windows (1.69%, interval 1.27-2.23), spread over 27 of 31 UTC days, 0.19% of windows decided by the end and 17-29% of the ones still undecided; Polymarket US vs Kalshi on 0 of 1,838. asset btc | eth | sol | xrp | bnb (bnb has no pair: Kalshi only); days 1-90 (default 30), capped by what the archive holds (it starts 2026-09-22 for polymarket.com and Kalshi, 2026-10-07 for Polymarket US). Read-only; cheap enough to call, it reads several thousand archive rows.

{"asset":"btc","days":30}

{"asset":"eth","days":14}

The same 15-minute crypto "up or down" window priced on polymarket.com, Polymarket US and Kalshi, side by side, with whether each pair is actually the same contract. Pass asset (btc | eth | sol | xrp | bnb) and window ("current" default, "next", "previous", or the window START as ISO such as 2026-10-27T14:15:00Z, on a 15-minute boundary). Per venue: question, Up bid / ask / mid / last, spread_pp, quote_state, volume WITH ITS UNIT, open interest, liquidity, settlement source, comparison basis, when it settles. THE VENUES ARE NOT ONE CONTRACT. Kalshi and Polymarket US settle on CF Benchmarks' BRTI (60-second average at the end against the same at the start): the same bet, so a gap between them is a real disagreement. polymarket.com settles on a Chainlink 60-second TWAP, end against start: same comparison shape, different feed, so a gap against either is partly the contract. `pairs[]` gives equivalent ("true"|"false"|"unclear"|"not_comparable") from resolution_diff for every pair, material_differences, mid_diff_pp (a minus b, in percentage points) and read_as in words. Measured over 30 days of settled windows the Chainlink and BRTI feeds settle a window differently about 1.2-1.8% of the time, almost entirely windows that ended near the threshold (see updown_divergence_rate). `net_spread` is computed only for the pair that is equivalent: the gap in mid terms and at top of book (buy Up where cheaper at the ask, Down where Up is dearer at 1 minus the bid) after BOTH venues' taker fees, each fee carrying its verified-as-of date. Top-of-book size is shown where the venue publishes it (Polymarket US); the Kalshi figure is not in its market payload, so read its order book before sizing. A venue with no market for the window is {status:"not_listed", reason}; one that could not be read is {status:"unavailable", refusal} -- never an empty object, and never the same thing. A one-sided book (typical Polymarket US just before a window is decided) has quote_state "bid_only", a null…

{"asset":"btc","horizon":"15m","window":"current"}

{"asset":"eth","window":"previous"}

{"asset":"btc","window":"2026-10-27T14:30:00Z"}

"Is it true that…" / "fact check" / "verify the claim that…" / "did X really…" / "was Y actually…" / "confirm or refute" / "true or false" — natural-language claim verification against authoritative sources. Use whenever the agent needs to check whether something a user said is factually correct. Company-financial claims (revenue, net income, cash for public US companies) verify via the structured SEC EDGAR + XBRL fast path with exact percent-delta math; ANY OTHER factual claim (macro statistics, rates, prices, drug data, records) automatically falls through to the grounded pipeline — routed to the right live source, answered with verbatim evidence, then judged. Returns a verdict (confirmed / approximately_correct / refuted / inconclusive / unsupported / could_not_verify), the grounded or structured actual value with pipeworx:// citation, and reasoning. IMPORTANT for callers: could_not_verify means the check did not happen (our LLM or source failed) and carries verification_error{stage,detail} — it is NOT evidence for or against the claim, and must not be shown as one. unsupported means we looked and cover no source for it. Replaces 4–6 sequential calls (NL parsing → entity resolution → data lookup → comparison).

{"claim":"Apple's fiscal 2023 revenue was $383 billion"}