Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

21 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

DBscouter

A database and ranking system for Dragon Ball characters, their forms, and their power levels across all canon and non-canon media — eventually backed by a public website for sorting and filtering.

The premise: arguments about who beats who in Dragon Ball are usually arguments about evidence. This project collects the evidence properly — every fight, scouter reading, boast, and transformation, cited down to the episode and subtitle line — and then ranks characters with a statistical model instead of vibes. Scouter readings anchor the low end of the scale, pairwise fight outcomes and comparative statements do the rest, and the model reports its own uncertainty because everything past the Frieza saga is honestly speculative.

A core design decision: the ranked unit is not "Goku" but (character, form, era). Saiyan-saga Goku and Buu-saga Goku are different nodes, as are Super Saiyan Goku and Ultra Instinct Goku. Skipping that produces nonsense rankings.

See PROJECT_PLAN.md for the full phase plan.

How it works

corpus (subtitles + wiki dumps)          <- fetched by db-content-fetcher
  -> dbscouter.sqlite                    <- built by ingest/
       media       episode/movie registry, canon tiers, dub-variant tagging
       lines       ~279k subtitle lines (FTS5-indexed), dub and sub tracks
       aliases     Kakarot=Goku etc., from 13k wiki redirects + curation
       characters / forms / eras / entities    the (character, form, era) registry
       power_readings    262 numeric anchors parsed from guidebook data
       claims      3,660+ typed, cited, reliability-tagged evidence records
  -> ranking model (planned)             <- Bradley-Terry over pairwise claims
  -> website (planned)

The corpus itself is not in this repo. It lives in a sibling checkout of db-content-fetcher, whose scripts download subtitles and Dragon Ball Wiki pages politely and record provenance for every file. Wiki content is CC-BY-SA (attribution: Dragon Ball Wiki); subtitle files are for personal research and are not redistributed here — only derived claims and short cited quotes.

Rebuilding the database

The SQLite file is fully derived and disposable. With the corpus checked out as a sibling directory:

python ingest/build_db.py        # registry, lines, FTS, aliases
python ingest/build_anchors.py   # power readings + entity registry
python ingest/build_claims.py    # wiki fight backbone + candidate pass
python ingest/extract_claims.py --load data/extraction/claims_transcript.jsonl
python ingest/apply_fight_outcomes.py --load data/extraction/fight_outcomes_wiki.jsonl
python ingest/apply_comparative_review.py --load data/extraction/comparative_review_transcript.jsonl
python ingest/review.py --reapply
python ingest/resolve_claims.py  # claim -> (character, form, era) entities
python ingest/dedupe_claims.py   # dub/sub merge + wiki-fight linking
python model/fit_bt.py           # Bradley-Terry fit -> bt_scores

The extract/reapply steps replay work that is expensive to redo: the LLM extraction results (2,000+ claims pulled from subtitle passages) and the human review decisions, both stored in this repo in stable formats that survive rebuilds.

Where the claims come from

Two sources, deliberately layered:

  • Wiki fight lists (1,801 fights): the wiki's per-episode Battles sections record who fought whom, in which forms. They do not record winners — those get filled in by extraction and human review.
  • Subtitle mining (~2,000 claims): a lexical pass cuts 279k lines to ~4,800 candidates, then an LLM pass extracts structured claims with a speaker-reliability tag. A scouter readout is instrument-grade data; Vegeta declaring himself unbeatable is a boast. Characters lie and misjudge constantly, and the model will weight accordingly.

Every claim cites its source (episode, dub/sub track, line number) and carries a review status. The review workflow is spreadsheet-based — see the docstring in ingest/review.py.

Status

Phase
0 Corpus acquisition done
1 Normalization, SQLite + FTS5, alias table done
2 Power-reading anchors + entity registry done
3 Evidence extraction extraction done; human review in progress
4 Bradley-Terry ranking model entity resolution, dedupe, first fit done; iterating with review
5 Website planned

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages