KISS Principle¶

A design heuristic requiring a system to remain no more complicated than its function and operating context demand, especially for comprehension, operation, diagnosis, and repair.

Version: v1 · 2026-09-28 · History
Domain-specific #: 7680
Domain group: Applied Sciences & Engineering
Origin domain: Engineering & Design (beyond software)
Subdomain: Maintainability → Engineering & Design (beyond software)
Aliases: Keep It Simple Stupid, Keep It Simple and Straightforward, Keep It Short and Simple

Core Idea¶

The KISS Principle is a design heuristic: keep a system as simple as its required function and operating context permit.^[1] It directs designers to remove complication that does not earn its cost in capability, comprehension, operation, diagnosis, or repair. The target is not minimum part count at any price, but fit between necessary complexity and the people and conditions that must use the design.

The familiar expansion is “Keep it simple, stupid,” with many softened variants. The wording is mnemonic rather than the abstraction's technical content. “Stupid” is best read as a warning against designer cleverness and as attention to the ordinary operator or maintainer, not as an insult to users.

The engineering story associated with Clarence “Kelly” Johnson makes context concrete. A fielded aircraft should be serviceable by an ordinary mechanic, under operational constraints, with a limited set of tools. The design succeeds only if sophistication at the drawing board does not create avoidable fragility or dependence on unavailable expertise at the point of use.

KISS begins by declaring requirements. Without that boundary, “make it simpler” can erase capability, safety, accuracy, robustness, or accessibility. A one-button interface that hides necessary choices may be visually simple but operationally confusing. A component removed from a safety system may reduce part count while increasing systemic risk.

The principle therefore distinguishes essential complexity from accidental complexity.^[2] Essential complexity arises from the problem, environment, regulation, or required behavior. Accidental complexity arises from representation, architecture, tooling, interfaces, duplication, premature generality, or uncoordinated additions. KISS attacks the second while making the first legible.

Simplicity is viewpoint-relative. A design can be simple for the end user while complex internally, or simple to manufacture while difficult to repair. Applying KISS requires naming the beneficiary and lifecycle stage: reader, operator, maintainer, developer, auditor, manufacturer, or incident responder.

In software, KISS favors direct control flow, small interfaces, conventional representations, limited dependency surfaces, and designs that can be tested and explained. It does not mandate one programming paradigm. A modest abstraction can simplify repeated reasoning; excessive abstraction can force readers to navigate layers that add no current value.

In hardware, the heuristic can reduce unique parts, special tools, inaccessible fasteners, delicate adjustments, and undocumented modes. Standardization may improve repair even when a standard component is not theoretically optimal. A system that works only under laboratory care can fail the KISS test for field deployment.

In communication, KISS can motivate direct language, visible structure, and removal of redundant decoration. Brevity alone is not enough. A short instruction that omits a critical condition is less simple in use because it produces ambiguity and recovery work.

The principle is prospective and diagnostic. Prospectively, it asks whether a feature or layer is required. Diagnostically, it asks whether failure, delay, or misunderstanding arises from unnecessary interactions. It can guide review questions without supplying a complete optimization function.

KISS does not prove that a simpler design is universally superior.^[3] Complexity can create redundancy, fault containment, configurability, performance, or graceful degradation. The relevant comparison holds requirements and context constant. If the simpler candidate does not meet them, it is not a KISS improvement.

The principle is related to Occam's Razor, but the two have different home problems. Parsimony concerns choosing among adequate explanations or representations without multiplying assumptions unnecessarily. KISS concerns artifacts and their lifecycle users. A simple theory can describe a complex machine; a maintainable machine may require redundant components that an explanatory parsimony rule would not evaluate.

It is also related to “You Aren't Gonna Need It,” which discourages speculative functionality, and to “Don't Repeat Yourself,” which discourages duplicated knowledge. Those principles can conflict. Removing duplication through a generalized abstraction may make a small codebase harder to understand. KISS is the broader contextual check, not an automatic trump card.

Minimalism is an aesthetic or cultural program as well as a design approach. KISS can support minimalist outcomes but is evaluated against use. A visually spare control panel that conceals system state may be minimalist while violating KISS for operators.

Complexity can be displaced rather than removed.^[4] A simple client API may depend on a highly complex service, deployment system, and failure model. Such encapsulation can be beneficial when the boundary is stable and responsibilities are clear. A valid KISS claim states where complexity went and who must manage it.

Measurement is plural. Designers can examine task time, error rate, learning time, repair time, dependency count, interface size, failure modes, cognitive load, or change cost. No one metric defines KISS, and reducing a proxy can worsen the total system.

Structural Signature¶

Sig role-phrases:

the designed artifact — the system, component, interface, procedure, or communication whose complication is being judged.
the required function — the capabilities, safety properties, and constraints that establish irreducible design demand.
the lifecycle actor — the user, operator, maintainer, developer, auditor, or other party whose burden is at issue.^[5]
the operating context — the tools, time, expertise, environment, and failure consequences under which the artifact must work.
the complexity inventory — the parts, layers, dependencies, modes, exceptions, and representations that impose lifecycle cost.
the necessity test — the mapping from each complication to the declared requirement or beneficiary that could justify it.
the constrained subtraction — removal, consolidation, or conventional replacement of complication that does not earn its cost.
the requirement-preserving validation — confirmation that the simpler alternative retains necessary capability, safety, robustness, accessibility, and repairability.^[6]
the displacement check — accounting for complexity hidden behind an interface or transferred to another actor or lifecycle stage.
the simplicity boundary — the point where further deletion would sacrifice a requirement rather than remove accidental complexity.

What It Is Not¶

Not indiscriminate minimization. KISS removes complication only while preserving the artifact's required capability and operating constraints; the fewest parts, shortest code, or sparsest interface can still be the worse design.
Not permission to delete protective work. Safety controls, error handling, accessibility, documentation, redundancy, and recovery paths are necessary complexity when the declared requirements and failure conditions demand them.
Not a synonym for visual minimalism or elegance. A clean surface can conceal modes, dependencies, or maintenance burden, while a visibly complicated design may be the simplest one that makes its state and recovery paths usable.
Not Occam's Razor applied to artifacts without qualification. Explanatory parsimony compares adequate accounts; KISS evaluates a designed artifact against function, lifecycle actors, tools, environment, and repair conditions.
Not simplicity for only one viewpoint. Reducing burden for an end user can shift it to operators, maintainers, developers, or downstream systems, so a valid claim names both the beneficiary and where the remaining complexity resides.
Not one proxy such as part count or line count. KISS requires a requirement-preserving comparison across comprehension, operation, diagnosis, and repair rather than victory on a single metric.
Not a judgment that users are deficient. The mnemonic warns against unnecessary designer cleverness; its field-repair logic requires the design to fit realistic skills, tools, time, and conditions.^[7]

Scope of Application¶

KISS applies to designed artifacts and communications whose required function, lifecycle actors, and operating conditions can be stated well enough to distinguish necessary from accidental complexity. Each habitat must identify whose burden is reduced and verify that simplification preserves capability, safety, and repairability rather than merely moving work elsewhere.

Aircraft and military equipment. The principle governs field-serviceable hardware when ordinary maintainers, limited tools, combat conditions, and fault recovery constrain the acceptable design.^[8]
Mechanical and electrical products. It guides part choice, access, adjustment, controls, and maintenance when alternatives can be compared against the same performance and safety requirements.
Software architecture and implementation. It applies to control flow, interfaces, dependencies, representations, and abstraction layers whose necessity can be tested against present system behavior and maintenance needs.
User interfaces and operational procedures. It evaluates controls, modes, instructions, and recovery paths from the perspective of the named user or operator, without treating visual sparseness as sufficient.
Maintenance and incident response. It favors designs whose state, failure modes, diagnostic path, and repair actions remain legible under the tools, expertise, and time actually available.
Technical and instructional communication. It supports direct language and visible structure when brevity does not omit conditions needed for correct action.
Animation practice. In the attested animation habitat, it warns against over-animation—movement or activity that adds work and visual complication without serving the scene or character action.

Clarity¶

Naming KISS turns the vague complaint “this is too complex” into a constrained design diagnosis. It separates complication that serves a declared requirement from complication created by clever implementation, speculative generality, unfamiliar interfaces, or avoidable dependencies. It also separates genuinely removing burden from merely moving it: an uncluttered control panel or small client API is not simple in the relevant sense if operators, maintainers, or downstream services inherit harder diagnosis and recovery.

The principle therefore licenses a sharper review question: for which lifecycle actor, under which operating conditions, does this part or layer earn its cost—and what required capability, safety margin, or repair path would be lost if it were removed? That question keeps KISS distinct from brevity, visual minimalism, low part count, and indiscriminate deletion. The slogan's euphemistic expansions are aliases; they do not change this design test.

Manages Complexity¶

KISS turns a sprawling artifact review into a bounded comparison between requirements and the complications introduced to meet them. Instead of treating every part, feature, dependency, mode, exception, and instruction as an isolated design choice, the analyst tracks a smaller set: the required function and constraints, the lifecycle actor who bears the burden, the operating conditions that actor faces, and the cost imposed by each complication in comprehension, coordination, operation, diagnosis, or repair. Holding the first three fixed makes the fourth interpretable. A layer that enables required behavior or fault containment is necessary complexity; a layer that contributes only speculative flexibility, duplicated representation, unfamiliar interaction, or avoidable dependency is a candidate for removal or consolidation.

This produces a practical branch structure. If removing a complication preserves required capability under the named conditions and lowers lifecycle burden, simplification is warranted. If removal sacrifices safety, robustness, accessibility, or repairability, the complexity has earned its place. If the visible artifact becomes easier only because work has moved behind an interface or onto another team, the result is displacement rather than reduction, and the analysis follows the burden to its new owner. KISS therefore compresses many local judgments into a repeated necessity test without pretending that one proxy—part count, code length, screen density, or dependency count—settles the system as a whole. Its compression stops where requirements conflict, future conditions are genuinely unknown, or different lifecycle actors bear different costs; those cases still require explicit trade-off judgment rather than a generic demand for simplicity.

Abstract Reasoning¶

The first move is a necessity diagnosis. Begin with the required function, constraints, operating conditions, and lifecycle actor, then trace each feature, layer, dependency, mode, or exception to the requirement it serves and the burden it creates. From that mapping, infer whether the complication is essential, accidental, or merely displaced behind an interface. A component with no defensible requirement and measurable comprehension or maintenance cost is a simplification candidate; one that supplies safety, fault containment, accessibility, or required capability has earned its place even if it increases part count.

The interventionist move is constrained subtraction. Remove, consolidate, or replace one complication while holding requirements and context fixed, then predict the consequences for operation, diagnosis, repair, and failure recovery. If the revised design preserves necessary behavior and lowers burden for the named actor, the change satisfies the KISS test. If it shortens code or cleans a screen by shifting work to maintainers, downstream services, or hidden procedures, it is relocation rather than reduction. If it removes a necessary guard or recovery path, the apparent simplification fails.

The boundary move compares viewpoints and time horizons. A design may be simple for users but difficult for operators, or straightforward today but rigid under a well-supported future requirement. When burdens or requirements conflict, KISS does not select a winner by itself; the analyst must declare whose simplicity and which lifecycle stage govern the decision. This prevents a local proxy such as line count, number of controls, or dependency count from being mistaken for whole-system simplicity.

Knowledge Transfer¶

Within engineering and design, KISS transfers literally across aircraft hardware, software architecture, interfaces, maintenance procedures, animation, and technical communication when the object remains a designed artifact evaluated against declared requirements and real lifecycle conditions. The same cargo carries: name the user, operator, maintainer, or auditor; inventory parts, layers, dependencies, modes, and exceptions; trace each complication to the requirement it serves; remove or consolidate one candidate complication; then verify that capability, safety, robustness, accessibility, and repair remain intact. Vocabulary such as necessary versus accidental complexity, lifecycle burden, constrained subtraction, and complexity displacement retains its operational meaning across those media.

Beyond designed artifacts, the honest transfer is (B) shared abstract mechanism with an (A) analogy boundary. The broader parent Parsimony (Occam's Razor) supports preferring an adequate option that does not carry needless complication, and that pattern can recur in explanation, modeling, or representation. KISS's home-bound cargo does not follow: an artifact with requirements, a lifecycle actor, operating tools and conditions, failure modes, and a validation step after simplification. Calling a scientific theory, personal lifestyle, or political slogan “KISS” may be useful analogy, but it does not establish the design heuristic unless those roles are supplied. The stopping boundary is therefore the requirement–artifact–lifecycle relation; outside it, the transferable lesson should be named as Parsimony rather than as KISS.

Examples¶

Canonical¶

The Kelly Johnson field-repair story gives the principle its defining engineering form.^[9] Johnson is described as handing aircraft designers a limited set of ordinary tools and requiring that the aircraft be repairable by an average mechanic under combat field conditions with those tools. The challenge does not demand the fewest possible aircraft parts or the elimination of sophisticated flight capability. It fixes the required function and asks designers to avoid access arrangements, fasteners, adjustments, and service procedures whose complexity would exceed the maintainer's real equipment and expertise. A design that is elegant in the drawing office but cannot be restored in the field fails the test. Conversely, a protective component or redundant path remains justified when removing it would sacrifice airworthiness or recoverability. Simplicity is therefore assessed at the point of operation and repair, not by appearance alone.

Mapped back: The aircraft is the designed artifact, field serviceability belongs to the required function, and the average mechanic is the lifecycle actor. Combat conditions and the handed-over tools define the operating context. Testing each service complication against that setting is the necessity test, while confirming that removal preserves safe operation is the requirement-preserving validation and fixes the simplicity boundary.

Applied / In Practice¶

Animation supplies a distinct attested practice. Richard Williams uses KISS to warn inexperienced animators against over-animation: adding motion and activity that do not serve the scene or character action.^[10] In a review, the animator can identify every extra gesture, camera movement, or secondary action, ask what communicative or dramatic function it performs, and remove movements that merely compete for attention. The revised shot must then be played back to confirm that timing, characterization, continuity, and the intended action remain legible. Deleting a necessary anticipation or expression simply because it adds drawings would not satisfy KISS; it would trade visible sparseness for a weaker scene. The practice applies the same constrained subtraction as the aircraft case, but the burden falls on viewers' comprehension and the production team's control of motion rather than on field maintenance.

Mapped back: The animated shot is the designed artifact, its dramatic and communicative job is the required function, and viewers and animators are the relevant instances of the lifecycle actor. Gestures and movements populate the complexity inventory; review applies the necessity test and the constrained subtraction. Playback supplies the requirement-preserving validation, preventing deletion beyond the simplicity boundary.

Structural Tensions¶

T1: Simplicity versus requirement completeness. Removing parts, modes, checks, or explanatory detail lowers visible complication, but the same subtraction can erase required capability, safety, accessibility, or recovery. KISS therefore favors the simplest requirement-preserving design, not the smallest artifact in isolation.

Diagnostic: Which declared requirement would fail under the proposed subtraction, and has that failure been tested under the actual operating conditions?

T2: One actor's ease versus another actor's burden. A sparse interface can simplify a user's task while transferring configuration, diagnosis, or exception handling to maintainers and operators. Encapsulation can be worthwhile, yet calling it simplification without following the displaced work conceals who now manages the complexity.

Diagnostic: Whose lifecycle burden falls, whose rises, and where does the removed complexity reappear?

T3: Present directness versus supported future change. Avoiding speculative extension points keeps today's design legible, while deleting every provision for foreseeable variation can make the artifact brittle. The unresolved judgment is whether flexibility answers an evidenced demand or merely protects against an imagined one.

Diagnostic: What concrete requirement or credible change case earns the added generality now?

T4: Reduced duplication versus fault tolerance. Consolidating repeated components or paths can lower coordination and maintenance cost, but purposeful redundancy may preserve service after failure or make recovery possible. Repetition is accidental complexity only when it lacks a reliability role.

Diagnostic: Does the duplicated element merely repeat work, or does it supply an independently required failure boundary or recovery path?

T5: Reusable abstraction versus navigational indirection. A well-chosen interface or abstraction can compress repeated reasoning and stabilize responsibility, while an extra layer can force readers to chase definitions and hidden interactions. KISS cannot decide from layer count alone because the same layer may remove local detail and create global opacity.

Diagnostic: Does the layer eliminate repeated decisions for its lifecycle actors, or add a traversal whose cost exceeds the variation it contains?

T6: Conventional familiarity versus locally optimal novelty. Standard parts, representations, and procedures can be easier to learn and repair with available tools, even when a bespoke solution is technically leaner. Yet convention can also preserve unnecessary constraints, so familiarity must earn its place through the real operating context rather than authority alone.

Diagnostic: Does the conventional choice reduce lifecycle burden under the available skills and tools, or merely perpetuate inherited complication?

T7: Local simplification versus whole-system simplicity. A component can become shorter or cleaner by exporting state, dependencies, or failure handling to the rest of the system. Local gains count only when the requirement-preserving comparison includes the interfaces and downstream work that the change creates.

Diagnostic: After tracing every new dependency and recovery obligation, is the total system easier to operate, diagnose, and repair?

T8: KISS autonomy versus reduction to Parsimony (Occam's Razor) (Parsimony (Occam's Razor)). The parent Prime carries the portable preference for an adequate option without needless complication. Every instance of KISS is a strict kind of Parsimony because it applies that preference to artifact complexity relative to required function. KISS remains an in-situ design specialization because it binds the preference to a designed artifact, declared requirements, named lifecycle actors, operating resources, and validation after constrained subtraction; treating it as wholly autonomous hides that general parsimony structure.

Diagnostic: Does the case preserve the artifact–requirement–lifecycle relation that makes KISS operational, or only express the broader Parsimony pattern?

Structural–Framed Character¶

The KISS Principle lies at the framed pole of the structural–framed spectrum because it is a prescriptive design rule whose simplicity judgment is constituted by declared requirements, lifecycle actors, and operating conditions. Its evaluative_weight is direct: it recommends removing complication that does not earn its cost while rejecting deletion that makes an artifact inadequate. It is strongly human_practice_bound because designed artifacts, user and maintainer burdens, functional requirements, and validation after subtraction have no KISS identity outside design practice. Its institutional_origin lies in engineering and design traditions that turn a slogan into a review heuristic, although no single organization fixes every application. Its vocab_travels unevenly: adequacy, complexity, burden, and simplification retain broad meanings, while the acronym, lifecycle actor, field repair, interface, and requirement-preserving subtraction keep the named principle design-typed. Under import_vs_recognize, KISS is literally recognizable across artifact media when the same requirement–artifact–lifecycle test is performed; applying the slogan to a theory, lifestyle, or preference without those roles imports a design frame by analogy.

The smallest positively reviewed portable skeleton is Parsimony (Occam's Razor): among alternatives that meet an explicit adequacy bar, prefer the one with less gratuitous structure under a declared complexity measure. The cross-domain reach of that adequate-rivals–simplicity-preference relation belongs to the Parsimony Prime. KISS remains home-bound by its designed artifact, required function, named lifecycle actor, operating resources, failure consequences, constrained subtraction, and validation that capability, safety, and repairability survive. Removing those design conditions leaves Parsimony; removing the parsimonious comparison leaves brevity, visual minimalism, or arbitrary deletion rather than KISS.

Its character: framed pole because a portable parsimony comparison supplies the structural pull, while prescriptive design practice and the requirement–artifact–lifecycle relation constitute the decisive frame.

Structural Core vs. Domain Accent¶

This decomposition explains why the KISS Principle is a domain-specific abstraction rather than a Prime.

What is skeletal (could lift toward a cross-domain prime). The carrier is a choice among alternatives that are adequate for the same stated demand. The operation compares them on a declared complexity dimension and removes structure that does not earn its cost; the invariant is adequacy under the controlling requirements, and recognition fails when the simpler option sacrifices what the comparison was required to preserve. That complete adequate-rivals, complexity-measure, defeasible-simplicity structure is Parsimony (Occam's Razor). KISS strictly specializes it by applying the preference to artifacts under conditions of use rather than to arbitrary explanations, models, or representations.

What is domain-bound. KISS requires a designed artifact, a required function, a named lifecycle actor, actual operating tools and conditions, and a necessity test for parts, layers, dependencies, modes, or instructions. Its characteristic operation is constrained subtraction followed by validation that capability, safety, robustness, accessibility, diagnosis, and repair remain adequate, together with a check that complexity was not merely displaced to another actor or lifecycle stage. Substitute an explanatory hypothesis for the artifact, omit the operator and use context, or minimize a proxy without requirement-preserving validation, and the result may be Parsimony or minimalism but is not the KISS design heuristic.

Why this does not clear the prime bar. The complete artifact–requirement–lifecycle relation and its intervention semantics do not recur literally in at least three unrelated domains with the same operational vocabulary; the literal uses surveyed in Knowledge Transfer remain within engineering and design practice. Broader uses in scientific theory choice, personal conduct, or political rhetoric either belong to Parsimony (Occam's Razor) or are analogical. Removing the design accent leaves the parent preference for an adequate simpler rival but not KISS, while removing the adequacy-preserving subtraction and displacement test leaves the slogan, design nouns, brevity, or aesthetic sparseness rather than this abstraction.

This entry is a kind of Parsimony (Occam's Razor).

Instantiates — Parsimony (Occam's Razor) (Parsimony (Occam's Razor)). The typed carrier is a designed artifact considered with a declared function, operating conditions, and lifecycle actors; the rivals are alternative designs that satisfy the same capability, safety, robustness, accessibility, and repair requirements. The operative comparison names a relevant complexity axis—parts, layers, dependencies, modes, tools, or cognitive and maintenance burden—and removes complication that does not earn its cost. The invariant is a defeasible preference for the simpler adequate design, never for a simpler but inadequate one. Removing engineering nouns leaves Parsimony's adequate-rivals, explicit-complexity-measure, simplicity-preference, and revisability signature; removing that signature leaves deletion, brevity, or aesthetic minimalism rather than KISS. The artifact–requirement–operator–lifecycle relation supplies the domain differentia.

Relationships to Other Abstractions¶

Current abstraction KISS Principle Domain-specific

Parents (1) — more general patterns this builds on

KISS Principle is a kind of Parsimony (Occam's Razor) Prime

The typed carrier is a designed artifact considered with a declared function, operating conditions, and lifecycle actors; the rivals are alternative designs that satisfy the same capability, safety, robustness, accessibility, and repair requirements.

Hierarchy paths (2) — routes to 2 parentless roots

KISS Principle → Parsimony (Occam's Razor) → Minimalism → Constraint

Show alternative path (1)

Neighborhood in Abstraction Space¶

KISS Principle sits in a sparse region of the domain-specific corpus (64^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2551 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Parsimony or Occam's Razor. Parsimony is the broader preference for an adequate explanation or representation without needless assumptions; KISS specializes simplicity as a design judgment about an artifact, its requirements, and its lifecycle actors. Tell: if the comparison is between accounts rather than between requirement-satisfying artifacts under operating and maintenance conditions, the governing concept is parsimony rather than KISS.
Minimalism. Minimalism is an aesthetic or cultural program favoring spareness, whereas KISS permits visible detail and internal complexity when they earn their cost in capability, safety, diagnosis, or repair. Tell: a spare surface that hides state or recovery work may be minimalist but fails KISS when it increases the named actor's lifecycle burden.
You Aren't Gonna Need It. YAGNI rejects speculative functionality that is not presently required; it is a narrower development rule than KISS, which also evaluates necessary features implemented with avoidable layers, modes, or dependencies. Tell: if the disputed element serves only an anticipated future use, test YAGNI; if it serves a current requirement but may be needlessly complicated, test KISS.
Don't Repeat Yourself. DRY targets duplicated knowledge representations, while KISS asks whether the resulting design is the least burdensome requirement-preserving arrangement. Tell: consolidating duplication into an abstraction satisfies DRY, but it satisfies KISS only if comprehension, operation, diagnosis, and repair improve for the declared lifecycle actors.
Encapsulation. Encapsulation hides implementation behind a stable interface and can simplify one actor's view while leaving or increasing complexity elsewhere; KISS includes an explicit displacement check across that boundary. Tell: inspect who must manage the hidden implementation and its failures—reduced client-visible detail alone establishes encapsulation, not a whole-system KISS improvement.

References¶

[1] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[2] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[3] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[4] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[5] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[6] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[7] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[8] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩

[9] KISS? ‘Yes.’ TMO? ‘No.’ registry ↩

[10] Unverified encyclopedia synthesis; claim-specific authoritative support was not established in this verification pass. ↩