examples/ has demo_rag.py and inclusion_proof.py, both of which show the happy path. The most convincing thing this project can show a newcomer is the unhappy one: change a single character in a source document, re-verify, and watch exactly which check fails and what the detail line says.
There is a tests/test_tamper.py, so the behaviour is covered. It is just not visible to anyone reading the repo rather than running pytest.
Proposal
An examples/tamper.py that builds a receipt, then walks through each way it can break, printing the verdict each time:
- a source document edited after the fact (fails
sources)
- a claim's citation swapped to a different source id (fails
grounding)
- the merkle root edited by hand (fails
merkle)
- the payload edited and re-signed with a different key (passes
signature, and this is the interesting one)
Paste its output into the README under a "what failure looks like" heading.
Good first issue: no library changes, only the example and a README section, and the tests already establish what each case should produce.
examples/hasdemo_rag.pyandinclusion_proof.py, both of which show the happy path. The most convincing thing this project can show a newcomer is the unhappy one: change a single character in a source document, re-verify, and watch exactly which check fails and what the detail line says.There is a
tests/test_tamper.py, so the behaviour is covered. It is just not visible to anyone reading the repo rather than running pytest.Proposal
An
examples/tamper.pythat builds a receipt, then walks through each way it can break, printing the verdict each time:sources)grounding)merkle)signature, and this is the interesting one)Paste its output into the README under a "what failure looks like" heading.
Good first issue: no library changes, only the example and a README section, and the tests already establish what each case should produce.