StillTrue — the freshness & claim-verification layer for AI

One line: give StillTrue a URL (and optionally a fact you believe is true), and it tells you whether the page is still live, whether its content changed since the last check, and whether your claim still holds — with confidence, a change summary, and supporting evidence.

Why it wins: AI agents and RAG pipelines hallucinate because they act on stale data. StillTrue is the "reality check" an agent calls before it commits to a fact or an action. It isn't a scraper fighting anti-bot walls — you bring the URL. And the moat compounds: every check stores a snapshot, so over time we own the change-history of the URLs the market cares about. That can't be copied overnight.

---

The contract (what every call returns)

{
  "url": "https://en.wikipedia.org/wiki/Python_(programming_language)",
  "checked_at": "2026-06-08T14:33:42+00:00",
  "is_live": true,
  "http_status": 200,
  "first_seen": true,
  "changed_since_last_check": false,
  "changed_at": null,
  "change_magnitude": 0,
  "change_summary": null,
  "claim": "Python was created by Guido van Rossum",
  "claim_status": "supported",
  "claim_confidence": 0.64,
  "claim_evidence": "Guido van Rossum began working on Python in the late 1980s as a successor to the ABC programming language.",
  "content_hash": "3ea21d77d6338320",
  "error": null
}```

`claim_status` ∈ `supported | contradicted | unverifiable | no_claim`.
Design principle: returning **`unverifiable`** when we can't tell is a feature — a verifier you can trust beats one that guesses.

---

## Run the demo (offline, no network needed)

```bash
pip install trafilatura httpx
python demo.py

It serves two versions of the same product page and proves the full pipeline: first-seen → supported, then page-changed → contradicted, while ignoring nav/footer noise.

Use as a library

from stilltrue import check
result = check("https://example.com/product", claim="The price is $29.00")
print(result.to_dict())

---

Project structure

stilltrue/            # the tested core engine (558 lines)
  models.py           # the result contract
  fetcher.py          # HTTP layer (injectable for tests / Apify proxy)
  extractor.py        # main-content extraction (kills false-positive diffs)
  diffing.py          # change detection + summary
  claims.py           # claim verification (v1 deterministic; strong on prices/numbers)
  store.py            # snapshot store (local JSON now; Apify KVS at deploy = the moat)
  engine.py           # orchestration: check(url, claim) -> CheckResult
demo.py               # offline proof
src/                  # Apify Actor entry (async, KVS-backed)
.actor/               # Apify config (actor.json, input_schema.json)  [DRAFT — verify at deploy]
Dockerfile            # Apify build  [DRAFT]
requirements.txt

---

Roadmap to sale

• 1. Spec & wedge — freshness + claim verification, price/number case first.
• 2. Core MVP — engine built and tested (this package).
• 3. Wrap — finalize Apify Actor + MCP server; verify .actor config vs current docs; first deploy.
• 4. Moat — persist snapshots in Apify KVS; add changes/timeline output + "notify me when X changes" webhook.
• 5. Pricing & packaging — pay-per-call + free tier; write the Store listing copy.
• 6. Distribution — publish to Apify Store + list on MCP directories. Launch.
• 7. Iterate — add the optional LLM verifier to upgrade free-text claims.

Honest limitations (v1)

• Claim verification is deterministic and strongest on numeric/price/quantity claims; free-text semantic claims degrade to unverifiable until the LLM verifier (step 7) lands.
• .actor/ config + Dockerfile are a deploy-ready draft — confirm field names against current Apify docs before the first push.
• The sandbox can't fetch arbitrary sites, so the engine is proven on injected fixtures; real fetching runs on Apify (with proxies).