A Framework for Evaluating New Technology

What is it?

A structured way to decide whether to bring a new technology into a household or small community, instead of adopting it automatically because it exists or rejecting it automatically out of fear. It treats technology adoption as a decision with consequences worth examining before they happen, not just afterward.

What is it good for?

• Deciding whether to take on a new tool, device, subscription service, or piece of infrastructure.
• Spotting hidden costs that show up as dependency, not as a price tag — on the grid, on a distant supplier, on a company's continued existence.
• Protecting skills and relationships that a "convenient" technology would quietly make unnecessary.
• Giving a household or community a shared, repeatable process for these decisions instead of relitigating each one from scratch.
• It is directly useful for evaluating the load-bearing systems this site documents — water, energy, food, and tools — where a bad adoption decision is hardest to reverse.

The physics behind it

There is no physics here — the underlying mechanism is a systems-dynamics one, not a material one. Two risks recur in essentially every technology-adoption decision, and both share the same property: they are invisible at the moment of adoption and obvious only in hindsight.

Single points of failure. Every technology sits on a supply chain — a grid connection, a subscription, a factory, a fuel delivery, an internet connection. Adopting it usually means retiring the older, more distributed way of meeting that need (a hand tool, a local relationship, a stored skill). The trade looks free at the moment of adoption, because the new dependency hasn't failed yet. It only becomes visible when the grid goes down, the company shuts off the service, or the supply chain is cut — at which point the old, distributed alternative has often already atrophied and can't be revived quickly.

Skill and relationship erosion. A technology that removes labor also tends to remove the reason two people, or two households, needed to cooperate. A washing machine removes the shared wash-day; a ride-share removes the neighbor who used to drive you; a search engine removes the elder who used to be asked. None of this is inherently bad — but it is a real cost, paid in social capital rather than money, and it is nearly always paid gradually and silently, over years, well after the purchase decision. By the time the erosion is noticeable, the skill or relationship it displaced is usually gone.

Because both effects are delayed and diffuse, they don't show up in an ordinary cost-benefit calculation done at the point of purchase. The framework below exists to force the delayed question to the front.

History

The clearest working example of this framework in practice is the Old Order Amish Ordnung ("order" or "discipline") — the set of unwritten, community-specific rules governing which technologies a given church district permits. The common caricature is that the Amish "reject technology," but the actual practice is more precise and more interesting: technology is evaluated for its social effects, not banned for being modern.

In practice, a new technology is typically first tried by one household, sometimes discreetly, sometimes with the bishop's awareness. The community observes its consequences over time — does it draw people away from the church district (a car makes it easy to work or worship elsewhere), does it create economic dependency on outsiders (grid electricity ties a farm to a utility company), does it erode a skill or interaction that held the community together (a telephone in every house removes the face-to-face visit)? Only after this observation period does the wider community decide, by consensus, whether and how to permit it.

Critically, the decision is often not a flat yes or no. Many Ordnung rulings are conditional: a telephone is permitted in a shed at the end of the driveway but not inside the house (available for emergencies, but not woven into daily life); machinery is permitted in a business context (a sawmill, a shop) but not as a home convenience; tractors are allowed for stationary belt-power but not for tillage, to preserve the horse-drawn skill and pace of farm work; batteries are often preferred over a grid connection, because a battery is a bounded, locally rechargeable resource, while a grid connection is a permanent point of dependency on an external system. This capacity to accept a modified version of a technology — rather than being forced into all-or-nothing — is the most transferable part of the practice.

Simple version

A short checklist to run through, personally or as a household, before adopting one new tool, device, or subscription service. Answer each honestly rather than defensively:

1. What does this remove? Does it replace a skill I currently hold, a relationship I currently rely on, or labor that was previously shared with someone else?
2. What single point of failure does this create? What has to keep working — a grid, a company, a subscription, a supply chain — for this to keep working? What happens the day it doesn't?
3. Is the old alternative still alive? If I stopped using this tomorrow, could I still do the task the old way — or has that capacity already quietly disappeared?
4. Can I adopt it partially? Is there a restricted or conditional version (business-only, occasional-use, offline-capable, battery- rather than grid-powered) that gets most of the benefit with less of the dependency?
5. Can I test it small and reversibly? Can I try this in a way that's easy to undo if the downsides turn out to outweigh the upsides?

If the answer to #2 is "something outside my control, with no fallback" and the answer to #3 is "no, that capacity is already gone," that is the combination worth pausing on.

Advanced version

A household-level trial-and-observe process, modeled directly on the individual-household step of the Ordnung practice:

1. Trial one household or one use case first, rather than adopting across the whole family or group at once.
2. Set an observation period (a season is a reasonable default) before treating the adoption as permanent.
3. Track effects deliberately, not just impressions — see "How to measure" below for concrete signals to log.
4. Ask what it displaced, specifically: which chore, skill, or interaction stopped happening once the new technology was in place?
5. Revisit the decision at the end of the period with the same seriousness as the original one — continuing a trial by default, without a real review, defeats the purpose.
6. Be willing to roll it back or restrict it if the trial shows a dependency or an erosion you're not willing to accept — this is the step most people skip, because reversing an adopted convenience feels like a loss even when it's the right call.

Industrial version

At community scale, this becomes the collective-deliberation process the Ordnung itself is: individual household trials feed into a community-wide, consensus-based review, rather than each household deciding in isolation.

• Aggregating individual trials. The community draws on what several households already learned from trying the technology individually, rather than debating it in the abstract.
• Consensus rather than authority. The decision is made collectively (in the Amish case, discussed and affirmed at a members' meeting), not imposed top-down — this matters because a rule the community didn't agree to tends not to hold.
• Conditional adoption as the default outcome, not the exception. The realistic menu of outcomes is not just "allowed" or "forbidden" — it includes "allowed for business but not home," "allowed on battery power but not grid-tied," "allowed for occasional use but not as a daily convenience," and similar middle paths. Treating conditional adoption as normal, rather than as a compromise nobody wanted, is what makes the process sustainable over decades instead of provoking a one-time fight that gets settled badly.
• Periodic re-review. Rulings aren't necessarily permanent; a technology once rejected can be revisited as circumstances (or the technology itself) change.
• Applying it beyond the Amish case. The same structure works for any small community — a homestead cooperative, an intentional community, an off-grid neighborhood — deciding, for example, whether to run a shared generator, adopt a communication platform, or bring in an outside contractor for a task the group currently does itself.

Building your own

Building the habit matters more than building any artifact:

1. Write the five simple-version questions down somewhere you'll actually see them — a note by the door, the first page of a household planning notebook — so they get asked before a purchase, not after.
2. Pick one upcoming decision (a new appliance, a subscription renewal, a piece of equipment) and run it through the checklist deliberately, on paper, before deciding.
3. Name your single points of failure explicitly. For each significant technology already in your household, write down what has to keep working for it to keep working. This inventory alone is usually eye-opening.
4. Identify one skill or relationship worth protecting, and treat any technology that would displace it as requiring the advanced-version trial process, not a snap decision.
5. If you're part of a group, propose the industrial-version process for your next shared-infrastructure decision — even an informal version of it (a trial period, then a group discussion) beats a decision made by whoever bought the thing first.
6. Review annually. Revisit past adoption decisions the way the Ordnung is periodically revisited — a decision that made sense two years ago may not fit today's dependencies.

Common mistakes

• Reflexive adoption — treating "it exists and it's convenient" as sufficient justification, with no review of what it displaces or what it depends on.
• Reflexive rejection — refusing all new technology on principle, which forfeits real benefits and is not what this framework recommends; the goal is deliberate choice, not Luddism.
• Evaluating cost but not dependency — running the math on price and time saved while ignoring what single point of failure is being created.
• All-or-nothing thinking — assuming a technology must be either fully adopted or fully banned, when a conditional or partial version usually exists.
• No review point — adopting something "on trial" and then never actually revisiting the decision, so the trial becomes permanent by default.
• Deciding alone what affects everyone — one household member or one member of a group adopting a shared-consequence technology without the conversation that the industrial version calls for.

How to measure

The framework isn't quantitative, but its effects are observable if you deliberately watch for them during and after a trial period:

• Time-use shifts. Track roughly how time is spent before and after adoption. Did the "saved" time go to something valued, or did it just get absorbed — and did time spent with other people specifically go down?
• New dependencies. List what now has to keep functioning for the household to function: a subscription payment, a grid connection, a specific company staying in business, an internet connection. Compare this list before and after the adoption.
• Skill retention. Check whether the skill or task the technology replaced is still practiced by anyone in the household or community — occasionally, as a backup — or whether it has already lapsed entirely.
• Reversibility check. Ask directly: if this technology disappeared tomorrow, how long would it take to return to the old way of doing this, and who still knows how?
• Frequency of the old interaction. For technologies that displace a relationship or shared task, track whether the in-person or cooperative version of that task still happens at all, and how often.

Videos

(TODO)

Downloadable PDF

(TODO)