Don't trust packages.
Re-derive them.
Every rederive package ships its contract — a spec and a held-out oracle — not bytes you have to trust. Verify the shipped code against it, or re-derive the code yourself from the spec.
The oracle is an independent source of truth no publisher can move. Tamper with a shipped package and it's caught two ways at once: the behavior fails the oracle, and the content hash mismatches.
Apache-2.0 · the CLI and catalog are free forever · launching on npm soon
You don't audit your dependencies. You trust the publisher.
And the publisher is the attack.
A maintainer pushed an infinite loop and garbage output into colors and faker — packages with millions of daily downloads, buried deep in transitive trees — breaking thousands of builds overnight. Nothing was technically "hacked." You ran the bytes the registry handed you, because that's the only thing a package manager ever gives you: bytes, and a name to trust.
Ship the contract, not the bytes
A rederive package carries a structural spec and a held-out oracle — worked input→output examples derived by executing the original. The implementation is something you verify or regenerate, not something you accept on faith.
Verify, deterministically
rdv check re-runs the held-out oracle against the shipped code and verifies its content hashes. No tokens, no network, no trust — just a pass/fail against an oracle the publisher can't edit.
Re-derive locally
Don't want to trust the shipped binary at all? rdv resynth regenerates the code from the spec with isolated workers, independently, and accepts it only on quorum. Torch some tokens; trust your own build.
Tamper-evident by construction
Change one byte and it's caught two ways at once: the behavior fails the held-out oracle, and the recorded content hash mismatches. Supply-chain tampering is detected from the contract alone.
See it work
A real package: @rederive/colors, a zero-dependency re-derivation of colors@1.4.0 — the last release before the sabotage.
$ rdv check @rederive/colors
✓ VERIFIED strip (str) => string
held-out 10/10 hashes match (zero-dep, FUNCTIONAL)
ALL UNITS VERIFIED — shipped src matches its contract.
# 2. tamper with the shipped code — flip one byte
$ rdv check @rederive/colors
✗ FAILED strip
held-out 5/10 miss=[csi_clear, osc_set_title, …] hashes MISMATCH (src:false)
VERIFICATION FAILED — do not trust this src; rebuild with: rdv resynth
# 3. so don't trust it — re-derive it yourself from the spec
$ rdv resynth @rederive/colors --n 3
spawned 3 isolated workers (original deleted) …
strip: emit_1 10/10 emit_2 10/10 emit_3 10/10
QUORUM 3/3 → applied; manifest srcSha256 updated
✓ VERIFIED — trust your own build, not the publisher's.
The held-out oracle even documents the original's real limits — colors.strip removes only color codes, so cursor/title-injection escapes survive. rederive pins that in the contract instead of hiding it.
Two ways to not trust a package
Both anchored to the same independent oracle. Neither requires trusting the publisher's bytes.
Verify
Re-run the held-out oracle against the shipped code and check the content hashes. If the bytes don't match the behavior the contract promises, it fails — loudly.
Re-derive
Regenerate the implementation locally from the spec with N isolated workers — the original never in scope — and accept it only when independent rebuilds agree on the full held-out set.
How it works
Three ideas, one principle: the source text is fungible; the executable behavior is fundamental.
SIR spec + a held-out oracle
Each unit decompiles to a structural spec (the SIR graph) and a behavioral oracle whose expected outputs are stamped by executing the original — never hand-authored. A frozen set teaches; a disjoint held-out set grades. Passing the held-out is evidence of behavior, not of matching a snapshot.
Independent rebuilds that must agree
To re-derive, N workers reconstruct the unit from the spec + oracle with the original deleted, in isolation. The build is accepted only when ≥2 independent emissions pass the full held-out set. One passing rebuild is luck; agreement is evidence.
Trust anchored to something the publisher can't edit
The verdict isn't the publisher's say-so or even the rebuild's self-report — it's a held-out oracle plus content hashes. A tamper fails the behavior and the hash. Self-consistent verification can rubber-stamp a mistake; an independent oracle is a brake.
The catalog
Verified re-derivations of the dependencies you can't trust to a maintainer anymore — starting with the abandoned and the once-sabotaged.
strip re-derived, quorum 3/3, 10/10 held-out — the last good release before the sabotage.eq / grade / quorum / hashOk — adversarial held-out, quorum 3/3. Re-derive your own verifier.getProxyFromURI), and a full NET trace unit (httpRequest) — ordered EMIT + REQUEST verified with the http transport injected (record/replay). All quorum 3/3. Re-deriving request.js's whole Request class is the remaining frontier.Want a specific dead dependency re-derived and behavior-locked? Tell us which one.
Some code is too tangled to re-derive. Untangle it — without changing what it does.
The catalog re-derives a unit from a compact contract. A 2,000-line promise machine or a stateful HTTP client has no compact contract. So you keep the original running as the oracle, propose a clean factoring, and prove the clean version still behaves exactly like the old one.
Re-derive from the contract
For a nameable unit with a compact spec + held-out oracle: delete the original and rebuild it by quorum. This is what the catalog ships.
Behavior-lock against the retained original
For a tangle: keep the original as a live oracle, cut it into firewall-clean units, and verify the result reproduces the original on generated, held-out scenarios it never saw. Modernize legacy code and prove the behavior is unchanged.
Time, the event loop, concurrency
Timers run on virtual time; the event loop is injected and replayed; genuinely concurrent code is verified by owning the message scheduler and checking the whole space of interleavings — scaled past brute force with partial-order reduction.
Proven on real modules: debug, q, request's redirect state machine (256/256 on generated + held-out scenarios), and p-map (its concurrency contract verified across the entire interleaving space for small inputs, partial-order-reduction-scaled beyond). The method is validated today; rdv normalize as a one-command workflow is what we're building next — not a shipping command yet.
Open core. Honestly.
The tools that verify trust are free and open, forever. We only ever charge for running them at team scale — never for the core.
The open core
- The
rdvCLI — check, vis, resynth - The SIR specification & package format
- The verified-recompose loop
- The public
@rederive/*catalog
The extra tools that make it better
- Managed re-derivation — don't run the fleet or spend your own tokens
- Private catalogs for your internal code
- Continuous verification & behavioral-drift alerts
- Governance — SSO, RBAC, policy, audit logs
- Compliance attestation — EU CRA / SSDF / SOC 2 evidence
We wrote down what we'll never do.
We will never paywall the ability to verify or re-derive a public package, never cripple the open core to force an upgrade, and never retroactively relicense what we've released. It binds the company through any funding, board, or acquisition — a written commitment, not a vibe.
Read the rederive Promise →About
rederive is built on Semcom's verified-recompose engine — the same machinery that compiles natural-language intent into verified, dependency-free machine code. Lane Thompson is the inventor and CEO of Apilify Inc. The idea is simple and uncomfortable: most tooling makes the publisher's bytes the source of truth. rederive makes an independent oracle the source of truth, and lets you regenerate the bytes yourself.