Learning paths

This site has about a hundred pages, and no reader needs all of them. This page gives each kind of reader a short path: a handful of pages in order, and what each one gives you. Pick the card that sounds most like you; the paths share pages, so switching later costs little.

Every path starts from the home page. If you are not sure which card fits, start with Why a score isn't enough.

Evaluator: "What is this, and is it for me?"

You know Python and your own product. About 30 minutes.

1. Why a score isn't enough: the problem in three real settings, and the six checks as plain questions.
2. Naive vs grounded: the same events decided by a score rule and by this library, side by side.
3. Your domain's case: one worked example close to what you do (fraud, clinical, moderation, operations).
4. Trust levels and honest limits: what each check does and does not establish.
5. FAQ: latency, model compatibility, graph size, and when not to use it.

You leave able to say whether it fits your problem, and what it would cost you in held decisions and data work.

Integrator: "How do I wire it in and run it?"

You know your service, HTTP and databases. About half a day, hands on.

1. Install: add it to your project and check it works.
2. Your first decision: a policy, strong and thin evidence, and the record field by field.
3. Build a decision service: the reference HTTP service with saved state, audit log, retries and a review queue.
4. State and policy versions: saving state between requests and changing a policy safely.
5. Integrate into a service: FastAPI, Kafka and cached evidence.
6. Learn parameters from your history, steps 6 to 8: load learned settings, store their fingerprint, and watch the live error rate.
7. Roll out safely and Operate and monitor: shadow mode, alerts, and what each signal means.

You leave with a running service you can adapt, and a rollout plan.

Domain owner: "What will it decide, and why?"

You run fraud, clinical, operations or moderation decisions. No code needed. About 45 minutes.

1. Why a score isn't enough: what the library looks at besides the score, in your terms.
2. Act, abstain, degrade: the three outcomes and which ones reach a person.
3. Your domain's case: what it decided, and why, on a realistic example.
4. Where every number comes from: the few numbers you decide (the error rate you accept, what counts as a related case and a correct outcome) and how the rest are learned.
5. Estimate impact before launch: how many decisions it will hold, before you switch it on.
6. Design-review checklist: the questions to settle with your engineers before launch.

You leave able to explain a held decision to your team and to set the policy and review capacity it needs.

Data scientist: "How do my data and scores map in?"

You know models, scores, graphs and statistics. About two hours.

1. Your first decision: the evidence fields and the record.
2. From your data to evidence: a graph of related cases turned into evidence, then thinned out.
3. The six checks: the precise rule each check applies, with worked numbers.
4. Build evidence from your data: links, outcomes and calibration sets for real domains.
5. Where every number comes from: which values are measured from your graph, which are learned, and which are yours to define.
6. Learn parameters from your history: learn the margin, window, alpha and calibration set from labelled outcomes, with a certified error rate and a provenance record.
7. Choose thresholds and calibration: what each setting does, and how to override one by hand.
8. Compare outcomes and features: the helpers for distribution shift, A/B tables and feature checks.

You leave able to build evidence from your own tables, learn every setting from your outcomes, and show where each number came from.

Theory reader: "Which result, stated how, with what limits?"

You know probability, graphs and algorithms. Read at your own pace.

1. Theory overview: which result backs which check, and what the companion math catalog is.
2. How to read these pages and Where each result stands: proven, published, or a practical stand-in, and which catalog claims are open problems in the wider literature.
3. Recovering a label from related cases and Knife-edge densities: the two results the evidence checks lean on, and where the code departs from them.
4. Coverage for unfamiliar cases: the unusual-case check.
5. Learning settings with a guarantee: how the checks' settings are chosen from data (Learn-then-Test), the exact test, and what the certificate assumes.
6. What we left out and why: results that are true but useless at practical sizes.

You leave knowing exactly what each check relies on, and where the code uses a practical rule instead of a theorem.

Contributor: "How is it built, and how do I change it?"

You have this repository checked out. About an hour before your first change.

1. Development and automation: the make targets, tests, CI and releasing.
2. Architecture: the layers, and what happens once versus on every decision.
3. Package structure: where things live and what is public.
4. Internals overview: how a policy is compiled and how the solvers work.
5. Writing the documentation: the standard every page is held to.

You leave able to make a change, test it, and document it.