Content pipeline build system

Edit the brief. Rebuild only what changed.

Drift treats your content pipeline as a dependency graph. Every title, caption, tag and post is content-addressed from its source — so changing one line rebuilds the four assets that depend on it, not all nine. And a manifest lets anyone re-verify what a build shipped.

Try it live ↗ View on GitHub ↗ Verify it yourself
The problem

One brief. Nine derived assets. Change one line and they all drift stale.

A creator ships a title, description, tags, thumbnail caption, captions and posts — all descended from one brief. Edit the brief and every downstream asset silently goes stale. Fix them by hand and you forget one. Schedulers will post them for you; no tool tells you which ones are no longer true.

Two scenarios, measured

The blast radius is the product.

Edit the source cascade

Change one line in the brief.

9 rebuild/ 0 reuse

Every derived asset re-fingerprints against the new source. The invalidation cascades through the graph automatically — nothing is silently trusted.

Edit the handle bound

Change only the handle.

2 rebuild/ 7 reuse

The handle is a bound parameter — it can only reach the two post nodes. Seven assets survive untouched, because the graph proves they never depended on it.

Prove it

Nothing here is a mockup.

Every number is a real run against a real file. Re-hash every asset from disk and the manifest confirms it — change one byte and it fails.

$ drift build demo/content              # 9 rebuild / 0 reuse
$ drift build demo/content              # 0 rebuild / 9 reuse
$ drift build demo/content --handle @newhandle   # 2 rebuild / 7 reuse
$ drift verify demo/content             # OK — every asset re-hashes

$ echo TAMPERED > out/tags.txt
$ drift verify demo/content             # FAILED — tags: hash mismatch