Technology Paternalism, Continued - Five Abilities and a Test for Self-Sovereign Identity

ReflectionIdentity Flow
Written By Martina
A follow-up to "Technology Paternalism Expands — A Case for Self-Sovereign Identity"
If this made you think →

Warming up

A while ago I published a piece on Technology Paternalism – the anti-pattern by which a technology system is designed to shape, restrict, or pre-decide choices for people, commonly justified as safety, efficiency, or protection. What resulted were vivid discussions. A huge thank you to all the voices in the discussion. This article picks up on them.

How to Navigate This

A note from the author: yes, this one fails the TL;DR test - gloriously. The discussion was too good to compress into a quick read, and some things earn their length.

That said, time is precious. A smart brevity version is in the pipeline, for when you have five minutes rather than fifty. Stay tuned.

In the meantime, here is a high-level overview, with direct links to each section.

This gloriously TL;DR-failed article has three parts

Part I starts with the conclusions - what I have drawn from the discussions

The fourth conclusion, From Technology Paternalism to Self-Sovereign Identity, is the main contribution. It describes how the five abilities a system should leave you with - the ones that address technology paternalism - also map onto the SSI lenses now being revisited, as test criteria for whether each lens is actually met.

The three conclusions before it: the abilities themselves, a stack towards technology paternalism, and the line between paternalism and coercion, provide the path towards the fourth.

Part II is about the discussions - on what the conclusions build upon

The sections in part II give the detail on how each of the four conclusions emerged from the back-and-forth, for anyone interested in the foundation. Spoiler: it is worth the walk - though you may want to rest along the way and come back later.

Part III ends where this began — the voices that made it possible

A few thoughts on what is still open, then a return to the people in the discussions. This article is as much theirs as mine: every conclusion was drawn from the discussion, and the voices behind it are credited here.

System, what?

A note on the word “system”: here, a system means anything built from software that may make or shape decisions for or about you – an app, a platform, an algorithm, a protocol, an identity wallet, or the infrastructure underneath them, like a trust graph.

Technology Paternalism in a Hazelnut

Spiekermann and Pallas define technology paternalism as follows: a technology acts paternalistically when it does something that

  1. the person experiences as limiting, punishing, or otherwise curbing their freedom
  2. they can't overrule without giving up the function altogether
  3. is justified as being mainly for their own good and
  4. the system carries out on its own

Points two and four are what specifically makes it technology paternalism, and not just paternalism - you can't get the last word, and the system acts on its own.

 

PART I

The Conclusions

what follows is what I have drawn from the discussions

 

I – Five Abilities a System Should Leave You

Throughout the discussions, one question kept returning: what Spiekermann and Pallas called the right to the last word, and the test of whether a system keeps technology paternalism in check. That is what the five abilities a system should leave you with protect (originally there were four abilities with Trace having emerged within the discussion of the first article about technology paternalism). None of them hinder a system from having defaults, filters, or rankings, systems almost always will. What they do is keep those decisions contestable, so a choice made on your behalf does not become one you just have to live with but one that you are, for example, aware of and can act on.

The image below shows the five abilities a system should leave to you. Depending on how well they are met by the system, they determine the degree with which the system resists technology paternalism and, as hypothesized in this article, test how well some of the revisited self-sovereign identity lenses and principles are met.

More information about each ability can be found in the corresponding drop-downs after the image.

  • Override is the strongest of the five abilities, because it returns the final say to the person. The system can recommend, sort, flag, or block — but when override is preserved, none of that is the last word.

    It is the ability that most directly delivers what Spiekermann and Pallas called the “right to the last word” – the ability to overrule autonomous system behavior – and it remains the hardest to find in practice.

    Most systems offer everything except this: you can be informed, you can appeal, but you cannot simply say no, do it my way and have the system comply.

  • Where override acts in the moment, contest works after the fact: the dispute of a decision that has been made.

    Contest is the ability most systems point at, for example, by providing an appeals form, a complaint button, or a support queue. But if there is no human who can actually reverse the outcome, or no record of how the decision was reached, the “contest channel” exists while the actual right to contest does not.

  • You cannot really challenge what you cannot see which is why the ability to inspect is important.

    Inspect is the right to know why, for example, which criteria were applied, which data was used, what logic produced the outcome. It also extends to the system itself: the right to understand how a safety or filtering mechanism works, and to confirm it does what it claims and nothing more.

    Without inspection, contestation becomes a dispute with a black box – “trust us” should not replaces “here is how it works”.

  • Trace goes one layer deeper than inspect. While inspect shows you the reasoning; trace asks whether the underlying conflict is still there to be examined at all.

    Often systems store only resolved states: the verdict, but not the dispute that produced it. When that happens, the contradicting claims that originally existed have already been processed, a winner and a loser declared before you could act, with nothing left to challenge.

    Trace treats contradiction as information rather than error: it keeps the conflict visible, so that finality is reached with you, not before you.

  • Leave is the last resort, and the one that gives the other four their power.

    You can override, contest, inspect, and trace a system, but each of those depends on a credible ability to walk away if the system won't yield. Take that away, and the others lose their teeth: when leaving means losing your credentials, your history, your relationships, and your identity, the system “knows” you probably cannot afford to go, and it has little reason to honor any right you try to exercise before.

    A practical exit is not a convenience feature; it is what keeps the word “voluntary” valuable. Without portability (which come with the ability to leave), every other ability is held hostage to the price of leaving.

The numbering has shifted from what was used in the original article on technology paternalism: there, leave was the fourth capability. Here it is the fifth, with trace inserted at position four. The order is deliberate - it follows the logic of escalation, from override through to leave as the last resort.
 

II – A Stack towards Technology Paternalism

The discussion that followed the original article on technology paternalism brought in one topic after another raised by different people. What I added was the connection between them. The image below shows a stack where each layer builds on the one before as a result of that work. Read top to bottom, it traces how technology paternalism settles in, and how, for the affected person, layer by layer, it grows harder to challenge: Technology Moralism at the top, perceived as easiest to argue with. Below it come Invisible Architecture, then Guardianship and Implicit Feudalism, Code as Law and Epistemic Invisibility, and finally Lock-in – the hardest to escape once it has set. Some layers also work by being hard to see: Invisible Architecture, or safety systems whose logic stays closed. Others, like lock-in, are plain enough, yet, you just discover them typically too late to leave. What they share is the direction of travel: the further down, the less the affected person can do about it, even as the people who built the system retain every option.

Each layer, and the contributor whose topic it builds on, is described in the corresponding dropdown after the image. For more details on how the topics evolved within the original discussion check out the Discussion Content section.

 
 

  • Designers build a model of who “their” user is, what they can handle, what they need to be protected from

    Built on Technology Moralism, raised by Tim Bouma

  • Defaults, interface flows, content filters, access rules. All of it still contestable, but already less visible than a claim made in the open.

    Built on Invisible Architecture, raised by Christopher Allen

  • Platforms frame their choices as expertise, safety, or necessity. Guardianship is the ideology; implicit feudalism is the infrastructure.

    Built on Guardianship and Implicit Feudalism, raised by Jonathan Bellack

  • Trust graphs that collapse conflicts before surfacing them, safety systems that operate without transparency, switching that requires losing everything

    Built on Code as Law, raised by Jonathan Bellack, Epistemic Visibility, raised by Veikko Eeva, and the Decentralized Trust Graph, raised by Drummond Reed

  • When the cost of leaving exceeds what any individual can realistically absorb, "voluntary" becomes a legal fiction

    Built on Exit & Portability, raised by Fredrik Lindén (and reinforced by Jeno Giordano's framing of portability as a correctness condition)

  • Social license is the ongoing acceptance and legitimacy a provider needs from the communities it governs - not just legal authority, but a standing that has to be continuously earned.

    Mapped to the stack, it is the condition that cuts across the layers, holding each layer accountable to those communities. Where a social license is absent, the layers operate without the legitimacy of those they affect. This means that technology paternalism could be omitted or limited but the system would still not have the standing to make decisions on behalf of those it governs.

    Raised by Colin W.

A note for readers of the original article: the four forms of technology paternalism described there - design, algorithmic, infrastructural, and protective - are not replaced by the stack shown here. The four forms describe what technology paternalism looks like; the stack describes how it settles in over time, layer by layer. Evolving the topic with the stack shows that the protective form, in particular, reappears throughout the stack (most directly in the guardianship and code-as-law layers).
 

III. Technology Paternalism and Coercion

At some point the discussion turned to coercion, which surfaced a distinction worth clearing up: technology paternalism and coercion are similar, and one can lead to the other, but they do not have the same source.

Technology paternalism is about a system deciding, however wrongly, in what it takes to be your interest, and usually in ways you cannot see or easily challenge, while coercion bends you toward an outcome that usually serves someone else's , through pressure rather than presumed care

A system can embed Technology Paternalism without coercing

A benign default set in your interest, say, the most privacy-protective setting switched on by default, is paternalism without coercion: a decision made for you, but with no pressure, no threat, and no direct third-party interest behind it.

A system can be coercive without Embedding Technology paternalism

A threat that serves the platform’s interest (“comply or lose access”, for the platform’s benefit, not yours) is coercion without any reasonable paternalistic “for your own good” justification.

Yet, while technology paternalism and coercion are different failures, the catch is that technology paternalism can tip into coercion. The image "When Technology Paternalism Tips into Coercion" below sketches how, with further explanations after the image.

 
 

Two Expressions of Technology Paternalism

The image shows that technology paternalism (upper-left box) is inherent when a system is designed to make decisions for you, on the assumption that these decisions are made in your interest, yet, without you being part of that assumption.

Depending on how firmly it does so, it takes one of two forms:

  1. Soft technology paternalism steers you but leaves a choice: a default you could change, if you noticed it was there

  2. Hard technology paternalism removes the choice altogether: a filter or restriction you can’t disable, even once you’ve noticed it

Tipping from Technology Paternalism into Coercion

The orange arrow, pointing from technology paternalism to coercion, shows what has to change for that technology paternalism turning into coercion: the intention, and whose interest the technology serves. Technology paternalism makes its decision for what it takes to be for your own good – that justifying goal is built into the concept. Coercion is different: it applies pressure – a threat, or the weight of a power imbalance – until going along with it is the only realistic “choice” left.

 

VI. From Technology Paternalism to Self-Sovereign Identity

what is any of this worth in the context of Self-Sovereign Identity?

Let’s get to the core of this article. The claim:

Building on the technology paternalism work – the original article and the discussion that followed – all five abilities (trace among them, which emerged from the discussion itself) can be mapped onto the RevisitingSSI lenses, a community effort revisiting the SSI principles now under way.

The image below shows how these abilities connect to six of those lenses: Coercion Resistance, Self-Coercion, Choice Architecture & Exit Rights, Binding Commitments, Principal Authority, and Stewardship, and how strongly each ability tests each lens.

The original article on technology paternalism discussed four lenses under Preventing Coercion. This follow-up maps onto six: the same four, plus Principal Authority and Stewardship. The two additional lenses came into focus through the discussion, particularly around delegation to agents and care relationships such as guardianship.

A closer look at each of the 13 connections can be found in the drop-downs after the image.

 
 

Legend

Each connection between an ability a system should leave you with and a SSI lens represents a claim: that the ability adds a way to test whether the corresponding SSI lens is actually being met.
  • A thick line is a strong test – it evaluates the lens almost directly: have the ability, and the lens is largely satisfied.
  • A thin line is a moderate test – it catches one part of the lens, but not the whole.
  • A dotted line is a conditional test – it holds only in a particular case, usually because the person can't act for themselves, so the ability works later, or through someone acting on their behalf.

Two patterns we can observe:

  1. The ability to leave connects to the most lenses — a strong test for four of the six lenses relevant to technology paternalism. It's the ability about getting out.

  2. The ability to inspect exposes the most hidden harms — a strong test wherever a harm depends on keeping you in the dark, like hidden profiling or surveillance you can't see. It's the ability about seeing in.

 

Next, we walk through all thirteen connections, lens by lens, opening each to the abilities that test it, strongest first.

Coercion Resistance

What it guards against: pressure applied to a person.

A system – or whoever stands behind it – leaning on you to make a “choice” or accept an outcome that actually is not reflecting what you want. That pressure runs along a range: at one end the explicit threat (comply or lose access), at the other the more subtle but often stronger weight of a power imbalance, where refusing feels the wrong “choice” due to being labelled in a certain way, being excluded from activities, or from the use of features.

Three abilities give you ways to test whether a system actually resists this.

  • Whether the pressure is a stated threat or the gravity of an imbalance, it only works if the decision a system implies on you is final.

    Override is what hinders this decision from being final. If you can override what the system is designed to decide for you, the party behind it can’t simply impose its will. This test cuts across the whole range of coercion, explicit or more subtle, because in every case override puts the last word back with you.

Override is a strong test of the Coercion Resistance lens

because it takes away the leverage the coercing side would otherwise hold

  • Pressure is easiest applied on you when you can’t see it coming. Coercion Resistance is mostly about addressing hidden inference, for example, a system sorting you into categories, then adjusting your access or your rates without letting you know.

    Inspect is the direct check: can you see what the system inferred about you and acted on? A system you can inspect can't pressure you from the shadows, because the leverage of invisible profiling disappears the moment it is visible.

Inspect is a strong test of the Coercion Resistance lens

because invisibility is exactly the condition this lens is trying to deny the coercing side

  • Contest is the gentler cousin of override: you don’t reverse the decision yourself, but you force it to answer for itself. Coercion Resistance is about whether a the decision a system implies on you can be challenged at all. Contest tests that – can you push back and be heard?

Contest is a moderate test of the Coercion Resistance lens

because the ability to contest is only one of the things to test this lens, alongside inference and lock-in, and because a challenge you can raise is weaker leverage than a decision you can simply overrule

  • Coercion Resistance touches on “inference closure”, which means a prediction about you slowly becomes true because you only ever see the verdict, never the conflict behind it.

    Trace would let you reach that conflict instead of just the outcome. However, the lens of Coercion Resistance is focused on profiling and manipulation, not about decisions being made before you can see them. This means, trace rather extends the lens than it tests it, and should be treated as a proposal here.

Trace is a moderate test of the Coercion Resistance lens

because it only addresses one edge of what the lens covers – the way a decision can harden before you ever see the conflicting signals behind it – rather than the profiling and manipulation the lens is mainly written about

 

Self-Coercion

What it guards against:the pressure you apply to yourself.

Knowing – or just suspecting – that you’re being watched, you police your own behavior before any rule is enforced. It’s the most effective control of all, because the system doesn’t have to do anything; you do its work for it, while typically not being aware of doing so.

  • This is one of the sharpest connections in the diagram. Self-coercion runs on not knowing – you self-censor based on what you imagine is being captured or inferred –.

    Inspect addresses that at the root of suspecting. If you can actually see what the system records and what it doesn’t, the imagined watcher who drives the self-censoring – real or not – loses its grip.

Inspect is a strong test of the Self-Coercion lens

because it doesn’t just test it; it comes close to dissolving the harm, because the harm was made of uncertainty in the first place

 

Choice Architecture & Exit Rights

What it guards against: lock-in.

The slow accumulation of small, reasonable choices into a dependency you can’t get out of (without loosing a lot) – credentials in a format that is not interoperable in a different context, reputation that won’t transfer, switching costs so high that “voluntary” is not actually a choice.

  • This is another of the sharpest connections in the diagram. The Choice Architecture & Exit Rights Lens is about whether you can walk away without losing everything you’ve built, and its central proposal is portability.

Leave is a strong test of the Choice Architecture & Exit Rights lens

because it's not just a test of it; it’s the test. To ask “can you leave with your data and relationships intact?” is to ask the exact question this lens exists to answer

 

Binding Commitments

What it guards against:the misuse of constraint.

Some commitments are good – they’re what lets people trust each other and cooperate over time. The danger is constraints that gradually become a cage: the “commitment” you can never get out of.

  • The Binding Commitments lens defends the good kind of constraint, but its whole safeguard is that you can always still get out – with proportionate costs, and an emergency escape if things turn exploitative.

    Leave is how you check that safeguard actually holds: a commitment you can exit is cooperation; a commitment you can’t is closer to captivity, and the only difference between them is whether leaving is actually possible.

Leave is a strong test of the Binding Commitments lens

because leaving is the line this lens draws between cooperation and captivity

 

Principal Authority

What it guards against: delegation that isn’t really delegation. When you grant a system authority – to a wallet, an issuer, a verifier – you’re supposed to stay the one in charge, able to pull that authority back. The harm is the “agent” that takes your authority and then can’t be recalled.

  • The Principal Authority lens says you remain the principal: the authority is yours, and you can revoke it.

    Override tests against that: can you overrule what the agent did in your name? If you can, the delegation was actually a delegation; if you can’t override an agent’s authority, the agent is running things, not you.

Override is a strong test of the Principal Authority lens

because the lens makes revocability the core of delegation – and override is revocability in action. If you can overrule the agent, the authority is still yours; if you can't, you didn't delegate it, you handed it away

  • Being able to leave, in the context of the Principal Authority lens, is the test of whether a delegation actually was in your interest. If exit destroys what you’ve accumulated or is priced out of reach, the relationship was never delegation but coercion in delegation’s clothing.

    Leave checks precisely this here, and it pairs with override from the other side: override pulls your authority back in the moment, leave walks away from the relationship entirely.

Leave is a strong test of the Principal Authority lens

because being able to actually leave proves the authority you granted is revocable in practice, and revocable authority is the difference between actual delegation and authority you only seem to have

  • The Principal Authority lens includes a disclosure duty: the agent owes you a full account of what it did, its conflicts, what it has paid and so on. Inspect lets you verify that account yourself, rather than trust the agent.

Inspect is a moderate test of the Principal Authority lens

because disclosure is one duty among several here (alongside acting in your interest and staying within scope); inspect verifies the seeing-part, not the whole set.

 

Stewardship

What it guards against: care that curdles into control.

Someone manages another person’s identity – a parent for a child, a guardian for someone who can’t act alone – which may be necessary, but the power in that relationship eventually can turn from protection into permanent control the person can not escape from.

  • This is the best-supported Stewardship connection. The central remedy of Stewardship for someone bound to a system – the child reaching eighteen – is the right to leave: to exit with no penalty, take their credentials, and not be locked for life into a choice made for them anytime in the past.

Leave is a strong test of the Stewardship lens

because it is the direct test of whether the care stayed temporary, or hardened into the control this lens fears

  • Stewardship is about people who can’t act for themselves, so override usually can’t be exercised in the moment – which is the main reason a person is vulnerable in the first place. The test only holds in a deferred or by-proxy form: can the person override later, once they can decide for themselves, or can someone act for them now? That is a real test of whether the care is the accountable kind.

Override is a conditional test of the Stewardship lens

because it leans on a future capacity or a third party rather than on the person overriding today

  • Similar to override, the vulnerable person usually can’t challenge a steward’s decision directly, so contest tests this lens through an advocate, an oversight body, or an appeals process acting on the person’s behalf, or by the person themselves later. Good stewardship is accountable stewardship, and contest is how that accountability gets exercised.

Contest is a conditional test of the Stewardship lens

because it works through someone else or at a later time, not by the person in the moment

 

PART II

The Discussions

what follows is how each conclusion actually emerged

 

1a. When Values Disappear into Systems

THE DISCUSSION STARTED

with technology moralism, a concept that can precede technology paternalism. A builder embeds their own moral judgment into a system. The problem is not that the judgment exists. It is that building the system does not make the judgment right.

THE DISTINCTION THAT EMERGED

IS ABOUT WHO GETS THE LAST WORD

Technology moralism makes a claim to moral authority. Someone states a position: this is what we think, and here is why we built it this way. As the person on the receiving end, you can weigh that position, disagree with it, propose something better. A position is something you can push against.

Technology paternalism is what is left when the standing-behind-it falls away. The same for-your-own-good decision is still being made. It has just been built into the system rather than stated. The system simply works that way — and pushing against it now may mean giving up the function.

What followed from that

is that when a decision can no longer be overruled, no one has to own it anymore either. That is not part of Spiekermann and Pallas's definition, which is about what the system does to the person rather than what happens to the builder's responsibility. But it is a consequence that tends to follow.

A position someone states openly is one you can argue with. A decision built into a system that runs on its own, and that you cannot overrule without losing the function altogether [1], is not.

 

1b. Social Licence

and the Legitimacy Gap

THE DISCUSSION CONNECTED THE MORALISM ARGUMENT TO social license

Social license is the ongoing acceptance and legitimacy a provider needs from the communities it governs - not just legal authority, but a standing that has to be continuously earned from those who are affected. It differs from formal regulatory permission because it cannot be issued once and held indefinitely. It has to be maintained.

Within the Discussion

and alongside the critique of technology moralism as a claim to moral authority, it was raised that there is the prior question of whether that authority was ever accepted by the people most affected. In government identity contexts, that question is typically explicit - it is what drives implementation decisions and shapes how agencies approach public trust.

Social License makes the difference between a provider who has the right to make a decision and one who has earned the standing to make it

This means, while technology moralism is what happens when a provider acts as though building the system confers moral authority. The absence of social license is what makes that assumption visible as an assumption: the provider decided, the people it serves were not part of that decision, and there is no ongoing mechanism for them to withdraw their agreement.

What follows from that

is a gap the stack shown above does not explicitly close. A system can satisfy all five abilities - override, contest, inspect, trace, leave - and still operate without social license, if the legitimacy of the decisions embedded in it was never established with the people it governs. *

The abilities test whether you can challenge a decision. Social license tests whether the decision had standing to be made in the first place.

 

2. Invisible Architectures -

Yesterday’s Assumptions, Tomorrow’s Defaults

THE DISCUSSION EXPANDED

towards Invisible Architectures, which is about decisions built into a system long after anyone remembers them having been made (Rebooting the Web of Trust (2016): the Invisible Architectures, described in Embedding Human Wisdom in Our Digital Tomorrow, authored by Daniel Hardman, Kaliya "Identity Woman" Young, and Matthew Schutte).

THE DISTINCTION THAT EMERGED

Is about time

The underlying issue with invisible architectures is that the corresponding decisions embed assumptions of the moment they were made – the values and the logic of a particular time and context – and keep applying them after that context has changed, sometimes long after.

This adds the dimension of time to technology paternalism, and with it, responsibility. If a system embeds assumptions from years ago, today, then the people building it are making choices whose consequences most likely outlast them – which means they have to build with that in mind.

What followed from that

is that considering invisible architectures in the context of technology paternalism helps explain why technology paternalism is so hard to shake. While previous decisions may have been reasonable on their own, and still may, they may also be adding up to a system that substitutes its judgment for yours by default. The people who built the system may not have intended that. The people who deploy it may not see it. And the people who use it experience it only as friction, or, more often, as a narrowing of what seems possible.

Technology paternalism can be the product of design decisions piling up over time

 

3. Guardians without Accountability

And Implicit Feudalism

THE DISCUSSION THEN MOVED back FROM DESIGN TO POWER

placing technology paternalism inside a much older political frame: guardianship - not in the legal sense of a court-appointed role, but in the older political sense of a group that claims the right to decide for others on the grounds that it knows better. That idea is ancient, it runs from Plato’s philosopher-kings, through Lenin’s revolutionary vanguard, down to today. The modern tech version is, for instance, a head of platform safety, a small standards committee, a product team. typically unelected, and rarely accountable to the people they decide for, however good their intentions.

THE DISTINCTION THAT EMERGED

IS ABOUT ACCOUNTABILITY

Protective technology paternalism, one of the four forms of technology paternalism I described in the original article, turns out to map onto Plato’s guardian class almost exactly: restrictions that are justified in the language of safety, security, or harm prevention, imposed by those who have decided they know what you need protecting from. It's a parallel that emerged from the discussion and that added depth to the original article’s framing of protective paternalism.

What followed from that

is the observation of a crucial difference. Guardianship in the digital world scales without accountability. Plato's philosopher-kings were visible - you knew who they were.

In the original article, guardianship was framed as a claim to authority: someone asserting they know best. Technology paternalism is almost the opposite. The claim is built into the system itself, so it no longer needs to be asserted. It shows via defaults, interface flows, filtering logic, or access rules.

With technology paternalism there is no guardian to question, because the guardianship has dissolved into the infrastructure.

And once it is in there, the system enforces what is best for everyone. Hence, technology paternalism can persist without an active guardian. The system does not need a philosopher-king. It only needs to have been built by someone with a particular idea of who the person using the system is - and then deployed at scale to everyone, including all the people who do not fit that idea.

THE DISCUSSION actually SURFACED

STRUCTURAL ASSUMPTIONS

or, what happens when guardianship is baked into the system itself? That is where the discussion put Nathan Schneider's concept of implicit feudalism into focus.

Schneider describes a bias - cultural and technical - in how online spaces get built. Platforms grant administrators absolutist control over their communities, with competition among them as the primary mechanism for quality control, under rules set by the platform companies above them. Whoever creates a space has essentially absolute power over it. The only tools available for addressing conflict are censorship and exile. There is no way to appeal.

Over time, Schneider argues, these feudal defaults train people to give up on their communities’ democratic potential - inclining them to tolerate autocratic authority and distrust their own capacity for self-governance.

What the discussion draw from that

is that while implicit feudalism is not the same concept as technology paternalism, and Schneider did not say otherwise, the two share the same structural logic. Where implicit feudalism describes how online spaces are built by default - with power already concentrated before any single design decision is made - technology paternalism describes what that concentration makes possible: decisions embedded in systems that the people affected by them cannot overrule.

Implicit feudalism puts the power asymmetry into the infrastructure before any single design decision is made. Technology paternalism moves into the space that creates.

 

4. Code as Law

Surveillance and the Right to Inspect

THE DISCUSSION then BROUGHT IN A software view

the original article had not used: Lawrence Lessig's insight that code is law. His argument, developed in Code and Other Laws of Cyberspace, is that software and hardware set permissions, create affordances, and block uses - regulating behavior just as law does, but through architecture rather than statute [2]. The people who write the code make the decisions. Everyone else has just to live according to them. Seen through that view, technology paternalism is not an edge case of system design. It is what happens when the regulatory power of code is turned inward - toward the people the system is meant to serve.

THE MOST ACUTE IMPLICATION

the discussion found, is around safety and surveillance. Platforms scan content at scale to prevent harm. But the same infrastructure that protects can just as easily restrict, censor, or repress.

Platforms scan content at scale to prevent harm. But the same infrastructure that protects can just as easily restrict, censor, or repress.

And because the architecture is closed and the decisions are made upstream, the people being governed by it have no way to see how those decisions get made — or whether they have drifted from their original purpose.

What the discussion draw from that

was a response about community rights.

Three rights communities should hold against the Systems that govern them

(1) the right to understand how a system’s safety mechanisms work

(2) the right to consent, in advance, to changes that increase surveillance

(3) the right to inspect those mechanims regularly – to confirm they do what they are said to do, and nothing more or less

These three rights line up almost exactly with the original article’s framing. There, the right to the last word rested on four abilities: override, contest, inspect, and leave.

The three community rights reflect, in essence, the ability to inspect: scaled up from an individual right to a community one, and stretched forward in time through consent in advance.

And the third right - the right to inspect regularly, to confirm the system does what it says and nothing more or less - is what determines whether safety means protection, or simply third-party control with better framing.

 

5. A Trust Graph as the Test Case

The Decentralized Trust Graph

THE DISCUSSION THEN tapped into practice

by focusing on a concrete testing ground: the Decentralized Trust Graph — a joint working group run by Trust over IP (ToIP) and the Decentralized Identity Foundation (DIF), launched in 2025 as part of a broader initiative on digital trust for agentic AI [3]. Its purpose is to define the standards for building decentralized trust graphs: graphs of trust relationships between people, organizations, AI agents, and so on - where there is no centralized database and all parties control their own portable subgraph of trust relationships [4].

WHAT THE DISCUSSION DREW FROM THAT

was that as an identity community, we run the risk of building systems that restrict behavior in the name of safety - and not noticing we have fallen into the very trap we set out to prevent. A system that makes its restrictions impossible to challenge is technology paternalism, regardless of the intentions behind it.

If in a trust graph participant cannot inspect the reasoning behind a decision a system made about or for them, the problem has not been solved. It has been built in

 

6. The Proposal for a Fifth Ability

Tracing Decisions Back to Their Conflicts

THE DISTINCTION THAT THEN EMERGED IS about CONTRADICTION

A further input sharpened the original article’s message: if a system only stores resolved states, the conflicting claims behind them are invisible by design. And you cannot judge what you cannot see. Judgment is only possible in a system whose decisions - and the reasons behind them - remain open to you.

Take the exclusion example. You cannot inspect or argue with why you were excluded if the system has already resolved the conflict on your behalf. The only thing it shows you is the outcome - the exclusion itself.

THE DISCUSSION SURFACED

is that a system that hides its conflicting claims reproduces protective technology paternalism at the level of the data model. Not through intent, but through architecture.

The question is not only whether you can see a system’s decisions. It is also whether the system keeps open the conditions under which you could disagree.

A system that surfaces its conflicts treats you as someone capable of judgment. A system that settles them before you ever see them treats you as the subject of a decision made elsewhere.

From this came a proposed fifth ability

Alongside the four abilities named in the original article, within the discussion a fifth one surfaced: the ability to trace a decision back to the conflict it came from, before the system has resolved it on its own and forced it into a final state.

The full list of abilities a system should leave you with, revised below. The order follows the logic of escalation: you first try to override, then contest, then inspect, then trace the decision back to the conflict behind it - and only leave when none of that has worked.:

(1) the ability to override a system’s decision

(2) the ability to contest A system’s decision

(3) the ability to inspect the reasoning behind A system’s decision

(4) the ability to trace a decision back to the conflict it came from (new ability)

(5) The ability to actually leave the system

 

7. The Exit that Isn’t

Portability as the Condition for Leaving

THE DISCUSSION THEN MOVED TO Portability

what is likely the most practical challenge of all: data portability; and whether, without it, the five abilities bear any value.

The discussion also raised a side question about whether technology paternalism belongs on the agenda of MyData Global, the international nonprofit working to empower individuals through the right to self-determination regarding their personal data.

WHAT THE DISCUSSION DREW FROM THAT

was the core challenge highlighted next:

Without portability, none of the five abilities is strong

You can contest a decision made by a system you cannot leave. You can also inspect the reasoning of a system whose data you cannot take with you. But contesting and inspecting do not count for much when acting on what you find means losing everything you have built up inside the system — your data, your history, your relationships.

Portability is what makes the ability to leave a valuable option: an exit you can actually take, with your data and relationships intact.

Without portability, the word voluntary has no value.

 

8. The Literacy Trap

"Just learn how it works" can excuse the problem instead of fixing it

ONE MORE DISTINCTION THAT THEN EMERGED digital literacy

Digital literacy is a person's ability to understand and use digital systems. It also bears a familiar argument: if people understood these systems better, they could navigate them better.

That is true, but it is not enough.

Understanding a system does not always give you the power to change it

You can know exactly how the defaults were set, and why, and still have no real way to switch them off. Knowledge of the mechanism is not the same as access to the controls.

There is a second problem with making literacy the answer. Those who have not had the chance to build it are left with whatever the system decided for them - which is worse, because it adds a layer of blame. The system constrained you, and now it is somehow your fault for not understanding it well enough.

Digital literacy is important – but it is a complement to structural fixes, not a substitute for them

Asking people to learn their way out of a technology paternalistic system legitimizes that system

 

Closing Thoughts

What Held, What Sharpened, What Opened

WHERE THIS LEAVES US.

The discussion took the original article apart - not to dismantle it, but to stress-test it. It opened the anti-pattern into pieces: moralism, assumptions hardening into infrastructure, guardianship without accountability, code that governs like law, conflicts resolved before anyone can see them. Always with the same question in focus: can the person still get the last word?

That question framed the two main takeaways. First, the five abilities – override, contest, inspect, trace, leave – are not a guarantee against technology paternalism. They are a way to see, in any given system, whether a decision made for you is still one you could challenge, understand, or walk away from. And second, how those same may map onto the SSI lenses now being revised, each one a way to test how concretely a given lens is actually met. That mapping is a beginning, not a conclusion.

One clarification

may be needed before going further. The five abilities are a measure, not a checklist every system must fully pass. Some systems - government identity infrastructure above all - cannot leave a direct override with you: a tax assessment or an eligibility ruling is final by law, for reasons that are considered to protect everyone. That is not the ability being waived. It is the last word exercised through due process - contest, inspect, a lawful appeal - rather than a toggle. The test still holds though: it shows how much of the last word a system preserves, and through what mechanism. In that context, a low score on direct override is a finding, not a failure.

A few directions that could further be explored are:

PRACTICALity

So far the abilities have been applied as an argument: for example, does override, in principle, test coercion resistance? The next step is to apply them as architecture. Take the Decentralized Trust Graph: can a participant override an exclusion, inspect why a trust relationship was dropped, trace the conflicting claims behind a verdict, leave with their relationships intact? That turns the abilities from criteria on paper into design requirements a protocol can be measured against.

broadness

This piece touched six lenses, not all fifteen. It may therefore be an opening into the RevisitingSSI work rather than a finished frame — offered, like the lenses themselves, as an invitation to engage

looking sideways

Technology paternalism has cousins. Persuasive computing sets out to change what you want. Nudging steers without removing the choice. Dark patterns push you toward someone else’s interest. Each is a little different: paternalism decides for what it takes to be your own good, persuasion reshapes your wants, coercion applies pressure. Telling them apart - and giving each its own evaluation criteria - may be where this work goes next.

Voices in The Discussion – Thank You

This follow-up exists because people read the first article and gave it their time, their thinking, their questions, and their pushback. That is a generous thing to do, and it is what made this piece possible.

Tim Bouma introduced technology moralism: the mistaken belief that being a technology provider also confers moral authority, which opened the thread on visibility and the right to the last word.

Colin W. connected the discussion to social license: the ongoing acceptance and legitimacy a provider needs from the communities it governs, and a concept already top of mind in most government identity implementations. It is the condition the stack does not just close on its own.

Christopher Allen picked up the original article on Life With Alacrity and Blockchain Commons, connected it to his Architecture of Autonomy work, identified the moment moralism turns into paternalism, brought in the Invisible Architectures concept from Rebooting the Web of Trust, named institutional guardianship in credential governance, proposed the four abilities as evaluation criteria for trust infrastructure, and pointed to the RevisitingSSI Stewardship and Preventing Coercion lenses discussed above.

Jonathan Bellack contributed the political-historical frame through his Platformocracy writing. The guardianship lineage from Plato to Lenin, Nathan Schneider’s implicit feudalism, and the code-as-law connection with the three community rights around platform surveillance - understand, consent, inspect - all trace to his work there.

Drummond Reed connected the discussion to the Decentralized Trust Graph Working Group at Trust over IP and the Decentralized Identity Foundation, making trust infrastructure the concrete test case for the five abilities.

Veikko Eeva introduced the distinction between restricting information and marking its epistemic status - and with it, the shape of the fifth ability: the right to reach the conflict behind a decision, before the system has resolved it out of sight.

Fredrik Lindén raised the question that surfaced the portability thread - whether technology paternalism belongs on the MyData Global agenda - and with it, exit as the practical floor beneath every other ability.

Jeno Giordano offered a practitioner’s confirmation: building an identity layer, his team found that anchoring credentials to a platform quietly repriced exit as loss - so they came to treat portability not as a feature but as a correctness condition.

Kaliya Young included the original article in Identosphere newsletter #167, bringing it to the wider identity community.

The conversation is not finished. If something here resonates, or if you think something is missing, that is a reason to continue it.

Sources and Further Reading

* Social license originated in the mining and resource industries. Its use in government digital identity contexts is growing while in the SSI and decentralized identity space the term is less established, yet.
If this made you think →

Change History

Started, June 12, 2026: began the writing phase after a previous longer elicitation phase
Published, June 22, 2026
Martina
Next

Technology Paternalism Expands — A Case for Self-Sovereign Identity