Inversion Thesis Engine

An evidence system that tells you whether a payment-infrastructure company is worth buying — and catches the lies in the CIM before you get to the data room.

The Problem

PE deal teams spend weeks reading CIMs, cross-referencing bank statements against management claims, and building EBITDA bridges in spreadsheets. The work is tedious, error-prone, and doesn't scale. When management says "we process $15M monthly" but the bank statements show $12M, that discrepancy hides in a tab someone forgot to check.

What This Does

Upload a PDF. The system reads it, extracts every financial metric it can find, tags each one as a fact or a claim, scores the company against Inversion's thesis criteria, and flags where management's story doesn't match the documents.

Three outputs, all auditable:

Thesis-Fit Scorecard — Six weighted criteria (fee intensity, cross-border exposure, processor concentration, settlement lag, reconciliation burden, ERP readiness) scored 0-1 from extracted data. No LLM in the scoring loop. Deterministic, reproducible, explainable.

Contradiction Report — Every claim compared against every fact for the same metric. Revenue stated as $25M in the CIM but $18.5M in the financials? Flagged as critical (26% discrepancy). Fee rates "below 2%" but processor reports show 2.9%? Caught. Severity thresholds: critical (>20%), high (10-20%), medium (5-10%).

EBITDA Bridge — Parameterized model: plug in current fee rates, settlement days, FX spreads, manual FTE count. Get projected savings across three scenarios (base, downside, partial adoption). Every assumption links back to the extraction that supports it.

How It Works

Upload PDF
  → Parse (PyMuPDF + pdfplumber)
  → Chunk (page-level, typed: text/table)
  → Extract (Claude Sonnet 4.6, schema-driven, fact/claim tagged)
  → Score (deterministic, 6 criteria)
  → Detect contradictions (claims vs facts)
  → Ready for analyst review

Everything runs async. Upload returns immediately with a job ID. Parse chains to extract, extract chains to scorecard + contradictions. The analyst sees results, not a loading spinner.

Quick Start

# Install
uv sync --all-extras

# Start Postgres + Redis + MinIO
docker compose up -d

# Add your API key
cp .env.example .env
# Edit .env → set ANTHROPIC_API_KEY

# Create tables
uv run python -c "from src.database import sync_engine; from src.models import Base; Base.metadata.create_all(sync_engine)"

# Run
uv run uvicorn src.main:app --reload --port 8000

# Create a company
curl -s -X POST http://localhost:8000/api/v1/companies \
  -H "Content-Type: application/json" \
  -d '{"name": "Acme Payments", "sector": "Payment Infrastructure"}' | jq .id

# Upload a CIM
curl -X POST http://localhost:8000/api/v1/companies/{ID}/documents \
  -F "file=@cim.pdf" -F "doc_type=cim"

# Check results
curl http://localhost:8000/api/v1/companies/{ID}/scorecard | jq
curl http://localhost:8000/api/v1/companies/{ID}/contradictions | jq
curl http://localhost:8000/api/v1/screener/rankings | jq

Tests

uv run pytest tests/ -v    # 107 tests, ~18s
uv run ruff check src/ tests/ dashboard/

All code follows the Google Python Style Guide with these project-specific choices:

• Line length: 100 (not 80) — configured in ruff
• Import style: from x import Class — idiomatic and consistent throughout
• Docstrings: Google-style with Args, Returns, Raises sections on all public functions
• Test docstrings: Not required per style guide §3.8.2.1

Design Principles

• Full provenance. Every extraction points to a chunk, every chunk to a document, every document to a file in S3. Nothing is a black box.
• Claims and facts are separate. The contradiction engine depends on this distinction. CIMs produce claims. Bank statements produce facts.
• Scoring is deterministic. No LLM in the scoring or bridge calculations. Reproducible, testable, auditable.
• Analysts decide. The system surfaces evidence and flags problems. Humans approve, override, or dismiss.
• Async everything. Uploads never block. Jobs chain automatically. Failed jobs are retryable.

Documentation

Detailed technical docs are in docs/:

• Architecture — system diagram, tech stack, project structure
• Data Model — all 13 tables
• API Reference — 25 endpoints across 7 resource types
• Engine Modules — extraction schemas, scoring criteria, contradiction algorithm, bridge calculator, job chaining
• Setup Guide — environment variables, Docker services, testing, usage examples