examples: fix fraud case-study blog link + byte-hash reproducibility claim#155
Open
ZhengyaoJiang wants to merge 1 commit into
Open
examples: fix fraud case-study blog link + byte-hash reproducibility claim#155ZhengyaoJiang wants to merge 1 commit into
ZhengyaoJiang wants to merge 1 commit into
Conversation
…y claim Two reader-facing fixes in the fraud-detection examples: 1. The case-study blog link pointed at weco.ai/blog/framing-the-problem, which 404s; the post ships as framing-the-puzzle-for-autoresearch (landing PR #90). Fixed in examples/README.md and both fraud-detection READMEs (4 occurrences). 2. prepare_data.py promised byte-identical SHA-256 parquets, but parquet bytes embed pandas/pyarrow writer metadata, so hashes do not survive version drift. Verified 2026-06-12 on a fresh venv (pandas 3.0.3, pyarrow 24.0.0): hashes differ from the published ones while evaluate.py still prints auc_roc: 0.909132 (strict) / 0.910171 (loose) exactly. A reader checking hashes would wrongly conclude their data prep failed. Replaced the hash claim in both prepare_data.py copies (docstring + final print) and the loose README with the version-independent check: evaluate.py reproducing the README baseline AUC. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Two reader-facing fixes in the fraud-detection examples (strict + loose), found while empirically verifying the strict example end-to-end for the Vardera case study blog (WecoAI/landing#92).
Dead blog link (4 occurrences across
examples/README.mdand both fraud READMEs):weco.ai/blog/framing-the-problem→weco.ai/blog/framing-the-puzzle-for-autoresearch, the slug the case-study post actually ships with (WecoAI/landing#90).Byte-hash reproducibility claim:
prepare_data.pyprinted "Expected SHA-256 (matches the published case study parquets)" and the loose README said the baseline is "verifiable via the SHA-256s". Parquet bytes embed pandas/pyarrow writer metadata, so hashes don't survive version drift even when the data is logically identical. Verified 2026-06-12 on a fresh Windows venv (pandas 3.0.3, pyarrow 24.0.0): both hashes differ from the published ones whileevaluate.pystill printsauc_roc: 0.909132(strict) andauc_roc: 0.910171(loose) exactly. A reader who checks hashes would wrongly conclude their data prep failed. Replaced with the version-independent check —evaluate.pyreproducing the README baseline — in bothprepare_data.pycopies (docstring + final print) and the loose README.The two
prepare_data.pyfiles remain byte-identical to each other after the edit; both compile-checked.🤖 Generated with Claude Code