# PIT — agent ingest > PIT is a point-in-time API for the US public record, built for evaluating models on data they could not have trained on. Given an instant and a company, it returns the filings that were visible then, the timestamp field it filtered on, and a coverage certificate for every day it read. Two eval windows come with it: a frozen offline bundle that ships issuer-redacted and date-shifted control arms as files, and a live tape that has been recording the record forward every 15 minutes since 2026-08-26, which puts each new week past any published training cutoff. Subscription plans are $29 and $79 a month. This file concatenates the first-party reference pages and a route list. Prefer `/llms.txt` as the map and follow its links; use this file when one document is easier than seven fetches. Host: `https://api.pit.aqx.llc`. Spec: `https://api.pit.aqx.llc/v1/openapi.json`. Auth: `Authorization: Bearer pit_live_…`. Local: `http://127.0.0.1:8080`. Everything below was read from a running server on 2026-08-26. ## What PIT sells A knowledge cut over the public record, rather than a headline feed. The two operations are `query_as_of(instant)` and `became_knowable(T0, T1)`. 1. Every historical read names `visible_by`, and the response repeats it. 2. Rows carry a `lane`, and a single page never mixes the two: `certified_pit` comes from a publisher artifact we stored and hashed; `forward_first_seen` is stamped when our poller first saw it, so a slow poll pushes the timestamp later than the publisher's release. 3. Coverage certificates come back in the body of every cut. 4. Identity — ticker to CIK valid at an instant — is resolved as part of the query. 5. REST suits interactive exploration; the signed parquet files are the path for a backtest that reads the whole corpus. 6. YouTube, Reddit, and Google News are not in the certified corpus. PIT does not publish prices, sentiment scores, or broker connectivity, and it does not resell licensed newswire text. ## The platform One product with four named capabilities, described together at https://pit.aqx.llc/products. They read the same rows through the same envelope, so a number one of them produces is comparable with a number from another. | capability | what it serves today | what it does not serve yet | |---|---|---| | Corpus | the as-of API and the certified history under it: 587,689 queryable rows, seven sources, oldest partition 2008-09-01; flat parquet partitions with a sha256 each on Power and above | filing text and per-filing items, both being crawled now; identity coverage wider than SEC ticker-to-CIK | | Tape | the forward record: a tick every 15 minutes since 2026-08-26, each new row stamped with the minute our poller first saw it, on the `forward_first_seen` lane, streamed from `/v1/stream` | a one-minute cadence, which needs a scheduler change plus a fresh tick measurement on the deployed image | | Bundles | `pit-eval-sec-2022-11_2023-03`: three arms over the same 287,929 rows (as served, issuer redacted, dates shifted ten years forward), a sha256 per file in `MANIFEST.json`, one certificate per calendar day in `receipts.jsonl` | the rebuild that carries filing text, which waits on the text crawl | | Monitor | a job that re-fetches every SEC day we hold complete, compares the bytes against the receipt stored when we first fetched them, and reports the rows SEC added, deleted or rewrote in its Saturday index rebuild | any published finding: the job is tested offline against fixtures and its first public report has not run | ## Timestamps Each row carries five. Three can be named in `visible_by`; the other two are there to be read. | field | records | query clock | |---|---|---| | event_at | when the underlying event happened, where the publisher states one | no | | published_at | the filer, publisher, or index clock. The default | yes | | available_at | first public availability we hold evidence for; null where we hold none | yes | | acceptance_at | SEC `ACCEPTANCE-DATETIME` from the filing header, converted from Eastern. Records EDGAR acceptance, which precedes dissemination | no | | committed_at | when we wrote the row. A 2026 backfill of a 2020 filing carries a 2026 value | yes | `visible_by` takes `published_at`, `available_at`, or `committed_at`. An empty value becomes `published_at`. Any other name, `event_at` and `acceptance_at` included, returns `invalid_clock` with HTTP 400. A row is in the cut when its chosen clock is at or before `as_of`. Both bounds are UTC and the comparison is inclusive. `acceptance_at` is populated only for filings whose EDGAR header we fetched, so most SEC rows carry null. Read it per row rather than assuming a partition has it. ### Asking for a clock the corpus does not hold Asking for `available_at` over a source that carries no availability evidence returns HTTP 409. `count` comes back as JSON null and `coverage.missing` holds an `availability.` key naming the source and the day. The corpus has nothing to answer the question with, and the status says so. ``` GET /v1/sample/news?example=svb&as_of=2023-03-10T23:59:59Z&visible_by=available_at → 409 status: "coverage_missing" count: null coverage.missing: ["availability.sec.edgar/2023-03-10"] ``` Every `sec.edgar` row has `available_at: null`, because SEC publishes no dissemination clock, so every strict cut over SEC data answers this way. ### Where available_at comes from `availability_basis` names the evidence, so a caller can tell a receipt from a published schedule. | availability_basis | meaning | where | |---|---|---| | unknown | no evidence; `available_at` is null | all of sec.edgar, all of us.ofac.sdn, and 2,208 Federal Register special filings | | ofr_regular_pi | the Office of the Federal Register's documented 08:45 America/New_York public-inspection batch | 19,528 us.federal_register.pi rows | | scheduled_release | a release time the publisher states in advance | all 1,149 us.cftc.cot rows, at 15:30 America/New_York on the release date | The 08:45 Eastern batch converts to 13:45Z in winter and 12:45Z in summer, so the UTC stamp moves with daylight saving. In a spring-forward gap or an autumn fold the wall-clock time is ambiguous, and the ingest job errors on that row instead of picking one of the two instants for it. ### Dates with no time Some publishers give a date and nothing finer. A date covers a whole day, and we encode it at the end of that day. | source | date-only case | published_at | |---|---|---| | sec.edgar | every daily-index row, which carries Date Filed and no time | filed date at 23:59:59Z | | us.federal_register.pi | a special filing with no `filed_at` | available-on date at 23:59:59Z | Day-start would place a whole day of filings before they existed: `2023-03-10T00:00:00Z` is 19:00 on 9 March in New York, and the SVB 8-K was accepted at 17:23 Eastern on the 10th, which would have made it readable 22 hours and 23 minutes early. Day-end errs the other way, so read `published_at` on a date-only row as an upper bound at day resolution rather than a claim about the minute. The bound stays inside the same UTC day, so `partition_date` is still the UTC date of `published_at`. To replay a whole day, ask at or after `23:59:59Z`; a cut earlier in the day returns none of that day's date-only rows. Where a real intraday clock exists we use it instead of the bound: the Federal Register `filed_at`, the 08:45 public-inspection batch, and `acceptance_at` from an EDGAR header. Python: `query_as_of(..., known_at=...)` maps to `GET /v1/news` with `as_of`. Paid historical reads require `as_of`. `became_knowable(T0, T1)` is the set of rows not visible at T0 and visible at T1 on the same clock, served by `GET /v1/news/diff`. It is a different question from "rows whose `event_at` falls in the window". ## Coverage certificates One certificate covers one source on one UTC day. `status` is `complete`, `missing`, or `partial`. A complete certificate carries the row count we hold; a missing one carries `row_count: null` rather than 0. ``` GET /v1/coverage?source=sec.edgar&date=2023-03-10 { "source_id": "sec.edgar", "partition_date": "2023-03-10", "status": "complete", "row_count": 3124, "sample": false, "scope": { "scope_id": "sec.edgar.forms.v1", "selection": "form_allowlist", "forms": ["10-K","10-K/A","10-Q","10-Q/A","13D","13D/A","13G","13G/A","4","4/A", "6-K","6-K/A","8-K","8-K/A","SC 13D","SC 13D/A","SC 13G","SC 13G/A"], "scope_sha256": "d17340d6247e3e26ea015c6bcbf5ad5a6f5fa8881f689508455e0b9985e5e2af" } } ``` `scope` says what the count was measured against. On `sec.edgar` the selection is a form allowlist of 18 types, hashed so a caller can tell whether two certificates were measured against the same forms. The certificate above counts 3,124 rows from an EDGAR daily index holding 5,461 data rows; the other 2,337 rows span 129 form types outside the allowlist, and `scope` is where that difference is declared. On a complete certificate, `row_count` is the rows we hold for that source-day. It is a different number from the `count` on your cut: `sec.edgar/2023-03-09` is complete with 2,828 rows, and the 9 March 20:00Z SVB cut still returns 0. | | complete and empty | gap | |---|---|---| | HTTP | 200 | 409 | | status | ok | coverage_missing | | count | 0 | JSON null | | results | [] | [] | | read it as | we hold that day and nothing matched the cut | we do not hold that day, so the number of filings is unknown | A complete certificate with `row_count: 0` is the third case: the publisher published nothing in scope that day. The openFDA enforcement sources have those — `us.fda.enforcement.drug` holds seven certified days, six complete and empty, one carrying all 85 rows. Asking `/v1/coverage` for a source and date we never ingested returns a missing certificate rather than a 404. ### Coverage keys `coverage.touched` and `coverage.missing` hold keys rather than certificates. There are four shapes. | shape | example | names | |---|---|---| | partition | `sec.edgar/2023-03-10` | one source on one UTC day | | identity | `identity.ticker/FB@2023-03-10` | one ticker's identity on one UTC day | | frontier | `sec.edgar/frontier:2008-09-01..2023-03-31;holes=93` | where a source's certified span starts and stops, with the count of days inside it that are not complete at or before the cut | | availability | `availability.sec.edgar/2023-03-10` | a source asked for `available_at` that holds no availability evidence | A source id cannot contain `/` and a ticker cannot either, so the shapes never collide. The frontier key is one line per source instead of thousands of absent days in every envelope; `/v1/coverage` enumerates what is inside it. ### What turns a cut into a 409 Keys in `touched` are the scope of the answer. Keys in `missing` suppress it: `status` becomes `coverage_missing`, `count` becomes JSON null, and no rows are read. Four things put a key there. 1. **No certificate.** No source in scope holds a certificate anywhere, so the answer would rest on nothing. A misspelled `source` lands here. 2. **Partition.** The cut's own UTC day is not complete for a source in scope. Missing, partial, and no certificate at all are all gaps, including a date outside the source's certified span. 3. **Identity.** A `ticker` that no point-in-time interval places at `as_of`. 4. **Availability.** `visible_by=available_at` asked of a source that carries no availability evidence. Gaps behind the frontier do not refuse later cuts. One uncertified weekend in 2008 would otherwise refuse every query the API can be asked, so completeness behind the cut is reported in the frontier key instead. Naming a `source` narrows the scope. A cut with no `source` touches all seven, and on 2023-03-10 two of them — `us.cftc.cot` and `us.ofac.sdn` — hold no certificate for that day, so the unscoped call is a 409 while `source=sec.edgar` answers 200. ### Identity gaps An identity key in `missing` means no point-in-time interval covers that ticker at `as_of`. Three things cause it: we never curated the ticker, its interval had lapsed, or it had been reassigned. ``` GET /v1/news?ticker=FB&as_of=2023-03-10T23:59:59Z → 409 count: null coverage.touched: ["identity.ticker/FB@2023-03-10", "sec.edgar/2023-03-10", …] coverage.missing: ["identity.ticker/FB@2023-03-10", …] ``` FB became META on 2022-06-09, so no interval places FB in March 2023. The SEC partition for that day is complete, and the gap is on the identity axis. Ask `ticker=META` for a cut after the rename, or `ticker=FB` for one before it. Without the identity key the same call would answer `count: 0` with clean coverage, which reads as though Meta had filed nothing that day. Any query naming a `ticker` records its identity key in `touched` whether or not the ticker resolved. `touched` carries one partition key per source in the cut's scope plus one frontier key each, so the real list is longer than the two lines shown above. Two cases that are not gaps: identity resolved and nothing matched (`count: 0`, `status: ok`), and a `ticker` plus `cik` pair whose intersection is empty, where identity is known at the cut and simply does not include that CIK. ## Identity mapping Ticker to CIK valid at an instant. Intervals are half-open, `[valid_from, valid_to)`: the left edge is included and the right edge is not, so an instant falls in exactly one interval per ticker. A listing opens the left edge and a delisting or suspension closes the right one. The CIK changes only when the registrant does. | ticker | cik | name at T | valid_from | valid_to | |---|---|---|---|---| | FB | 1326801 | Facebook, Inc. | 2012-05-18 | 2021-10-28 | | FB | 1326801 | Meta Platforms, Inc. | 2021-10-28 | 2022-06-09 | | META | 1326801 | Meta Platforms, Inc. | 2022-06-09 | null | | SIVB | 719739 | SVB Financial Group | 2005-05-31 | 2023-03-28 | The 2021-10-28 boundary is the company rename on the same symbol. The 2022-06-09 boundary is the Nasdaq ticker change from FB to META, effective before the open. SIVB was suspended on 2023-03-28, so the SVB filings of that March still map. `leakage_risk` labels where a mapping row came from: `curated` is `none`, and `sec_company_tickers_current` is `current_universe` — a dated snapshot of today's SEC ticker file, holding the assignments in force when the snapshot was taken, so joining 2019 filings on it drops FB. A ticker whose only interval at the cut is `current_universe` is treated as a coverage gap on `/v1/news` rather than resolved. Paid: `GET /v1/mapping/ticker/{ticker}?as_of=` and `GET /v1/mapping/cik/{cik}?as_of=`, with `as_of` required. Omitting it returns `invalid_clock` with HTTP 400. A ticker that no interval places at `as_of` returns HTTP 409 with `coverage_missing` — the same fact that appears on `/v1/news` as an `identity.ticker/…` key in `coverage.missing`. ## Envelope Every JSON body, including errors, has this shape. `/v1` is additive: field names, error codes, and parameter names are never reused for a new meaning, and new fields may appear without a version bump. ``` { "request_id": "uuid", "corpus_version": "sha256:…", "as_of": "2023-03-10T23:59:59Z", "visible_by": "published_at", "status": "ok", "results": [], "next_cursor": null, "count": 0, "coverage": { "touched": [], "missing": [] }, "error": null } ``` `status` is `ok`, `error`, or `coverage_missing`. `count` is the number of rows in this page of a cut that was actually served; a gap, a 400, a 401 and a 429 all report JSON null instead of 0. `corpus_version` is a SHA-256 over the corpus the answer was read from, and sample routes report `sha256:sample`. Timestamps are RFC3339 UTC with a literal `Z`. Cursor pagination, sorted on `(published_at, id)`. `limit` defaults to 100 and accepts 1 to 1000; outside that range the call returns `invalid_request` with HTTP 400. `next_cursor` is opaque and is null on the last page. A caller totalling a cut adds the pages up rather than reading the first `count`. Headers: `X-Request-Id` on every response, `X-Corpus-Version` on corpus reads, `X-RateLimit-Limit`, `X-RateLimit-Remaining` and `X-RateLimit-Reset` (UTC unix seconds), and `Retry-After` on a 429. Corpus reads also carry `ETag`, `Cache-Control: private, max-age=300` and `Vary: Authorization`; send the ETag back as `If-None-Match` for a 304. ### Error codes `error` is `{ code, message, param }`. `code` is stable and safe to branch on, `message` is plain English and may change, and `param` names the offending parameter or is null. | code | HTTP | cause | |---|---|---| | invalid_clock | 400 | `as_of` missing or malformed, or `visible_by` naming a field that is not a query clock | | invalid_request | 400 | an unknown parameter, or a value outside its range | | unauthorized | 401 | key missing, malformed, or revoked | | plan_required | 403 | no plan, or the plan does not include what was asked for | | commercial_license_required | 403 | the declared use needs a commercial license | | not_found | 404 | no such row or route | | coverage_missing | 409 | a key in `coverage.missing`; `count` is JSON null | | rate_limited | 429 | over the per-minute limit; `Retry-After` gives the wait | | internal | 500 | a server fault, identified by `X-Request-Id` | | billing_not_configured | 503 | checkout unavailable in this deployment | | auth_not_configured | 503 | that login method unavailable in this deployment | An unknown query parameter returns `invalid_request` and names the parameter. Dropping it quietly would run a broader query than the caller asked for and hand back the result as though the filter had applied. ## Routes (API version 0.1.0) Public, no key: - `GET /health` — liveness - `GET /llms.txt` — the short map - `GET /docs` — human documentation - `GET /v1/openapi.json` — the specification - `GET /v1/meta` — corpus version, accepted clocks, plan limits, per-source row and certificate counts - `GET /v1/sample/news` — `example=svb|aapl|meta`, optional `as_of` and `visible_by`. Watermark `sample: true` - `GET /v1/sample/diff` — sample `became_knowable` - `GET /v1/sample/coverage` — the 16 certificates behind the samples - `GET /v1/sample/mapping` — sample identity at an instant Sample routes are limited to 30 requests a minute per IP and are not a free plan. Paid, `Authorization: Bearer pit_live_…`, with `as_of` required on historical reads and either `ticker` or `cik` named: - `GET /v1/news` — the cut at `as_of` - `GET /v1/news/{id}` — one row; `as_of` is required, so the read is still a point-in-time question - `GET /v1/news/diff` — `became_knowable(as_of_start, as_of_end)` - `GET /v1/coverage` — certificates; optional `source`, `date`, `as_of` - `GET /v1/mapping/ticker/{ticker}` — `as_of` required - `GET /v1/mapping/cik/{cik}` — `as_of` required - `GET /v1/files` — parquet partitions, each with its own SHA-256 and a signed GCS URL. Power plan - `GET /v1/files/{id}` — a signed GCS GET, not a packed custom binary - `GET /v1/stream` — server-sent events for new rows carrying `available_at`, once live ingest runs Account and billing, session or key as specified in the OpenAPI document: `/v1/auth/*`, `/v1/me`, `/v1/keys`, `/v1/billing/checkout`, `/v1/billing/portal`, `/v1/billing/usage`, `/v1/billing/webhook`. ## Sources Certified: SEC EDGAR daily indexes (the 8-K family, 10-K and 10-Q, Form 4, 13D and 13G), Federal Register public inspection with the regular 08:45 America/New_York batch, OFAC SDN actions, and CFTC Commitments of Traders with a 15:30 America/New_York scheduled release. In the `forward_first_seen` lane: openFDA enforcement for drug, device, and food. Curated ticker-to-CIK intervals back the identity routes. License terms per source: https://pit.aqx.llc/legal/license Read from `/v1/meta` on 2026-08-26 — 587,689 queryable rows under 612 certificates, 415 of them complete. The tape adds to the sec.edgar and us.federal_register.pi rows continuously, so treat those two as floors: | source | lane | rows | complete | missing | first partition | last partition | |---|---|--:|--:|--:|---|---| | sec.edgar | certified_pit | 564,182 | 204 | 99 | 2008-09-01 | 2026-08-26 | | us.federal_register.pi | certified_pit | 21,931 | 182 | 91 | 2020-02-01 | 2026-08-26 | | us.cftc.cot | certified_pit | 1,149 | 4 | 0 | 2023-03-07 | 2023-03-28 | | us.ofac.sdn | certified_pit | 7 | 4 | 1 | 2023-03-09 | 2024-08-06 | | us.fda.enforcement.drug | forward_first_seen | 85 | 7 | 0 | 2023-03-06 | 2023-03-12 | | us.fda.enforcement.device | forward_first_seen | 41 | 7 | 0 | 2023-03-06 | 2023-03-12 | | us.fda.enforcement.food | forward_first_seen | 17 | 7 | 0 | 2023-03-06 | 2023-03-12 | First and last are `partition_date` bounds, the day the publisher assigned, not `published_at` bounds; on `sec.edgar` a few index rows carry a Date Filed earlier than the partition holding them. The SEC backfill is ten months rather than a continuous run: 2008-09, 2020-02, 2020-03, 2021-01, 2021-10, then 2022-11 through 2023-03, with the live tape adding days from 2026-08-26 on. Only that last backfilled stretch is contiguous — 151 calendar days from 2022-11-01 to 2023-03-31, every one certified, 103 complete and 48 missing — with Federal Register public inspection over the same window. Of the 99 SEC days marked missing, 88 are Saturdays and Sundays and 11 are US federal holidays, so every calendar day inside those ten months carries a certificate. Federal Register public inspection has 91 such days. They are recorded as missing because we never fetched the index for them, so there is no measurement to certify. The newest row of the backfill is one OFAC action dated 2024-08-06, so between 2023-03-31 and 2026-08-26 no PIT call returns a SEC or Federal Register filing. The live tape has been writing every 15 minutes since 2026-08-26; rows it writes arrive on the `forward_first_seen` lane, stamped with the minute our poller first saw them. Each week it runs is an eval window dated after any published training cutoff. Not retained: WSJ, Reuters, Bloomberg, or FT article bodies, and scraped publisher HTML presented as a licensed archive. ## Samples (no account) ``` curl -s 'https://api.pit.aqx.llc/v1/sample/news?example=svb&as_of=2023-03-09T20:00:00Z' ``` `count` is 0 with `coverage.missing` empty, so the zero is a fact about SVB rather than a gap in the tape; `sec.edgar/2023-03-09` is complete with 2,828 rows. ``` curl -s 'https://api.pit.aqx.llc/v1/sample/news?example=svb&as_of=2023-03-10T23:59:59Z' ``` `count` is 1 on the default `published_at`. The row is accession `0001193125-23-067777`, CIK 719739, form 8-K, with `published_at=2023-03-10T23:59:59Z` (a date-only row at the day-end bound), `available_at=null`, `availability_basis=unknown`, and `acceptance_at=2023-03-10T22:23:03Z`. The same `as_of` with `visible_by=available_at` returns 409. Mapping: `example=meta` with `as_of=2021-10-01T00:00:00Z` answers FB, and `as_of=2022-06-10T00:00:00Z` answers META, on CIK 1326801. Interactive: https://pit.aqx.llc/demo — four moments (`?example=svb`, `meta`, `aapl`, `fr`), each running two cuts at two instants. The samples are three fixed companies for reading the shape of a response. The rest of the corpus needs a key. ## Plans and license | plan | price | as-of range | rate | keys | flat files | |---|---|---|---|--:|---| | sample | free, no account | three fixed examples | 30/min per IP | — | no | | researcher | $29/mo | the whole ingested history | 60/min | 3 | no | | power | $79/mo | the whole ingested history | 300/min | 10 | yes | | desk | $499/mo | the whole ingested history | 1,200/min | 25 | yes | All three paid prices are founding prices, and a founding subscriber keeps theirs. All three read the whole ingested history, so the rate limit, the key cap, and the parquet files are what a customer is choosing between. Each account belongs to one person, and the API has no route that creates a seat or an organization. Access is paid; the sample routes are the only free surface. A self-serve key covers internal research and applications you operate for yourself or your employer, and checkout requires an attestation to that effect. A commercial license — `operations@aqx.llc` — is required if your end users receive PIT data, or if you redistribute, resell, sublicense, embed it in a customer-facing product, train a public model on it for others, or build a competing information API. Legal: https://pit.aqx.llc/legal — terms, privacy, license, refund, AUP, subprocessors. ## Compare, one line each Each of these is a page with a comparison table. Price bands quoted on them are public list prices as of August 2026. - https://pit.aqx.llc/compare/pit-vs-massive — Massive sells the tape and a Benzinga news add-on; PIT sells the knowledge cut. Complementary. PIT does not resell Benzinga text - https://pit.aqx.llc/compare/pit-vs-tiingo — Tiingo News is an inexpensive publisher-clock archive; PIT names the clock and labels gaps - https://pit.aqx.llc/compare/pit-vs-benzinga — Benzinga originates catalysts; PIT serves the as-of public record - https://pit.aqx.llc/compare/pit-vs-newsapi — NewsAPI and Newscatcher search headlines; PIT does not scrape the open web as certified data - https://pit.aqx.llc/compare/pit-vs-ravenpack — RavenPack is sales-led news analytics; PIT has no sentiment product Alternatives pages, same rules: https://pit.aqx.llc/alternatives/sec-api-io (sec-api.io indexes 20 million EDGAR filings back to 1993 and sells the filing text; PIT bounds the query to an instant and states which days it read), https://pit.aqx.llc/alternatives/benzinga-news-api, https://pit.aqx.llc/alternatives/tiingo-news Worked examples: https://pit.aqx.llc/use/llm-backtest-without-lookahead and https://pit.aqx.llc/use/sec-8k-as-of ## Running a backtest against PIT 1. Name `visible_by` on every historical read. 2. Cut at `as_of`. A row whose chosen clock is null stays out. 3. On `coverage_missing`, stop. Imputing zero events over a gap is the error the 409 exists to prevent. 4. Join identity at the cut instant, not against the current ticker file. 5. For rows that appeared between two instants use `/v1/news/diff`, which asks about visibility rather than event time. 6. Keep `certified_pit` and `forward_first_seen` apart. 7. Explore over REST; read the whole corpus from the parquet files on the Power plan. 8. Do not prompt a model with a live index and label the prompt with a historical date. ## Common mistakes - Writing a value into `available_at` that no receipt or published schedule supports. - Reading a coverage gap as zero events. - Joining historical filings against the current ticker universe without labeling the leakage. - Expecting WSJ, Reuters, Bloomberg or FT article bodies, YouTube archives, Reddit posts, or Google News results; none of them are in the corpus. - Attributing a SOC 2 or ISO certification, a traffic figure, or a free API key to PIT. Contact: operations@aqx.llc Site: https://pit.aqx.llc Status page (off the API origin, DNS not yet pointed): /status