Downstream · draft, not for sending as-is
Hey [name],
I'm building Downstream, a public record of what laws actually do after they pass, and the part I want your eyes on is the pipeline underneath it.
What runs today: the archive has fetched every day since it switched on, the Federal Register digest publishes each business day, a presidential corpus keys every memorandum by a hash of its own text because three publishers render one document three ways, a House floor radar joins the schedule to who sponsored what, and an MCP server with nine tools sits over all of it, which other people's agents already query. Point-in-time is structural, not a flag: a historical as_of can only be answered from dated, hashed daily files, the live path is unreachable from it, and a future as_of is refused rather than clamped, because a silent clamp is how a backtest reads tomorrow's newspaper. Forecasting does not run. Every consequence claim drafted so far is gated as unverified, and the publish step refuses while that is true. The honest hook is the archive: it is the one asset that cannot be backfilled. Everything else here could be rebuilt later by someone with more money. The missed days could not.
The work-in-progress deck is at https://seedownstream.com/deck/. I want your objections more than your interest. Tell me where the pipeline story is wrong and which part you would never trust in production. And if it grabs you instead, let's talk.
Hey [name], I'm building Downstream, a public record of what laws actually do after they pass, and the part I want your eyes on is the pipeline underneath it. - Every fetch runs one way: fetch, hash, store immutable, parse from the stored copy. Nothing downstream of the snapshotter is allowed to touch the network, so every page is reproducible from a hash rather than from a promise. - Every capture outcome is a record, including the boring ones. A 304 is a positive observation that nothing changed. A 404 on a URL that answered 200 yesterday is a deletion event, and it is the highest-signal thing the archive holds. "We looked and it was identical" and "we did not look" are different facts, and the store keeps them apart. - Each day seals a merkle root over its captures, chains it to the day before, and commits it to git, so the chain is timestamped by a host I don't control. Zero runtime dependencies, on purpose. The runner works on a clean checkout with no install step. What runs today: the archive has fetched every day since it switched on, the Federal Register digest publishes each business day, a presidential corpus keys every memorandum by a hash of its own text because three publishers render one document three ways, a House floor radar joins the schedule to who sponsored what, and an MCP server with nine tools sits over all of it, which other people's agents already query. Point-in-time is structural, not a flag: a historical as_of can only be answered from dated, hashed daily files, the live path is unreachable from it, and a future as_of is refused rather than clamped, because a silent clamp is how a backtest reads tomorrow's newspaper. Forecasting does not run. Every consequence claim drafted so far is gated as unverified, and the publish step refuses while that is true. The honest hook is the archive: it is the one asset that cannot be backfilled. Everything else here could be rebuilt later by someone with more money. The missed days could not. The work-in-progress deck is at https://seedownstream.com/deck/. I want your objections more than your interest. Tell me where the pipeline story is wrong and which part you would never trust in production. And if it grabs you instead, let's talk.