Skip to content

Rule of Least Power (Minimum Sufficient Capability)

Prime #
1154
Origin domain
Computer Science & Software Engineering
Subdomain
software design → Computer Science & Software Engineering

Core Idea

The rule of least power directs a designer to choose the least expressive, least capable mechanism that still solves the problem. Greater capability is not free: each increment of expressive power — Turing-completeness, write access, discretion, side-effect range — extends what an actor, or the artifact itself, can do, and therefore extends what callers, reviewers, and downstream systems must reason about, audit, or defend against. Capability that is not needed is structural debt: it weakens analyzability, composability, and safety guarantees without paying for itself in function.

The load-bearing structural content is an inversion of the usual design question. Rather than asking "which mechanism is most powerful?", the rule asks "which is the weakest that still works?" — and treats every dimension of power (write versus read, dynamic versus static, global versus local, indefinite versus scoped) as a quantity to minimize subject to function rather than to maximize. This inversion is load-bearing because capability and analyzability trade off against each other: a less capable artifact has stronger upper bounds on its possible behavior, and those upper bounds are exactly what makes it machine-checkable, composable, and safe. The rule therefore implies a partial order on mechanisms — declarative below imperative-pure below imperative-side-effecting below self-modifying — and a corresponding partial order on guarantee strength, with weaker mechanisms admitting stronger guarantees. The key reframing is that capability slack — the gap between what an artifact can do and what it must do — is not neutral headroom but latent risk surface, to be measured and pruned rather than left standing for the convenience of possible future use.

How would you explain it like I'm…

Use The Smallest Tool

If a job just needs a butter knife, don't grab a giant chainsaw — the chainsaw can do way more, but that extra power can cause trouble you don't need. Pick the simplest tool that still gets the job done. Less power means fewer ways for things to go wrong.

Weakest Tool That Works

The rule of least power says: pick the least powerful tool that still solves your problem. Extra power isn't free — the more a tool can do, the more everyone has to check, watch, and guard against, because there are more ways it could go wrong or be misused. Power you don't actually need is like a hidden cost; it makes things harder to understand and trust without giving you anything back. So instead of asking "which option is the most powerful?", you ask "which is the weakest one that still works?" A simpler tool has tighter limits on what it can possibly do, and those tight limits are exactly what make it safe and easy to check.

Minimum Sufficient Capability

The rule of least power directs a designer to choose the least expressive, least capable mechanism that still solves the problem. Greater capability isn't free: each increment of expressive power — Turing-completeness, write access, discretion, side-effect range — extends what an actor or the artifact can do, and therefore extends what callers, reviewers, and downstream systems must reason about, audit, or defend against. Capability that isn't needed is structural debt: it weakens analyzability, composability, and safety guarantees without paying for itself. The load-bearing move is an inversion of the usual design question — instead of "which mechanism is most powerful?", ask "which is the weakest that still works?", treating every dimension of power (write vs. read, dynamic vs. static, global vs. local, indefinite vs. scoped) as a quantity to minimize subject to function. This matters because capability and analyzability trade off: a less capable artifact has stronger upper bounds on its possible behavior, and those bounds are exactly what make it machine-checkable, composable, and safe. So the rule implies a partial order on mechanisms — declarative below imperative-pure below imperative-side-effecting below self-modifying — with weaker mechanisms admitting stronger guarantees. The reframing is that capability slack — the gap between what an artifact can do and what it must do — isn't neutral headroom but latent risk surface, to be pruned rather than left standing for possible future use.

 

The rule of least power directs a designer to choose the least expressive, least capable mechanism that still solves the problem. Greater capability is not free: each increment of expressive power — Turing-completeness, write access, discretion, side-effect range — extends what an actor, or the artifact itself, can do, and therefore extends what callers, reviewers, and downstream systems must reason about, audit, or defend against. Capability that is not needed is structural debt: it weakens analyzability, composability, and safety guarantees without paying for itself in function. The load-bearing structural content is an inversion of the usual design question. Rather than asking "which mechanism is most powerful?", the rule asks "which is the weakest that still works?" — and treats every dimension of power (write versus read, dynamic versus static, global versus local, indefinite versus scoped) as a quantity to minimize subject to function rather than to maximize. This inversion is load-bearing because capability and analyzability trade off against each other: a less capable artifact has stronger upper bounds on its possible behavior, and those upper bounds are exactly what makes it machine-checkable, composable, and safe. The rule therefore implies a partial order on mechanisms — declarative below imperative-pure below imperative-side-effecting below self-modifying — and a corresponding partial order on guarantee strength, with weaker mechanisms admitting stronger guarantees. The key reframing is that capability slack — the gap between what an artifact can do and what it must do — is not neutral headroom but latent risk surface, to be measured and pruned rather than left standing for the convenience of possible future use.

Structural Signature

the function to be served — the partially ordered space of candidate mechanisms by expressive power — the capability cost borne by every downstream consumer — the minimize-power-subject-to-function selection rule — the capability slack as latent risk surface — the inverse guarantee gradient (weaker power, stronger provable bounds)

The pattern is present when each of the following holds:

  • A function. There is a problem to solve or use-case to meet, which fixes the minimum capability genuinely required.
  • A power-ordered mechanism space. Candidate mechanisms differ in expressive power along orderable dimensions — declarative below imperative-pure below imperative-side-effecting below self-modifying; read below write; scoped below ambient — forming a partial order.
  • A capability cost. Every increment of power extends what the artifact can do, and so extends what callers, reviewers, and downstream systems must reason about, audit, or defend against; this cost falls on consumers, not the chooser.
  • A minimizing selection rule. The design question is inverted — not "which mechanism is most powerful?" but "which is the weakest that still works?" — treating every dimension of power as a quantity to minimize subject to function.
  • Capability slack. The gap between what an artifact can do and what it must do is named as latent risk surface to be measured and pruned, not neutral headroom kept for possible future use.
  • An inverse guarantee gradient. Lower capability yields tighter upper bounds on possible behavior, so weaker mechanisms admit stronger guarantees; choosing a mechanism is simultaneously choosing a provability ceiling.

These compose so that safety and analyzability are read off the behavior an artifact cannot exhibit: the size of that forbidden space is the measure, and the discipline is to enumerate required capabilities, revoke the rest, and prefer the declarative and the bounded.

What It Is Not

  • Not principle_of_least_privilege. Least privilege bounds authority — what an actor may act upon. The rule of least power bounds expressiveness — what a mechanism can compute or say. These are independent axes: a declarative artifact can hold broad grants, and a Turing-complete one can be tightly sandboxed (see principle_of_least_privilege).
  • Not parsimony_occam_s_razor. Occam's razor minimizes the number of assumptions in an explanation for epistemic reasons. The rule of least power minimizes expressive capability in a designed artifact for analyzability and safety. One is a criterion for theories; the other for mechanisms (see parsimony_occam_s_razor).
  • Not minimalism. Minimalism reduces parts or features for economy or aesthetics. The rule of least power specifically reduces expressive power even where adding features is cheap, because power — not part-count — is the cost being minimized. A feature-rich but declarative artifact satisfies the rule; a single Turing-complete one violates it.
  • Not constraint. A constraint is any restriction on a system's states. The rule of least power is the design discipline of choosing the most constrained mechanism sufficient for function — it prescribes which constraints to prefer (those that bound expressiveness), not constraint as such.
  • Not statistical_power. Despite embedding-nearness and the shared word, statistical power is a test's probability of detecting a true effect — wholly unrelated. The "power" here is expressive capability, not inferential sensitivity.
  • Common misclassification. Treating "we used the least powerful language" as if it also bounded authority. Expressiveness and reach are separate axes; minimizing one leaves the other wide open. The tell: have you minimized what the mechanism can express and what it may act upon separately?

Broad Use

The same capability-minimization discipline recurs across substrates that share little but the structure of a design choice. In software and web architecture, it favors declarative HTML and CSS over Turing-complete JavaScript when both suffice, because declarative artifacts can be indexed, transformed, and reasoned about by other tools, and it favors regular expressions over context-free grammars over general parsers when the input fits. In security and systems administration, it appears as granting a process, user, or token only the rights its task requires, reducing blast radius on compromise. In constitutional and institutional design, it appears as enumerated powers, narrow mandates, and sunset clauses on emergency authority, granting the smallest authority that does the job because any standing authority will eventually be used. In legal drafting, it appears as narrow indemnities, scoped warranties, and minimum necessary discretion, since broad clauses become broad liabilities. In API and protocol design, it appears as exposing the smallest interface that meets the use case, since every extra method is a future compatibility constraint and a future attack surface. And in pedagogy, it appears as using the simplest formalism that captures a problem — arithmetic rather than calculus, first-order rather than modal logic — so that more readers can follow and more tools can check. In each, the unused capability is the cost, and the recipe is to minimize it subject to function.

Clarity

The rule clarifies by reframing "what mechanism should we use?" from a capability choice — which is most powerful? — into a constraint choice — which is the weakest that still works? Once a reasoner sees this inversion, a whole class of design questions becomes well-posed: every dimension of power becomes something to minimize subject to function rather than something to maximize, and the default flips from "grant capability unless there is a reason not to" to "withhold capability unless function requires it." The clarifying force is to make capability slack visible and accountable: rather than treating extra power as harmless headroom, the frame names it as a cost borne by every downstream consumer who must now reason about behaviors that will never actually occur.

Manages Complexity

Limiting expressive power makes artifacts dramatically more analyzable. Declarative content can be machine-rewritten; pure functions can be memoized and reordered; least-privilege processes have small blast radii; narrow legal clauses have predictable interpretations. Lower power means fewer cases to reason about — for compilers, auditors, courts, reviewers, and operators alike. The complexity payoff is structural rather than incidental: a less capable mechanism has simpler upper bounds on possible behavior, not merely simpler current behavior, so the simplification holds for every possible future use, not just the present one. By pruning capability slack, the rule shrinks the space of behaviors any analysis must consider, converting an open-ended "what could this do?" into a bounded "what can this do at most?" — and it is the boundedness, not the current quiescence, that keeps the system tractable as it composes with others.

Abstract Reasoning

The rule lets a designer reason along the axis of capability slack: how much of what this artifact can do is not what it must do? Slack is risk surface, and the question "how much slack does this mechanism carry?" is the prime's central diagnostic. The rule also implies a partial order on mechanisms by expressive power, and a corresponding partial order on guarantee strength, so that choosing a mechanism is simultaneously choosing a provability ceiling. These relationships are substrate-neutral: they concern the trade-off between what a mechanism can do and what can be proved about it, a trade-off indifferent to whether the mechanism is a markup language, a database credential, a constitutional grant, or a contractual clause. To reason with the rule is to reason about the behavior an artifact cannot exhibit, and to treat the size of that forbidden space as the measure of the artifact's safety and analyzability.

Knowledge Transfer

The transferable content is a single intervention vocabulary: enumerate required capabilities; revoke unused ones; prefer declarative over imperative; prefer scoped over ambient; treat capability slack as latent risk. The move recurs across domains with the idiom swapped. From software to law, every broadly worded clause is, in effect, a Turing-complete contract, and the response is to choose the narrowest enforceable scope. From security to AI tool design, agent tools should be scoped to least capability — read-only by default, narrow targets, rate limits — before any write or shell access is granted. From constitutional design to organizations, role authority should be enumerated rather than residual, with the default being no power and granted power the minimum that lets the role function.

The structural roles map across substrates. The adjustable-capability mechanism is the markup-or-script choice, the credential, the mandate, or the clause; the function is the use-case that requires only some of that capability; the capability cost is the burden each unused power places on callers, auditors, and attackers; the choice rule selects the minimum capability sufficient for function; and the guarantee gradient runs from weaker capability through stronger upper bounds to stronger analyzability and safety. A web architect choosing static HTML over an executable document, a database administrator issuing a read-only credential before granting writes to the few endpoints that need them, and a constitutional drafter enumerating powers rather than leaving them residual are performing the same structural act: selecting the least capable mechanism sufficient for the function and treating the remaining slack as risk to be pruned. The diagnostic — how much can this do beyond what it must, and can that slack be revoked? — travels unchanged across software, security, constitutions, contracts, APIs, and pedagogy. Because the recipe is identical across these media, a practitioner who has pruned capability slack in one domain can import the whole discipline — enumerate, scope, prefer the declarative and the bounded — into a domain that frames the same trade-off in its own normative vocabulary.

Examples

Formal/abstract

Consider the choice of formalism for matching a class of inputs in a parser. The function is to recognize whether a string belongs to some language — say, valid email-local-parts, or balanced parentheses, or an arbitrary nested configuration grammar. The power-ordered mechanism space is the Chomsky hierarchy: regular expressions below context-free grammars below Turing-complete code. Each step up the hierarchy adds expressive power but extends what the mechanism can do, and therefore what every consumer must reason about. The minimizing selection rule is to pick the weakest level that still recognizes the language: if the inputs are regular (no unbounded nesting), a regular expression suffices, and choosing a full general parser is pure capability slack. The inverse guarantee gradient is sharp and provable here. A regular expression compiles to a finite automaton, which is guaranteed to run in linear time and constant memory and to halt — the forbidden-behavior space (no backtracking blowup, no infinite loop, no unbounded recursion) is exactly what makes it safe to expose to untrusted input. Reach for a Turing-complete validator and those guarantees vanish: the engine can now loop forever, exhaust memory, or be exploited via catastrophic backtracking, because the upper bound on its behavior is unbounded. The diagnosis the rule licenses is to read safety off what the mechanism cannot do — and the intervention is to drop down the hierarchy whenever the input class permits, pruning the slack rather than keeping a powerful engine "in case the grammar grows."

Mapped back: language-recognition is the function, the Chomsky hierarchy is the power-ordered mechanism space, an over-general parser is the capability slack, and the finite automaton's guaranteed halting and linear time are the inverse guarantee gradient — weaker power buying stronger provable bounds.

Applied/industry

Two applied substrates show the same minimize-power discipline. First, a web team deciding how to render a content page. The function is to display structured text and images; the mechanism space runs declarative HTML/CSS below Turing-complete client-side JavaScript. The rule selects the weakest sufficient option — static HTML — because a declarative document carries strong guarantees a script cannot: it can be indexed by search engines, transformed by accessibility tools, cached, and reasoned about by other software, precisely because its behavior is bounded and it cannot execute arbitrary logic. Rendering the same page as a JavaScript application is capability slack that imposes a cost on every downstream consumer — the crawler, the screen reader, the security reviewer who must now defend against an execution surface. Second, database credentialing: a reporting service that only reads data should be issued a read-only credential, not an admin one. The function fixes the minimum authority; the capability cost of a write-capable credential falls on whoever must later reason about what a compromised reporting service could do. Scoping the credential to read-only shrinks the forbidden-behavior space so that the worst-case outcome of compromise is data exposure rather than data destruction. The identical move — grant the smallest authority sufficient for function — appears in constitutional design as enumerated powers and sunset clauses, where any standing authority will eventually be used, so the minimum grant is the safe one.

Mapped back: page rendering and data reporting are the functions; declarative HTML and the read-only credential are the least-powerful sufficient mechanisms; client-side JavaScript and admin rights are the capability slack; and indexability, cacheability, and bounded breach-damage are the guarantees that weaker power buys — the rule operating across web architecture, security, and institutional design.

Structural Tensions

T1 — Sufficient for Which Function (temporal/scopal). "The weakest mechanism that still works" depends on knowing the function fully — but requirements grow, and a mechanism chosen as minimal for today's spec may be too weak tomorrow, forcing a costly migration up the power hierarchy. The rule under-specifies the future the mechanism must serve. Failure mode: a declarative configuration that hits a wall the moment a genuinely computational requirement arrives, triggering an expensive rewrite the headroom would have avoided. Diagnostic: is the function's expressive requirement stable, or is it on a trajectory toward the next power tier? Stability justifies minimalism; a clear growth path may justify headroom.

T2 — Minimal Power versus Developer Velocity (scalar, local vs global). The capability cost falls on downstream consumers (reviewers, crawlers, integrators), but the expressive convenience of a powerful general mechanism accrues to the original author — so minimizing power can globally optimize safety while locally taxing the builder, who must do more work in a constrained tool. Failure mode: a team that, under velocity pressure, reaches for the Turing-complete tool because it is faster to write, externalizing the analyzability cost onto everyone downstream. Diagnostic: who bears the cost of the extra power, and who bears the cost of forgoing it? The rule is right only if the downstream cost dominates, which is usual but not universal.

T3 — Capability Slack versus Useful Headroom (sign/direction). The prime reframes unused capability as latent risk surface to be pruned — but some slack is deliberate extensibility, the open surface of the open-closed principle, kept precisely so future change routes additively. One frame says "prune the power," the other says "preserve the extension point." Failure mode: stripping a mechanism to its current-minimum and thereby destroying a designed-in extension surface, so the next change requires a kernel break. Diagnostic: is the unused capability speculative (prune it) or a load-bearing extension contract with a concrete anticipated use (keep it)?

T4 — Provability Ceiling versus Real Threats (measurement). The inverse guarantee gradient says weaker mechanisms admit stronger provable bounds — but provable bounds are not the same as actual safety; a maximally constrained mechanism can still be misused within its bounds, and the proof addresses only the behaviors the power-ordering captures. Failure mode: certifying a system safe because its mechanism is provably bounded, while the real attack exploits the application logic the proof never modeled. Diagnostic: do the guarantees the weaker mechanism buys actually cover the threat you face, or only a formally tractable subset of it?

T5 — Power versus Privilege (competing prime). This rule bounds expressive capability (what a mechanism can compute or express); the principle of least privilege bounds authority (what an actor may act upon). They are independent axes, and minimizing one says nothing about the other — a declarative artifact can still hold broad grants, and a Turing-complete one can be tightly sandboxed. Failure mode: treating "we used the least powerful language" as if it also bounded authority, leaving the privilege axis unaddressed. Diagnostic: have you minimized expressiveness and reach separately? Conflating them leaves whichever axis you ignored wide open.

T6 — Composition of Weak Parts (coupling). Each component chosen at minimum power is locally safe, but their composition can re-create the power that was individually denied — a pipeline of declarative stages can be Turing-complete in aggregate, so the system-level expressiveness exceeds any part's. The local guarantee does not compose. Failure mode: a collection of "safe, bounded" mechanisms wired together into an emergently unbounded system, with no single component to blame. Diagnostic: what is the combined expressive power of the composed mechanisms, not just each in isolation? Weakness must be argued at the system level, not part by part.

Structural–Framed Character

The rule of least power sits on the framed side of the structural–framed spectrum, consistent with its aggregate of 0.8 — solidly framed. There is a real relational fact underneath — that lower expressive capability yields tighter provable upper bounds on behavior, an inverse guarantee gradient that holds for any power-ordered mechanism space — but the prime is fundamentally a prescriptive design heuristic, and four of the five diagnostics pull it toward the framed pole.

Evaluative weight and institutional origin both max out and reinforce each other. The prime is a named design principle, articulated by Berners-Lee for the web, and invoking it issues a normative prescription — choose the least powerful mechanism that still works — that carries unmistakable approval: capability slack is framed as "structural debt," "latent risk surface," a thing one ought to prune. That is a value judgment built into the prime, not a neutral description of how mechanisms behave. The prime is also thoroughly human-practice-bound: its substrates are software architecture, security credentialing, constitutional drafting, contract law, API design, and pedagogy — all design-and-authorship practices presupposing a chooser who selects a mechanism for a function. It has no physical or biological instantiation; nothing without a designer "chooses the weakest sufficient tool." Vocabulary travels only partway, scored at the midpoint: "expressive power," "capability slack," "declarative below imperative," "provability ceiling" carry a computer-science design lexicon, and the prime is recognizable in non-software domains only by analogy to least-privilege or parsimony, after the home idiom is translated.

What keeps it from the extreme framed pole is that the underlying trade-off — between what a mechanism can do and what can be proved about it — is genuinely substrate-neutral once named: the diagnostic "how much can this do beyond what it must, and can that slack be revoked?" applies to a markup language, a database credential, a constitutional grant, and a contractual clause alike. The relational core is real, but the named-design-principle origin and its heavy prescriptive charge place the prime well onto the framed side.

Substrate Independence

The rule of least power is a moderately substrate-independent prime — composite 3 / 5 on the substrate-independence scale. Its discipline — choose the least expressive mechanism that still solves the problem, because unused capability is structural debt that weakens analyzability and safety — reaches a domain breadth of 4: web and language design (preferring declarative markup or data over arbitrary code, its Berners-Lee origin), security architecture, constitutional and statutory drafting (granting only the narrowest power that achieves the aim), contract design, API and protocol design, and pedagogy (introducing the least-powerful tool sufficient for a lesson). What holds structural abstraction to 3 is that the rule is fundamentally a prescriptive design heuristic: it carries strong normative weight (less power is "better") and is recognizable outside software only by analogy to parsimony or least-privilege, rather than reading as a neutral description of how systems behave. Transfer evidence is 3 for the same reason — the cross-domain instances are the same expressive-minimality maxim re-applied by designers, not a shared formal model carried intact across media. The composite settles at 3: a broadly applicable capability-minimality principle whose ceiling is its prescriptive, human-design frame.

  • Composite substrate independence — 3 / 5
  • Domain breadth — 4 / 5
  • Structural abstraction — 3 / 5
  • Transfer evidence — 3 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Rule of Least Power …composition: ConstraintConstraint

Parents (1) — more general patterns this builds on

  • Rule of Least Power (Minimum Sufficient Capability) presupposes, typical Constraint

    The file: rule_of_least_power 'prescribes WHICH constraints to prefer (those that bound expressiveness)' — a design discipline of choosing the most constrained mechanism sufficient for function. Presupposes constraint as its object. (Owner may prefer minimalism as an alt parent.)

Path to root: Rule of Least Power (Minimum Sufficient Capability) → Constraint

Neighborhood in Abstraction Space

Rule of Least Power (Minimum Sufficient Capability) sits in a moderately populated region (44th percentile for distinctiveness): it has near-neighbors but no dense thicket of synonyms.

Family — Formal Methods & Idealized Models (31 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The rule of least power's most consequential confusion is with the principle_of_least_privilege, and the two are so often invoked together in secure-system design that they are routinely treated as one discipline. They are not: they minimize along orthogonal axes, and satisfying one says nothing about the other. The rule of least power bounds expressiveness — how computationally capable the language, format, or mechanism is (a declarative config versus a Turing-complete script). The principle of least privilege bounds authority — what an actor is permitted to do to the rest of the system (which files it can write, which accounts it can charge). The axes come apart cleanly in both directions: a maximally constrained, non-Turing-complete mechanism can be handed sweeping authority over the whole system, and a fully Turing-complete engine can be tightly sandboxed with almost no authority. The practitioner consequence, which the prime's own tension T5 turns on, is that minimizing one axis leaves the other wide open. A team that proudly "used the least powerful language" may have left the artifact holding broad grants; a team that scoped authority meticulously may have embedded an arbitrary-code surface inside the bounded grant. Both disciplines are required, and the diagnostic must be run twice — once for expressiveness, once for reach — because conflating them produces a false sense of security in which whichever axis was ignored remains fully exposed.

A second confusion is with parsimony_occam_s_razor, since both counsel "less" and both feel like minimization principles. The distinction is in what is minimized and why. Occam's razor is an epistemic criterion for choosing among explanations: prefer the hypothesis with the fewest assumptions, because — all else equal — it is more likely true and easier to test. The rule of least power is a design criterion for choosing among mechanisms: prefer the least expressive one sufficient for the function, because lower expressiveness yields tighter provable upper bounds on behavior, hence better analyzability and safety. One ranges over theories and is justified by probable truth and falsifiability; the other ranges over artifacts and is justified by the guarantees that weakness buys. They can even pull apart: a more parsimonious explanation is not necessarily implemented in a less powerful mechanism, and a least-power mechanism may encode a baroque, assumption-heavy model. A reasoner who fuses them will apply truth-oriented arguments ("the simpler account is more likely correct") to a safety-oriented design choice, or apply behavior-bounding arguments to a question of explanatory adequacy, in each case importing the wrong justification.

A third worthwhile contrast is with minimalism. Minimalism reduces parts, features, or elements — for economy, clarity, or aesthetics — and a minimalist artifact is one with few moving pieces. The rule of least power is indifferent to part-count; it minimizes expressive power specifically, and a feature-rich artifact built entirely from declarative, bounded mechanisms satisfies the rule while a single, tiny, Turing-complete component violates it. The two can diverge sharply: a maximally minimal design (one small script) can carry maximal expressive power, and an elaborate, many-featured declarative system can carry minimal power. The cost the rule targets is the unbounded behavior that expressive capability admits, not the cognitive or visual load of many parts. A reasoner who confuses them will count features or lines and believe they have reduced power, when the relevant quantity — what the mechanism can do at its upper bound — may be untouched or even increased by a terse but powerful construct.

These distinctions matter because each neighbor, taken for the prime, leaves a specific gap. Confusing the rule of least power with least privilege leaves the authority axis unbounded (or the expressiveness axis, depending on which was minimized); confusing it with Occam's razor imports a truth-justification where a safety-justification is needed; and confusing it with minimalism counts parts where power is the quantity that matters. The rule's distinctive contribution — minimize expressive capability subject to function, because the behavior an artifact cannot exhibit is the measure of its safety and analyzability — is exactly what none of these neighbors supplies on its own.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.