every tool inside fatcousin forensics
is publicly graded.
fatcousin forensics — the investigator-facing section of fatcousin.com — runs an automated audit against every tool in the forensics catalog and assigns a letter grade. the grade is visible on each tool's page, in case-type and industry lists, and exported alongside every captured tool run inside a case session. nothing is hidden. this page explains exactly how the grade is computed so investigators can decide for themselves how much weight to put on any output.
current grades · 1199 tools inside fatcousin forensics
- 555A · 46%
- 644B · 54%
- 0C · 0%
- 0D · 0%
counts regenerate every time the audit script is run (see methodology below). grades are not promotional — a B-grade tool is a perfectly useful tool with known boundaries; the rubric values honesty about limits over the appearance of polish.
letter grades
letters compress a 14-point raw score plus capability-class caps plus overclaim penalties into a single chip.
| grade | what it means | raw score | what to expect from output |
|---|---|---|---|
| Aflagship triage | real parser depth · 2+ exports with reason fields · honest limits · canonical UI shell | raw 12–14 / 14 | trust as a first-pass tool · still verify before any legal use |
| Bsolid triage | real parsing or rule engine · at least one structured export · honest about boundaries | raw 9–11 / 14 | useful for narrowing an investigation · expect rough edges on uncommon inputs |
| Cthin or overclaiming | marketing exceeds the engine · or shallow parser · or known UI drift | raw 5–8 / 14 | treat output as a lead at best · scheduled for deepen-or-reframe |
| Dbroken or stub | missing engine · crashes on standard input · or no exports | raw 0–4 / 14 | do not rely on output · scheduled for rebuild or removal |
capability classes
one capability class per tool — describing the dominant technique its engine uses. each class has its own ceiling. heuristic and ML-adjacent tools cap below A by default; they have to earn the ceiling through honesty, output quality, and UI consistency.
| code | class | what it does | max grade | examples |
|---|---|---|---|---|
| E | export / document parser | structured exports — JSON, CSV, EML, ZIP, HTML — parsed against the file format spec | A | google-takeout · gmail-mbox · slack-export |
| S | structured store parser | binary databases and plist/registry hives — SQLite, plist, lnk, registry text, logcat | A | sqlite analyzers · plist parsers · registry hive inspectors |
| B | binary / media inspection | byte-level inspection of image/audio/video/document containers and metadata | A | png-chunk · exif · header carving · stream inspection |
| H | heuristic screener | rule-based scoring · statistical anomaly detection · gap analysis — flags worth checking, not verdicts | B (A when honesty + output + UI all maxed) | anomaly detectors · gap analyzers · stat-only screeners |
| M | ML-adjacent claim | tools that imply learned classification — synthetic-voice, fingerprint, perplexity, deepfake | C (B when a real bundled model is verified) | synthetic-voice detectors · perplexity scorers · authorship probes |
seven dimensions
each dimension is scored 0, 1, or 2. raw score is the sum, out of 14. the rubric defines anchors for each score so two reviewers looking at the same tool land within one letter grade of each other.
| code | dimension | what it scores | score 1 anchor | score 2 anchor |
|---|---|---|---|---|
| IF | input fidelity | how many real artifact types and schema variants the parser actually handles | handles one well-known format | handles 2+ artifact types or multiple known schema variants |
| OU | output usefulness | what an investigator can actually export and reuse downstream | one structured export | 2+ exports with source-file and reason fields |
| DQ | detection quality | the granularity and explainability of any flagging logic | named rules + thresholds + reasons visible in the UI | multi-signal flags with severity levels |
| RB | robustness | how the tool behaves on malformed, empty, or oversized inputs | graceful skip with log · multi-file ingest | per-file error isolation · large input safe |
| HN | honesty | alignment between marketing copy and what the engine actually does | description matches capability | precise copy plus a visible limitations panel for heuristic/ML tools |
| CC | coverage / correlation | whether the tool joins evidence across files instead of treating them in isolation | multi-file dedupe and sorted timeline | cross-artifact correlation as promised |
| UI | ui consistency | use of canonical fatcousin shell components for predictable investigator behavior | uses container/section/dropzone primitives · some shell components | primary-button for exec · system-log · no local styled buttons · exec + status sections |
caps & overrides
- capability cap: H-class is capped at B unless honesty, output usefulness, and UI all score 2 and raw is ≥12. M-class without a verified bundled model is capped at C.
- overclaim cap: if the tool name or description uses a high-risk token (“detector”, “analyzer”, “decoder”, “reconstructor”, etc.) without engine evidence to support it, and honesty is below 2, the grade is capped at C.
- UI floor: if UI scores 0 and the raw score would otherwise be A or B, the grade drops one letter until the UI is migrated. (logic can be strong while the interface is still drifted.)
what a grade does not mean
- not a court-admissibility score. admissibility depends on jurisdiction, witness qualifications, and the entire evidentiary chain — not on anything fatcousin forensics, or fatcousin more broadly, can compute.
- not a guarantee of correctness. even A-grade tools can be wrong on rare inputs, malformed files, or adversarial samples. independent verification is always required before consequential use.
- not a popularity score. the grade is independent of how many people use the tool or how often it ships in a curated stack.
methodology & source
the rubric in long form lives at docs/forensics-tool-quality-rubric-v0.md in the public fatcousin repository. the audit is run by npm run tools:audit-forensics and outputs forensics-audit.csv at the repo root. the slug → grade map shown on each fatcousin forensics tool page is regenerated from that csv on every build via npm run forensics:grades.
newly-added tools entering fatcousin forensics must clear the B ship-bar before merging. the bar lives in .cursor/rules/forensics-new-tool.mdc and is enforced by quality.audit.json sidecars on each tool folder.