Correct by construction.
Dependency-free by consequence.
rederive builds software as verified units: decompose into named leaves, contract each one with a held-out oracle, rebuild it blind, accept only on quorum. Every unit answers to a source of truth its author can't move.
We never ask it to avoid npm. A fully decomposed workflow simply never needs a package — except as an oracle: run the ecosystem's decades of reference behavior to stamp contracts, then ship none of it. Dependencies don't get replaced. They stop existing.
Apache-2.0 · free forever · live now: npm i -g rederive · sir-factory + sir-toolkit open on GitHub
Numbers from a production app built end-to-end this way — the full story below.
One method. Three doors.
Every artifact ships a contract — a spec plus a held-out oracle stamped by executing a reference — and verification is a command anyone can re-run. Apply that verb where you need it:
Write features as verified units
Decompose to named leaves, contract each, rebuild blind by isolated re-emitters, accept on quorum. Correctness lands on your app code — and the dependency count falls out on its own. A production app built this way ↓
Get packages out of your trust tree
For the dependencies you already have: re-derive them as verified, zero-dependency vendors you own — or verify shipped code against its contract before you run it. Why the publisher is the attack ↓
Re-run the evidence on every change
rdv check is deterministic, offline, and free — in CI, in an audit, on an auditor's own laptop. Evidence you re-run beats evidence you attest. The compliance posture ↓
The method doesn't stop at your code. Builds, IAM policies, network topology, machine code — the same derive-and-verify verb runs the whole stack at Semcom, where this engine comes from.
Built this way: a production shared-mailbox AI categorizer
A real application, written essentially one-shot — every functional unit constructed by blind re-emitters that never saw an original, or each other.
38 units, 38 first-time quorums
Every unit decomposed to a named leaf, contracted, and rebuilt by three isolated clean-room workers: 114 blind rebuilds, 114 passes (38 × 3 — check the arithmetic yourself). Agreement between workers that can't see each other isn't luck; it's evidence the contract is complete.
Graded on what no one saw
463 held-out vectors (of ~949 total) stayed hidden from every implementation. Passing cases you never saw is evidence of behavior, not memorization — the same split that separates a correct port from a confident hallucination.
~2,090 checks on every change
The pipeline re-proves the whole app deterministically — offline, no tokens, no AI in the loop. A regression anywhere in the contract surface turns a check red before it turns a user's day bad.
The part nobody asked for
The finished app's dependency list reads like an architecture diagram. At the platform edges, what the environment requires: React + MSAL in the browser, Apollo/GraphQL + jose at the API — every one pinned to an exact version. Interior to those edges — core, worker, all the logic — exactly one discretionary npm package: zod, at the validation boundary. Nobody banned npm; the decomposed workflow just never reached for it. The registry served as a library of oracles: reference behavior to stamp contracts from, not code to ship.
Don't trust packages. Re-derive them.
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. And it hasn't stopped: 2025's Shai-Hulud worm spread through compromised npm packages' install hooks. A verified rederive vendor sits in your own tree — no install hooks, no unread transitive code, every byte accounted for.
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.
Reduce your npm dependencies — by replacing them.
A popular package we tested declared 5 dependencies. npm i installed 650 packages. That's not unusual — that's normal.
You can't audit 650 packages
Nobody can. Scanners — npm audit and the good commercial ones — tell you which of the 650 are known-bad today. The other six hundred stay what they've always been: unread code with publish rights into your build.
So stop shipping them
rederive replaces a dependency with a verified, zero-dependency vendor you own — re-derived from its contract, proven on held-out cases it never saw, hash-pinned in your tree. The tree gets smaller. What remains is code you can account for.
Scanning flags packages. rederive removes them. That's the whole difference — and it's why the verified core itself ships with zero dependencies.
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.
Get started
Install once, then put it to work — from Claude Code, or just the verifier in CI.
# 2 · the Claude Code plugin — the skills & agents that drive them
# 3 · put it to work — just ask Claude Code:
# and in CI, the verifier alone re-proves any verified unit — deterministic, offline, no AI
Behind those two asks: sir-verify re-derives a unit from its contract — blind rebuilds, graded on held-out cases they never saw. preflight builds the oracle for untested code first — coverage + adversarial review + mutation testing + chaos, gated on a measured score. All Apache-2.0: sir-toolkit · sir-factory · rederive. Sending an agent instead? rederive.ai/prompt.md is the whole flow, written for 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.
The EU CRA asks about your components. Answer with proof.
The Cyber Resilience Act's obligations start phasing in from September 2026. Its due-diligence question is old-fashioned and brutal: do you know what's in your product — and can you show your work?
A dependency tree you can actually answer for
A tree of verified, zero-dependency vendors is a component inventory with nothing hiding in it: every byte accounted for, every behavior pinned to a contract, no transitive strangers. That is the component posture CRA due diligence expects — by construction, not by paperwork.
Verification an auditor can re-run
rdv check is deterministic, offline, and free. So your evidence isn't a PDF claiming verification happened once — it's a command the auditor can run again and get the same verdict. Re-runnable proof beats attested proof, every time someone doubts you.
Attestation, when you need it packaged
Continuous verification with EU CRA / NIST SSDF / SOC 2 evidence packaging is what rederive Cloud is for. The verification itself stays free and open, forever — that's written down. Shipping into the EU and want to talk it through? Book a call.
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 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 Semcom's verified-compute method applied to the languages you already ship — the same machinery that compiles natural-language intent into verified, dependency-free machine code, one level up. Lane Thompson is the inventor and CEO of Apilify Inc. The idea is simple and uncomfortable: most tooling makes the author's bytes the source of truth. rederive makes an independent oracle the source of truth, and regenerates the bytes to match. Code that doesn't exist can't be exploited; dependencies that never existed can't be compromised.