This essay is part of an evolving unified theory of governance development and Social Architecture. Later, it is formalized as the 9‑part Social Architecture Series (starting with “The Foundations Of Sustainable Organizations: Four Batteries”).

Game theory has become the default language of Web3. If a protocol has a clever payoff matrix, a Schelling point, and a whitepaper full of equilibria, it is often assumed to be "well-governed."

In a previous essay, "Game Theory Assumptions That Hurt Web3", I went through the standard assumptions one by one- rational actors, static games, perfect information, no coalitions, and so on- and showed how they fail in real networks:

https://paragraph.com/@holonic-horizons/game-theory-assumptions-that-hurt-web3

This piece zooms out a level. It's the synthesis that has been emerging for me through:

• Ongoing strategy workshops with public goods and protocol teams,

• work inside funding ecosystems like Octant and Greenpill,

• and many conversations with mechanism designers, governance researchers, and "tokenomics" folks.

The core claim is:

Web3 keeps trying to solve a multi-dimensional governance problem using a single design domain: game-theoretic mechanism design. That isn't just incomplete, it's a strategic error- optimizing the wrong thing.

The alternative is not to throw game theory out the window. It is to reposition it as one domain among several that together determine whether public-goods systems actually work over time.

In the strategy workshops I run, we usually start by asking a deceptively simple question:

"What are you actually trying to achieve? Not in mechanism terms, in human terms."

Once people answer that, it becomes much easier to distinguish between outputs and outcomes.

• Outputs are what a mechanism directly produces.

• Outcomes are what the system actually cares about.

In the context of Web3 governance:

Mechanism outputs include things like:

• juror votes and court verdicts (think Kleros and similar "decentralized justice" systems),

• finalized on-chain proposals,

• equilibria where no agent has an incentive to deviate (under the model's assumptions),

• proofs that some action is "incentive compatible."

System outcomes are things like:

• whether people still trust the process after a few years of hard edges and weird edge cases,

• whether participation is sustainable beyond a small inner circle of governance obsessives,

• whether funded projects genuinely strengthen the commons rather than just winning contests,

• whether the system survives new attack classes, regulatory shocks, social fracture, and internal drama.

In most of the mechanisms I see, the design work stops at outputs and quietly treats them as outcomes. If the court converges on a Schelling point, or the vote reaches equilibrium under the assumed incentives, the job is considered done.

That is exactly the strategic mistake.

Mechanisms are tools. Equilibria are intermediate results. The actual outcomes live in:

• how individual inputs are aggregated,

• how governance load is distributed across people and time,

• how rules and institutions evolve.

Ignoring that distinction is how you end up with systems that are mathematically elegant and socially brittle.

Over time, working with different teams, it has been useful to separate governance work into at least four distinct design domains:

1. Aggregation domain – how individual inputs become collective decisions.

2. Mechanism domain – how incentives and information are structured locally.

3. Structural domain – how the web of participants carries load over time.

4. Institutional domain – how rules are made, changed, nested, and enforced.

Game theory mostly lives in domain 2. The error is treating domain 2 as if it were the entire problem.

Before you design any incentives, there is a prior question:

Given a bunch of individual opinions or preferences, how should they be combined into a collective decision?

This is the world of social choice theory:

• Simple majority and plurality.

• Borda count (rank everything; give points by rank and sum).

• Condorcet methods (look at all pairwise matchups; does someone beat everyone head-to-head?).

• Approval voting (mark everything you can live with).

• Score or range voting (give each option a 0–10 rating).

• Quadratic voting/funding, and its many variations.

Arrow's impossibility theorem and related results show something uncomfortable: there is no perfect rule. You can't simultaneously satisfy all the fairness criteria you might like. You must decide which properties you care about more (Pareto, independence of irrelevant alternatives, monotonicity, participation, etc.) and which you're willing to relax.

Yet in practice, most Web3 systems simply hardcode:

• "one-token one-vote" majority, or

• quadratic funding with a few ad hoc guardrails, or

• simple juror-majority in decentralized dispute resolution,

and rarely surface the underlying value choices. The aggregation domain gets treated as a minor implementation detail when it is one of the main places where legitimacy is created or destroyed.

A Schelling-point court can produce very coherent votes, but how those votes are aggregated- what counts as passing, how ties or cycles are resolved, whether secondary preferences matter- is a separate design choice that game theory does not answer.

This is the familiar territory:

• juror incentives in a dispute system,

• staking and slashing rules,

• bonding curves for token issuance,

• fee and reward structures.

Game theory is genuinely useful here. It asks:

• Given a particular aggregation rule and objective, how should payoffs and information be structured so that strategic actors do not wreck the system?

The problem isn't the tool. It's what happens when we let this one domain colonize everything else.

Most of the "game theory assumptions that hurt Web3" are really examples of overreach:

• Rational, payoff-maximizing actors are a reasonable approximation for some local decisions; they break when applied wholesale to identity, trust, and long-term commitment.

• Static game forms work for a one-off auction or a paper proof; they don't capture a protocol that upgrades, forks, and evolves alongside its ecosystem.

• Ignoring coalitions is fine for a homework assignment; in actual blockchains, coalitions (mining pools, delegate blocs, nation-states, cartels) are often the primary actors.

The mechanism domain needs game theory, but it is not a suitable master theory of governance.

When I sit down with teams and map out who is actually doing governance work, the picture is usually pretty stark:

• a handful of addresses or people propose almost everything,

• a slightly larger ring votes on almost everything,

• The long tail is either passive or only shows up for controversies.

That's the structural domain: not what the mechanism does in isolation, but how governance is distributed across the underlying network.

It helps to borrow a simple image from tensegrity.

A tensegrity structure is one where rigid pieces (rods) are held in shape by a web of tension (cables). The rods don't all bolt directly to each other; they're suspended. The structure is stable, not because everything is stiff, but because tension and compression are balanced across the whole.

Translate that to governance:

• Rigid elements are the hard pieces:

  • formal roles,

  • smart contracts,

  • legal entities,

  • explicit obligations.

• Tension elements are the soft but load-bearing connections:

  • ongoing working relationships,

  • expectations,

  • trust,

  • reputations,

  • lines of communication.

• Pre‑tension is the baseline:

  • a standing level of trust and mutual commitment that lets you make decisions without everyone checking every detail every time.

In that picture, a few straightforward ideas become obvious- even without any math:

• If you add a new participant with no real connections, they are "floating." They will either do nothing or cause chaos. A healthier pattern is: new people are always connected to at least two existing anchors (mentors, teams, delegations) so the structure knows where to place them.

• If one relationship is doing too much- one facilitator in the middle of every conflict, one reviewer on every big proposal- that edge will eventually snap. You fix that by splitting the edge: add an intermediate role or sub-group; share the tension.

• You can track structural health in simple ways:

  • How unequal is governance participation? (Gini over proposals, votes, and dispute roles.)

  • How concentrated is influence? (Centrality measures in the governance graph.)

  • How fast are active contributors churning out?

  • Are there multiple independent "paths" for decisions, or is everything routed through a few nodes?

The key point is: a mechanism can look fine locally and still be structurally harmful if it continually channels responsibility, stress, and decision power onto the same small set of people. That's a structural failure, not a payoff failure.

The last domain is the institutional one- what Elinor Ostrom spent decades documenting in real commons (fisheries, forests, irrigation systems, etc.).

When you look at the systems that actually resisted collapse over long periods, you see recurring patterns:

• People affected by rules can participate in changing them (collective choice).

• Sanctions are graduated: warnings first, then modest penalties, then stronger measures.

• There are low-cost, informal ways to resolve conflicts before they escalate into formal hearings.

• Governance is nested: small-scale issues are handled locally, broader issues in wider forums, with multiple centers of authority.

Many Web3 "governance" systems implement a very thin slice of this:

• a formal voting mechanism,

• maybe a court or slashing rule,

• some notion of a "community," and that's it.

From an Ostromian perspective, that's upside down. Courts and hard sanctions are late-stage tools in mature commons, not the starting point, and yet look at the popularity of Kleros right off the bat- it seems skipping to the end is very popular. But, if you drop these into an institutional vacuum- no mediation, no collective choice over the rules, no hierarchy of decision forums- you get brittle behavior and escalating conflict.

It is no wonder then that token holders- especially large token holders, and even broad-minded token holders-too often get impatient with the process and skip to the end. This happens in one of two ways: Kleros or other formal process, or just buy your way into the decision you wanted all along.

This isn't just a human problem; it reveals the underlying structural issue.

Seen through these four domains, the pattern becomes clearer:

• Aggregation is usually under-designed (some default choice is made and rarely revisited).

• Mechanisms are carefully optimized (new courts, new payoff tweaks, new staking schemes).

• Structure is invisible (no dashboards, no metrics, no deliberate capacity management).

• Institutions are left to "culture" and vibes (until something breaks).

NOTE: In later work, I’ll treat these “invisible” structural and institutional layers as the outer expression of a deeper inner architecture—consciousness development, presencing capacity, battery health, and tensegrity—that determines whether any mechanism actually survives contact with reality.

There are reasons for this:

• Mechanism design is legible to protocol engineers: you can formalize it, prove things, and write precise specifications.

• Aggregation, structure, and institutions force you into uncomfortable territory: messy social realities, partial observability, and non-mathematical expertise.

But if you're trying to build public-goods infrastructure, that imbalance is not just a gap; it is an existential risk. Public goods live or die on:

• legitimacy,

• long-term trust,

• participant capacity,

• and institutional adaptability.

If design work concentrates on one domain, the others will fail, and no clever equilibrium will save you.

In the workshops and research work I'm doing now, "beyond game theory" has started to mean something quite specific:

• Treat the choice of voting/aggregation rule as a strategic design decision, not a convenience.

• Use different rules for different jobs:

  • approval or score voting when you care about intensity and broad acceptability,

  • Borda or Condorcet-style methods when relative ranking matters,

  • hybrids for complex slates.

• Be explicit about which fairness properties you're prioritizing and which you're relaxing.

• Use game theory where it fits:

  • juror incentive schemes,

  • attack-resistance analysis,

  • local payoff design.

• Stop asking it to explain:

  • social identity,

  • legitimacy,

  • long-term institutional evolution.

Those belong elsewhere.

• Instrument the basics:

  • participation inequality,

  • concentration of influence,

  • contributor churn,

  • self-reported cognitive load,

  • simple redundancy measures in the participation graph.

• Define thresholds:

  • When a handful of addresses exceed a share of governance work, trigger rotation/delegation,

  • When burnout signals rise, enforce rest periods or distribute responsibilities,

  • When redundancy drops, introduce new roles or pathways.

These are things you can wire into operational rhythms and even smart contracts, not just slide decks.

• Add mediation and repair mechanisms around formal dispute processes.

• Build sanction ladders instead of binary "no penalty / full slash" regimes.

• Give communities ways to modify their own rules within safe bounds.

• Design for nested governance: project-level, protocol-level, ecosystem-level, each with different scopes.

This is where work in places like Greenpill can get much sharper and more operational: not just "we need better culture," but "here is how we design and test institutional modules around the mechanisms we already have."

The reason I've been integrating all of this into strategy workshops is that teams keep hitting the same wall:

• They ship a well-argued mechanism,

• It behaves reasonably under simulated assumptions,

• And then, in practice, participation dwindles, conflicts escalate, or outcomes feel skewed.

From a strategy lens, that's not bad luck; it's an error in what is being optimized.

The funding side of the ecosystem has already experienced one version of this. Before things like Octant, a lot of grant programs were optimized for:

• number of grants awarded,

• speed of decision-making,

• total capital deployed,

without asking hard questions about:

• sustainability of the funding source,

• alignment with long-term public goods,

• or the health of recipient ecosystems.

We eventually learned to treat funding as an infrastructure problem, not just a grant-issuance problem.

Governance is at the same turning point.

If Web3 keeps equating "we have a game-theoretic mechanism" with "we have governance," we will re-run the same cycle: clever designs, early excitement, quiet structural failure.

If, instead, we can normalize talking about:

• aggregation choices,

• structural health,

• institutional scaffolding,

Alongside incentives and equilibria, we can build public goods systems that actually last.

That's the work I'm most interested in right now- both in the strategy rooms and in more technical design conversations. If you're working on funding protocols, decentralized justice, DAO governance, or regen-aligned experiments and want to push past mechanism-only thinking, this is the conversation I'd like to keep opening up.

The Social Architecture Series picks up from here by treating human sustainability (the Four Batteries and Hidden Factories) as the structural layer beneath these four design domains.

In later work, I extend this four-domain frame with a deeper Social Architecture layer- consciousness topology, presencing mechanics, tensegrity configurations, health vectors, and the Four-Battery framework- that determines whether any aggregation, mechanism, structural, or institutional design is actually sustainable.

This essay is part of an evolving unified theory of governance development and Social Architecture. Later, it is formalized as the 9‑part Social Architecture Series (starting with “The Foundations Of Sustainable Organizations: Four Batteries”).

Game theory has become the default language of Web3. If a protocol has a clever payoff matrix, a Schelling point, and a whitepaper full of equilibria, it is often assumed to be "well-governed."

In a previous essay, "Game Theory Assumptions That Hurt Web3", I went through the standard assumptions one by one- rational actors, static games, perfect information, no coalitions, and so on- and showed how they fail in real networks:

https://paragraph.com/@holonic-horizons/game-theory-assumptions-that-hurt-web3

This piece zooms out a level. It's the synthesis that has been emerging for me through:

• Ongoing strategy workshops with public goods and protocol teams,

• work inside funding ecosystems like Octant and Greenpill,

• and many conversations with mechanism designers, governance researchers, and "tokenomics" folks.

The core claim is:

Web3 keeps trying to solve a multi-dimensional governance problem using a single design domain: game-theoretic mechanism design. That isn't just incomplete, it's a strategic error- optimizing the wrong thing.

The alternative is not to throw game theory out the window. It is to reposition it as one domain among several that together determine whether public-goods systems actually work over time.

In the strategy workshops I run, we usually start by asking a deceptively simple question:

"What are you actually trying to achieve? Not in mechanism terms, in human terms."

Once people answer that, it becomes much easier to distinguish between outputs and outcomes.

• Outputs are what a mechanism directly produces.

• Outcomes are what the system actually cares about.

In the context of Web3 governance:

Mechanism outputs include things like:

• juror votes and court verdicts (think Kleros and similar "decentralized justice" systems),

• finalized on-chain proposals,

• equilibria where no agent has an incentive to deviate (under the model's assumptions),

• proofs that some action is "incentive compatible."

System outcomes are things like:

• whether people still trust the process after a few years of hard edges and weird edge cases,

• whether participation is sustainable beyond a small inner circle of governance obsessives,

• whether funded projects genuinely strengthen the commons rather than just winning contests,

• whether the system survives new attack classes, regulatory shocks, social fracture, and internal drama.

In most of the mechanisms I see, the design work stops at outputs and quietly treats them as outcomes. If the court converges on a Schelling point, or the vote reaches equilibrium under the assumed incentives, the job is considered done.

That is exactly the strategic mistake.

Mechanisms are tools. Equilibria are intermediate results. The actual outcomes live in:

• how individual inputs are aggregated,

• how governance load is distributed across people and time,

• how rules and institutions evolve.

Ignoring that distinction is how you end up with systems that are mathematically elegant and socially brittle.

Over time, working with different teams, it has been useful to separate governance work into at least four distinct design domains:

1. Aggregation domain – how individual inputs become collective decisions.

2. Mechanism domain – how incentives and information are structured locally.

3. Structural domain – how the web of participants carries load over time.

4. Institutional domain – how rules are made, changed, nested, and enforced.

Game theory mostly lives in domain 2. The error is treating domain 2 as if it were the entire problem.

Before you design any incentives, there is a prior question:

Given a bunch of individual opinions or preferences, how should they be combined into a collective decision?

This is the world of social choice theory:

• Simple majority and plurality.

• Borda count (rank everything; give points by rank and sum).

• Condorcet methods (look at all pairwise matchups; does someone beat everyone head-to-head?).

• Approval voting (mark everything you can live with).

• Score or range voting (give each option a 0–10 rating).

• Quadratic voting/funding, and its many variations.

Arrow's impossibility theorem and related results show something uncomfortable: there is no perfect rule. You can't simultaneously satisfy all the fairness criteria you might like. You must decide which properties you care about more (Pareto, independence of irrelevant alternatives, monotonicity, participation, etc.) and which you're willing to relax.

Yet in practice, most Web3 systems simply hardcode:

• "one-token one-vote" majority, or

• quadratic funding with a few ad hoc guardrails, or

• simple juror-majority in decentralized dispute resolution,

and rarely surface the underlying value choices. The aggregation domain gets treated as a minor implementation detail when it is one of the main places where legitimacy is created or destroyed.

A Schelling-point court can produce very coherent votes, but how those votes are aggregated- what counts as passing, how ties or cycles are resolved, whether secondary preferences matter- is a separate design choice that game theory does not answer.

This is the familiar territory:

• juror incentives in a dispute system,

• staking and slashing rules,

• bonding curves for token issuance,

• fee and reward structures.

Game theory is genuinely useful here. It asks:

• Given a particular aggregation rule and objective, how should payoffs and information be structured so that strategic actors do not wreck the system?

The problem isn't the tool. It's what happens when we let this one domain colonize everything else.

Most of the "game theory assumptions that hurt Web3" are really examples of overreach:

• Rational, payoff-maximizing actors are a reasonable approximation for some local decisions; they break when applied wholesale to identity, trust, and long-term commitment.

• Static game forms work for a one-off auction or a paper proof; they don't capture a protocol that upgrades, forks, and evolves alongside its ecosystem.

• Ignoring coalitions is fine for a homework assignment; in actual blockchains, coalitions (mining pools, delegate blocs, nation-states, cartels) are often the primary actors.

The mechanism domain needs game theory, but it is not a suitable master theory of governance.

When I sit down with teams and map out who is actually doing governance work, the picture is usually pretty stark:

• a handful of addresses or people propose almost everything,

• a slightly larger ring votes on almost everything,

• The long tail is either passive or only shows up for controversies.

That's the structural domain: not what the mechanism does in isolation, but how governance is distributed across the underlying network.

It helps to borrow a simple image from tensegrity.

A tensegrity structure is one where rigid pieces (rods) are held in shape by a web of tension (cables). The rods don't all bolt directly to each other; they're suspended. The structure is stable, not because everything is stiff, but because tension and compression are balanced across the whole.

Translate that to governance:

• Rigid elements are the hard pieces:

  • formal roles,

  • smart contracts,

  • legal entities,

  • explicit obligations.

• Tension elements are the soft but load-bearing connections:

  • ongoing working relationships,

  • expectations,

  • trust,

  • reputations,

  • lines of communication.

• Pre‑tension is the baseline:

  • a standing level of trust and mutual commitment that lets you make decisions without everyone checking every detail every time.

In that picture, a few straightforward ideas become obvious- even without any math:

• If you add a new participant with no real connections, they are "floating." They will either do nothing or cause chaos. A healthier pattern is: new people are always connected to at least two existing anchors (mentors, teams, delegations) so the structure knows where to place them.

• If one relationship is doing too much- one facilitator in the middle of every conflict, one reviewer on every big proposal- that edge will eventually snap. You fix that by splitting the edge: add an intermediate role or sub-group; share the tension.

• You can track structural health in simple ways:

  • How unequal is governance participation? (Gini over proposals, votes, and dispute roles.)

  • How concentrated is influence? (Centrality measures in the governance graph.)

  • How fast are active contributors churning out?

  • Are there multiple independent "paths" for decisions, or is everything routed through a few nodes?

The key point is: a mechanism can look fine locally and still be structurally harmful if it continually channels responsibility, stress, and decision power onto the same small set of people. That's a structural failure, not a payoff failure.

The last domain is the institutional one- what Elinor Ostrom spent decades documenting in real commons (fisheries, forests, irrigation systems, etc.).

When you look at the systems that actually resisted collapse over long periods, you see recurring patterns:

• People affected by rules can participate in changing them (collective choice).

• Sanctions are graduated: warnings first, then modest penalties, then stronger measures.

• There are low-cost, informal ways to resolve conflicts before they escalate into formal hearings.

• Governance is nested: small-scale issues are handled locally, broader issues in wider forums, with multiple centers of authority.

Many Web3 "governance" systems implement a very thin slice of this:

• a formal voting mechanism,

• maybe a court or slashing rule,

• some notion of a "community," and that's it.

From an Ostromian perspective, that's upside down. Courts and hard sanctions are late-stage tools in mature commons, not the starting point, and yet look at the popularity of Kleros right off the bat- it seems skipping to the end is very popular. But, if you drop these into an institutional vacuum- no mediation, no collective choice over the rules, no hierarchy of decision forums- you get brittle behavior and escalating conflict.

It is no wonder then that token holders- especially large token holders, and even broad-minded token holders-too often get impatient with the process and skip to the end. This happens in one of two ways: Kleros or other formal process, or just buy your way into the decision you wanted all along.

This isn't just a human problem; it reveals the underlying structural issue.

Seen through these four domains, the pattern becomes clearer:

• Aggregation is usually under-designed (some default choice is made and rarely revisited).

• Mechanisms are carefully optimized (new courts, new payoff tweaks, new staking schemes).

• Structure is invisible (no dashboards, no metrics, no deliberate capacity management).

• Institutions are left to "culture" and vibes (until something breaks).

NOTE: In later work, I’ll treat these “invisible” structural and institutional layers as the outer expression of a deeper inner architecture—consciousness development, presencing capacity, battery health, and tensegrity—that determines whether any mechanism actually survives contact with reality.

There are reasons for this:

• Mechanism design is legible to protocol engineers: you can formalize it, prove things, and write precise specifications.

• Aggregation, structure, and institutions force you into uncomfortable territory: messy social realities, partial observability, and non-mathematical expertise.

But if you're trying to build public-goods infrastructure, that imbalance is not just a gap; it is an existential risk. Public goods live or die on:

• legitimacy,

• long-term trust,

• participant capacity,

• and institutional adaptability.

If design work concentrates on one domain, the others will fail, and no clever equilibrium will save you.

In the workshops and research work I'm doing now, "beyond game theory" has started to mean something quite specific:

• Treat the choice of voting/aggregation rule as a strategic design decision, not a convenience.

• Use different rules for different jobs:

  • approval or score voting when you care about intensity and broad acceptability,

  • Borda or Condorcet-style methods when relative ranking matters,

  • hybrids for complex slates.

• Be explicit about which fairness properties you're prioritizing and which you're relaxing.

• Use game theory where it fits:

  • juror incentive schemes,

  • attack-resistance analysis,

  • local payoff design.

• Stop asking it to explain:

  • social identity,

  • legitimacy,

  • long-term institutional evolution.

Those belong elsewhere.

• Instrument the basics:

  • participation inequality,

  • concentration of influence,

  • contributor churn,

  • self-reported cognitive load,

  • simple redundancy measures in the participation graph.

• Define thresholds:

  • When a handful of addresses exceed a share of governance work, trigger rotation/delegation,

  • When burnout signals rise, enforce rest periods or distribute responsibilities,

  • When redundancy drops, introduce new roles or pathways.

These are things you can wire into operational rhythms and even smart contracts, not just slide decks.

• Add mediation and repair mechanisms around formal dispute processes.

• Build sanction ladders instead of binary "no penalty / full slash" regimes.

• Give communities ways to modify their own rules within safe bounds.

• Design for nested governance: project-level, protocol-level, ecosystem-level, each with different scopes.

This is where work in places like Greenpill can get much sharper and more operational: not just "we need better culture," but "here is how we design and test institutional modules around the mechanisms we already have."

The reason I've been integrating all of this into strategy workshops is that teams keep hitting the same wall:

• They ship a well-argued mechanism,

• It behaves reasonably under simulated assumptions,

• And then, in practice, participation dwindles, conflicts escalate, or outcomes feel skewed.

From a strategy lens, that's not bad luck; it's an error in what is being optimized.

The funding side of the ecosystem has already experienced one version of this. Before things like Octant, a lot of grant programs were optimized for:

• number of grants awarded,

• speed of decision-making,

• total capital deployed,

without asking hard questions about:

• sustainability of the funding source,

• alignment with long-term public goods,

• or the health of recipient ecosystems.

We eventually learned to treat funding as an infrastructure problem, not just a grant-issuance problem.

Governance is at the same turning point.

If Web3 keeps equating "we have a game-theoretic mechanism" with "we have governance," we will re-run the same cycle: clever designs, early excitement, quiet structural failure.

If, instead, we can normalize talking about:

• aggregation choices,

• structural health,

• institutional scaffolding,

Alongside incentives and equilibria, we can build public goods systems that actually last.

That's the work I'm most interested in right now- both in the strategy rooms and in more technical design conversations. If you're working on funding protocols, decentralized justice, DAO governance, or regen-aligned experiments and want to push past mechanism-only thinking, this is the conversation I'd like to keep opening up.

The Social Architecture Series picks up from here by treating human sustainability (the Four Batteries and Hidden Factories) as the structural layer beneath these four design domains.

In later work, I extend this four-domain frame with a deeper Social Architecture layer- consciousness topology, presencing mechanics, tensegrity configurations, health vectors, and the Four-Battery framework- that determines whether any aggregation, mechanism, structural, or institutional design is actually sustainable.