Constraints become the unit of version control. Code is what you derive from them.
rederive treats the constraint set as the durable artifact and the implementation as a verifiable materialization. Review moves up one layer. Diffs become semantically dense. Verification gates acceptance.
The problem
You ship code with an LLM, and CI stops meaning anything.
Pull requests arrive faster than any human can meaningfully review. Diffs are noise around tiny intent changes. Green CI tells you nothing about whether constraints were preserved, because the constraints were never written down where a machine could check them.
Status quo
"It compiles. The tests pass. I can't tell if the change is correct."
- Diffs touch dozens of unrelated lines per intent change.
- Reviewers triage volume rather than read for intent.
- CI verifies the suite against itself, not against a specification.
- Retraction is hostile: rolling back a generation requires rolling back three subsequent rewrites.
- Authorship lives in the wrong place. Git blame answers a question nobody is asking.
Under rederive
"The constraint diff is one page. The verifier signs the materialization. Done."
- Diffs shrink to the constraints that moved.
- Reviewers read intent; the implementation is regenerated and re-verified.
- CI verifies code against an explicit, version-controlled specification.
- Retraction means reverting a constraint and re-deriving.
- Authorship is recorded against the constraint, not the line.
The shape
A constraint file is the source of truth.
Markdown with a small discipline. H2 per requirement, a metadata block, prose stating the requirement, fenced evidence the platform routes to verification backends. Reviewable by a human. Executable by the engine.
## SLUG2 type: predicate authority: human-authored scope: module status: active depends-on: [SLUG1] The slugify function lowercases its input and replaces every run of non-alphanumeric characters with a single hyphen. Leading and trailing hyphens are stripped from the result. ```assert slugify("Hello World") === "hello-world" slugify(" Foo Bar ") === "foo-bar" slugify("Foo!!!Bar") === "foo-bar" slugify("---x---") === "x" ```
Two materializations from the same constraint set, both passing verification, are interchangeable. A load-bearing claim, not a slogan: line-level differences below the constraint layer are noise by construction. Review happens where intent actually lives.
The pipeline
Eight deterministic stages. One signed materialization.
Six stages are pure functions. The seventh calls a language-model substrate. The eighth signs the result with Ed25519 provenance. The platform's commitment is correctness and auditability, not transfer efficiency, not magic.
Each stage emits structured events. Tooling, CI, and the browser UI hook the stream.
The proof
The engine has derived its own modules.
Seven of seven modules verify against their constraints. 850 hand-written lines of TypeScript bootstrapped the engine. 692 lines of derived TypeScript were produced by the engine from prose specifications, each materialization Ed25519-signed.
The bootstrap loop is closed. The engine derives code that the engine itself depends on; the resulting tree type-checks clean and passes its regression suite. The full methodology, the constraint typology, and the verification backends are written up in the whitepaper.
What exists today
Working surface, not vapor.
01The engine
850 hand-written lines of TypeScript, type-checks clean under strict mode, signs every materialization with Ed25519 provenance.
Read the architecture →02The whitepaper
~4,900 words across 9 sections plus 4 appendices, with a novelty audit at tier γ confidence 0.5.
Read it →03The web UI
12 components derived through the engine itself, ~1,500 lines of TypeScript across 12 routes.
Browse the UI →04Verification backends
Seven backends compose at the verify stage: type-checker, assertion-runner, property-runner, llm-judge, pin-checker, flow-runner, a11y-checker.
How they compose →05Wire protocol
Content-addressed clone / push / pull, Ed25519 signature-based authentication, signers manifest as a constraint document.
API quick-start →06Signed materializations
Every passing build emits a signed artifact: specification hash, substrate identity, code hash, verdict. Ed25519 signatures verifiable offline against the platform's public key.
Provenance details →Specification was always supposed to be the source.
The rate-limit on engineering work has moved. The practitioner's working surface should move with it. rederive is one operational form of that surface; the runtime layer is adoptable today.