The Timeless Philosophy

The philosophy that describes how and why we consider design choices the way we do effects everything downstream of it.

We consider some traits essential: Reliability. Reviewability.

// Note: this page is a draft.



like a (old, brick-and-mortar, filled with books) library. we expect to be able to refer to things, and once having a reference, we expect it to not change. we need to be able to embed this reference in other documents, and having them construct a chain of facts which are themselves referencable.

(the “things” here will turn out to be not just data, but computation as well; especially the computations that compile our tools for more computation on more data!)


supports reasoning about its overall flow statically


undecaying, uncorruptable, without deterioration.

temporal context may not be bound.

that “ability to reason about statically” property must hold regardless of time.

(spoiler alert: this is why the whole project is called “the timeless stack”.)

reproducible by design

temporal context may not be bound!

this is to some degree a restatement of “referencable”, but explicitly more expansive: we want to be able to use our references to construct plans to produce more data; and we want to be able to reasonably expect – or failing that, at least test – or best yet, both – that these plans will be for processes that are reproducible.

it is important not just to state this principles, nor merely to follow them to the best of our abilities: it is critical to build tools that force us to notice quickly should we falter.


unencumbered products

sort of the converse of composable; we want the products of our systems to be usable without a support network.

each package should be a prepper xD

this doesn’t come up quite so much in repeatr and core tools, but it’s a huge piece of guidance when it comes to packaging style recommendations and the radix project.

decentralized authorship

social! no presuming of monorepos.

offline anytime


“builds” are a function from fileset to fileset.

builds are not the only thing that matches this description.

this is a large distinction from most other projects currently pursuing reproducible builds: (linux-)distribution driven approaches consider builds a function from packages to package, and the result is a system that’s much less reusable, has much more emotional baggage, is more likely to capture other properties regarding which there are validly distinct PoVs, much higher complexity, a greater tendency to culturally slip into (crippling) acceptance of side-effects (for reasons that may be valid for some user stories in a distro, but are entirely orthagonal to the question of builds/fncompute)…

some aphorisms:

  • Updating shouldn’t bring you anxiety.