Course Drift Oracle
A signed drift report for Microsoft's ai-agents-for-beginners
course. It scans the course for two things that go wrong quietly:
- model pins that name a deployment which is deprecated or scheduled to
retire
- package version floors whose open
>= requirement now resolves to a
newer major version than the course was written against
Both are invisible in a diff. Nothing in a course repo tells you a pinned
model is about to stop serving, or that pip install today pulls a package
two majors ahead of what the lessons assume. Answering that question takes
someone actually checking each pin against the platform's own retirement
calendar and the package's real release history. This repository does that
checking, continuously, and sells the result as a signed report.
Why trust it
Every report is signed, not just asserted:
- Ed25519 signatures over RFC 8785 canonical JSON. The exact bytes that
were signed can be reconstructed and re-hashed by anyone, in any language.
A Python-signed receipt verifies against the TypeScript verifier with no
shared trust between them - see
oracle/receipt.py (signs) and
worker/src/logic.ts (verifies).
- Append-only publication chain. Every report ever published is a link
in
oracle/chain.jsonl, each entry pointing at the hash of the one before
it. Drop an entry, edit one, or reorder two and every later link stops
matching. oracle/verify_chain.py checks this independently of the code
that writes it.
verify_report is free. Call it before paying to confirm the free
summary's claims are backed by a real signature, and after paying to
confirm the paid report matches the hash the free summary already
committed to. A seller who serves fewer findings than promised gets
caught by arithmetic, not by trust.
- This repository is the source. Nothing here is a description of the
product; it is the product's actual scanner, signing code, and server,
in the same form that runs the live service.
Use it in five minutes
The service is an MCP server over streamable HTTP:
Copy-paste quickstart, plain curl, no client library (every command
here was run against production before being written down):
The same pattern calls every tool in the table above; only the name
and arguments change.
Ten tools:
The twelve audit checks, so you know what a score means before paying:
robots-exists, robots-ai-directives, robots-not-blanket,
llmstxt-exists, llmstxt-shape, llmstxt-links, mcp-advert,
structured-data, title-meta, charset, content-type-sanity,
homepage-response. Ten are scoreable; homepage-response and
robots-not-blanket are informational readings by construction and
never count for or against a site, which is why a flawless site scores
10 of 10, not 12 of 12.
A typical run:
- Call
drift_summary. It costs nothing and returns a signed receipt
describing how many findings exist, their severity, and which lessons
are affected. Decide from that whether the full report is worth buying.
- Call
verify_report with the receipt from step 1. Confirm the signature
is valid before you pay anything.
- Pay $0.25 and call
drift_report (or drift_report_x402 if you are
paying with USDC). You get every finding with a file, a line number,
what is wrong, and the fix.
- Call
verify_report again, this time passing the findings array you
just received alongside the same receipt. Confirm the hash matches -
this is what proves you got everything you paid for, not a trimmed
version of it.
Use it as a GitHub Action
Add the scanner to a course repo's CI in one line:
That is the whole add - every input below has a default.
Inputs
Outputs
Why offline is the default
PyPI lookups are a live-network dependency, and a one-line CI add should
not force one on a stranger by default. With offline: true (the
default), the Action only checks model pins against the catalog bundled
in this repo - no outbound calls beyond the checkout itself. Set
offline: false to also catch package version drift against the live
PyPI JSON API.
What it never touches
The Action never touches the Ed25519 signing key or the publication
chain (oracle/chain.jsonl). It only reads the checkout it is given and
the catalog bundled with the Action, and writes nothing back to the repo
it runs in.
Verifying a receipt yourself
Every response carries a receipt object: a signed statement of what was
found, when, and by which key, chained to every report published before it.
verify_report does the check for you over MCP, but nothing about it is a
black box - the two files that do the actual work are short and readable:
oracle/receipt.py builds and signs a receipt: canonicalize the payload
(RFC 8785), hash it (SHA-256), sign the hash (Ed25519).
worker/src/logic.ts does the same steps in TypeScript to check a
signature. Read both side by side and there is nothing left to take on
faith.
oracle/verify_chain.py walks the full publication history in
oracle/chain.jsonl and confirms every signature is valid and every entry
links correctly to the one before it - the check a buyer or an outside
auditor would run against the whole record, not just one receipt.
A free, signed skill
skills/course-drift-check/SKILL.md is the correct procedure for using
this oracle, written for agents: audit the seller before paying, pay on
either rail, verify the goods after. It is free, and it is signed - the
receipt.json beside it commits to the file's exact SHA-256 under the
same Ed25519 key that signs every report, so an agent loading the skill
can prove it is running the procedure the operators published, unaltered
(oracle/sign_skill.py is the 100-line signer; verification needs
nothing from us). Signature proves provenance and integrity, not
correctness - the same boundary every receipt here draws.
Payments
Two rails carry identical goods:
- MPP (Machine Payments Protocol) is designed to settle by card or
stablecoin; this deployment currently charges on the Tempo testnet.
- x402 settles in USDC and exists mainly for discovery: agents that
search for services through the x402 Bazaar only find ones that settle
through an x402 facilitator.
Both rails currently run on testnets - MPP against the Tempo testnet,
x402 against Base Sepolia. The x402 rail's payment mechanics are proven
end to end: on 2026-08-28 a real testnet settlement cleared against the
live worker (the buyer client in clients/ signed a $0.25 USDC payment,
the facilitator settled it on Base Sepolia, and the client independently
verified the findings hash it paid for - 7 passed, 0 failed, 0 skipped).
No mainnet money has moved, and MPP settlement has not yet been exercised;
both stated plainly rather than glossed over. You can reproduce the proof
yourself: fund a throwaway wallet with faucet USDC (no ETH needed) and run
the buyer per "Wiring a real x402 payer" in clients/buyer/README.md.
What this repository contains
Project-Office, the private repository this mirror is drawn from, holds
the day-to-day working process, deploy automation, and credentials. None of
that is needed to use or verify this service, so none of it is here.
Honest limits
- Payments settle on testnets, not mainnet, as of this writing.
- The model and package catalog this scanner checks against is maintained
by hand and covers a limited set of models today. Coverage expands every
cycle; it is not exhaustive yet.
- Signature verification proves a report was produced by this service and
has not been altered. It does not prove the report is correct - that
claim rests on the sources cited inside each finding, which you are free
to check yourself.
License
No license file is included. Absent one, all rights are reserved by
default; this is a decision for the repository owner to make explicitly,
not an oversight.
Contact
[email protected]