Digital signature

one_liner: Bind a specific message to a specific private-key holder with a short string anyone can check against the public key, confining all remaining trust to one question — does this public key authentically belong to its claimed principal?

core_idea:
A digital signature is a cryptographic construction that binds a specific message to a specific private-key holder in a form any party with the matching public key can verify. The holder of a private key runs a signing algorithm over the message (typically over its cryptographic hash) and produces a short string — the signature — whose correctness can be checked by anyone with the public key, without that verifier needing access to the private key or to any shared secret. Three guarantees follow from the construction: authenticity (only the holder of the private key could have produced a valid signature for that message), integrity (any modification to the message after signing invalidates the signature, because the signature was computed over the original), and non-repudiation (the signer cannot plausibly deny having signed, since the signing operation requires the private key that only they hold).

The construction is concretely machinery-specific: it requires a public-key cryptosystem (RSA, ECDSA, Ed25519) paired with a collision-resistant hash function, and it presupposes a public-key infrastructure — some means by which the verifier can obtain the authentic public key of the claimed signer and trust that it belongs to them. Without the PKI layer, the signature's authenticity guarantee collapses: a signature that anyone verifies but no one can link to a specific real-world principal is not an identity guarantee. The real-world failure modes (DigiNotar 2011, the Symantec distrust events) are uniformly failures in the key-management and certificate-authority trust-anchor layer, not in the cryptographic primitive itself.

The construction is the operational foundation for distributed trust in networked systems: TLS certificate validation, code-signing pipelines, SSH host authentication, signed software updates, blockchain transaction authorization, and cryptographic protocol authentication all reduce to one or more digital-signature verifications. What distinguishes the cryptographic construction from the surrounding governance is the machine-checkable precision: the verification step is a deterministic algebraic check that any party can run independently, so the trust that must be established socially is narrowed to the single question of whether a given public key authentically belongs to its claimed principal.

scope_of_application:
The digital signature lives across cryptography, security, and distributed systems; its reach is within that domain — wherever public-key cryptography, a collision-resistant hash, and a public-key infrastructure are available, the *same* algebraic construction is reused literally. The pre-digital attestation cousins (wax seals, notary stamps, audit opinions) are co-instances of the parent `attestation`, not literal digital-signature habitats here, and the cryptographic machinery does not travel to them.

- **TLS and certificate validation** — a certificate authority signs each issued certificate, and the server signs a handshake message proving possession of the certified private key; the commercial Web rests on these two verifications.
- **Code signing and software updates** — signed binaries and update packages let any party verify authorship and integrity before execution.
- **SSH and host authentication** — host keys and key-based login bind a session to the holder of the private key.
- **Blockchain transaction authorization** — only the private-key holder can move funds, with each transaction a signature verification.
- **Consensus and authenticated protocols** — validator signatures in consensus protocols and authenticated messaging (Signal, certificate transparency) reduce to signature checks with identical semantics.
- **Digital legal instruments** — electronic signatures under eIDAS/ESIGN, digital identity documents, and signed timestamps, the governed application of the same primitive.

structural_signature:
**Sig role-phrases:**

- **the private key** — a secret unique to the principal, possession of which is the sole means of producing a valid signature
- **the public key** — the matching key any verifier uses to check a signature, requiring no shared secret and no access to the private key
- **the message and its hash** — the specific artifact bound, signed over its collision-resistant cryptographic hash so the signature is message-specific and non-replayable
- **the signing operation** — the algebraic computation (RSA, ECDSA, Ed25519) over the hash with the private key, yielding the short signature string
- **the deterministic verification check** — a machine-decided algebraic test any third party can run alone, settling correctness without social trust
- **the three guarantees** — authenticity (only the keyholder could produce it), integrity (any post-signing modification invalidates it), non-repudiation (the signer cannot disown it) — produced together but failing under different conditions
- **the trust anchor / PKI binding** — the residual socially-resolved question the construction confines trust to: does this public key authentically belong to its claimed principal?
- **the key-binding weak point** — the characteristic failure locus: real incidents (DigiNotar, Symantec distrust) are broken key-binding (breached CA, distrusted root, leaked key), not broken math

what_it_is_not:
- **Not encryption.** A digital signature provides authenticity, not secrecy. Signing reveals who produced a message and whether it was altered; it says nothing about who may read it, and the signed message is typically in the clear. Reaching for a signature to obtain confidentiality (or encryption to obtain authorship) is a category error — the two goals are orthogonal, and the construction speaks only to the second.
- **Not a scanned handwritten signature.** It is not an image of a signature pasted onto a document. A digital signature is a cryptographic computation over the message itself (typically its hash), so it is *message-specific* and *tamper-evident*: any change to the bytes invalidates it, and it cannot be lifted onto a different document. A static graphic of a handwritten mark has none of these properties and is not a digital signature.
- **Not where the cryptography is the weak point.** The verification step is a sound, deterministic algebraic check; the math is rarely what breaks. The characteristic failures — DigiNotar, the Symantec distrust — are broken *key-binding*: a breached certificate authority, a distrusted root, a leaked private key. Hardening the algorithm when the trust anchor is the weak point is effort spent where the problem is not.
- **Not self-sufficient for identity.** A signature that verifies cleanly but cannot be linked to a specific real-world principal is *not* an identity guarantee. The authenticity claim rests entirely on a public-key infrastructure that authentically binds the public key to its claimed owner; strip that PKI layer and "valid signature" tells you only that *some* holder of *some* key signed, not *who*.
- **Not the abstract attestation pattern.** The digital signature is the *cryptographic instance* — RSA/ECDSA/Ed25519 plus a collision-resistant hash plus PKI — of the broader attestation pattern that wax seals, notary stamps, and audit opinions also instantiate. The verifiable-mark *shape* travels; the cryptographic machinery does not. Calling a wax seal a "digital signature" borrows the shape while importing guarantees the seal cannot deliver "by the math."
- **Not a warrant for the message's truth or the signer's intent.** A signature binds a key-holder to a specific string of bytes; it certifies neither that the message's contents are true, nor that signing was authorized, nor that the signer understood or meant what they signed. It establishes authorship, integrity, and non-repudiation of the bytes — not the legitimacy, accuracy, or intent behind them.

clarity:
Naming the digital signature as its own construction separates two goals that share a toolchain and are therefore constantly conflated: *secrecy* and *authenticity*. Encryption hides a message's contents; a signature says nothing about who can read the message and everything about who produced it and whether it was altered. The two are orthogonal — one can sign without encrypting, encrypt without signing, or do both — and a practitioner who keeps them distinct stops reaching for the wrong primitive when the requirement is "prove this came from the claimed sender unmodified" rather than "keep this from prying eyes." The construction also makes the three guarantees nameable and separable in turn: authenticity, integrity, and non-repudiation are produced together but fail under different conditions, so an analyst can ask which one a given system actually needs and which one a given attack actually breaks.

The sharper clarity is about where the trust lives. Because verification is a deterministic algebraic check any party can run alone, the construction collapses what would otherwise be a sprawling social-trust problem down to a single residual question: *does this public key authentically belong to the principal it claims?* Everything else — that the signer held the key, that the message is unmodified, that the check is sound — is machine-decided. That isolation is what makes the public-key-infrastructure layer visible as the true weak point rather than the cryptographic primitive. A practitioner who has internalized the concept reads the canonical failures — a breached certificate authority, a distrusted root — not as broken math but as broken key-binding, and knows that the strength of any signature is bounded by the discipline that keeps the private key private and distributes the public key correctly. The question the concept licenses is no longer "is the algorithm secure?" but "is the trust anchor sound, and is the key management around it disciplined?"

manages_complexity: Building a system in which mutually distrustful parties must rely on each other's messages is, in the raw, an unbounded social-trust problem: for every artifact that crosses the wire, a participant would have to satisfy itself that the sender is who they claim, that the bytes were not altered en route, and that the sender cannot later disown what they sent — across TLS handshakes, code-signing pipelines, SSH logins, software updates, consensus votes, and blockchain transactions, each seemingly its own bespoke trust negotiation. The digital signature collapses that sprawl by making the verification step a deterministic algebraic check any party can run alone. Once that holds, the three guarantees — authenticity, integrity, non-repudiation — are produced together and decided by the machine, so the architect no longer reasons artifact-by-artifact about whether to believe a message; every one of those diverse protocols reduces to one or more signature verifications with identical semantics. What this buys analytically is a drastic narrowing of where trust must still be established by hand. Everything the signature settles — that the signer held the key, that the message is unmodified, that the check is sound — drops out of the analyst's attention, leaving a single residual scalar to track: *does this public key authentically belong to the principal it claims?* That one question is the whole remaining surface, and it is what makes the public-key-infrastructure layer — certificate authorities, trust anchors, key-management discipline — legible as the system's true weak point rather than the cryptographic primitive. The analyst reads the qualitative security of any signature-bearing system off the soundness of its key-binding, and the branch structure is correspondingly sharp: a failure is either broken math (rare, and a primitive-level concern) or broken key-binding (the common case — a breached CA, a distrusted root, a leaked private key). The canonical incidents — DigiNotar, the Symantec distrust — sort instantly into the second branch, and the design question stops being "is the algorithm secure?" and becomes the far smaller "is the trust anchor sound and the key management around it disciplined?" A whole edifice of distributed-trust complexity is thereby compressed to one verifiable check plus one socially-resolved binding question.

abstract_reasoning:
The digital signature licenses a set of security-reasoning moves that all turn on one structural fact: verification is a deterministic algebraic check decided by the machine, so trust is confined to a single residual binding question. The *boundary-drawing* move comes first and is the most distinctive. Facing a security requirement, an analyst asks whether the need is secrecy or authenticity, because the construction speaks only to the second: it tells who produced the message and whether it was altered, and says nothing about who may read it. That partition decides which primitive applies — sign when the requirement is "prove this came from the claimed sender, unmodified," encrypt when it is "keep this from prying eyes," do both when both — and reasoning across the boundary (reaching for a signature to obtain confidentiality, or encryption to obtain authorship) is diagnosable as a category error. The construction further partitions its own product: authenticity, integrity, and non-repudiation are produced together but fail under different conditions, so the analyst asks separately which guarantee a given system actually requires and which one a given attack actually breaks.

The *diagnostic* move runs from an observed failure back to its layer. Because the cryptographic check is machine-decided and sound, a valid-looking signature that nonetheless admits an impostor is reasoned back not to broken math but to broken key-binding: the verifier obtained or trusted a public key that did not authentically belong to the claimed principal. The reasoning sorts every incident into one of two branches — a primitive-level break (a broken hash, a forgeable scheme; rare) or a key-binding break (a breached certificate authority, a distrusted root, a leaked or mis-issued private key; the common case) — and the canonical failures sort instantly into the second. From a symptom (a connection trusted a forged server, an update ran with a valid-looking signature) the analyst infers the compromised element by elimination: the algebra held, so the fault is in the trust anchor or the key-management discipline around it, and the search narrows to the certificate-authority and revocation layer rather than the cipher.

The *interventionist* move reasons forward from where the residual trust lives to where hardening must go, and from the structure of the verification to what must hold for a guarantee to stand. Since the strength of any signature is bounded by the discipline that keeps the private key private and distributes the public key correctly, the predicted high-leverage interventions land on the public-key-infrastructure layer — sound trust anchors, disciplined key management, working certificate revocation — not on the algorithm, and effort spent strengthening a primitive that was never the weak point is predicted inert. The move also reasons from the construction's preconditions to its guarantees: because the signature is computed over the message (typically its hash), any post-signing modification is predicted to invalidate it, so an unaltered-and-valid pairing licenses the integrity inference; because signing requires the private key only the holder possesses, a valid signature licenses the authenticity and non-repudiation inferences — but each of those licenses is explicitly conditional on the binding question being answered, so the analyst withholds the identity guarantee for a signature that verifies cleanly yet cannot be linked to a specific real-world principal. The recurring verification habit the construction installs is to ask, of any signed artifact: does the algebra check, and does the public key it checks against authentically belong to the principal it claims — the first machine-decided, the second the whole remaining surface of trust.

knowledge_transfer:
Within cryptography, security, and distributed systems the construction transfers *as mechanism*, fully and literally, because the *same* algebraic object and the *same* analysis apply wherever public-key cryptography and a hash function are available. The secrecy-versus-authenticity boundary, the separation of the three guarantees (authenticity, integrity, non-repudiation) that are produced together but fail under different conditions, the diagnostic sort of every incident into broken-math (rare) versus broken-key-binding (the common case), and the interventionist conclusion that hardening belongs on the public-key-infrastructure layer rather than the cipher all carry intact across TLS certificate validation, code-signing pipelines, SSH host authentication, signed software updates, blockchain transaction authorization, consensus-validator signatures, and authenticated-protocol messaging (Signal, certificate transparency). Each of these reduces to one or more signature verifications with identical semantics, and the canonical failures (DigiNotar 2011, the Symantec distrust) sort instantly into the key-binding branch. Within this substrate the transfer is not analogy at all — it is the same construction reused.

Beyond settings that literally have public-key infrastructure, the cryptographic apparatus does **not** travel, and the honest report is **(B) shared abstract mechanism**: what recurs across domains is the *attestation* pattern that the digital signature is one implementation of — *a verifiable, principal-binding, tamper-evident mark applied to a message or artifact, checkable by a third party who need trust neither the signer nor a shared secret*. That pattern long predates and outranges the digital construct, recurring as genuine co-instances: wax seals, notary stamps, handwritten signatures, royal proclamations, peer-review sign-off, audit opinions, holographic marks, and blockchain inclusion proofs are all the same skeleton answered by different machinery. So the cross-domain lesson should be carried by the parent `attestation` (filed as an emergent candidate), of which the digital signature is the cryptographic instance — structurally parallel to how a Bloom filter is a specific machinery carrying a transferable underlying pattern. The *home-bound cargo* is everything cryptographic: the public-key cryptosystems (RSA, ECDSA, Ed25519), the collision-resistant hash, the modular-arithmetic verification, the PKI and certificate-authority trust anchors, and the key-management failure modes (compromised keys, CA breaches, algorithm deprecation, revocation). None of that survives extraction to a wax seal or a notary's stamp.

What *does* export cleanly, and is worth naming as the practically useful transfer, is a thin diagnostic layer riding on top of the attestation pattern: the three-guarantees *checklist* (can the bound principal be identified — authenticity; can tampering be detected — integrity; can the signer disown it — non-repudiation) and the operator *question* "can a third party verify this without trusting either signer or verifier?" These are substrate-independent diagnostics that sharpen analysis of any commitment or artifact — a wax seal, a notarized deed, a cited result, an audited statement — and they transfer literally as questions because they are properties of the attestation abstraction, not of the cipher. The boundary to mark is therefore between *exporting the attestation question* (legitimate, the right level of abstraction) and *importing the cryptographic guarantees by name* (a category error): a hologram or a notary does not give you non-repudiation "by the math," and calling a wax seal a "digital signature" is **(A) analogy** that borrows the verifiable-mark shape while dropping the PKI machinery that gives the digital construct its bite. When the lesson is wanted cross-domain, carry `attestation` and its three-guarantees checklist; the cryptographic construction is its networked-systems realization. See *Structural Core vs. Domain Accent* for why this profile places the entry as a domain-specific implementation of `attestation` rather than a prime.


Direct Manipulation

one_liner: Let a user control a system by physically acting on a continuously visible representation of the objects — dragging, resizing, pointing — with reversible actions and sub-100ms feedback, rather than issuing symbolic commands that name objects indirectly.

status: draft

core_idea:
Direct manipulation is a human-computer interaction paradigm, articulated by Ben Shneiderman in the early 1980s, in which the user controls a system by acting physically on a continuously visible representation of the objects of interest — dragging, resizing, pinching, pointing — rather than issuing symbolic commands that refer to those objects indirectly.

The paradigm is defined by four co-present properties: the objects and actions of interest are continuously represented in the display; actions are physical and incremental, operating on the visible representation rather than on a textual or command description of it; operations are rapidly reversible so that exploration is low-risk; and the effect of each action is immediately and perceptibly visible, closing the perception-action loop within the threshold at which users report feeling they are acting on the object itself rather than on a depiction of it (typically below ~100 ms for the sensation of directness). The contrast class is the command-and-symbolic-reference paradigm — issuing a command that names an object by identifier and specifies an operation abstractly, then waiting for a response — in which the user must maintain a mental model of the system's internal state without perceptual support. The transition from line-addressed text editors (ed, ex) to screen-based editors and then to GUI editors is the canonical case: symbolic-reference errors (misremembered line number, mistyped identifier) gave way to motor errors (wrong target, wrong direction), recovery shifted from mental-state reconstruction to undo, and the felt cognitive load of maintaining the system model dropped because the display continuously provided it. Shneiderman's original formulation identified spreadsheets, drawing programs, and file managers as the paradigm's key exemplars; it now extends to touch and gesture interfaces, data-visualization brushing-and-linking, flight simulators, and robotic teleoperation via haptic devices — all contexts in which a physical motion maps to a state change in a continuously rendered object.

scope_of_application:
Direct manipulation lives across the interaction-design subfields of HCI — every context where a physical motion maps to a state change in a continuously rendered object; its reach is co-extensive with representation-mediated interaction, the interface layer, not the substrates whose representations it manipulates. The general tight perception-action coupling (a pilot's stick, a cellist's bow, acting on the world directly rather than on a depiction) is carried by the feedback-loop and sensorimotor-control primes, and belongs to *Knowledge Transfer*.

- **Graphical user interfaces** — Shneiderman's original exemplars (spreadsheets, drawing programs, file managers) and the GUI as a class, the home of the paradigm.
- **Data visualization** — brushing-and-linking, lasso selection, and zoom-and-pan acting on the rendered data object.
- **Touch and gesture interfaces** — drag, pinch, and swipe on a continuously rendered object on mobile and tablet surfaces.
- **Training and flight simulators** — acting on a continuously rendered model with immediate feedback, including surgical and lab trainers.
- **Robotic teleoperation** — direct positional control via a haptic device representing the manipulator pose.
- **Augmented and virtual reality** — hand-tracked interaction with visualized objects, the loop extended into three dimensions.
- **Tangible and physical computing** — sliders, knobs, and control surfaces mapping a physical motion to a continuously displayed parameter.

structural_signature:
**Sig role-phrases:**

- **the continuously rendered object** — a persistent visible representation of the object of interest, supplying the system model so the user need not hold it in their head
- **the physical incremental action** — input that operates on the representation itself (drag, resize, pinch, point) rather than on a symbolic description of it
- **the rapid reversibility** — undo as a first-class affordance, making exploration low-risk
- **the sub-threshold feedback** — the effect of each action immediately and perceptibly visible, the perception-action loop closing within ~100 ms for the sensation of directness
- **the directness latency cliff** — the perceptual threshold gating felt directness: cross it and the experience flips from manipulating the object to operating a delayed depiction
- **the direct-vs-symbolic contrast** — the defining binary against command-and-symbolic-reference control (name the object, specify abstractly, wait)
- **the consequence package** — what the paradigm choice fixes: motor errors (wrong target/direction) versus symbolic-reference errors, recovery by undo versus state reconstruction, low versus high felt cognitive load
- **the partial-defection sensitivity** — weakening any one leg (a confirmation modal, drifting latency, hidden state) degrades the whole loop rather than being a local tweak

what_it_is_not:
- **Not merely "a GUI" or "point-and-click."** The paradigm is not defined by the input device or by having a graphical interface. It is the co-presence of four properties — continuous representation, physical incremental action on that representation, rapid reversibility, and sub-threshold feedback — so a mouse-driven interface that names objects symbolically and makes you wait is not direct manipulation, while a haptic teleoperation rig acting on a rendered pose is.
- **Not WYSIWYG.** Despite the family resemblance, direct manipulation is not the same as fidelity between an edit view and rendered output. WYSIWYG is a narrower claim about output matching; direct manipulation is more general — a CAD tool need not be WYSIWYG to be directly manipulated. What it requires is acting on a continuously rendered object, not that the rendering equals the final product.
- **Not a single feature to bolt on.** Direct manipulation is not one toggle added to an interface. It is a paradigm commitment that turns a cluster of downstream decisions into entailments — there must be undo, latency must stay under the directness threshold, feedback must be immediate — so weakening any one leg (a confirmation modal, drifting latency, hidden object state) is not a local tweak but a partial defection that degrades the whole loop.
- **Not a generic tight feedback loop.** The portable tight perception-action coupling — incremental input, immediate feedback below the directness window — is broader than this paradigm. Direct manipulation is its specifically *representation-mediated* instance: the user acts on a continuously rendered object standing in for the system state, with undo as recovery and a ~100 ms cliff tied to a depiction. A pilot's stick or a cellist's bow acts on the world directly, not on a representation, so it is the parent coupling, not direct manipulation.
- **Not a change to the upstream content.** The paradigm does not alter what the manipulated thing *is* or *means*. It governs only the interface layer — how a user acts on a representation — leaving untouched what a biologist sees about cells, what a roboticist computes about kinematics, or what the data themselves mean; its force is the accessibility of those things through their renderings, not the things.

clarity:
Naming direct manipulation gives a designer one handle for a control style that is otherwise discussed only through its scattered symptoms. The concept's force is that it bundles four properties — continuous representation, physical and incremental action on that representation, rapid reversibility, and feedback fast enough to feel direct — as a single co-present commitment rather than a checklist of separate choices. Once a system is understood to be in this paradigm, a cluster of downstream decisions stop being open questions and become entailments: there must be an undo, the latency budget must stay under the threshold for felt directness, feedback must be immediate and perceptible. The label lets the practitioner ask whether each leg of that loop actually holds, and to recognize that weakening any one of them — adding a confirmation modal, letting latency drift, hiding the object's state — is not a local tweak but a partial defection from the paradigm.

The concept's sharper work is to make the contrast with command-and-symbolic-reference control explicit, and that contrast reorganizes how a designer reasons about cognition and error. The crisp binary is "act on the thing itself" versus "issue a description that names the object and wait" — and it predicts where a user will form a fluent mental model directly from the display versus where they must maintain the system's state in their head through an intervening symbolic layer. Naming the paradigm also reclassifies the failure profile it produces: the errors shift from symbolic-reference mistakes (a misremembered identifier, a wrong line number) to motor mistakes (wrong target, wrong direction), recovery shifts from reconstructing unseen state to pressing undo, and the felt cognitive load drops because the continuously rendered object now supplies the model the user would otherwise have to carry. What looked like an undifferentiated "it's easier to use" becomes a specific, structural account of *why* — and a set of variables a designer can deliberately tune.

manages_complexity: An interface presents a designer with a long, seemingly independent list of decisions — how to render state, how to map input to changes, whether and how to support undo, what latency to budget, how granular the feedback should be, how errors get recovered, how much of the system's state the user must hold in their head — and a correspondingly diffuse evaluative question, "why is one design easier to use than another, and how will it fail?" Direct manipulation compresses both. It bundles four co-present properties — continuous representation of the objects of interest, physical and incremental action on that representation, rapid reversibility, and feedback fast enough (below roughly 100 ms) to feel direct — into a single paradigm commitment, so that once a system is placed in the paradigm, the scattered downstream decisions stop being open and become entailments: there must be an undo, the latency budget must stay under the directness threshold, feedback must be immediate and perceptible. The designer therefore tracks four loop-legs rather than dozens of independent choices, and reads off the consequences — and recognizes that weakening any one leg (a confirmation modal, drifting latency, hidden object state) is not a local tweak but a partial defection from the paradigm. The second compression is the contrast itself: the whole tangle of cognition-and-error questions reduces to one binary — act on the thing itself versus issue a description that names the object and wait — from which the qualitative outcome reads directly. That single switch predicts the error profile (motor mistakes such as wrong target or wrong direction on the direct branch, symbolic-reference mistakes such as a misremembered identifier or line number on the command branch), the recovery mode (press undo versus reconstruct unseen state), and the felt cognitive load (low, because the rendered object supplies the system model, versus high, because the user must carry that model through an intervening symbolic layer). What had been an undifferentiated "it's easier to use" collapses to a low-dimensional reading off one paradigm choice and four loop-legs, and the branch structure is exactly that paradigm binary — direct versus symbolic — with each side fixing a known package of cognition, error, and recovery characteristics the designer can anticipate instead of re-deriving for each interface.

abstract_reasoning:
Direct manipulation licenses an interaction-design reasoning kit organized around one paradigm binary and a four-legged perception-action loop.

*Classification → prediction — place a UI on the direct-versus-symbolic branch and read off its consequence package.* The signature move reasons FROM whether the user acts on the thing itself or issues a description that names the object and waits TO a known package of cognition, error, and recovery characteristics. On the direct branch, predict motor errors (wrong target, wrong direction), recovery by undo, and low felt cognitive load because the continuously rendered object supplies the system model. On the command branch, predict symbolic-reference errors (a misremembered identifier, a wrong line number), recovery by reconstructing unseen state, and high cognitive load because the user must carry the model through an intervening symbolic layer. The single paradigm choice thus forecasts where a user will form a fluent mental model directly from the display versus where they must hold the system's state in their head — turning an undifferentiated "it's easier to use" into a specific structural account of why and how it will fail.

*Diagnostic — check whether each leg of the loop holds.* Because the paradigm bundles four co-present properties — continuous representation, physical and incremental action on that representation, rapid reversibility, and feedback fast enough to feel direct — the move interrogates a candidate UI leg by leg: is the object's state continuously rendered, do actions operate on the representation rather than a description, are operations rapidly reversible, is feedback immediate and perceptible? Reasoning runs FROM a failing leg TO the specific way the sensation of directness will break, localizing the defect to one component of the loop rather than to the interface as a whole.

*Diagnostic — read a weakened leg as a partial defection from the paradigm.* Once a system is understood to be in the paradigm, a cluster of downstream decisions become entailments rather than open choices — there must be an undo, the latency budget must stay under the directness threshold, feedback must be immediate. The move reasons FROM a change that weakens one leg (adding a confirmation modal, letting latency drift, hiding the object's state) TO the conclusion that it is not a local tweak but a partial defection that degrades the whole loop. The designer evaluates a proposed modification by which entailment it violates and what felt-directness cost that carries.

*Predictive — forecast felt directness from the latency threshold.* The move treats directness as gated by a perceptual threshold: reason FROM the perceived latency between action and visible effect TO whether the user will report acting on the object itself or on a depiction of it, with the sensation of directness holding only when the perception-action loop closes within roughly 100 ms. Latency is thus a tunable design variable with a predictable qualitative cliff — cross the threshold and the experience flips from manipulating the object to operating a delayed representation of it.

knowledge_transfer:
Within human-computer interaction and interaction design, direct manipulation transfers *as mechanism*, intact, across the contexts where a physical motion maps to a state change in a continuously rendered object. The four-leg loop (continuous representation, physical incremental action on it, rapid reversibility, sub-threshold feedback), the direct-versus-symbolic classification with its consequence package (error profile, recovery mode, cognitive load), the latency cliff, and the partial-defection diagnostic all carry without translation from Shneiderman's original exemplars (spreadsheets, drawing programs, file managers) to data-visualization brushing-and-linking, to touch and gesture interfaces, to training and flight simulators, to robotic teleoperation via haptic devices, and to AR/VR hand-tracked interaction. Only the input device and the rendered object change; the loop and its design variables (latency budget, feedback granularity, reversibility, the visible-object metaphor) are the same. This is the home domain, and it is broad — but the breadth is of *applications*, not of substrates: in every case what direct manipulation governs is the *interface layer*.

That last point is the crux of an honest transfer account. The cross-domain extensions — education simulations, robotics, data visualization — are genuine reuses of the mechanism, but they reuse it precisely *as* an HCI mechanism: the directness is about how a user acts on a representation, while the upstream content is untouched. Direct manipulation does not change what a biologist sees about cells, what a roboticist computes about manipulation kinematics, or what the data themselves mean; it changes only how those things are interacted with through their renderings. So the paradigm "travels" into a robotics or science application without becoming a structural fact *about* robotics or science — its force stays in the interface layer wherever it goes. This is why it remains a domain-specific (HCI) abstraction rather than a substrate-spanning prime: its reach is co-extensive with representation-mediated interaction, not with the substrates whose representations it manipulates.

What genuinely recurs beyond the interface layer is the more general pattern direct manipulation instantiates, and the cross-domain lesson should ride that parent. Strip the visible-object representation and what remains is a *tight perception-action coupling* — a loop in which an actor's incremental input produces immediate perceptible feedback below the threshold for felt directness — and that recurs far outside interfaces: in flight control, athletic skill, and musical performance, where a performer acts and the world responds within the loop-closure window. That general coupling is carried by the catalogue's tight-feedback-loop and sensorimotor-control patterns, and it is *they*, not "direct manipulation," that should carry the insight into those domains; direct manipulation is the specifically *representation-mediated* interface instance of it. Its own home-bound cargo is exactly that mediation — the continuously rendered object standing in for the system state, the GUI/visual metaphor, undo as the recovery affordance, the ~100 ms directness threshold tied to a depiction — none of which a pilot's stick or a cellist's bow requires, because those act on the world directly rather than on a representation of it. The general tight-perception-action-coupling pattern travels via the feedback-loop and sensorimotor primes; the representation-mediated paradigm, with its visible-object loop and latency cliff, stays in interaction design, the boundary *Structural Core vs. Domain Accent* makes precise below.


Discourse

slug: discourse

one_liner: Treat a topic's talk as a regime — a vocabulary, roster of recognised speakers, admissibility rules, and precedent history — that governs which utterances are sayable, hearable, and consequential, rather than as the sum of what was said.

core_idea: Discourse is the structured, historically accumulating exchange through which a community of speakers and writers produces, contests, and stabilises shared meaning around a topic — not the sum of individual utterances but the regime that governs which utterances are possible, credible, and consequential. The structural commitment is that meaning is generated *intersubjectively over time*: a given utterance acquires its force from the surrounding history of prior moves, the institutional venues that license it, and the responses it opens or forecloses for other participants. The pattern has four components: a *topic-defining vocabulary* (the terms in play and what they index), a set of *recognised speakers or subject-positions* with standing to contribute, *rules of admissibility* that determine what counts as a relevant claim, valid evidence, or appropriate response, and a *precedent history* of prior moves against which each new utterance is read. Changes to any of the four alter what utterances mean without changing the utterances themselves — the same claim made in a different venue, by a speaker lacking recognised standing, or in a period when the admissibility rules have shifted can mean something entirely different, go unheard, or be actively disqualifying. Linguistics and discourse analysis use the concept to study cohesion, coherence, and turn-taking at the text level; sociology (following Foucault and Habermas) uses it to analyse how institutionalised regimes of knowledge — medical discourse, legal discourse, scientific discourse — govern who can speak as expert, which questions are askable, and which explanations count as real. The chronic-pain case illustrates the mechanism: over several decades, the medical discourse around pain shifted as patient-advocacy movements, biopsychosocial models, and new methodologies changed all four components simultaneously — new speakers (patients, social scientists) gained standing, new evidence types (qualitative reports, functional neuroimaging) became admissible, the vocabulary added concepts like central sensitisation, and the accumulated precedent history normalised non-lesion explanations — so that the same patient utterance ("my pain is real and constant") reads differently in the post-shift discourse than it did before.

scope_of_application:
Discourse lives across the human-communication subfields concerned with institutionally-venued, intersubjective meaning-making — the regime exists wherever there are recognised speakers and rules of admissibility, and the four-component grid applies literally across arenas of human talk. Off that substrate ("a discourse of cells, of code") there is only anthropomorphising metaphor, carried by the parent primes (`convention`, `gatekeeping`, `framing`, `legitimacy`, `regime`), not by discourse itself — so it stays off this map.

- **Linguistics and discourse analysis** — the text-level study of cohesion, coherence, and turn-taking, treating connected talk as structured beyond the individual sentence.
- **Sociology of knowledge (Foucauldian / Habermasian)** — how institutionalised regimes such as medical, legal, and scientific discourse govern who can speak as expert, which questions are askable, and which explanations count as real.
- **Clinical and health communication** — arenas like the chronic-pain case, where shifts in vocabulary, admissible evidence, recognised speakers, and precedent change what a patient's utterance means over time.
- **Legal and courtroom settings** — the venue's admissibility rules and recognised standing determining which claims and evidence carry force.
- **Scholarly peer review and research journals** — the regime fixing what counts as a credible contribution, valid method, and citable precedent in a field.
- **Policy debate and public deliberation** — arenas (hearings, online forums, hashtag publics) where the four components govern what is sayable, hearable, and consequential about a topic.

structural_signature:
**Sig role-phrases:**

- **the institutional venue** — the setting that hosts the exchange and confers standing (clinic, courtroom, peer-review system, policy arena)
- **the topic-defining vocabulary** — the terms in play and what they index, fixing what the discourse is about
- **the recognised speakers (subject-positions)** — the roster of participants with standing to make admissible moves
- **the rules of admissibility** — what counts as a relevant claim, valid evidence, or appropriate response
- **the precedent history** — the accumulated prior moves that constrain current moves and supply the interpretive context each utterance is read against
- **the intersubjective-over-time commitment** — the load-bearing claim that meaning is generated by the regime across history, not encoded statically by a sender
- **the regime-governs-force property** — the whole determining what is sayable, hearable, and consequential, so the same words carry different force under a different regime
- **the four-dial meaning-change mechanic** — a shift in what an utterance means decomposed into which component moved (new speakers, newly admissible evidence, an added term, accumulated precedent), without the words changing
- **the regime-level power** — control exercised by setting vocabulary, speaker-roster, and admissibility rather than by dictating any individual utterance

what_it_is_not:
- **Not the sum of individual utterances.** Discourse is the *regime* that governs which utterances are possible, credible, and consequential — the vocabulary, the recognised speakers, the admissibility rules, the precedent history — not a collection of the things people said. The same words carry different force, or none, under a different regime, which is exactly what an utterance-tally cannot capture.
- **Not sender-encoded meaning.** Meaning is generated *intersubjectively over time*, not packed into an utterance by a speaker and unpacked by a listener. An utterance's force comes from the surrounding regime that reads it, so the well-posed question is "against which vocabulary, speakers, admissibility rules, and precedent is this read?" — not "what did the sender encode?"
- **Not narrative.** A narrative is a particular ordered story; discourse is the *regime under which narratives become tellable and credible*. Stories are moves within a discourse, not the discourse itself, which sets what kinds of story can be told and believed.
- **Not rhetoric.** Rhetoric is the craft of persuasion *within* a regime; discourse is the regime itself. One is a skill a speaker deploys to move an audience; the other is the structure that determines what counts as a credible speaker or relevant evidence in the first place.
- **Not language or culture.** Discourse is *meso-scale*: larger than any single utterance, smaller and more venue-specific than the whole symbolic medium (language) or the broad pattern of practice (culture). It is the regime governing talk about a topic in a setting, not the medium it is conducted in nor the entire way of life around it.
- **Not a substrate-general structure.** The concept presupposes language, institutional venues, recognised speakers, and intersubjective meaning-making over time, so a "discourse of cells" or "discourse of code" is metaphor that anthropomorphises. What genuinely travels off the human substrate is the parent machinery — convention, gatekeeping, framing, legitimacy, regime — not "discourse" with its contestation-by-speakers-with-standing.

clarity:
Naming discourse separates three things that an utterance-by-utterance view runs together: *what was said*, *what could be said*, and *what a saying does in this venue*. Without the concept, an analyst confronting a body of talk has only the utterances themselves, and is pushed toward explaining meaning as something each speaker encodes and each listener decodes. Discourse relocates the explanatory weight to the regime that governs the talk, so the sharp question becomes not "what does this utterance mean?" but *against which vocabulary, which recognised speakers, which admissibility rules, and which precedent history is it being read?* That question has purchase the utterance-level one lacks, because it explains how the very same words can carry different force — or none — when the surrounding regime differs, and it gives an unfamiliar arena (a clinic, a courtroom, a peer-review system) a small set of structural handles rather than an uncatalogued stream of moves.

The concept makes two further confusions tractable. It dissolves the puzzle of why an argument that "wins on the merits" in one setting gains no traction in another: the settings run different admissibility rules, so what counts as relevant evidence or a credible speaker is not shared, and merit is itself regime-relative rather than venue-neutral. And it makes a form of power legible that operates without anyone overtly controlling what is said — by setting the vocabulary, the roster of speakers with standing, and the rules of admissibility, a party constrains *what is sayable and hearable* while leaving each individual utterance free. The chronic-pain shift shows the payoff precisely: because the four components can be tracked, a change in what a patient's "my pain is real and constant" *means* is explained not as the words changing but as new speakers gaining standing, new evidence becoming admissible, and the precedent history accumulating — a structural account of meaning-change that a static, sender-encodes view cannot give.

manages_complexity:
An arena of talk — a clinic, a courtroom, a peer-review system, a policy debate — presents the analyst with an unbounded stream of individual utterances, each potentially meaning something different depending on who said it, where, when, and against what history. Cataloguing that stream utterance by utterance is hopeless: the moves are too many, and their force is not in the words but in everything around them. Discourse compresses the arena by replacing the utterance stream with four structural parameters — the topic-defining vocabulary, the roster of recognised speakers (subject-positions with standing), the rules of admissibility, and the precedent history. Characterising those four *is* characterising the regime, and from them the analyst reads off what any given utterance can mean, who can make it count, and what it forecloses, without re-deriving each move from scratch. An unfamiliar arena becomes four questions rather than a transcript.

The compression is what makes a whole class of otherwise-intractable questions answerable. Meaning-change over time, instead of demanding a fresh interpretation of every utterance in every period, collapses to tracking which of the four components shifted: the chronic-pain case becomes legible precisely because "my pain is real and constant" reading differently than it did decades earlier decomposes into new speakers gaining standing, new evidence becoming admissible, the vocabulary acquiring central sensitisation, and the precedent history accumulating non-lesion cases — four tracked dials rather than an unanalysable shift in what words mean. The branch structure carries the rest. Why an argument that "wins on the merits" gains no traction across a venue boundary routes to a single check — do the two arenas share admissibility rules? — so merit is read as regime-relative rather than venue-neutral. How power can operate without anyone overtly controlling speech routes to the same four parameters: set the vocabulary, the recognised-speaker list, and the admissibility rules, and you constrain what is sayable and hearable while leaving each utterance free. What would be an uncatalogued sprawl of moves and meanings reduces to four structural handles, from which an utterance's force, a meaning-shift's mechanism, a cross-venue failure, and a form of constraint all read off.

abstract_reasoning:
The concept's foundational move *relocates the meaning question* from the utterance to the regime. Rather than asking "what does this utterance mean?", the analyst asks *against which vocabulary, which recognised speakers, which admissibility rules, and which precedent history is it being read?* — reasoning from the four components of the surrounding regime to the force a given saying carries. This explains, by inference rather than stipulation, how the *same words* can carry different force or none: hold the utterance fixed and vary the venue, the speaker's standing, the admissibility rules, or the accumulated precedent, and the meaning moves. The controlled comparison that licenses the inference is exactly that invariance of the words against variation of the regime, which is why a sender-encodes/listener-decodes account cannot reproduce it.

That re-posing grounds a *diagnostic* move on meaning-change over time: a shift in what an utterance means is decomposed into *which of the four components shifted*. The reasoning runs from an observed change in force to the responsible component(s) — new speakers gaining standing, new evidence types becoming admissible, the vocabulary acquiring a term, or the precedent history accumulating cases — so that "my pain is real and constant" reading differently across decades is inferred to result from patients and social scientists gaining standing, qualitative reports and functional imaging becoming admissible, the vocabulary adding central sensitisation, and non-lesion cases normalising, rather than from the words changing. The same structure runs *predictively forward*: deliberately change one component and predict the downstream effect on what is sayable and hearable. The *interventionist* corollary is direct — expand the recognised-speaker roster, alter the admissibility rules, or introduce a topic-defining term, and predict that prior utterances acquire new force or lose it; this is the lever through which a regime is reshaped without authoring any individual utterance.

A *cross-venue* move predicts traction failure across an arena boundary. Facing an argument that "wins on the merits" in one setting yet gains no purchase in another, the analyst routes to a single check — *do the two arenas share admissibility rules?* — and infers that where they do not, what counts as relevant evidence or a credible speaker is not shared, so merit is regime-relative rather than venue-neutral and the argument's failure is structural, not a deficiency of the argument. Finally, a *power-legibility* move makes a form of control inferable that no one exercises by overtly dictating speech: by setting the vocabulary, the roster of speakers with standing, and the rules of admissibility, a party constrains what is *sayable and hearable* while leaving each individual utterance free — so from a pattern of what reliably goes unheard or is disqualified, the analyst infers a constraint operating at the regime level rather than censorship at the utterance level. A *boundary* move keeps these inferences inside their substrate: they presuppose language, institutional venues, and intersubjective meaning-making over time, so the four-component analysis applies to arenas of human talk — clinics, courtrooms, peer-review systems, policy debates — and is not transported to systems lacking recognised speakers and admissibility rules, where the regime the concept names does not exist.

knowledge_transfer:
Within the human-communication domain the concept transfers *as mechanism*, and its four-component decomposition (topic-defining vocabulary, recognised speakers, rules of admissibility, precedent history) functions as a portable diagnostic that applies literally across arenas of talk of every scale: a clinic, a courtroom, a peer-review system, a Senate hearing, a Reddit subforum, a research journal, a policy debate. In each, the same four questions characterise the regime, and the same inferences carry — relocating an utterance's force to the regime that reads it, decomposing a meaning-shift over time into which of the four components moved (the chronic-pain case), predicting traction failure across a venue boundary from a mismatch in admissibility rules, reading regime-level power off what reliably goes unheard, and intervening by changing one component (expand the recognised-speaker roster, alter the admissibility rules, introduce a topic-defining term) to predict that prior utterances acquire or lose force. This is wide substrate-spanning reach, but it is reach *within* the domain of human, institutionally-venued, intersubjective meaning-making; the regime the concept names exists wherever there are recognised speakers and rules of admissibility, and the four-part analysis applies throughout.

Beyond that domain the boundary is sharp and the honest verdict is largely *metaphor*. The structural commitments are irreducibly humanities-coded — they presuppose language, institutional venues, and meaning generated intersubjectively over time — so there is no useful "discourse of cells" or "discourse of code" except by analogy that anthropomorphises. Transposing the term to a non-human system borrows the regime-governs-meaning shape while dropping recognised speakers, admissibility rules, and a precedent history of contested moves, which is precisely what gives the concept its force. Where something genuinely *does* travel cross-substrate, it is not "discourse" but the more general primes the concept composes, which operate at a level that does not require human speakers: the regularity-by-agreement pattern is `convention`, the standing-to-be-heard-and-permission-to-pass pattern is `gatekeeping`, the standard-of-recognised-authority pattern is `legitimacy`, the salience-and-construal pattern is `frame`/`framing`, and the governing-set-of-allowed-states pattern is `regime`. Those carry the substrate-independent structural work. So the disciplined statement is double: the four-component audit is a real, transferable instrument *within* human discursive arenas, and its over-reach boundary is the move to non-human substrates, where only the convention/gatekeeping/framing/legitimacy parents travel and "discourse" itself adds humanities-specific content — the contestation of meaning by speakers with standing under institutional admissibility rules — that is load-bearing precisely because it does *not* generalize. (See *Structural Core vs. Domain Accent*.)


Discoverability

slug: discoverability

one_liner: Measure the degree to which a system's actions and features can be located through perception and exploration alone — a property of the artifact, not the user — separating capability from findable capability and locating unfound features as a design defect.

core_idea:
Discoverability is a property of a system — not of its users — measuring the degree to which the system's available actions, features, or content can be located by a prospective user through perception and exploratory interaction alone, without requiring prior instruction, external documentation, or insider knowledge.

The structural commitment is to distinguish capability from findable capability: a system may support a hundred actions while a typical user encounters twelve, not because the others are absent but because the substrate's cues, labels, hierarchy, and search surfaces do not guide exploratory navigation toward them. The possibility space of a system and the portion of that space reachable under bounded exploratory search are two different quantities, and discoverability is a measure of the ratio between them, weighted by user-goal frequency. In HCI, Donald Norman's signifier framework describes the local mechanism: signifiers are perceptible cues that communicate where and how an action is available; discoverability is the system-level emergent property produced by the cumulative effect of signifiers, information hierarchy, naming discipline, empty-state guidance, hover/preview states, and in-app search. A discoverability defect exists when a feature that functions correctly and is frequently desired by users is nonetheless rarely found because the cues that would lead a user to it are absent, misleading, or buried behind low-salience navigation. The diagnostic is: subtract the set of features users successfully locate through exploration from the set of features that exist; the remainder, weighted by user-goal frequency, measures the discoverability debt. In software API design the same structure applies with different signifiers: predictable naming conventions, type signatures as inline documentation, autocomplete-friendly surface, and README prominence determine whether a function is discovered through exploration of the API itself or only through reading external documentation.

scope_of_application:
Discoverability lives across the interface- and information-design subfields that share a cue-substrate plus a goal-driven user search; its reach is within that one cues-plus-search structure, lightly re-skinned per substrate. The deeper navigability-of-a-possibility-space-under-bounded-search pattern is carried by a composition of `search` + `navigation` + `affordance` + `signifier` + `information_scent` (or a unifying navigability prime), and the cross-domain lesson rides those, so it belongs to *Knowledge Transfer*.

- **Human-computer interaction** — the home turf, Norman's signifier/affordance framing operationalized as menus, hover states, empty-state guidance, and onboarding surfaces.
- **Library and information science** — findability of documents through cataloguing, classification, signage, and search affordances.
- **Architecture and wayfinding** — building entry sequences, sightlines to elevators, and signage hierarchy that lead a goal-driven visitor through physical space.
- **Software API design** — predictable naming, type signatures as inline documentation, autocomplete-friendly surface, and README prominence determining whether a function is found by exploring the API or only by reading external docs.
- **Onboarding and education** — making the space of available next actions perceptible to a new participant through tours and progressive disclosure.
- **Game design** — environmental cues that telegraph available interactions versus deliberately hidden secrets.

structural_signature:
**Sig role-phrases:**

- **the possibility space** — the full set of actions, features, or content a system supports in principle (its capability)
- **the goal-driven user** — a prospective user with a goal but incomplete knowledge, performing an implicit search over the system
- **the cue substrate** — the signifiers, labels, information hierarchy, naming, empty-state guidance, hover/preview states, and in-app search that impose a cost-of-search
- **the bounded exploratory reach** — the portion of the possibility space actually locatable through perception and exploration alone, without instruction or insider knowledge
- **the capability-vs-findable fork** — the load-bearing distinction the construct names: a wanted-but-unused feature is either absent (capability defect, build it) or present-but-unsurfaced (discoverability defect, surface it)
- **the system-as-encountered framing** — locating the defect in the artifact rather than the audience, refusing the "didn't look hard enough" reading
- **the goal-weighted discoverability debt** — the metric: capability inventory minus encountered inventory, weighted by goal frequency, with which the qualitative outcome is read off
- **the cost-of-search lever** — the intervention: change the substrate (top-level placement, indexing, goal-based labels) to shorten and bias the user's search toward high-value targets

what_it_is_not:
- **Not a property of the user.** Discoverability is not about whether a person looked hard enough, read the docs, or got enough training. It is a property of the *system as encountered* — whether the cues, labels, hierarchy, and search surfaces lead exploratory navigation to a feature that exists and is wanted — so an unfound capability is a defect in the artifact, not a deficiency in the audience.
- **Not the same as capability.** That a system *supports* an action does not make it discoverable. The load-bearing cut is capability versus findable capability: a system can support a hundred actions while a typical user ever encounters twelve. "The feature does not exist" and "the feature exists but is invisible to the users who want it" are different diagnoses with opposite remedies — build it versus surface it.
- **Not learnability.** Discoverability is not how quickly a user becomes proficient once they know a feature is there. The two often co-occur but come apart: an action found only via help text or a tutorial can be learned without ever having been *discovered* through perception and exploration. Discoverability concerns being *found* under bounded exploratory search; learnability concerns mastery after the fact.
- **Not searchability alone.** In-app search is one mechanism of discoverability, not its whole. Search presupposes the user can already articulate a query for what they want; discoverability also covers the user who does not yet know the feature exists and must be led to it by signifiers, hierarchy, and empty-state cues encountered through exploration, not by typing a term.
- **Not findability of content only.** This is not merely the information-science property of locating documents. Discoverability extends the same cues-plus-search structure to *actions* and *features* — whether the system's available moves announce themselves — not just to retrievable content, which is why its toolkit includes empty-state guidance, hover/preview states, and goal-based labeling, not only catalogue and search.

clarity:
Naming discoverability relocates a failure that is otherwise pinned on the user. When a feature works but goes unused, the default readings blame the person — they didn't look hard enough, they should have read the documentation, they need more training. Defining discoverability as a property of the *system as encountered*, not of its users, moves the defect to where it can be fixed: the cues, labels, hierarchy, and search surfaces failed to lead exploratory navigation toward a feature that exists and is wanted. That reframing is what licenses the designer to treat unfound capability as a defect in the artifact rather than a deficiency in the audience.

The concept's central clarifying cut is between *capability* and *findable capability*. A system can support a hundred actions while a typical user ever encounters twelve, and naming discoverability separates the two diagnoses that this collapses: "the feature does not exist" and "the feature exists but is invisible to the users who want it" are different problems with different fixes — build it, versus surface it. The concept also turns a vague unease into a measurable quantity. By framing the situation as a possibility space versus the portion of it reachable under bounded exploratory search, weighted by how often users actually want each part, it yields a concrete diagnostic: subtract the set of features users locate through exploration from the set that exists, weight the remainder by goal frequency, and read off the discoverability debt. That gives the practitioner a sharper question than "is this usable?" — namely, which high-frequency targets are not being reached under realistic exploration, and which absent or misleading signifiers are responsible.

manages_complexity: A system's findability is, attacked directly, a sprawl: dozens of independent design surfaces — signifiers, labels, information hierarchy, naming conventions, empty-state guidance, hover and preview states, in-app search, README prominence — each contribute to whether any given feature gets found, and when a working feature goes unused the explanations proliferate and tend to blame the user (didn't look hard enough, should have read the docs, needs training). Discoverability compresses that sprawl into a single system-level quantity: the portion of a system's possibility space reachable under bounded exploratory search, taken as a ratio against the full capability and weighted by how often users actually want each part. The whole heterogeneous toolkit of design moves collapses under one criterion — can a user locate the action through perception and exploration alone, without instruction or insider knowledge? — so the designer no longer reasons about each surface in isolation but tracks one measurable diagnostic and reads the qualitative outcome off it: subtract the set of features users locate through exploration from the set that exists, weight the remainder by goal frequency, and the discoverability debt falls out, along with which absent or misleading signifiers are responsible. The move is from a high-dimensional "is this usable, and why is this feature unused?" to a low-dimensional reading of one goal-weighted findability ratio. The branch structure the construct makes legible is the capability-versus-findable-capability fork that the question "the feature works but isn't used" otherwise hides: either the feature does not exist (a capability defect, fixed by building it) or it exists but the cues fail to lead wanting users to it (a discoverability defect, fixed by surfacing it) — two diagnoses with opposite remedies that the bare observation conflates, and that the construct separates by locating the defect in the system as encountered rather than in the audience. The same compression carries to API design with the substrate's own signifiers — predictable naming, type signatures as inline documentation, autocomplete-friendly surface, README prominence — where the identical ratio (functions found by exploring the API itself versus only by reading external docs) is what the designer tracks and reads the debt off.

abstract_reasoning:
Discoverability licenses a design-reasoning kit that treats findability as a measurable, system-level property and locates unfound capability as a defect in the artifact rather than the audience.

*Diagnostic — fork an unused-but-working feature into build versus surface.* The signature inference runs FROM the observation "the feature works but is rarely used" TO one of two opposite diagnoses: a capability defect (the feature does not exist, or not for this case) versus a discoverability defect (it exists but the cues fail to lead wanting users to it). The move resists the default reading that blames the person — didn't look hard enough, should have read the docs — by relocating the defect to the system as encountered, and it selects the remedy from the branch: build it, versus surface it. Distinguishing capability from findable capability is what keeps the designer from fixing the wrong problem.

*Measurement — compute the goal-weighted discoverability debt.* The move turns a vague unease into a quantity. Reason FROM the gap between the set of features that exist and the set users actually locate through bounded exploratory search, weighted by how often users want each part, TO the discoverability debt. Concretely: subtract encountered inventory from capability inventory, weight the remainder by goal frequency, and read the debt off the result. This yields a sharper question than "is this usable?" — namely which high-frequency targets are not being reached under realistic exploration — and makes findability a single ratio the designer can track rather than dozens of surfaces reasoned about in isolation.

*Diagnostic — attribute the debt to specific failing signifiers.* Having localized a discoverability defect, the move traces it to the local mechanisms responsible: which signifiers, labels, hierarchy levels, empty-state guidance, hover or preview states, or search surfaces are absent, misleading, or buried behind low-salience navigation. Reason FROM a high-frequency target that goes unreached TO the missing or misleading cue on the path a goal-driven user would actually take — for example, users searching for one goal term never encountering the menu labeled by internal structure instead of user goal. The system-level property is thus decomposed back into the cumulative signifier failures that produced it.

*Interventionist — change the substrate to lower search cost toward high-value targets.* The corrective move reasons over the implicit search graph the user performs — its branching factor, the depth to common targets, recoverability from wrong turns — and predicts the effect of substrate changes on it. Reason FROM surfacing a frequent action (top-level placement, indexing it in in-app search, mentioning it in the relevant empty state, labeling by user goal rather than internal structure) TO a shorter, better-biased search that reaches the target under exploration alone. The intervention is selected to cut the cost-of-search for the high-value items the debt identified, and its predicted payoff is the reduction of that goal-weighted debt — with the identical reasoning carrying to API design via its own signifiers (predictable naming, type signatures as inline documentation, autocomplete-friendly surface, README prominence) where the same ratio of found-by-exploration versus found-only-in-docs is the target.

knowledge_transfer:
Within interface and information design, discoverability transfers *as mechanism*, intact, across the domains that share its structure of a cue-substrate plus a goal-driven user search. The capability-versus-findable-capability fork, the goal-weighted debt computation (capability inventory minus encountered inventory, weighted by goal frequency), the attribution to specific failing signifiers, and the lower-the-cost-of-search intervention all carry without translation from GUI menus and onboarding surfaces to library and information science (findability of documents via cataloguing, classification, signage, search affordances), to architecture and wayfinding (entry sequences, sightlines to elevators, signage hierarchy), to software API design (predictable naming, type signatures as inline documentation, autocomplete-friendly surface, README prominence), and to game design (environmental cues that telegraph available interactions). Only the signifiers change — signage and mentor introductions in wayfinding and onboarding, type signatures and naming in APIs — while the diagnostic and the remedy stay the same. This is the home domain, and it is broad, but the breadth is of *substrates lightly re-skinned*: every case is the same cues-plus-search structure, which is why discoverability is a domain-specific (interface/information-design) abstraction rather than a substrate-spanning prime.

The honest characterization of that breadth (case B) is that the cross-domain extensions are genuine co-instances, not metaphors, but they instantiate a structure more general than "discoverability," and the cross-domain lesson should be carried by that general structure. The deeper pattern is *navigability of a possibility space under bounded search cost*: a set of available targets, a substrate of cues that imposes a cost-of-search, and a goal-driven agent performing an implicit search over that substrate — navigability is high when the cues make the search cheap and bias it toward high-value targets, low when they are absent, misleading, or biased toward low-value ones. That pattern recurs across wayfinding, findability, and information foraging, and the catalogue already carries its pieces — `search` and `navigation` (the implicit search process and its graph), `affordance` and `signifier` (the local cue mechanisms), and `information_scent` (the cue-following heuristic) — with a plausible unifying candidate (something like *navigability under bounded search cost*) sitting alongside search and navigation as the general prime. Discoverability is the *interface-design criterion* that synthesizes these into a usability standard.

So the division is clean. The genuinely portable content — "a wanted target goes unreached because the substrate's cues fail to bias a bounded search toward it; fix the cues, don't blame the searcher" — should ride the composition of `search`, `navigation`, `affordance`, `signifier`, and `information_scent` (or the unifying navigability prime), under each domain's own cue vocabulary, when the lesson is needed in architecture, librarianship, or organizational design. Discoverability's own contribution — the goal-weighted findability ratio as a usability metric, the system-as-encountered framing that relocates the defect from audience to artifact, the specific HCI signifier toolkit (empty-state guidance, hover/preview states, in-app search) — is the interface-design cargo that synthesizes the general pattern into a design standard and stays home. The general navigability-under-bounded-search pattern travels via those composed primes; the interface-design criterion stays in HCI and information design, the boundary *Structural Core vs. Domain Accent* makes precise below.


Discoverability Failure

one_liner: Diagnose why a working feature goes unused: the capability exists and functions perfectly, but no signal on any surface the user samples announces it, so the user's option set is bounded by the visible interface and the feature is operationally nonexistent.

core_idea:
Discoverability failure is the interaction-design condition in which a capability genuinely exists in a system — is implemented, tested, and listed in the engineering inventory — but the interface surface presents no signal, label, affordance cue, or contextual prompt that would announce the capability's existence to a user who has not been independently told it is there. The system is complete and correct; the feature is merely invisible. The user's effective option set is bounded by the visible interface surface, not by the underlying supported set, so the undiscoverable capability is operationally nonexistent for that user even though it functions perfectly for any user who already knows to look.

The structural gap has three components: a latent capability in the system; an interface surface on which signals about that capability could be placed but are not; and a user whose option-set construction depends on the surface, not on the implementation. The gap between the supported option set and the user's discovered set is the failure space. The intervention is not documentation or training — it is placing a perceptible cue (menu item, tooltip, autocomplete suggestion, onboarding highlight, command-palette entry) on a surface the user reliably samples during the task flow where the capability is relevant.

The failure is distinct from information-scent failure, which is when the cue exists but mispredicts the destination, and from empty-state failure, which is when the user reaches a view whose content absence goes unscaffolded. Discoverability failure occurs before any attempt: the user never forms the intention to use the capability because no surface signal makes its existence part of the user's model of what the system can do.

scope_of_application:
Discoverability failure lives across HCI and interaction design — every interactive substrate where a user builds an option set from the surfaces they sample; its reach is within that domain. The cross-domain cousins (unclaimed welfare benefits, invisible legal rights, low-take-up public services) are co-instances of the parent `invisible_affordance` / `unsignaled_capability`, not literal habitats here, and the interface-design apparatus does not travel to them.

- **GUI applications** — hidden menu items, gesture-only operations (right-click, swipe-revealed, long-press on mobile), keyboard shortcuts without menu mirroring, and "secret" settings reachable only through search.
- **Web applications** — features behind hover-only menus on touch devices, never-expanded accordions, and settings pages organized by internal team boundaries rather than user task.
- **Voice and conversational UIs** — a skill or intent exists but no surface prompts the user toward it, so they never learn what the assistant can do beyond what they have tried.
- **Command-line tools** — hidden subcommands, undocumented flags, and behavior gated by environment variables not surfaced in `--help`.
- **APIs** — endpoints documented in code but absent from the published reference, and rate-limit-relief options offered only on request.

structural_signature:
**Sig role-phrases:**

- **the latent capability** — a genuinely supported, implemented, tested operation in the system, present in the engineering inventory
- **the interface surface** — the locations on which a signal about the capability could be placed but is not
- **the user's sampling pattern** — which surfaces the user reliably inspects for capability cues during the relevant task flow
- **the supported set vs. discovered set split** — the system's full capabilities versus the user's experienced option set, which is built from sampled surfaces and the signals placed on them, not from the implementation
- **the discoverability gap** — the difference between supported and discovered set: the failure space, measurable in adoption telemetry, search logs, and usability studies
- **the before-any-attempt position** — the failure occurs before any attempt: no surface signal ever makes the capability part of the user's model, so the intention is never formed
- **the operational-nonexistence outcome** — an unsignaled capability is operationally nonexistent for that user no matter how well it functions for anyone who already knows to look
- **the place-a-cue intervention** — close the gap by putting a perceptible cue (menu item, tooltip, autocomplete, command-palette entry, onboarding highlight) on a sampled surface, or bringing a cued surface into the sampling path — not documentation or training

what_it_is_not:
- **Not a missing or broken feature.** The capability genuinely exists — implemented, tested, in the engineering inventory — and works perfectly for anyone who knows to look. What is absent is the *surface signal* that would announce it. The system is complete and correct; the feature is merely invisible, so the fault is in the interface's advertising, not in the implementation.
- **Not a documentation or training problem.** The remedy is not a help article, tour, or tutorial. Those teach a feature whose problem is invisibility on the surface and leave the discovered set unchanged for users who never reach the documentation. The fix is to place a perceptible cue on a surface the user already samples in the relevant flow — a design-budget move, not a documentation-budget one.
- **Not user fault.** "They should have explored more" misdiagnoses it. A user's effective option set is built from the surfaces they sample and the signals placed there, not from their diligence; a capability with no cue on a sampled surface is operationally nonexistent regardless of how curious the user is. The complaint "I didn't know I could do that" is evidence about the surface, not the person.
- **Not information-scent failure.** A scent failure has a cue that *exists but mispredicts its destination* — the user forms an intention and is misled. Discoverability failure has *no cue at all*: the intention is never formed because nothing made the capability part of the user's model. One fixes the cue's prediction; the other places a signal that was never there.
- **Not empty-state failure.** In an empty-state failure the user has already *arrived* at a view and finds its content absence unscaffolded. Discoverability failure occurs *before any attempt*, upstream of arrival — the user never navigates toward the capability because its existence never entered their model. The two sit at different points in the interaction loop and call for different fixes.
- **Not information asymmetry.** This is not a case of parties holding unequal *private* knowledge. Both the designer and the system fully "know" the capability; nothing is concealed or strategically withheld. The user simply lacks a *surface signal*, a perceptual gap on a shared, non-secret interface — not an epistemic advantage one party holds over another.

clarity:
Naming discoverability failure reframes the recurring user complaint "I didn't know I could do that" away from user blame — they should have read the documentation, taken the tour, explored more — and toward an interface-design diagnosis: the surface failed to advertise a capability that was sitting right there. That reframing moves the intervention out of the training-and-documentation budget and into the design budget, because the fix is not teaching the user about the feature but placing a perceptible cue on a surface the user already samples during the relevant task. A team that has internalized the concept stops shipping a help article to paper over the gap and starts asking where, in the user's actual flow, the capability's existence could become visible.

The concept's sharper work is to make the *discovered set* a first-class object distinct from the *supported set*. A practitioner can now hold apart what the system can do (the engineering inventory) from what any given user knows it can do (bounded by the surfaces they sample and the signals placed there), and treat the difference between the two as a measurable failure space — readable in adoption telemetry, search logs, and usability studies — rather than an unfortunate fact about users. Naming it also fixes its position in the interaction loop relative to its near neighbors, which the bare phrase "bad UX" blurs together: discoverability failure happens *before any attempt*, when the user never forms the intention because no signal made the capability part of their model of the system — upstream of information-scent failure, where a cue exists but points to the wrong destination, and of empty-state failure, where the user has already arrived somewhere and finds it unscaffolded. The diagnostic question becomes precise: not "why did the user fail at this?" but "which surface that the user reliably inspects carries no signal of a capability that lives behind it?"

manages_complexity: An interaction designer otherwise confronts a long, heterogeneous catalogue of "bad UX" complaints, each looking like its own defect: a hover-only menu invisible on touch devices, a gesture no one finds, a keyboard shortcut with no menu mirror, a setting buried three accordions deep, a voice skill the user never invokes, an undocumented CLI flag, an API endpoint absent from the published reference. Treated as separate bugs, each invites its own one-off remedy and its own help article. Discoverability failure compresses the whole catalogue into a single structural relation between three objects — a latent capability, an interface surface where a signal could sit but does not, and a user whose option set is built from the surfaces they sample rather than from the engineering inventory — so the designer reasons about one failure space, the gap between the *supported set* and the *discovered set*, instead of re-diagnosing each symptom from scratch. That compression hands the analyst a measurable quantity in place of an anecdote: the supported-minus-discovered gap is readable directly in adoption telemetry, search logs, and usability studies, and every distinct symptom becomes the same gap manifesting on a different surface. The qualitative outcome then reads off a small set of factors — which surfaces the user reliably samples in the relevant task flow, and whether any of them carries a perceptible cue for the capability that lives behind it. If a sampled surface signals the capability, it enters the user's model and the gap closes; if no sampled surface signals it, the capability is operationally nonexistent regardless of how well it is implemented. The intervention family collapses identically: every fix is the same move — place a perceptible cue (menu item, tooltip, autocomplete suggestion, command-palette entry, onboarding highlight) on a surface the user already inspects, or bring a cued surface into the user's sampling path — rather than a bespoke per-feature campaign of documentation and training. Locating the failure precisely in the interaction loop further prunes the branch structure: because discoverability failure sits *before any attempt* (no intention is ever formed), it is cleanly separable from information-scent failure (a cue exists but points to the wrong destination) and empty-state failure (the user arrived and found nothing scaffolded), so the diagnostic narrows from the open-ended "why did the user fail?" to the sharp, surface-indexed "which surface that the user reliably inspects carries no signal of a capability behind it?"

abstract_reasoning:
Discoverability failure licenses a family of design-reasoning moves built on one relation: the user's discovered set is constructed from the surfaces they sample, not from the engineering inventory, so a capability with no signal on a sampled surface is operationally nonexistent regardless of how well it is built. The *diagnostic* move runs from a surface symptom — low adoption of a shipped feature, a "I didn't know I could do that" report, users laboriously hand-rolling something the system already does — back to a structural cause that is explicitly not user fault: the analyst infers that some surface the user reliably inspects during the relevant task carries no perceptible cue for a capability living behind it, and locates the failure in the gap between the supported set and the discovered set rather than in user diligence. The reasoning is surface-indexed: from the symptom one predicts *where* the missing signal sits by asking which surfaces the user samples in that flow and checking each for a cue, and the gap itself is treated as a measurable quantity readable in adoption telemetry, search logs, and usability studies — so the diagnosis yields a number, not an anecdote.

The *boundary-drawing* move fixes the failure's position in the interaction loop, and that position is load-bearing because it separates this diagnosis from look-alikes that demand different fixes. Discoverability failure occurs *before any attempt*: the user never forms the intention to use the capability, because no surface signal ever made its existence part of their model of what the system can do. Reasoning from this boundary, the analyst distinguishes it from information-scent failure, where a cue *does* exist but mispredicts its destination (the user forms an intention and is misled), and from empty-state failure, where the user has already *arrived* somewhere and finds it unscaffolded. The decision procedure is sharp: did the user never form the intention (discoverability failure, place a signal), form it and get pointed wrong (scent failure, fix the cue's prediction), or arrive and find nothing (empty-state failure, scaffold the view)? Mis-locating the failure point predicts the wrong remedy, so getting the boundary right is the first analytic act.

The *interventionist* move reasons forward from the gap to its closure and rules out an entire class of remedies as misdirected. Because the failure is absence of signal on a sampled surface — not absence of knowledge in the user — the predicted effective intervention is to place a perceptible cue (a menu item, tooltip, autocomplete suggestion, command-palette entry, onboarding highlight) on a surface the user already inspects, or to bring an already-cued surface into the user's sampling path; and the prediction is directional — if a sampled surface comes to signal the capability, it enters the user's model and the gap closes, while if no sampled surface signals it the capability stays operationally nonexistent. The same structure predicts that documentation, help articles, and training are the wrong budget: they attempt to teach a feature whose problem is invisibility on the surface, so they are predicted to leave the discovered set essentially unchanged for users who never reach the documentation, and the move accordingly redirects effort from the documentation budget to the design budget before a single help article is written. The recurring design habit the concept installs is to hold the supported set and the discovered set apart as separate first-class objects and, for any capability, to ask not "why did the user fail?" but "which surface that this user reliably inspects carries no signal of the capability behind it?" — converting an open-ended usability question into a surface-by-surface audit with a measurable target.

knowledge_transfer:
Within HCI and interaction design the concept transfers *as mechanism*, because the three-object relation it names — a latent capability, an interface surface where a signal could sit but does not, and a user whose option set is built from sampled surfaces rather than the engineering inventory — holds across every interactive substrate. The diagnostic move (read low adoption or an "I didn't know I could do that" report back to a missing signal on a sampled surface, not to user diligence), the supported-set-versus-discovered-set framing measured in adoption telemetry and search logs, the before-any-attempt boundary that separates it from information-scent and empty-state failures, and the single intervention family (place a perceptible cue on a surface the user already samples, or bring a cued surface into the sampling path) all carry intact across GUI applications (hidden menu items, gesture-only operations, unmirrored keyboard shortcuts, buried settings), web applications (hover-only menus on touch, never-expanded accordions, team-organized settings pages), voice and conversational UIs (skills the user never invokes), command-line tools (hidden subcommands, undocumented flags), and APIs (endpoints absent from the published reference). The supporting theory transfers with it: Norman's perceived-versus-real affordances (real affordances must be made perceivable), information-foraging's surface-sampling-with-cost (no scent on a sampled surface means unfindable), and CLI discoverability conventions (`--help`, tab completion, command palettes) generalize to graphical slash menus and global search. Within the domain this is mechanism transfer, not analogy.

Beyond computing interfaces the honest report is **(B) shared abstract mechanism**: the underlying pattern is genuinely cross-domain, but it travels under a *more general* name, not under "discoverability failure." The parent is *invisible affordance* / *unsignaled capability* (filed as an emergent candidate): a capability, right, service, or opportunity genuinely exists, but no surface signals it to the potential user, so it is operationally nonexistent for everyone not independently told. That pattern recurs as genuine co-instances across domains: unclaimed welfare benefits and legal entitlements people do not know exist; library or archive holdings invisible to non-experts; organizational rights and HR remedies employees discover only when they litigate; public services with low take-up because of invisible-to-the-target-population design; statute-book provisions that go unused; latent reciprocity in a social network (one could ask, but the ask is not signaled as okay); even latent ecological niches signaled to no prospective coloniser. In each, the failure is absence of *signal* about an existing capability, and the cross-domain lesson — audit which surfaces the potential user samples and whether any signals the capability — is exactly what carries. So when the lesson is wanted outside HCI, carry `invisible_affordance` / `unsignaled_capability`, of which discoverability failure is the interface-design instance.

What stays **home-bound** is the entry's HCI cargo: the *interface surface* and *sampling pattern* as design objects, the catalogue of concrete cues (menu item, tooltip, autocomplete, command-palette entry, onboarding highlight), the precise interaction-loop position relative to information-scent and empty-state failures, and the telemetry/usability-study measurement substrate. These presuppose a designed interface and a user navigating it, and they do not survive extraction to a welfare entitlement or a statute. So invoking "discoverability failure" for an unclaimed benefit is **(A) analogy** in naming — apt, because the mechanism really is the shared parent, but the interface-design apparatus does not come along. Two boundaries keep this exact: discoverability failure is the *negative-space* counterpart of the positive `affordance` prime (the fit exists but is perceptually inaccessible), and it is distinct from `information_asymmetry` (where parties hold unequal *private* knowledge — here both designer and system "know" the capability and the user merely lacks the surface signal) and from `traceability` (which is about audit-trail followability, not option-set visibility). When the lesson generalizes, carry `invisible_affordance`; "discoverability failure" is its interaction-design instance. See *Structural Core vs. Domain Accent* for why this profile places the entry as a domain-specific instance of that parent rather than a prime.