Evidence / Not claims
The distinction between a published artifact, a teaching model and a private project matters. This directory points to what is publicly accessible and says when implementation evidence isn't available.
Verified public code / Testable reference
These public original teaching projects contain their own tests and threat-model notes. They were prepared with AI assistance, are not claimed to be client work or production deployments, and currently have no explicit reuse license.
TypeScript / Node.js crypto / node:test
One-time challenge, request binding, replay rejection and concurrency edge cases.
5 passing Node tests at publication
Not platform attestation; a distributed deployment needs an atomic shared replay store.
Inspect GitHub repository ↗Try the related lab →TypeScript / Node.js / example PostgreSQL schema
Concurrent HTTP mutation deduplication, tenant-scoped keys, request fingerprints and retained outcomes.
6 passing Node tests at publication
Not distributed exactly-once processing or external transaction coordination.
Inspect GitHub repository ↗Try the related lab →TypeScript / Node.js crypto / node:test
Single-use refresh credentials, revoked sessions and replay-resistant family transitions.
5 passing Node tests at publication
Not a production auth provider; multi-node state requires durable transactions.
Inspect GitHub repository ↗Try the related lab →Publicly inspectable / Educational examples
Each lab runs deterministically in the browser. Download the same TypeScript models and regression tests that the site uses. No private source, secrets or customer data are in the bundle.
Download source and testsNot cryptographic attestation, production authentication, operational telemetry or evidence of a particular customer deployment.
These are engineering case studies with conceptual diagrams and verification approaches. They aren't presented as open-sourced customer systems, release notes or independently audited deployments.
Separating device posture hints from evidence a backend can actually verify.
Public source or verified app release: not provided
1 linked reference article(s)
Review the case study →Making identity recovery paths explicit instead of quietly weakening authentication.
Public source or verified app release: not provided
0 linked reference article(s)
Review the case study →Keeping verification and failure modes visible during retries and dependency outages.
Public source or verified app release: not provided
0 linked reference article(s)
Review the case study →Open source / GitHub
Public repositories appear here automatically, with clickable source links. Original projects are distinguished from forks so attribution stays clear.
Checking GitHub for current public projects…
Forked work is attributed as a fork, not presented as original code.
A future public project should have a verifiable repository URL, accurate ownership attribution, reproducible setup and tests, screenshots only when genuine, and measured results only when independently supportable. GitHub forks are labeled as forks.
Report an incorrect evidence claim