Seven Generations Thinking in Systems Design

There's a principle that comes from Haudenosaunee tradition — and has been articulated across many Indigenous nations — that decisions should be made with consideration for their effects seven generations forward. The rough translation is: don't optimize for the present at the cost of what comes after.

I think about this a lot in systems design. Most infrastructure is built with a horizon of two to three years. The cloud services industry runs on one-year commitment discounts. Software product cycles measure in months. The incentive structures of the field push relentlessly toward short-horizon thinking, and the result is systems that are clever at launch and brittle by year four.

Seven Generations thinking, applied to infrastructure, is a discipline. It asks different questions than the ones technical interviews tend to reward.

The Questions It Asks

Not "how do we scale this up?" but "how do we hand this off to someone who didn't build it?" The system that's elegant to its creator and impenetrable to its successor isn't a well-designed system — it's a single point of failure with a human face.

Not "what's the cheapest way to run this?" but "what's the cheapest way to run this in year seven?" Infrastructure debt, like technical debt, compounds. The $72/month EKS control plane you committed to because the team was already comfortable with Kubernetes costs the same in year three as it did in year one — but by year three you've paid over $2,500 in control plane fees for a development cluster. The $10/month Nomad cluster you chose because the problem actually fit the tool is still $10/month in year three.

Not "what does this system need to do?" but "what happens when the person who built this isn't here?" This is the question that separates infrastructure that works from infrastructure that works for its creator. Runbooks, documentation, IaC that represents the actual state of the system rather than an idealized snapshot — these are the outputs of thinking about who inherits the system, not who built it.

Where It Shows Up in Practice

Every project in my portfolio has a Seven Generations question embedded in its design decisions, whether I've named it explicitly or not.

Nomad Edge: The cost architecture post makes the case for SNS over Kinesis and Nomad over EKS on performance-per-dollar grounds. But the deeper argument is about what happens to a rural cooperative or agricultural operation in year three when the person who set up the cloud infrastructure has moved on. EKS requires someone who understands Kubernetes operational complexity. Nomad's SCDC topology can be understood, documented, and handed off to a less specialized operator. The right tool isn't just the one that performs well now — it's the one that can be maintained by whoever comes next.

Watershed: Offline-first isn't a performance optimization. It's a design decision for the environment where the system actually operates. A sensor network that stops working when the internet goes down isn't useful in a rural property. The SQLite buffer and async reconnect loop aren't technically interesting features — they're what makes the system trustworthy to someone who can't monitor it hourly.

The Stewardship Node: The entire project is a Seven Generations exercise. The LiFePO4 battery chemistry is selected for 3,000+ cycle longevity, not upfront cost. The food stewardship IoT system is built to be observable and governable by community members who aren't engineers. The network topology is designed to degrade gracefully and recover automatically because the community shouldn't require an on-call rotation to function.

The Tension With Delivery Culture

I want to be honest about the friction here. Seven Generations thinking runs counter to delivery culture, which rewards shipping and punishes overthinking. The fastest path to a working demo is almost never the right long-term architectural choice. This creates a real tension for anyone trying to build something lasting in an industry that measures output in sprint velocity.

My resolution to this tension is procedural: the design phase is where Seven Generations questions live. Once the design is settled, the build phase optimizes for delivery. You don't revisit foundational decisions mid-sprint, but you make sure the foundational decisions were made with a long horizon in mind.

The Deploy-Prove-Destroy methodology applies here too. Small, reversible steps. Validate before committing. If a choice turns out to be wrong, you've built in the assumption that you'll discover that and need to change course — which is also a Seven Generations design principle. Humility about what you know now, and architecture that accommodates correction later.

What It Means for Community Infrastructure

The Stewardship Node is the most direct application of this thinking I've built toward. A community that's designed to last seven generations — or even seven years — has different infrastructure requirements than one that's designed to exist while the founders are young and motivated.

Power systems that last twenty-five years without replacement (LiFePO4 at full cycle life). Network topology that a non-engineer can operate and troubleshoot. Food systems that generate data without requiring someone to interpret the data to make it useful. Buildings that adapt to changing needs rather than lock in a single configuration forever.

These aren't idealistic goals. They're engineering requirements that come from asking "who uses this in year fifteen?" instead of "who uses this at launch?"

Seven Generations thinking doesn't make systems more expensive or slower to build. It makes them more honest. It forces the question of who the system actually serves — not just at launch, but across the full arc of its operational life.

That's a question worth asking of every system, not just the ones designed to outlast their builders.

---

This post is part of the writing that accompanies the Stewardship Node project. The full four-part series on the technical build is linked above.