Independent Submission R. Rodriguez Intended Status: Informational Roderick Consulting Inc. Expires: November 4, 2026 M. P. Graña RGC Argentina S.A. Constructing Generative Metaphor Vocabularies for Distributed System Architecture Abstract This document proposes a method for constructing internally consistent metaphor-based vocabularies that name the components and operational concepts of distributed systems. The central observation is that a metaphor drawn from a single coherent source domain, when carefully matched to a target architecture, produces a vocabulary whose internal relationships mirror the architectural relationships of the system, and which generates new names organically as new components are introduced, without straining the metaphor or resorting to ad hoc neologisms. The document presents the observation as a claim, articulates a stepwise method derived from it, and illustrates the method with a worked example: the El Mundo lexicon, a vocabulary for a distributed industrial-data platform constructed from the institutional life of the rural pueblo in post- colonial Spanish America. The contribution is methodological. The worked example is offered as evidence that the method produces useful outputs and as a teaching case demonstrating each step. The method is intended to be portable: teams working in any cultural-linguistic tradition can apply it to their own target architectures and source domains. The document also discusses the secondary observation that vocabularies drawn from non-dominant linguistic traditions can preserve architectural commitments that the dominant technical English vocabulary has worn smooth, and considers the trade-offs that such vocabularies impose on adoption and review. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 4, 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction ....................................................4 1.1. Problem Statement ..........................................4 1.2. Contribution ...............................................5 1.3. Document Structure .........................................6 1.4. Terminology ................................................7 2. Related Work ....................................................7 2.1. Conceptual Metaphor: The Cognitive Foundation ..............8 2.2. Semiotics: Codes, Connotation, and Cultural Units ..........9 2.3. Formal Terminology Studies ................................11 2.4. Metaphor in Software Architecture .........................12 2.5. The City Metaphor .........................................13 2.6. Extreme Programming and the System Metaphor ...............14 2.7. Working Languages Absorb Local Experience: Two Illustrations ............................................15 2.8. Cross-Cultural Considerations in Interaction Design .......17 2.9. Controlled Vocabularies in IETF Tradition .................18 3. The Central Claim ..............................................11 3.1. Generative Coherence ......................................11 3.2. Connotational Preservation as Supporting Argument .........13 3.3. Failure Modes the Claim Addresses .........................14 4. The Method .....................................................15 4.1. Overview ..................................................15 4.2. Step 1: Characterize the Target Architecture ..............16 4.3. Step 2: Identify Candidate Source Domains .................17 4.4. Step 3: Test Source-Target Mapping ........................18 4.5. Step 4: Adopt or Reject ...................................20 4.6. Step 5: Apply the Vocabulary Iteratively ..................21 4.7. Step 6: Document the Lexicon Canonically ..................22 4.8. Anti-Patterns and Failure Modes ...........................23 5. Worked Example: The El Mundo Lexicon ...........................24 5.1. Target Architecture .......................................24 5.2. Source Domain Selection ...................................25 5.3. Mapping Validation ........................................26 5.4. Selected Vocabulary .......................................27 5.5. Generative Episodes During Construction ...................30 5.6. Connotational Preservation in the Example .................31 6. Evaluation .....................................................32 6.1. Coherence .................................................32 6.2. Generativity ..............................................33 6.3. Connotational Density .....................................33 6.4. Adoption Friction .........................................34 6.5. Limits of Single-Example Evaluation .......................35 7. Discussion .....................................................35 7.1. When the Method Applies ...................................35 7.2. When the Method Does Not Apply ............................36 7.3. Translation, Loss, and the International Audience .........37 7.4. The Proliferation of Imperfect Adoptions ..................39 7.5. Cultural Authority and Its Responsibilities ...............40 8. Future Work ....................................................41 9. Security Considerations ........................................42 10. IANA Considerations ...........................................42 11. References ....................................................43 11.1. Informative References ..................................43 Appendix A. The El Mundo Lexicon: Term Definitions ................46 Authors' Addresses ................................................52 1. Introduction 1.1. Problem Statement Distributed systems are routinely named using vocabulary drawn from conventional English-language software-engineering terminology: "service," "node," "container," "endpoint," "queue," "cluster," "log," "audit trail," "event bus," and so on. This vocabulary is universal across the discipline and instantly recognizable to any working software engineer. It carries the considerable advantage of being immediately understood by collaborators across organizational and national boundaries. The vocabulary also carries a less-discussed disadvantage. The metaphors it embeds have been worn smooth by decades of pragmatic use. A "service" today denotes any addressable software component; it has lost the connotation of obligation, courtesy, or relationship that the underlying word once carried. An "audit trail" is a passive record of events, drained of the institutional weight that "audit" once implied. A "ledger" is shorthand for any append-only data store, no longer evoking the practice of bookkeeping that gave the word its discipline. The terms remain functional but no longer carry inferential power. They name components, but they do not encode commitments about what those components are for or how they should behave. This loss has practical consequences. A team designing a system whose central commitment is, for example, the immutable preservation of operational truth cannot easily encode that commitment in the word "ledger" alone. The word has been worn flat. The team must compensate with surrounding documentation, naming conventions, architectural decision records, and constant verbal reinforcement. The vocabulary itself does not carry the commitment. A second problem compounds the first. Most distributed-system vocabularies are *blended* metaphors. A typical architecture diagram speaks simultaneously of "pipes" (plumbing), "services" (commerce), "clusters" (botany), "containers" (logistics), "loads" (cargo), and "events" (calendars). Each individual term may be apt, but the metaphors do not cohere. They cannot be reasoned about as a system. When a new component is introduced, there is no source domain to draw on; teams resort to ad hoc invention, inconsistent borrowing, or English-default labeling. These two problems suggest a question: can a vocabulary be constructed deliberately, drawn from a single coherent source domain, that preserves connotational weight and generates new names organically as the architecture evolves? This document proposes that the answer is yes, and offers a method. 1.2. Contribution The document makes one principal claim and proposes one method derived from the claim, with one supporting observation. The principal claim, developed in Section 3, is that a metaphor drawn from a single coherent source domain, when carefully matched to a target architecture, produces a vocabulary whose internal relationships mirror the architectural relationships of the system, and which generates new names organically as new components are introduced. The claim is supported by the observation, presented as a worked example in Section 5, that such a vocabulary was constructed for a real distributed industrial-data platform and exhibited the predicted properties during construction. The proposed method, presented in Section 4, is a stepwise procedure that takes a target architecture and a candidate source domain and produces a vocabulary satisfying coherence, generativity, and connotational-density criteria. The method is articulated as six steps with explicit decision points, anti- patterns, and failure modes, so that teams working in any cultural-linguistic tradition can apply it to their own systems. The method is proposed-and-illustrated rather than empirically validated; one worked example is a single data point, not a study, and Section 6.5 discusses the limits this imposes. The supporting observation, developed in Section 7, is that vocabularies drawn from non-dominant linguistic-cultural traditions can preserve architectural commitments that the dominant technical English vocabulary has worn smooth. This observation is offered as a secondary argument rather than the document's central claim, because it concerns the relationship between vocabulary choice and meaning preservation rather than the construction method itself. 1.3. Document Structure Section 2 surveys related work across six traditions: the cognitive-linguistic theory of conceptual metaphor; semiotics and the theory of codes and connotation; formal terminology studies; metaphor-based naming in software architecture; the linguistic tradition of working languages absorbing local cultural-linguistic experience, illustrated by Hispanic panhispanic lexicography and English's absorptive history; and the IETF tradition of controlled-vocabulary documents. Section 3 articulates the central claim, distinguishes it from related claims in the literature, and identifies the failure modes it addresses. Section 4 presents the method as a six-step procedure with explicit decision points and failure modes. Section 5 presents the El Mundo lexicon as a worked example of the method applied to a real distributed-system architecture in the upstream oil and gas industrial-data domain. Section 6 evaluates the lexicon against the method's claimed criteria and discusses the limits of single-example evaluation. Section 7 discusses the conditions under which the method applies, the proliferation of imperfect adoptions when vocabularies cross language boundaries, and the cultural- authority considerations that arise when borrowing from non- dominant linguistic traditions. Section 8 identifies future work the present document does not undertake. Appendix A presents the El Mundo lexicon's full term definitions for readers who wish to study the worked example in detail. 1.4. Terminology Throughout this document the following terms are used as defined here. *Target architecture*: the distributed-system architecture for which a vocabulary is being constructed. The architecture's components, their relationships, and their behavioral commitments constitute the target domain of the metaphor. *Source domain*: the cultural, geographic, institutional, or social field from which vocabulary is drawn. The source domain's internal relationships are mapped onto the target architecture's relationships. *Mapping*: the systematic correspondence between elements of the source domain and elements of the target architecture, in the sense developed by Lakoff and Johnson [Lakoff-Johnson]. *Vocabulary*: the set of terms drawn from the source domain and adopted as names for components and concepts in the target architecture. *Lexicon*: a documented vocabulary together with its term definitions, mapping rationale, and conventions for use. *Generativity*: the property that the source domain produces names for new components when the target architecture evolves, without recourse to ad hoc invention or out-of-domain borrowing. *Connotational density*: the property that a single term carries substantial historical, social, or institutional meaning beyond its literal denotation, such that the term encodes commitments the bare denotation would not convey. *Coherence*: the property that the source domain is unitary rather than blended, so that the relationships among terms in the vocabulary mirror the relationships among components in the target architecture without contradiction. 2. Related Work The method proposed in this document draws on three intellectual traditions that have rarely been put in conversation: cognitive linguistics (specifically the theory of conceptual metaphor), semiotics (specifically Eco's theory of codes and connotation), and software-architecture practice (specifically the use of metaphor to organize architectural vocabulary). It also engages with formal terminology studies, with the broader linguistic tradition in which working languages grow by absorbing local cultural-linguistic experience, and with the IETF tradition of controlled-vocabulary documents. Each tradition contributes a distinct foundation; the contribution of this document is to integrate them into a workable method for distributed-system architecture. 2.1. Conceptual Metaphor: The Cognitive Foundation Lakoff and Johnson's foundational work on conceptual metaphor [Lakoff-Johnson] establishes that metaphor is not decorative language but a fundamental mechanism of human cognition. Conceptual metaphors structure how speakers reason about abstract domains by mapping them systematically onto more concrete domains. The mappings are not arbitrary; they preserve inferential structure, so that reasoning patterns valid in the source domain can be applied to the target domain. The present method draws directly on this insight. The architectural relationships among components in a distributed system are abstract; the relationships among institutions in a well-developed cultural domain are concrete and richly structured. A mapping that preserves the inferential structure between the two allows engineers to reason about the architecture using the source domain's conceptual machinery, and the vocabulary serves as the medium through which that mapping becomes shared. The method's emphasis on a single coherent source domain follows from Lakoff and Johnson's observation that conceptual metaphors work because of the systematic structure they preserve. Blended metaphors break that structure and lose inferential power. 2.2. Semiotics: Codes, Connotation, and Cultural Units The cognitive-metaphor tradition explains why metaphor works as reasoning. The semiotic tradition explains how individual terms carry meaning beyond their literal denotation, and why some terms carry more meaning than others. The two traditions are complementary: cognitive linguistics treats the structural mapping between source and target domains, while semiotics treats the meaning carried by individual signs within those domains. The method proposed in this document depends on both. Eco's foundational treatment in A Theory of Semiotics [Eco-1976] distinguishes denotation (the literal class an expression names) from connotation (the second-level meaning that the literal sign carries within a cultural code). Crucially for the present method, Eco's treatment establishes that connotation is not personal-emotional but cultural-codal: a sign carries connotation because the cultural code shared by speakers loads it with meaning, and that meaning is reproducible across speakers who share the code. A sign whose connotation has been thinned by indiscriminate use within a code is, in Eco's framework, code- attrited; a sign drawn from a less-worn region of the code retains its full connotational charge. This semiotic framing makes precise what the method is doing. When the method selects a term from a source-domain culture (for example, the historical pulpería of rural Spanish-American life), it is selecting a sign whose denotation is "country store" but whose cultural-code connotation includes a specific institutional history of public bookkeeping, public dispute resolution, and public credit. The term is chosen not for its denotation but for its position in the cultural code. The English near-equivalent ("country store") shares the denotation but does not occupy the same position in any English code; the connotation does not transfer. Eco's later move in Semiotics and the Philosophy of Language [Eco-1984] from codes to encyclopedia further clarifies the stakes. The encyclopedia is the open-ended cultural memory that informs how readers complete the meaning of a sign; it is not a closed dictionary but a living reservoir of associations. When the present method's vocabulary is adopted by a reader who shares the source-domain encyclopedia, the meaning is acquired automatically. When it is adopted by a reader who does not share the encyclopedia, the canonical lexicon serves as a partial substitute, providing access to enough of the encyclopedia for the connotation to be reconstructed. The proliferation of imperfect adoptions discussed in Section 7.4 is, in Eco's terms, a failure of encyclopedia transfer: adopters who learn the term from secondary sources acquire only its denotational core, missing the connotational layers the source-domain encyclopedia would supply. The defense Section 7.4 proposes (canonical lexicons referenced by version) is a semiotic intervention: it tries to transfer enough of the encyclopedia along with the sign so that the connotation survives the transfer. The present method extends a semiotic principle into engineering practice. The principle is that vocabularies are codes; codes shape what speakers can reason about; codes can be chosen deliberately. The engineering application is that distributed- system architectures benefit from being given vocabularies whose codal density matches the architectural commitments they encode. 2.3. Formal Terminology Studies The discipline of terminology studies has formalized the construction of controlled vocabularies for technical domains. The international standard ISO 1087 [ISO-1087] establishes basic terms and definitions for terminology work, distinguishing concepts (units of thought), designations (representations of concepts by signs), terms (verbal designations within special languages), and concept systems (the structured relationships among concepts in a domain). The traditional terminology-studies approach proceeds top-down: the domain's concept system is analyzed first, then designations are assigned to concepts, with consistency and unambiguity as the principal criteria. Terms are typically expected to be monosemic within the domain (one concept per term), domain- specific, and aligned with international standardization where applicable. The method proposed in this document differs in two ways. First, it operates on a different unit: rather than constructing a technical glossary for an entire discipline (which terminology studies addresses), it constructs an architectural vocabulary for a single distributed system. Second, it deliberately seeks polysemy of a particular kind, in which a term carries both its source-domain connotation and its target-architecture denotation simultaneously. Where formal terminology studies would treat such polysemy as a problem to be eliminated, the present method treats it as the property that makes the vocabulary load-bearing. The two approaches are nevertheless compatible. A vocabulary constructed by the present method can be documented using the formal apparatus of terminology studies, and the canonical- lexicon discipline of Step 6 (Section 4.7) is essentially a terminography practice applied to the method's outputs. 2.4. Metaphor in Software Architecture Kruchten observes that "metaphors are everywhere in software architecture" and that the discipline has, throughout its history, used systematic metaphors to describe architectural structures [Kruchten-Metaphors]. He distinguishes ontological metaphors that name things ("clients and servers," "pipes and filters"), structural metaphors that organize spatial-procedural relationships ("on top of," "parallel to"), and the rich container metaphors used throughout the discipline ("packages," "repositories," "libraries"). Kruchten further observes that good metaphors carry inferential power: a reader who understands the source domain can reason about the target domain by analogy. He catalogs failure modes including the abuse of inference where the source-target mapping is incomplete, and the breakdown of mixed metaphors where the designer "uses 2 different domains and combines them." Such blends, he notes, are "rather delicate to achieve and often lead to confusion." The present method is constructed precisely to avoid the blending failure mode by requiring a single coherent source domain. Smolander's qualitative study of architecture in software organizations [Smolander-Architecture] identifies four general metaphors of architecture itself: blueprint, literature, language, and decision. The "architecture as language" metaphor in his framework is closest to the concerns of the present document, which treats vocabulary as a primary medium through which architectural commitments are expressed. 2.5. The City Metaphor The "city metaphor" tradition in software visualization, surveyed by Moreno-Lumbreras and colleagues [City-Metaphor], maps software systems to urban geography in a manner closely related to the pueblo metaphor used in the worked example of Section 5. Districts correspond to packages, buildings to classes, streets to dependencies. The mapping has been implemented in research tools and used effectively for the visualization of large codebases. The city metaphor differs from the present method's scope in two ways. First, it is primarily a visualization aid; it maps a single codebase to a geographic depiction for inspection, rather than producing names that engineers use in code, documentation, and conversation. Second, the source domain (a generic city) is not anchored to a specific cultural- linguistic tradition; the names that result ("district," "building," "street") are English-default and carry the same wear that the present document identifies as a problem in conventional vocabularies. The two approaches share the conviction that spatial- institutional metaphors carry useful inferential structure when their internal relationships mirror architectural relationships. The present method extends that conviction by proposing that the source domain should be specific enough to carry connotational weight, not generic enough to be drained of it. 2.6. Extreme Programming and the System Metaphor Beck's Extreme Programming methodology proposes a "system metaphor" practice in which a development team chooses an architectural metaphor early in a project to provide a shared vocabulary [XP-Metaphor]. The practice acknowledges both the generativity of metaphor (the analogies suggest new ideas about the system) and its risks (a flawed metaphor leads to confusion when the analogy breaks). The XP system metaphor practice has been described in retrospect as among the least successfully adopted of XP's practices. Kruchten suggests this may be because the practice was named too modestly: "Beck should have boldly called it Allegory: an extended metaphor in which a story is told to illustrate an important attribute of the subject, or even a Parable!" [Kruchten-Metaphors]. The present method shares the XP system metaphor's central conviction that a vocabulary should be chosen deliberately and shared across the team. It differs in providing an explicit stepwise procedure for choosing the metaphor, criteria for evaluating candidates, and explicit failure modes to watch for. The method is intended to address the practical question that the XP practice left open: how does a team actually choose a good metaphor? 2.7. Working Languages Absorb Local Experience: Two Illustrations The method proposed in this document does not claim that technical English should be replaced by another language. It claims something narrower and more defensible: that working languages have always grown by absorbing local cultural- linguistic experience, that this absorption strengthens rather than fragments the shared language, and that the present method is a structured and repeatable version of a practice that working languages already perform informally. Two traditions illustrate the underlying pattern. The first illustration is the Hispanic philological tradition that treats Spanish as a single language enriched by its bicontinental life. Ángel Rosenblat's Nuestra lengua en ambos mundos [Rosenblat-1971] is a representative work. Rosenblat treats the language as one organism whose unity is preserved precisely because each region's cultural-linguistic experience contributes to the shared lexicon rather than fragmenting it. The two mundos of his title are the Iberian peninsula and the Americas, and the work's central argument is that the local developments of each region — the lexical contributions of indigenous languages, the institutional vocabularies of colonial life, the regional turns of phrase that emerge from particular landscapes and economies — strengthen the language rather than dividing it. The institutional expression of the same conviction is the panhispanic lexicographical tradition: the Diccionario de Americanismos documenting the lexical contributions of the Americas to Spanish [Diccionario-Americanismos], the Diccionario Panhispánico de Dudas adjudicating usage questions across the entire Spanish-speaking world rather than imposing a single regional norm [DPD], and the Asociación de Academias de la Lengua Española [ASALE] in which twenty-three national academies work jointly on the principal works of Spanish lexicography. Each region's local cultural-linguistic experience contributes to the shared lexicon; none replaces the others. The Mexican Academy's volume El español y el náhuatl: Encuentro de dos mundos [Espanol-Nahuatl] addresses the bidirectional borrowing that occurred when Spanish met Náhuatl in the sixteenth century, and treats the resulting lexical enrichment as a strengthening rather than a dilution of the language. The second illustration is English itself. English vocabulary is, by historical record, perhaps the most absorptive of any major working language [Durkin-Borrowed]. Where the Hispanic tradition manages absorption through national academies and coordinated lexicography, the English-speaking world has famously taken the opposite path: there has never been a national academy in Britain, the United States, or any other English-speaking country attempting to restrict loanwords. The absorption proceeds informally, driven by the working communities encountering new concepts, and the language has nevertheless remained recognizably one language across the continents and centuries. The historical pattern is well documented. Norman French contributed the institutional and legal vocabulary of medieval English administration (court, judge, justice, parliament, verdict). Latin and Greek contributed the academic and scientific vocabulary that emerged with the medieval and Renaissance universities (species, radius, vacuum, hypothesis, phenomenon, psychology, chromosome). Arabic contributed the mathematical, astronomical, and chemical vocabulary that accompanied the transmission of Greek-Arabic scholarship into Latin Europe (algebra, algorithm, zenith, alkali, alcohol, cipher). German contributed scientific and philosophical terms when German universities were the centers of nineteenth- and early-twentieth-century research (gestalt, zeitgeist, eigenvalue, bremsstrahlung). In each case the borrowing community was a working community of practitioners who needed words their ambient vocabulary did not supply, and the borrowing strengthened rather than fragmented the language. Software engineering itself has continued this pattern. The word algorithm derives from al-Khwarizmi, the ninth-century Persian mathematician whose Arabic name was Latinized in the medieval translation tradition. The word robot derives from Czech robota, coined by Karel Čapek in 1920. The word avatar derives from Sanskrit, entered English through nineteenth- century Indological scholarship, and was adopted into computing in the 1980s for player-controlled representations. The word daemon, in the precise computing sense of a background process, was introduced at MIT's CTSS project drawing on the archaic spelling of Greek-derived demon, and the term is documented throughout the Jargon File / New Hacker's Dictionary tradition [Jargon-File]. The Japanese vocabulary of the Toyota Production System — kanban, kaizen, poka-yoke, muda, kata, dojo — entered software-engineering practice through the lean-thinking and agile traditions [Lean-Thinking], and is now standard terminology across the industry. Each of these terms encodes a commitment that the available English vocabulary did not compactly express: kanban encodes pull-based scheduling; kaizen encodes incremental improvement as discipline; poka-yoke encodes mistake-proofing as design. What the two illustrations share is more important than what distinguishes them. In both cases, working communities encountering new architectural, institutional, or operational commitments have absorbed terms from local cultural-linguistic experience to encode those commitments, and the resulting vocabularies have strengthened rather than fragmented their ambient languages. The Hispanic tradition pursues this absorption with structured panhispanic coordination; the English tradition pursues it without any coordination at all. Both work. The contribution of the present method is neither to invent the practice nor to monopolize it. The practice exists; the method offers a structured and repeatable version of it for teams who want to apply it deliberately rather than incidentally. A team that adopts the method to construct a distributed-system vocabulary is doing, for one architecture, what English has always done at the level of the language as a whole: absorbing local cultural-linguistic experience to encode commitments the ambient vocabulary does not carry. The novelty is the structure (the explicit steps of Section 4, the evaluation criteria of Section 6, the canonical-lexicon discipline of Step 6). The borrowing itself is ordinary. This framing also rebuts an objection that might otherwise apply. Critics might argue that constructing technical vocabularies from non-Anglophone source domains threatens the universality of technical discourse. The historical record shows the opposite: the universality of technical discourse has been built by absorbing terms from many source languages, not by restricting absorption. The method proposed here continues that historical practice with greater discipline, not against it. 2.8. Cross-Cultural Considerations in Interaction Design Designers of interaction metaphors have long observed that metaphors are culturally specific. A metaphor that resonates with one cultural audience may be inert or confusing to another. Saffer's guidelines for design metaphors note explicitly that "metaphors are cultural" and that "different cultures have different conceptual frameworks, especially about abstract ideas." The "desktop" metaphor for personal computing relies on readers who have used a physical desktop; for readers without that background the metaphor functions as an opaque label rather than a generative analogy. The present method takes a position on this trade-off. It accepts that a vocabulary drawn from a specific cultural- linguistic tradition will impose adoption friction on readers who do not share that tradition. It argues that the friction is worth paying because opaque labels can be learned, while drained metaphors cannot be re-charged. A reader new to the source-domain vocabulary can read the lexicon definitions and acquire the meaning. A reader using a drained vocabulary cannot recover the connotational weight that has been worn off. This trade-off is also addressed by both traditions discussed in Section 2.7. The price of preserving regional or working- community contributions to a shared language is that speakers from one region encountering vocabulary from another region must learn the regional vocabulary; the benefit is that the shared language remains rich enough to encode the full range of cultural-linguistic experience its speakers bring to it. Both costs are real; the historical judgment of both Hispanic and English absorptive traditions, with which the present method aligns, is that the benefit exceeds the cost. 2.9. Controlled Vocabularies in IETF Tradition The IETF has a tradition of publishing controlled vocabularies as standalone informational documents. RFC 4949 [RFC4949] provides definitions, abbreviations, and explanations of terminology for information system security across more than three hundred pages of entries. RFC 6365 [RFC6365], which obsoletes RFC 3536 [RFC3536], establishes the terminology used in IETF discussions of internationalization. These documents serve as references that other IETF documents can cite to use the defined terms with precision. The bilingual glossary tradition in the Spanish-language technical community provides a parallel. Works such as the Glosario básico inglés-español de informática y tecnología [ATI-Glosario] and the Diccionario Politécnico de las lenguas Española e Inglesa [Diccionario-Politecnico] exist precisely because Spanish speakers working with English-dominated technical vocabularies need reference materials that preserve precision across the language boundary. The present document is not itself a controlled vocabulary in the RFC 4949 sense. It is a methodology for constructing controlled vocabularies. The El Mundo lexicon presented in Appendix A is a controlled vocabulary of the kind RFC 4949 represents, constructed using the method this document proposes. 3. The Central Claim 3.1. Generative Coherence The central claim of this document is that a metaphor drawn from a single coherent source domain, when carefully matched to a target architecture, produces a vocabulary with three simultaneous properties: *Coherence*: the relationships among terms in the vocabulary mirror the relationships among components in the target architecture, without contradiction. Because the source domain is unitary, terms can be reasoned about as a system. *Generativity*: when the target architecture introduces a new component for which no name yet exists, the source domain produces a candidate name through inspection rather than through ad hoc invention. The generation is organic: the source domain already contains the institution corresponding to the new architectural concern, and adopting its name preserves the coherence already established. *Connotational density*: each term carries historical, social, or institutional meaning beyond its denotation, such that the term encodes commitments the bare denotation would not convey. The claim is that these three properties are achievable simultaneously when the source domain is well-chosen and the mapping is performed carefully, and that they are achievable together rather than in isolation. A vocabulary with coherence but no connotational density (such as a vocabulary built from abstract Greek or Latin roots) misses the encoding of commitments. A vocabulary with connotational density but no coherence (such as a vocabulary that draws individual evocative terms from many domains) cannot generate new names without blending failures. Both properties together require a single coherent source domain rich enough to supply institutions matching every architectural concern the system raises. The claim is bounded in scope. It is not a claim that all distributed-system vocabularies should be constructed this way. It is a claim that for systems whose architectural commitments include preservation, authority, provenance, or other concerns that benefit from connotational encoding, this method offers a route to a vocabulary that supports those commitments better than the conventional English-default vocabulary does. 3.2. Connotational Preservation as Supporting Argument The supporting observation, which informs but does not constitute the central claim, is that vocabularies drawn from non-dominant linguistic-cultural traditions can preserve architectural commitments that the dominant technical English vocabulary has worn smooth. This observation operates at the level of individual terms rather than at the level of vocabulary construction. The English word "ledger" today is closer to "any append-only data store" than to its earlier meaning of bookkeeping with its discipline and accountability. The English phrase "audit trail" suggests passivity and post-hoc inspection. A team committing to immutable operational truth and active institutional authority cannot encode those commitments in those English terms; the words have been worn flat by decades of imprecise use. By contrast, a Spanish word such as *pulpería*, naming the country store that historically kept its books in public, settled disputes openly, and never unilaterally rewrote its records, carries the architectural commitment in its connotation. A reader who understands the term's historical weight inherits the commitment without needing it spelled out. The same applies to *cabildo* (the colonial-era town council whose records carried legal weight), *escribanía* (the notary's office that conferred legal force by sealing documents), *cartilla* (the credential booklet that accumulated the bearer's civic history rather than merely identifying them at a moment in time). This observation is empirically true at the level of individual word choices. It is offered here as supporting argument rather than central claim because the central methodological contribution does not depend on it. The method works equally well when applied to source domains in any linguistic tradition; it does not require the source domain to be non-dominant or the language to be non-English. A team using the method to construct a vocabulary from the source domain of, for example, medieval European trade guilds, or pre-industrial Japanese craft hierarchies, or 19th-century railroad operations, would produce a coherent vocabulary with generative properties even though none of those source domains is non-dominant in the author's sense. The connotational-preservation observation, however, suggests a reason why the method can be especially valuable when applied to source domains drawn from non-dominant traditions: the vocabularies of dominant traditions have been more thoroughly worn by use, while the vocabularies of less-frequented traditions retain more of their connotational weight. 3.3. Failure Modes the Claim Addresses The claim is partly defined by the failure modes it attempts to address. Three are particularly worth naming. *Blending failure*: the construction of vocabularies that mix source domains, producing terms whose individual meanings may be apt but whose collective relationships do not cohere. Kruchten's catalog of metaphor failure modes identifies this as a common error, and most conventional distributed-system vocabularies suffer from it: pipes, services, clusters, containers, queues, and events do not cohere as a system. *Drainage failure*: the use of metaphors so worn by repeated use that they no longer carry inferential power. Conventional English software-engineering vocabulary suffers from drainage broadly, with specific severity in terms whose original institutional meaning has been thinned by indiscriminate use. *Stranding failure*: the case in which an architecture introduces a new component for which the existing vocabulary has no counterpart in its source domain, leaving the team to invent ad hoc names that strain or break the existing metaphor. Most architectures eventually encounter stranding when they evolve beyond the source domain that generated their initial vocabulary. The proposed method addresses blending by requiring a single coherent source domain. It addresses drainage by selecting source domains whose terms retain their institutional connotations. It addresses stranding by selecting source domains rich enough to contain institutions corresponding to a wide range of architectural concerns, and by treating the source domain as a generator rather than as a fixed term list. 4. The Method 4.1. Overview The method consists of six steps. Steps 1 and 2 are largely independent and may be performed in either order or in parallel. Steps 3 through 5 are iterative; the method explicitly assumes that not every candidate source domain will pass mapping validation, and that early candidates may be rejected after substantial work. Step 6 closes the loop by establishing the lexicon as a documented institutional artifact. The method is intended to be applied by a small group of architects and engineers working together. It is not amenable to fully individual or fully crowdsourced application; the judgments at Step 3 require collective reasoning about both the target architecture and the candidate source domain, and the judgments are partly aesthetic. The method assumes that the target architecture is sufficiently stable that its principal commitments can be characterized. Applying the method to an architecture still in flux produces a vocabulary that may need substantial revision once the architecture stabilizes; deferring vocabulary construction until the architecture is settled is generally preferable. 4.2. Step 1: Characterize the Target Architecture The first step is to characterize the target architecture in terms its vocabulary will need to support. The output of this step is a written list of architectural commitments and a preliminary inventory of components. The list of commitments includes the system's principal guarantees (immutability, authoritativeness, provenance, availability, consistency), its principal relationships (single- tenant or multi-tenant, federated or centralized, online or offline-tolerant), and its principal operational concerns (audit, security, retention, dispute resolution). The inventory of components includes both currently-recognized components and anticipated components that the architecture is expected to include but has not yet specified. The inventory should be thorough enough that the team can recognize, when examining a candidate source domain, whether the source contains institutions corresponding to each component. The output of Step 1 is the basis for Step 3's mapping validation. Without a clear characterization of the target, mapping cannot be evaluated. 4.3. Step 2: Identify Candidate Source Domains The second step is to identify one or more candidate source domains. Each candidate is a cultural, geographic, institutional, or social field whose internal structure is rich enough to contain institutions corresponding to the target architecture's components and relationships. Good candidates share several properties: *Internal richness*: the source domain contains many distinct institutions, roles, processes, and artifacts, providing a wide palette of names to draw on. *Structural articulation*: the source domain's institutions relate to one another in well-defined ways (authority, delegation, exchange, memory, dispute resolution), so that the relationships among names can mirror architectural relationships. *Historical depth*: the source domain has been studied or recorded in enough depth that team members can learn its institutions through accessible references, rather than requiring ethnographic original research. *Connotational vitality*: the source domain's terms still carry institutional weight in the linguistic community to which the team belongs, rather than having been thinned by overuse or reduced to opaque historical curiosities. Candidate source domains drawn from the team's own cultural- linguistic tradition tend to satisfy connotational vitality automatically; candidates drawn from foreign traditions may require the team to verify that the chosen source's terms still carry weight in their original linguistic community. It is generally productive to identify several candidates rather than committing to one immediately. Step 3 is most informative when it has alternatives to compare. 4.4. Step 3: Test Source-Target Mapping The third step is to test, for each candidate source domain, whether a systematic mapping exists between source-domain institutions and target-architecture components. This is the step at which most candidates fail; the test should be undertaken in good faith with willingness to reject. The test proceeds by attempting to find, for each architectural component identified in Step 1, an institution in the candidate source domain whose function corresponds. The correspondence need not be perfect, but it must be defensible: the team should be able to articulate, for each pairing, why the source-domain institution genuinely matches the architectural component rather than merely serving as a convenient label. Three failure modes commonly emerge during Step 3. *Coverage failure*: the source domain lacks institutions corresponding to one or more important architectural components, forcing the team to either invent names ad hoc (breaking the coherence the method aims for), or to abandon the candidate. *Strain*: the source domain technically contains an institution for each component, but several pairings are stretched, requiring the team to argue that an institution serves a function it historically did not. Strained mappings tend to break in practice when the architecture evolves; if many mappings are strained, the candidate should be rejected. *Inversion*: the source domain's relationships among institutions contradict the target architecture's relationships among components. A source domain in which authority flows from the periphery to the center should not be mapped to an architecture in which authority flows from the center to the periphery, even if the individual institutions correspond. Inversions are subtle and often discovered late; they are reason to reject the candidate. The test is iterative. The team examines pairings, identifies strain or inversion, and either revises the mapping or rejects the candidate. A candidate that survives Step 3 with all pairings defensible and the relationships intact is a strong candidate; one that survives only with substantial strain or significant inversions should be rejected even if alternatives are unavailable. 4.5. Step 4: Adopt or Reject The fourth step is the decision: adopt the surviving candidate as the source domain, or reject all candidates and return to Step 2. Adoption is a substantive commitment. Once a source domain is adopted, the team is committing to use its vocabulary throughout code, documentation, and conversation; to respect its internal coherence; to allow it to generate names for new components; and to resist the temptation to translate or substitute its terms in moments of friction. The commitment should not be undertaken lightly. Rejection is also legitimate. A team that examines several candidates and finds none satisfactory may be working with a target architecture too novel for any existing source domain to match. In that case the appropriate response is to defer vocabulary construction until either the architecture has matured (and a candidate emerges naturally) or until the team is prepared to accept the conventional English-default vocabulary with its known limitations. The decision should be documented with reasoning, so that future team members understand why the chosen source domain was selected and why alternatives were rejected. 4.6. Step 5: Apply the Vocabulary Iteratively The fifth step is the application of the adopted vocabulary throughout the project. This is not a one-time renaming exercise; it is an ongoing practice that continues as the architecture evolves. When a new component is introduced for which no term yet exists in the lexicon, the team consults the source domain. The institution in the source domain whose function matches the new component's function is identified, and its name is adopted into the lexicon. The team documents the addition, including the reasoning that connects the source-domain institution to the architectural component. The method assumes that this generation will succeed in most cases, because Step 3's mapping validation confirmed that the source domain has sufficient richness. When generation fails for a specific new component, the team should examine whether the architectural component is genuinely novel (in which case careful invention may be necessary) or whether the source-domain institution has been overlooked (in which case more careful inspection is warranted). Repeated generation failures may indicate that the source domain is, in fact, less rich than Step 3 suggested, or that the architecture has evolved beyond the source domain's scope. In either case the team should reconsider whether the source domain remains appropriate. 4.7. Step 6: Document the Lexicon Canonically The sixth step is to establish the lexicon as a documented institutional artifact, with a clear status, a versioning convention, and a single canonical location. The lexicon document should include, for each term: the canonical spelling, the source-domain institution from which it is drawn, the architectural component it names, the rationale for the pairing, and any nuances that adopters should preserve. The document should also include conventions for use (in code, in documentation, in customer-facing material) and the methodology for proposing additions. Canonical status is important because it prevents the proliferation of imperfect adoptions that Section 7 discusses. When team members or external readers want to use the vocabulary, the canonical document is the source of truth; when the vocabulary appears in derivative documents (specifications, marketing material, public publications), it can be checked against the canon. The lexicon should be versioned. Substantive changes (new terms, refined definitions, deprecations) bump the version; cosmetic changes do not. Derivative documents that reference the lexicon should record which version they reflect. 4.8. Anti-Patterns and Failure Modes Several anti-patterns commonly emerge when teams attempt to apply the method without sufficient discipline. These are not failures of the method itself but failures in its application. *Decoration over commitment*: the team adopts colorful names from a source domain but does not require that the names encode architectural commitments. The vocabulary becomes flavorful labeling rather than load-bearing structure. This anti-pattern is detected by asking, for each term, whether removing the chosen name in favor of a generic English equivalent would change anything about how engineers think about the component. If not, the term is decoration, not method output. *Blending under pressure*: the team adopts a primary source domain but, when stranding occurs in Step 5, borrows from a second domain rather than rejecting the strand or revisiting Step 4. The vocabulary's coherence degrades; over time the discipline erodes and the vocabulary returns to conventional blended state. *Preciousness*: the team treats the lexicon as inviolable and resists necessary revision when the architecture evolves or when a term proves wrong in practice. Lexicons should be respected but not frozen; Step 6's versioning convention exists precisely to allow disciplined evolution. *Translation drift*: the team allows translated equivalents of the chosen vocabulary into code or documentation as a courtesy to readers unfamiliar with the source domain. The translations strip the connotational weight that motivated the choice in the first place; over time, the translations become primary and the original terms become decorative footnotes. The defense is to refuse translation as a discipline, accepting the adoption friction this imposes on new readers. These anti-patterns are described to be recognized and resisted, not avoided perfectly. Real teams will encounter all of them; the test is whether the team recognizes the drift and corrects it, not whether the drift never occurs. 5. Worked Example: The El Mundo Lexicon 5.1. Target Architecture The El Mundo lexicon was constructed for a distributed industrial-data platform whose principal commitment is the immutable preservation of operational truth from remote field environments into a unified ledger system spanning both local deployments and central services. The platform is targeted initially at the upstream oil and gas sector with deployments in Latin America and the Gulf Coast, but is designed to generalize. The architectural commitments characterized in Step 1 included: append-only data preservation; original timestamps and original units of measurement preserved verbatim; full provenance on every datum; explicit recording of conflicting readings as conflicts rather than silent reconciliation; SOC 2 compliance as the natural expression of the architecture rather than a bolt-on layer; and the support of both multi-tenant cloud and single-tenant on-premises deployments with optional federation. The component inventory included field-deployable units handling sensor acquisition and local buffering; the wire transport from field to center; the canonical operational ledger; an audit ledger distinct from the operational ledger; a cryptographic notary supporting both internal tamper-evidence and optional public-chain anchoring; long-term archive storage; a data exchange surface governing all ingest and export; intra- and inter-deployment messaging; an administrative control plane; identity registry and credentials; conflict resolution process and the role that adjudicates conflicts. 5.2. Source Domain Selection Several candidate source domains were considered in Step 2. Candidates included generic-city geography (drawing on the city metaphor tradition), medieval European trade guilds, 19th- century railroad operations, post-industrial logistics networks, and the institutional life of the rural pueblo in post-colonial Spanish America. Each was tested against the component inventory in a Step 3 mapping exercise. Generic-city geography produced a vocabulary with adequate coverage but limited connotational density; "district," "building," "street" did not encode architectural commitments much beyond their literal meanings. Medieval European trade guilds produced a vocabulary rich in connotational density but with strain in coverage: the guild institutional structure did not naturally accommodate field- deployment versus central-deployment distinctions. The rural Spanish-American pueblo emerged as the strongest candidate. Its institutional structure included a clear distinction between *el campo* (the field, where work happens) and *el pueblo* or *campamento* (the town or camp, where records and authority reside). Its institutions included the *baqueano* (the local guide whose knowledge of the terrain was indispensable to long-distance work), the *pulpería* (the country store, bar, post office, and informal court of record), the *cabildo* (the town council whose records had legal force), the *escribanía* (the notary's office that sealed documents), the *bóveda* (the vault for long-term safekeeping), the *mercado* (the marketplace whose exchanges were governed by posted rules), the *correo* and *correo mayor* (the postal service and its colonial governing institution), the *padrón* (the citizen registry), the *cartilla* (the credential booklet that accumulated the bearer's civic history), and the *árbitro* (the arbitrator who resolved disputes). Each architectural component identified in Step 1 found a defensible source-domain match. The relationships among institutions in the source domain mirrored the relationships among components in the target architecture. The candidate was adopted in Step 4. 5.3. Mapping Validation The mapping was validated by walking each major architectural commitment and confirming that the source-domain term encoded it. *Append-only preservation* is encoded in *pulpería* (the country store kept its books in public on a board behind the counter; entries were added, never erased) and in *cabildo* (the colonial town council's records were ratified and added to, never silently rewritten). *Provenance* is encoded in the *posta* concept (originally the relay station where messengers changed horses, the term doubling colloquially in modern Argentine Spanish to mean "authoritative truth" — *está en la posta* meaning both "it has been delivered to the relay station" and "it is the authoritative record"). Each datum in transit is a *posta* carrying both its message and its authority. *Conflict-as-conflict, not silent reconciliation* is encoded in *careo* (the formal legal procedure of confronting two conflicting witnesses face to face) and *árbitro* (the arbitrator who hears the *careo* and rules). Both readings are preserved; the resolution is itself a recorded act. *Cryptographic notarization* is encoded in *escribanía*. The colonial-era escribano did not produce truth; he sealed documents others produced, conferring legal force through the sealing. The cryptographic notary in the architecture occupies the same functional position. *Identity that accumulates history* is encoded in *cartilla*. The historical Argentine cartilla was not merely an identification document; it accumulated the bearer's civic acts as stamps over a lifetime. The architectural identity credential, similarly, accumulates audit trail through every action its bearer performs in the system. The mapping was deemed sufficiently defensible across the inventory to justify adoption. 5.4. Selected Vocabulary Twenty-seven terms were adopted in the initial application of the method. The full term definitions appear in Appendix A. A summary table is provided here for orientation. +------------------+--------------------------------------------+ | Term | Architectural component | +------------------+--------------------------------------------+ | Mundo | The whole system | | Campo | Field-side environment | | Pueblo | Cloud-side environment, multi-tenant | | Campamento | Cloud-side environment, single-tenant | | Baqueano | Field tier software | | Aperos | Field tier hardware | | Rastro | Field perception layer | | Cuadrilla | Field-tier peer mesh | | Capataz | Fleet management agent | | Posta | Data unit in transit | | Senderos | Wire transport layer | | Pulpería | Operational ledger | | Cabildo | Audit ledger | | Escribanía | Cryptographic notary | | Sello | Cryptographic signature | | Testimonio | Verification artifact | | Bóveda | Long-term storage | | Mercado | Data exchange surface | | Correo | Intra-environment messaging | | Correo Mayor | Federation governance | | Diligencias | Federation transport | | Centro | Administrative control plane | | Foro | Documentation portal | | Padrón | Identity registry | | Cartilla | Identity credential | | Careo | Conflict resolution process | | Árbitro | Conflict resolver service | +------------------+--------------------------------------------+ The relationships among these terms mirror the relationships among the architectural components they name. Baqueanos work in *el campo* and forward Postas along Senderos to the Pulpería in the Pueblo or Campamento. The Pulpería's records are sealed by the Escribanía with a Sello; verification produces a Testimonio. Acts upon the system are recorded in the Cabildo. Long-term retention moves to the Bóveda. Data exchange with external systems flows through the Mercado. Messaging within an environment is handled by Correo; federation between environments is governed by Correo Mayor and transported by Diligencias. Identity is enrolled in the Padrón and credentialed by Cartilla. Conflicts between Postas are adjudicated through Careo by the Árbitro. Each of these statements, expressed in vocabulary, encodes an architectural commitment. 5.5. Generative Episodes During Construction The method's claim of generativity was tested during construction, when several architectural concerns emerged that had not been anticipated in the initial Step 1 inventory. In each case, the team consulted the source domain, identified the corresponding institution, and adopted its name. Three episodes are illustrative. *The federation governance and transport split.* The initial inventory included intra-environment messaging (Correo) but did not yet anticipate the need to distinguish federation governance from federation transport when the platform began to address multi-region deployments. Inspection of the source domain produced two distinct institutions: the Correo Mayor (the colonial Spanish institution that governed routes, schedules, and trust frameworks for inter-city postal service) and the Diligencias (the stagecoaches that actually moved between cities under Correo Mayor's authority). Architecturally, this maps to the well-known distinction between federation policy and federation protocol; the source domain produced both names without strain. *The on-premises deployment.* The initial inventory included the cloud-side environment as a single concept (Pueblo). When the architecture introduced support for single-tenant on- premises deployments, the team needed a parallel name that captured the differences: customer-operated rather than provider-operated, single-tenant rather than multi-tenant, self-contained rather than shared. The source domain produced *campamento* — the term used in Argentine Spanish for an oil company's operational base, a self-contained single-purpose installation operated by the company that owns it, distinct from the public pueblo. The mapping was exact and required no strain. *Conflict resolution.* The initial inventory recognized that conflicting Postas needed to be recorded as conflicts but did not name the resolution process or the resolver. The source domain provided both: *careo*, the formal legal procedure of confronting two conflicting witnesses, and *árbitro*, the arbitrator who rules. Each name encoded an architectural commitment that bare English equivalents (*"dispute resolution process"*, *"resolver service"*) would have left implicit. In each episode, the source domain produced names that the team adopted with confidence, without invention or strain. The episodes are presented as evidence that the generativity claim is not merely theoretical: it operated in practice. 5.6. Connotational Preservation in the Example The supporting observation of Section 3.2 was visible in the construction. Several terms were chosen specifically because their Spanish-language connotations encoded architectural commitments that no English equivalent preserved. *Cartilla* was chosen over alternatives such as *credential* or *identity document* because the historical cartilla accumulated the bearer's civic history; modern English equivalents do not. The architectural credential in El Mundo accumulates audit trail through every action its bearer performs, and the Spanish term encodes that commitment in its institutional history. *Pulpería* was chosen over alternatives such as *operational ledger* or *primary store* because the historical pulpería kept its books in public on a board behind the counter and settled disputes openly. Modern English *ledger* has been worn smooth by use to mean any append-only data store; the discipline of the pulpería is not in the word. Adopting *pulpería* placed the discipline back in the name. *Escribanía* was chosen over alternatives such as *notary service* or *signing layer* because the historical escribano did not produce truth but conferred legal force on documents others produced. The architectural commitment of the cryptographic notary is structurally identical: it does not make data true; it cryptographically confers force on data produced by other components. The Spanish term encodes that structural relationship; English equivalents do not. These cases are presented as evidence for the supporting observation that connotational preservation is achievable in non-dominant linguistic vocabularies when matching English alternatives have been thinned by use. 6. Evaluation 6.1. Coherence The vocabulary's coherence was evaluated by examining whether relationships among terms in the lexicon mirror relationships among architectural components. Examination found no contradictions: every architectural relationship the platform designed had a corresponding institutional relationship in the source domain, and the directional structure (authority, delegation, exchange) was preserved. One minor strain was identified during evaluation: the relationship between *Cuadrilla* (peer mesh) and *Capataz* (fleet management) is asymmetric in the architecture, with Capataces commanding many Baqueanos while Cuadrillas are peer relationships among Baqueanos at one site. In the source domain, the Capataz was historically the foreman of an estancia and could indeed command multiple cuadrillas, so the asymmetry maps cleanly. No revision was required. 6.2. Generativity Generativity was evaluated by counting the terms that emerged from the source domain during construction (Section 5.5 reports three principal episodes) versus the terms invented ad hoc or borrowed from other domains. No ad hoc inventions were required; no borrowing from other domains occurred. Every architectural concern encountered during construction was named from the source domain. This evaluation is limited to the construction period. Future evolution of the architecture may introduce concerns the source domain does not contain. Section 8 identifies this as future work. 6.3. Connotational Density Connotational density was evaluated qualitatively by examining each term and asking whether its source-domain history encoded architectural commitments beyond the bare denotation. For approximately half the terms (Posta, Pulpería, Cabildo, Escribanía, Cartilla, Mercado, Careo, Bóveda, Correo Mayor, Diligencias, Baqueano, Capataz), the connotational encoding was substantial. For others (Mundo, Campo, Pueblo, Centro, Foro), the encoding was lighter, with the term carrying primarily denotational meaning. This distribution is consistent with expectations: not every term needs to be load-bearing. The vocabulary as a whole is load-bearing because its structural terms (those naming ledgers, notaries, registries, exchanges) carry weight, and its lighter terms (those naming environments, control planes, documentation surfaces) do not need to. 6.4. Adoption Friction The adoption friction the method's vocabularies impose on readers was evaluated through informal observation during the project. Engineers familiar with the source-domain culture acquired the vocabulary essentially instantly. Engineers unfamiliar with the source-domain culture required approximately one to two hours with the lexicon document to internalize the principal terms, with full fluency emerging over weeks of regular use. This friction is real but bounded. It is comparable to the friction of learning any new technical vocabulary; engineers joining any new project must learn its terminology. The distinguishing feature of the El Mundo vocabulary is that its terms encode commitments rather than merely labeling components, which engineers reported as making the architecture easier to remember rather than harder. 6.5. Limits of Single-Example Evaluation This evaluation is based on one application of the method. A single example cannot validate a method; it can only illustrate it and demonstrate that the method's claimed properties were achieved at least once. Properties that appeared to hold in the El Mundo lexicon may or may not hold in other applications; failure modes that did not arise here may arise elsewhere. The honest claim the document can make is that the method was applied successfully in one case, that the predicted properties were observed, and that the method appears amenable to application by other teams. Stronger claims require additional applications, ideally by different teams in different cultural-linguistic traditions and different target architectures. Section 8 identifies this as future work. 7. Discussion 7.1. When the Method Applies The method is most useful for distributed-system architectures whose principal commitments include preservation, authority, provenance, audit, dispute resolution, or other concerns that benefit from connotational encoding in their vocabulary. For such systems, the conventional English-default vocabulary's wear is a real cost, and the method's vocabulary provides real value. The method is also useful for architectures sufficiently complex that vocabulary discipline matters. For small systems or short-lived projects, the overhead of constructing a custom lexicon may exceed the benefit; the conventional vocabulary's familiarity outweighs its wear. The method is most successful when the team applying it includes members fluent in the source-domain culture. A team borrowing from a foreign culture without genuine fluency risks shallow adoption and the proliferation of imperfect adoptions discussed in Section 7.4. 7.2. When the Method Does Not Apply The method does not apply well in several cases worth naming. *Architecture in flux*: applying the method before the target architecture has stabilized produces a vocabulary that may need substantial revision; deferring is preferable. *Genuinely novel architectures*: when the target architecture introduces structural innovations that no historical source domain has institutions matching, the method strands. In such cases the architecture itself may be the contribution, and vocabulary should follow rather than lead. *Teams without source-domain fluency*: as noted in Section 7.1, fluency is a precondition. Teams without it should consider engaging members who have it before adoption, or should select source domains within their own cultural- linguistic tradition. *Standardization contexts*: vocabularies intended for use across organizations and across cultural boundaries (the IETF tradition) face stronger adoption-friction constraints than internal vocabularies. The method may be applied to internal architectural vocabularies even when the broader domain's standardized vocabulary remains conventional English. 7.3. Translation, Loss, and the International Audience A vocabulary constructed by the method described in this document is, by design, untranslated. Each term remains in the source-domain language in code, in documentation, and in conversation. This decision is not ornamental; it follows from a specific observation about what happens to load-bearing words when they cross between languages. A term carries two distinct kinds of meaning. The first is denotational: the literal class of object or concept the term names. The second is connotational: the bundle of historical, social, institutional, and emotional associations the term evokes for native speakers. Translation reliably preserves the first and reliably loses some portion of the second. For ordinary technical vocabulary this loss is acceptable, because the denotation is what matters. For vocabularies constructed by the method, the connotation is what makes the term useful, and translation strips the term of its function. Consider Pulpería from the El Mundo example. The denotational translation is "country store" or "general store." Both are correct and both are functionally useless. The pulpería was a country store, but it was also a bar, a post office, an informal court, a gossip exchange, a credit institution, and the place where strangers were vetted by the locals. The pulpero kept records on a board behind the counter. Disputes over those records were resolved on the spot, in public. None of this travels in the phrase "country store." A reader who knows only the denotation will not understand why the term was chosen for a canonical operational ledger; a reader who knows the connotation will understand instantly. The methodological implication is that vocabularies constructed by this method should retain their original- language forms in code and documentation. Adoption friction for non-native readers is the price paid for connotational preservation; the price is paid willingly, and the friction is bounded by accessible reference material. 7.4. The Proliferation of Imperfect Adoptions A second phenomenon related to but distinct from translation loss arises when speakers of a target language adopt a term from a source language without fully understanding the source-language nuance. The result is a proliferation of terms in the target language that are formally similar to the source term but that have shifted in meaning. Over time, the shifted meaning may become standard in the target language while remaining incorrect from the perspective of the source language. For vocabularies constructed by this method, this phenomenon presents a specific risk: as the vocabulary spreads from its original team to a wider audience, individual terms may be adopted with reduced or altered meaning, and the resulting imperfect usage may then be cited as authoritative by subsequent adopters. Two illustrations from the El Mundo example are instructive. *Posta mistranslated as "post."* The term Posta in the El Mundo lexicon names the unit of data in transit, with the dual meaning of "relay-station message" and "authoritative truth." When adopted by speakers who know only the denotational meaning, the connotation evaporates. Posta becomes synonymous with "post" in the sense of a posted message, and the architectural claim that a Posta is both message and truth is lost. Subsequent adopters who learn from these reduced uses inherit the reduced meaning. *Cabildo conflated with "council."* The term Cabildo names the audit ledger, drawing on the colonial Spanish-American institutional history in which the cabildo was the seat of municipal authority whose records carried legal weight. When translated as "council" or "town council," the institutional specificity is lost; "council" in English denotes a wide range of advisory bodies, many without formal authority. A Cabildo so misunderstood becomes a generic discussion forum rather than the authoritative recorder of acts upon the system. The defense against this drift is the canonical lexicon itself. Adopters who consult the canonical reference encounter both denotation and connotation explicitly. Adopters who take terms from secondary or tertiary sources may not. The methodological implication is that lexicons should be canonical, accessible, and version-stamped, and that derivative documents should reference specific lexicon versions rather than implying paraphrased equivalents. 7.5. Cultural Authority and Its Responsibilities The deliberate use of vocabulary drawn from a non-dominant linguistic-cultural tradition in technical work raises questions of cultural authority that deserve explicit acknowledgment. The El Mundo lexicon draws from a specific tradition (post- colonial Spanish-American rural institutional life) which is the cultural background of one of the present authors. The borrowing is from within rather than from without; the authors are not claiming to speak for a tradition not their own. This matters: methods that propose adopting vocabulary from foreign cultures should be applied with care, because such borrowing risks being received as appropriation rather than as honoring. For teams whose own cultural-linguistic background offers suitable source domains, the method described here can be applied directly to source domains within that background. For teams who wish to draw on traditions outside their own background, the responsibilities are heavier: members of the source-domain culture should be involved meaningfully in construction, the borrowing should be acknowledged explicitly, and the resulting vocabulary should be open to feedback from members of the source-domain culture who are not part of the construction team. The method does not require borrowing from non-dominant traditions; the central claim of generative coherence applies equally well to source domains in any tradition. The supporting argument about connotational preservation applies especially well to non-dominant traditions because their vocabularies have been less worn by use, but the central contribution does not depend on this argument. The present document is published in part to make the method available to teams working in many traditions, with the hope that vocabularies constructed in many cultural-linguistic backgrounds will enrich the discipline. 8. Future Work Several directions of future work are identified, none of which the present document undertakes. *Multiple worked examples*. The method's claimed properties have been observed in a single application. Additional applications, ideally in different target architectures and different source-domain traditions by different teams, would strengthen the empirical basis for the claim and identify failure modes the present worked example did not exhibit. *Empirical adoption studies*. The method's effect on team communication, onboarding time, architectural decision quality, and long-term codebase comprehensibility could be studied empirically. The present document offers only informal observations. *Tooling*. Automated checks for vocabulary consistency (every Pulpería reference resolves to the canonical term; no ad hoc names slip in) could be built into linters and documentation generators. The lexicon's canonical-document format could be standardized so that tools could parse it. *Cross-domain studies*. The relationship between source- domain richness and architectural complexity is unclear. Some architectures may require source domains of specific sizes or structures; the present document does not characterize this relationship. *Federation of vocabularies*. When multiple platforms each adopt vocabularies via the method but using different source domains, federation between them raises translation questions the method does not address. 9. Security Considerations This document defines a method for constructing vocabularies and does not specify protocols, algorithms, or security mechanisms. Security considerations applicable to the distributed systems whose vocabularies are constructed using this method are properties of those systems and are addressed in their own architecture documents. One observation deserves note. A vocabulary that encodes architectural commitments in single words places those commitments in the foreground of every conversation that uses the vocabulary. Engineers who use a term such as Cabildo (in the El Mundo example) are reminded, every time they use it, that the audit ledger is an institution with authority and discipline rather than a debug log. This effect is indirect but real; vocabulary discipline contributes to security posture by shaping the discipline with which systems are implemented and operated. 10. IANA Considerations This document requests no actions from IANA. The method defined in this document is a procedure for constructing vocabularies; it does not allocate identifiers, define protocol parameters, register media types, or engage any other category of identifier for which IANA maintains registries. Vocabularies constructed by applying this method are internal artifacts of the systems that adopt them. Should any specific vocabulary constructed by the method be subsequently considered for cross-organizational standardization, that consideration would be a matter for a separate document and would have its own IANA considerations if any. 11. References 11.1. Informative References [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, DOI 10.17487/RFC3536, October 2003, . [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, . [Lakoff-Johnson] Lakoff, G. and M. Johnson, "Metaphors We Live By", University of Chicago Press, 1980. [Eco-1976] Eco, U., "A Theory of Semiotics", Indiana University Press, 1976. Italian original: "Trattato di semiotica generale", Bompiani, 1975. [Eco-1984] Eco, U., "Semiotics and the Philosophy of Language", Indiana University Press, 1984. Italian original: "Semiotica e filosofia del linguaggio", Einaudi, 1984. [ISO-1087] International Organization for Standardization, "ISO 1087:2019 - Terminology work and terminology science - Vocabulary", 2nd edition, September 2019, . [Kruchten-Metaphors] Kruchten, P., "Metaphors in Software Architecture", philippe.kruchten.com, July 2009, . [City-Metaphor] Moreno-Lumbreras, D., et al., "The influence of the city metaphor and its derivates in software visualization", Journal of Systems and Software, 2024. [XP-Metaphor] Beck, K., "Extreme Programming Explained: Embrace Change", Addison-Wesley, 1999. [Smolander-Architecture] Smolander, K., et al., "Four metaphors of architecture in software organizations: finding out the meaning of architecture in practice", IEEE International Symposium on Empirical Software Engineering, 2002, DOI 10.1109/ISESE.2002.1166942. [Rosenblat-1971] Rosenblat, Á., "Nuestra lengua en ambos mundos", Salvat Editores - Alianza Editorial, Estella, 1971, . [ASALE] Asociación de Academias de la Lengua Española, . [Diccionario-Americanismos] Asociación de Academias de la Lengua Española, "Diccionario de americanismos", 2010, . [DPD] Real Academia Española and Asociación de Academias de la Lengua Española, "Diccionario panhispánico de dudas", 2nd edition, 2025, . [Espanol-Nahuatl] Johansson, P., editor, "El español y el náhuatl: Encuentro de dos mundos (1519-2019)", Academia Mexicana de la Lengua, Colección Horizontes, 2020, ISBN 9786079871710. [ATI-Glosario] Carrión Tavárez, Á., "Glosario básico inglés- español de informática y tecnología", Asociación de Técnicos de Informática (ATI), . [Diccionario-Politecnico] Atienza, F. B., et al., "Diccionario Politécnico de las lenguas Española e Inglesa", 3rd edition, Editorial Díaz de Santos, 2009. [Durkin-Borrowed] Durkin, P., "Borrowed Words: A History of Loanwords in English", Oxford University Press, 2014. [Jargon-File] Raymond, E. S., editor, "The New Hacker's Dictionary", 3rd edition, MIT Press, 1996. Online continuation as "The Jargon File", . Original Jargon File compiled at the MIT AI Lab and Stanford AI Lab from 1975, edited in 1983 by Guy L. Steele as "The Hacker's Dictionary", Harper & Row. [Lean-Thinking] Womack, J. P. and D. T. Jones, "Lean Thinking: Banish Waste and Create Wealth in Your Corporation", Simon & Schuster, 1996. Appendix A. The El Mundo Lexicon: Term Definitions This appendix presents the full term definitions of the El Mundo lexicon as constructed in the worked example of Section 5. The definitions are reproduced here for readers who wish to study the method's outputs in detail. The internal canonical version of the lexicon is maintained separately by Roderick Consulting Inc.; this appendix reflects the lexicon at version 2026-05-03. A.1. Mundo Mundo names the whole system: field plus cloud, the entire universe of the platform. The term denotes totality and is used when discussing the system as one integrated entity or when addressing concerns that span the entire platform. The primary internal division of Mundo runs between Campo (field side) and Pueblo or Campamento (cloud side). A.2. Campo Campo designates the field-side environment, the portion of the platform where physical operations occur. Each individual remote site counts as one campo; the collective of all sites under platform management is el Campo. Field workers (the Baqueanos) perform their work in the campo. The historical resonance of "trabajar en el campo" captures the real, physical, weather-exposed labor at the edge of the system. A.3. Pueblo Pueblo names the multi-tenant cloud-side environment operated by the platform provider. It is the shared, public cloud destination where data arrives from many remote sites for reception, validation, sealing, archiving, and serving. Multiple tenants share the same Pueblo with isolation provided through tenancy controls. Pueblos exist in the plural; deployments may serve different geographic regions independently and federate when needed. A.4. Campamento Campamento designates the single-tenant on-premises cloud- side environment operated by the customer on its own infrastructure. The term evokes the self-contained operational base a company maintains at a remote site. A Campamento contains the same institutions as a Pueblo, scoped to one tenant. Campamentos may federate with Pueblos when the trust framework permits. A.5. Baqueano Baqueano names the field-tier software, the intelligence deployed at the remote operational site. The historical baqueano was the indispensable local guide who knew the terrain because he lived in it, who could read weather and danger where maps failed, and who was already present rather than dispatched from a distant center. The Baqueano software is a permanent intelligent presence at the remote site with deep local knowledge that the central tier does not possess. A.6. Aperos Aperos names the field-tier hardware: the physical gear of the Baqueano. The historical aperos were the gaucho's complete kit, including saddle, bridle, reins, blanket, knife, lasso, and other items needed for work on the open land. In the platform, Aperos comprise the embedded board, enclosure, antennas, cabling, sensor interfaces, power conditioning, and field-deployable ports. A.7. Rastro Rastro names the field-tier perception layer: the protocol decoding, sensor reading, timestamp resolution, unit-of- measurement preservation, and provenance assembly performed by the Baqueano. The historical rastro was the trail or sign read in the dirt by the baqueano: the broken twig, the hoofprint, the disturbed grass. The Rastro layer is what the Baqueano interprets from sensor inputs. A.8. Cuadrilla Cuadrilla names the peer mesh of multiple Baqueanos at one site. The historical cuadrilla was a small work crew under shared task and shared territory, with peer relationships among members. Architecturally, multiple Baqueanos at one site cooperate as a Cuadrilla to negotiate forwarding, relay traffic when one has lost backhaul, and coordinate over local mesh transports. A.9. Capataz Capataz names the fleet-management agent that commands many Baqueanos. The historical capataz was the foreman of the estancia, with vertical authority over workers. The Capataz dispatches updates to its fleet, monitors health, decides takeover when a Baqueano fails, allocates work across Cuadrillas, and acts autonomously where authorized. Capataz actions are recorded in the Cabildo with the Capataz's own Cartilla as the actor. A.10. Posta Posta names the unit of data in transit. The historical posta was the relay station where messengers changed horses on long routes; the term doubled colloquially in modern Argentine Spanish to mean "authoritative truth," with the phrase "está en la posta" meaning both "it has been delivered" and "it is the authoritative record." Each Posta is the platform's atomic unit of data in transit, carrying full provenance and immutable once written into the Pulpería. A.11. Senderos Senderos names the wire transport layer: the physical paths Postas travel from a Baqueano to its destination Pueblo or Campamento. The historical senderos were paths through the campo that existed because they were walked, with seasonal reliability and local knowledge required to choose well. The Senderos layer chooses among available transports (Starlink, customer WAN, cellular, microwave) and manages compression, security, retry, and replay. A.12. Pulpería Pulpería names the canonical operational ledger. The historical pulpería was the country store, bar, post office, informal court, and credit institution of the rural Spanish-American pueblo. Records were kept on a board behind the counter; disputes were resolved publicly; entries were added, never erased. The Pulpería receives Postas, validates them, seals them through the Escribanía, and serves them to queries. Conflicts between simultaneous Postas are recorded as conflicts, never silently reconciled. A.13. Cabildo Cabildo names the audit ledger. The historical cabildo was the colonial-era town council whose records had legal force, distinct from the day-to-day commercial records of the pulpería. The Cabildo records every act upon the system itself: configuration changes, authorizations, methodology versions registered, exports issued, Careos resolved, Capataz actions, Cartillas issued or revoked. Append-only, sealed by Escribanía, with retention policies independent of Pulpería retention. A.14. Escribanía Escribanía names the cryptographic notary. The historical escribano did not produce truth but conferred legal force on documents others produced through sealing. The Escribanía applies Sello signatures to Postas and Cabildo entries, producing tamper-evident chains. The service operates in two modes: Mode 1 (internal hash chain, no external dependencies) and Mode 2 (Mode 1 plus periodic merkle-root anchoring to a public chain). The customer-facing artifact is the Testimonio. A.15. Sello Sello names the cryptographic signature applied by the Escribanía. The historical sello was the wax impression a notary applied to a document to certify authenticity. Each Sello incorporates the hash of the previous Sello, forming the chain. In Mode 2, periodic merkle roots over batches of Sellos are anchored to the public chain via actas de cierre. A.16. Testimonio Testimonio names the customer-facing verification artifact. The historical testimonio was the certified copy of a notarial act given to a party as proof of the original. In the platform, when a customer asks the platform to prove that a Posta existed at a given time and has not been altered, the platform produces a Testimonio: in Mode 1, an internal certificate; in Mode 2, a merkle inclusion proof plus the public-chain transaction hash, verifiable by the customer with any blockchain explorer. A.17. Bóveda Bóveda names the long-term storage layer. The historical bóveda was the secure, climate-controlled vault where valuables and important documents were kept after active business with them was concluded. After Postas and Cabildo entries age out of active tier, they migrate to Bóveda for compliance retention. Records remain sealed; their Sellos travel with them; Testimonios over Bóveda records remain producible. A.18. Mercado Mercado names the data exchange surface. The historical mercado was the marketplace whose exchanges were governed by posted rules: certified scales, standardized weights, public terms, sanctions for false dealing. All ingest and export, every integration with a customer's data lake, every regulatory reporting feed, every third-party application that consumes platform data, is mediated by the Mercado under explicit contracts logged in the Cabildo. A.19. Correo Correo names intra-environment messaging. The historical correo was the post office handling routine mail. Within one Pueblo or Campamento, the Correo is the messaging and notification layer for alerts to Recipients, system notifications, asynchronous events to applications, and bridges to humans through email and SMS. A.20. Correo Mayor Correo Mayor names federation governance: the rules and trust framework for inter-environment messaging. The historical Correo Mayor de las Indias was the Spanish crown's institution that governed colonial postal routes between cities. It did not move mail itself; it governed how mail moved. Correo Mayor defines authority across federated environments, addressing schemes, recognition of Cartillas, and Sello recognition. A.21. Diligencias Diligencias names federation transport. The historical diligencia was the stagecoach service running fixed routes on schedules between cities under the authority of Correo Mayor. Diligencias carry batches of messages along defined routes, on defined schedules (or on demand for high- priority traffic), under the authority of Correo Mayor's trust framework. A.22. Centro Centro names the administrative control plane. The historical centro was the town hall, the administrative seat where the work of running the institution was done. Configurators and Approvers do their work in Centro: configuration, approvals, user management, tenant provisioning, fleet management dashboards. Every Centro action is recorded in the Cabildo with the actor's Cartilla. A.23. Foro Foro names the documentation portal. The historical foro was the Roman public space for discussion and ruling, with the word surviving in Spanish for any place of formal discussion. The Foro is the platform's documentation portal: API reference, conceptual guides, tutorials, interactive examples, sandbox environments. May be interactive with runnable examples. A.24. Padrón Padrón names the identity registry. The historical padrón was the citizen registry: the official list of who was enrolled in a town's civil life. Every human user, every autonomous agent, every Baqueano, every Capataz, every Pulpería, every component that authenticates is enrolled in the Padrón of its environment. Across federation, one environment's Padrón may recognize Cartillas from another environment's Padrón under the rules of Correo Mayor. A.25. Cartilla Cartilla names the identity credential. The historical cartilla was the older Argentine credential booklet predating the modern DNI; each citizen carried theirs and it accumulated their civic acts as stamps over a lifetime. In the platform, a Cartilla identifies its bearer and accumulates the bearer's audit history through every action they perform in the system. The choice of Cartilla over DNI is deliberate: identity in this platform is record-bearing, not snapshot-only. A.26. Careo Careo names the conflict resolution process. The careo is the Spanish legal term for the formal confrontation of two conflicting witnesses, brought face to face and made to repeat their accounts in the presence of the other. When two Postas observing the same physical phenomenon disagree, the Pulpería links them, flags the disagreement, and a Careo is initiated. The Careo's outcome is recorded in the Cabildo and sealed by the Escribanía. A.27. Árbitro Árbitro names the conflict resolver service. The árbitro is the arbitrator: authoritative without grandeur, decisive without judicial formality. The Árbitro hears Careos and rules. The Árbitro implements a justice-of-the-peace pattern, examining both Postas with full provenance and producing a ruling. In some configurations the Árbitro is automated; in others it escalates to a human Approver. The Árbitro's ruling is itself a Posta-class event sealed by the Escribanía and recorded in the Cabildo. Authors' Addresses Ramon Rodriguez Roderick Consulting Inc. Houston, TX United States of America Email: info@roderickc.com Maria Paula Graña RGC Argentina S.A. Buenos Aires Argentina Email: info@rgc.ar