← Pueblo
Internet Drafts
Two IETF Internet-Drafts authored by Ramon Rodriguez and María Paula Graña. The first articulates metaphor-driven vocabularies as a general engineering practice; the second is the El Mundo lexicon as an instance of that practice.
draft-rodriguez-grana-metaphor-vocabularies-00
Metaphor-Driven Vocabularies for Software Architecture · Independent Submission
Argues that the names a distributed-system architecture chooses are themselves architectural commitments — and that drawing those names from a single, internally coherent source domain (a metaphor) makes the commitments durable rather than decorative. Proposes a discipline for building and maintaining such vocabularies.
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,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC3536] Hoffman, P., "Terminology Used in
Internationalization in the IETF", RFC 3536, DOI
10.17487/RFC3536, October 2003,
<https://www.rfc-editor.org/info/rfc3536>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC
6365, DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.
[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,
<https://www.iso.org/standard/62330.html>.
[Kruchten-Metaphors]
Kruchten, P., "Metaphors in Software Architecture",
philippe.kruchten.com, July 2009,
<https://philippe.kruchten.com/2009/07/21/
metaphors-in-software-architecture/>.
[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,
<https://archive.org/details/
nuestralenguaena0000rose>.
[ASALE] Asociación de Academias de la Lengua Española,
<https://www.asale.org/>.
[Diccionario-Americanismos]
Asociación de Academias de la Lengua Española,
"Diccionario de americanismos", 2010,
<https://www.rae.es/obras-academicas/diccionarios/
diccionario-de-americanismos>.
[DPD] Real Academia Española and Asociación de Academias
de la Lengua Española, "Diccionario panhispánico de
dudas", 2nd edition, 2025,
<https://www.rae.es/dpd/>.
[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),
<https://www.ati.es/novatica/glointv2.html>.
[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",
<http://www.catb.org/jargon/>. 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
draft-rodriguez-grana-mundo-lexicon-01
El Mundo Lexicon · Independent Submission
The El Mundo lexicon as an Internet-Draft. The companion artifact to the metaphor-vocabularies draft — specifies the 32 architectural terms with their historical antecedents, their commitments, and the generator rules that produce new names organically as the architecture evolves.
Internet-Draft R. Rodriguez
Intended Status: Informational Roderick Consulting Inc.
Expires: November 4, 2026 M. P. Graña
RGC Argentina S.A.
El Mundo: Lexicon of Internal Codenames
for Distributed Data Platforms
Abstract
This document defines a complete set of internal codenames for the
architecture, components, and operational concepts of the El Mundo
distributed data platform. The vocabulary draws from the social,
geographic, and institutional life of the rural pueblo in post-
colonial Spanish America, rooted in Castilian linguistic traditions
of the 19th century. The metaphor was chosen deliberately because
the relationships between historical pueblo institutions map
directly onto the relationships between architectural components in
a modern distributed data platform. These names encode architectural
meaning; they are not decorative.
The primary motivation is to address the loss of semantic nuance
that Spanish-speaking engineers and academics frequently experience
when technical concepts are expressed only in English. Many English
terms flatten rich metaphors or carry historical baggage that does
not translate cleanly. By contrast, the Spanish vocabulary of the
rural pueblo carries fully loaded meanings that encode roles,
relationships, and processes in single words. The use of these terms
as codenames allows teams to retain the full metaphorical weight of
the concepts. This approach eases the learning curve for Spanish
speakers and invites Spanish-speaking academia to embrace the
vocabulary, to expand it, and to adapt it as its use broadens across
domains and regions. The document serves as the canonical reference
for all such codenames.
This revision adds extended discussion of translation loss when
technical vocabularies cross language boundaries, including two
illustrative examples of how the proliferation of imperfect
adoptions can degrade the meaning of load-bearing terms. It also
places the lexicon in the context of similar and opposing approaches
in the software-architecture literature, and expands the IANA
considerations to record the rationale for not requesting registry
action at this time.
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 Roderick Consulting Inc. and the persons
identified as the document authors. All rights reserved.
Table of Contents
1. Introduction ....................................................3
2. The Core Metaphor ...............................................3
3. Definitions of Terms ............................................4
3.1. Mundo ......................................................4
3.2. Campo ......................................................4
3.3. Pueblo .....................................................5
3.4. Campamento .................................................5
3.5. Baqueano ...................................................6
3.6. Aperos .....................................................6
3.7. Rastro .....................................................7
3.8. Cuadrilla ..................................................7
3.9. Capataz ....................................................8
3.10. Posta .....................................................8
3.11. Senderos ..................................................9
3.12. Pulpería ..................................................9
3.13. Cabildo ..................................................10
3.14. Escribanía ...............................................10
3.15. Sello ....................................................11
3.16. Testimonio ...............................................11
3.17. Bóveda ...................................................12
3.18. Mercado ..................................................12
3.19. Correo ...................................................13
3.20. Correo Mayor .............................................13
3.21. Diligencias ..............................................14
3.22. Centro ...................................................14
3.23. Foro .....................................................15
3.24. Padrón ...................................................15
3.25. Cartilla .................................................16
3.26. Careo ....................................................16
3.27. Árbitro ..................................................17
4. How the Metaphor Generates New Names ...........................17
5. Conventions for Use ............................................18
6. Status of This Document ........................................19
7. Translation, Loss, and the International Audience ..............19
7.1. Why Translation Loses Nuance ..............................19
7.2. The Proliferation of Imperfect Terms ......................20
7.3. Example: "Posta" Mistranslated as "Post" ..................21
7.4. Example: "Cabildo" Conflated with "Council" ...............21
7.5. Loss in the Other Direction ...............................22
7.6. Implications for Adoption .................................22
8. Similar and Opposing Approaches in the Literature ..............23
8.1. Similar Approaches ........................................23
8.2. Opposing Approaches and Cautions ..........................24
8.3. Position of This Lexicon ..................................24
9. Security Considerations ........................................25
10. IANA Considerations ...........................................25
10.1. Rationale for No Registry Action ........................25
10.2. Future Work .............................................26
11. References ....................................................26
11.1. Informative References ..................................26
Authors' Addresses ................................................28
1. Introduction
This document establishes the working vocabulary for the
architecture, components, and operational concepts of the El Mundo
distributed data platform. The platform records operational truth
from remote field environments into a unified ledger system that
spans both local deployments and central services. The vocabulary
provides a consistent set of names that teams can use in code, in
documentation, in design diagrams, and in architectural decision
records.
The names are internal codenames. They are not commercial brand
names. They are not trademarks. They are not customer-facing
product names. Commercial naming for the platform remains a separate
matter that will be resolved when appropriate resources become
available.
The metaphor is generative rather than fixed. When a new
architectural concern arises that lacks a name, the rule is to
identify the corresponding institution or figure from the rural
pueblo in post-colonial Spanish America and to adopt that name. The
metaphor functions as a living generator of vocabulary.
The motivation for this lexicon stems from the practical difficulty
that Spanish-speaking professionals face when working exclusively
with English technical terminology. Nuances of authority, trust,
provenance, and institutional relationships often evaporate in
translation. The pueblo metaphor restores those nuances by drawing
on a cultural and linguistic tradition in which a single word can
carry an entire web of social and operational meaning. The approach
is intended to lower the cognitive load for Spanish-speaking teams
and to provide a living vocabulary that Spanish-speaking academia
can adopt, critique, extend, and evolve as the underlying
architectural patterns find wider application.
This document follows the IETF tradition of publishing authoritative
controlled vocabularies as standalone informational documents. Well-
known examples include the Internet Security Glossary [RFC4949],
which supplies precise definitions across security and PKI domains,
and the Terminology Used in Internationalization in the IETF
[RFC3536], which frames discussions of language and character-set
issues. In the Spanish-speaking technical community, analogous
efforts have produced bilingual glossaries such as the Glosario
básico inglés-español de informática y tecnología issued by the
Asociación de Técnicos de Informática (ATI) in multiple editions and
the Diccionario Politécnico de las lenguas Española e Inglesa. These
works help Spanish speakers retain precision when navigating
English-dominated terminology.
Within software architecture more broadly, the deliberate use of
metaphors to name and relate components is a recognized practice.
The "city metaphor" for software visualization, in which modules
appear as districts and classes as buildings, has been extensively
studied and implemented in research tooling. The system metaphor
concept from Extreme Programming supplies teams with a shared
narrative that simplifies complex structures. The present lexicon
extends that tradition by anchoring the metaphor in the specific
institutional and social fabric of the post-colonial Spanish-
American rural pueblo, thereby supplying not only individual names
but a generative framework whose internal relationships mirror
architectural relationships.
2. The Core Metaphor
The entire system carries the name Mundo. Mundo is Spanish for
world. It names the totality of the platform. Everything the
platform encompasses, from a sensor at a remote operational site to
an application programming interface that serves an analytics
workload, forms part of El Mundo. The term appears when teams speak
of the system as a single integrated whole, when they address
platform-wide concerns such as identity or federation, or when they
distinguish what lies inside the platform from what lies outside.
The primary internal division of Mundo runs between two environments.
One environment is the field side, known as Campo. The other
environment is the cloud side, known as Pueblo, or the on-premises
side, known as Campamento. All other components reside in one of
these environments or move between them.
3. Definitions of Terms
3.1. Mundo
Mundo names the whole system. It encompasses both the field
environment and the cloud or on-premises environment. Mundo
represents the complete universe of the platform. Teams use the term
when they discuss the system as one integrated entity or when they
address concerns that span the entire platform.
3.2. Campo
Campo designates the field-side environment. This is the portion of
the platform where physical operations actually occur. Campo
includes all remote operational sites, sensor deployments, local
processing resources, and the locations where data first originates.
Campo forms one half of the overall platform. The other half
consists of the cloud environment known as Pueblo or the single-
tenant on-premises deployment known as Campamento.
Each individual remote site counts as one campo. The complete
collection of all remote sites under platform management forms el
Campo in the collective sense. Field agents perform their work in
the campo. The historical resonance of the phrase "trabajar en el
campo" captures the real, physical, weather-exposed labor that takes
place at the edge of the system. The metaphor honors the fact that
the field side is where the actual work happens, no matter where the
final records come to rest.
3.3. Pueblo
Pueblo names the cloud-side environment. It is the multi-tenant
software-as-a-service deployment. Pueblo serves as the shared,
public cloud environment where data arrives from many remote sites.
In Pueblo the data is received, validated, sealed, archived, and
made available to applications and to human users. Multiple tenants
share the same Pueblo, yet their data remains isolated through
tenancy controls while the underlying infrastructure is shared.
Pueblos exist in the plural. A deployment may serve one geographic
region while another deployment serves a different region. Each
Pueblo operates independently, yet all Pueblos can federate with one
another when a tenant's data must cross regional boundaries. A
Pueblo contains many institutions. These institutions include the
operational ledger, the audit ledger, the notary service, the
archive, the data exchange, the messaging service, the
administrative center, the documentation portal, and the identity
registry. Together these institutions constitute the Pueblo. A
Pueblo serves many tenants by design. This characteristic
distinguishes it from a Campamento.
3.4. Campamento
Campamento designates the cloud-side environment when it takes the
form of a single-tenant on-premises deployment. The customer
operates the Campamento on its own infrastructure, whether that
infrastructure is a private data center, a dedicated cloud account,
or an isolated network. The platform software runs inside the
Campamento, and the customer manages its operation while the
platform provider supplies the software and support.
Architecturally a Campamento runs in parallel with a Pueblo. It
contains the same set of institutions, each scoped to the single
tenant that operates it. The term Campamento is exact. It evokes
the self-contained operational base that a company maintains at a
remote site. The metaphor maps the on-premises deployment to that
precise concept: a self-contained base run by the tenant for its own
purposes and distinct from any shared Pueblo.
A Campamento can federate with a Pueblo through the appropriate
governance and transport mechanisms when the trust framework
permits. Nevertheless a Campamento remains fundamentally single-
tenant by design. It serves only the tenant that operates it. The
dual-mode operation of the notary service was driven in part by the
Campamento case. Tenants who run on-premises Campamentos may forbid
outbound traffic to public blockchains. The tamper-evident mode of
the notary service must therefore function fully offline to serve
those tenants.
3.5. Baqueano
Baqueano names the field tier software. It is the intelligence
deployed at the remote operational site. The baqueano is a
historical figure from the rural pampas regions of South America.
Historical accounts portray the baqueano as an indispensable local
guide who knew the terrain because he lived in it. The baqueano was
essential to travel, to herding, and to any activity that required
reliable movement across open country. He could read weather,
terrain, water sources, and danger in places where maps failed.
Crucially the baqueano was not a scout sent out from a distant
headquarters. He was already present, a permanent resident of his
territory.
This role maps directly to the field tier of the platform. The
Baqueano software is not a temporary probe dropped in from a central
location. It is a permanent intelligent presence at the remote site.
It possesses deep local knowledge of which sensors are reliable,
which transports degrade at particular times, and what operators
actually do during shift changes. The central tier neither possesses
nor should second-guess this local knowledge.
The Baqueano constitutes the intelligence. It is the software, the
firmware, and the autonomous logic that runs at the field. It pairs
with its hardware kit known as the Aperos. It produces observations
known as Rastros. A single Baqueano serves a single physical
deployment. Multiple Baqueanos at the same site cooperate as a
Cuadrilla. Many Baqueanos across many remote sites may be commanded
by a Capataz.
3.6. Aperos
Aperos names the field tier hardware. It is the physical gear that
belongs to the Baqueano. The aperos constitute the complete kit that
a rural worker of the period carried. The kit included the saddle,
the bridle, the reins, the blanket, the knife, the lasso, and every
other item needed for work on the open land. The word is
unmistakably rural and evokes the self-reliant worker of the
Americas.
In the platform the Aperos are the physical hardware on which the
Baqueano runs. The hardware includes the embedded board, the
enclosure, the antennas, the cabling, the sensor interfaces, the
power conditioning, and the field-deployable ports. The full set of
physical gear is strapped to the field deployment.
The relationship between Baqueano and Aperos is deliberate. The
Baqueano owns the Aperos in the same way a rural worker owns his
kit. The software defines what the hardware is for. Hardware without
the software is dead metal. This is why the codename for the field
tier is the worker rather than the box. The intelligence is what
gives the box its identity. The natural phrasing is "the Baqueano
and his Aperos." The word is grammatically plural by default because
the gear always forms a set. The platform therefore speaks of Aperos
in the plural even when it refers to the hardware kit of one
deployment.
3.7. Rastro
Rastro names the field functionality that consists of what the
Baqueano reads and perceives. A rastro is a track, a trail, or a
sign read in the dirt. The baqueano's most important skill was the
reading of rastros. He interpreted the broken twig, the hoofprint,
the disturbed grass, and the smoke on the horizon. He did not merely
see the landscape. He interpreted it.
The Rastro layer performs the perceptive function of the Baqueano.
It handles protocol decoding, sensor reading, timestamp resolution,
unit-of-measurement preservation, and provenance assembly. It is
what the Baqueano does with the raw signals that its Aperos receive.
Sensor inputs become Rastros. Rastros are interpreted observations
that carry full context. Rastros become Postas when the Baqueano
forwards them along transport paths toward the Pueblo or the
Campamento.
The word also carries a quiet poetic resonance. The platform reads
the rastros that the physical world leaves behind. Every datum is a
sign that operational reality has left for the system to find.
3.8. Cuadrilla
Cuadrilla names the field mesh formed by cooperating Baqueanos at
the same site. A cuadrilla is a work crew. Historically it was a
small group that worked together under a shared task and within a
shared territory. Mining crews, construction crews, and agricultural
crews all formed cuadrillas. The word implies peer cooperation.
Members of a cuadrilla are equals who work together. They are not
subordinates who work under a single superior.
When multiple Baqueanos are deployed at the same remote site, they
cooperate as one Cuadrilla. They negotiate which Baqueano forwards
which Postas. They relay one another's traffic when one loses
backhaul. They share sensor inventory and avoid duplicate Postas.
They coordinate over local mesh transports. The Cuadrilla embodies
peer cooperation. This relationship is distinct from the vertical
command relationship embodied by the Capataz. Both relationships are
real. Both receive names.
3.9. Capataz
Capataz names the fleet management agents that command groups of
Baqueanos. The capataz is the foreman of the rural estate. He
commands the workers who labor on the land. He plans the day's work,
decides who goes where, sets priorities, intervenes in disputes
among the crew, and reports to the estate owner while exercising
authority over the workers.
In the platform the Capataces are the fleet-management agents that
command groups of Baqueanos. A Capataz dispatches updates to its
fleet. It monitors health. It decides which Baqueano takes over when
another fails. It allocates work across Cuadrillas. It escalates
problems to human operators in the administrative center. Where
authorized, it acts autonomously. Capataces are themselves software
agents, possibly artificial intelligence agents. They operate as
tenants of the platform. They possess their own credentials and
their own provenance trails. Every action a Capataz takes is
recorded in the audit ledger with the same discipline applied to
human operators.
A Capataz commands many Baqueanos. A Cuadrilla is the peer
relationship among Baqueanos at a single site. The two relationships
coexist. A Cuadrilla of Baqueanos at one site may all fall under the
command of a single Capataz. That Capataz may be one of several
Capataces who work under the broader fleet operation.
3.10. Posta
Posta names the unit of data in transit. It is a single message. It
is also the truth. In rural communities of the period, posta meant
the relay station where messengers changed horses on long routes.
The word doubled in everyday speech to mean the authoritative
version, the truth itself. The question "¿Es posta?" asked whether
something was true. The statement "Está en la posta" meant
simultaneously that a message had been delivered to the relay
station and that it constituted the authoritative record.
The Posta is the platform's atomic unit of data in transit. A single
sensor reading, a single human form submission, a single annotation,
or a single configuration event each constitutes a Posta. Every
Posta carries full provenance. The provenance records who or what
produced the Posta, when it was asserted at the source, when it was
received, on what transport it arrived, in what units it is
expressed, and against what authority it stands. Postas are
immutable once written. Postas accumulate into the operational
ledger to form the canonical operational record.
The dual meaning is the entire architectural claim of the platform
compressed into one word. A Posta is both the message and the truth.
The Baqueano sends Postas. The operational ledger records Postas.
The archive preserves Postas. The verification artifact attests to
Postas. Every layer of the architecture handles the same atomic unit
of data. The name of that unit encodes the platform's commitment to
authoritativeness. This is the most semantically loaded codename in
the lexicon. It is held in reserve specifically for this purpose. No
other concept in the platform may be called Posta.
3.11. Senderos
Senderos name the wire transport layer. They are the physical paths
that Postas travel from the field environment to a Pueblo or a
Campamento. Senderos are paths or trails. They are informal routes
worn by use across open land. Some paths are wide. Some are narrow.
Some are reliable. Some are seasonal. A field agent knows them all
and chooses the right one for the prevailing conditions.
In the platform the Senderos layer is responsible for choosing the
available transport, whether that transport is satellite, customer
wide area network, cellular, or microwave. The layer compresses the
payload, secures the connection, batches messages where appropriate,
retries on failure, replays on reconnection, and acknowledges
delivery. Senderos are transport-agnostic at the application layer.
The Posta does not know which Sendero it traveled. The plural form
is standard. The layer chooses dynamically among the available
paths.
3.12. Pulpería
Pulpería names the cloud ledger. It is the canonical operational
record. The pulpería was the country general store, bar, post
office, and meeting place of the rural pueblo. Workers rode in from
the field to the pulpería to drink, to exchange news, to pick up
mail, and to conduct trade. The pulpería served as the unofficial-
official information hub of rural life. The storekeeper kept records
on a board. Debts and credits were tracked. News was exchanged.
Strangers were vetted by the locals before they were trusted.
The Pulpería is the canonical operational ledger. It is the layer in
the Pueblo or the Campamento that receives Postas from Baqueanos and
records them as the authoritative operational record. Postas arrive
at the Pulpería. They are validated. They are sealed by the notary
service. They are recorded. They are made available for query. The
Pulpería is append-only. Postas are never altered. They are never
deleted. They are only added. Conflicts between simultaneous Postas
are recorded as both Postas linked together with a disagreement
flag. They are never silently reconciled. This approach mirrors
exactly how the historical pulpería kept its books when two patrons
disputed an account.
The Pulpería is the heart of the cloud tier. Every other cloud
institution exists to support, to audit, to archive, to attest to,
or to serve from the Pulpería.
3.13. Cabildo
Cabildo names the audit ledger. It is the place where official
decisions are recorded. The cabildo was the colonial-era town
council. It was the seat of municipal authority. Decisions of
consequence, such as the appointment of officials, the issuance of
ordinances, and the recording of formal disputes, were ratified and
recorded in the Cabildo. The Cabildo's records were distinct from
the day-to-day commercial records of the pulpería. They carried
legal weight.
The Cabildo is the audit ledger. Every configuration change in the
platform, every authorization granted, every methodology version
registered, every export issued, every conflict resolution, every
fleet management deployment, and every credential revocation is
recorded in the Cabildo. The Cabildo is distinct from the
operational ledger. The operational ledger records what was
observed. The audit ledger records what was done to the system
itself. Both ledgers are append-only. Both are sealed by the notary
service. Both feed the archive for long-term retention.
The Cabildo serves as the evidence layer for compliance frameworks.
Its retention policies are independent of those of the operational
ledger. Its access controls are stricter. Reads of the Cabildo are
themselves logged in the Cabildo.
3.14. Escribanía
Escribanía names the cryptographic notary service. It operates in
dual mode. One mode provides tamper-evident sealing. The optional
second mode adds publicly verifiable anchoring. The escribanía was
the notary's office in colonial and republican-era Spanish-speaking
countries. The notary witnessed, sealed, and certified documents
such as contracts, wills, deeds of sale, and official acts. The
notary gave those documents legal force. A notary did not produce
the truth. A notary sealed the truth that others produced so that no
one could later argue about what had been recorded.
The Escribanía is the cryptographic notarization layer. Postas and
entries in the audit ledger pass through the Escribanía to receive a
cryptographic seal. The seal links each record into a tamper-evident
chain. The Escribanía operates in two configurable modes.
In the first mode the service provides tamper-evident sealing only.
It maintains an internal hash chain. Each new seal incorporates the
hash of the previous seal. Any alteration of past records breaks the
chain forward and becomes detectable. The mode is entirely internal.
It has no external dependencies and no public exposure. A tenant can
claim that if anyone tampered with a record, the tenant can prove
it. This mode is the default for Campamentos that forbid outbound
traffic.
In the second mode the service adds publicly verifiable anchoring to
the first mode. Postas and audit ledger entries are batched into
Merkle trees. The root of each batch is published to a public
blockchain on a defined cadence. A tenant or a regulator can
independently verify that any given Posta existed at a given time
and has not been altered, without trusting the platform operator.
This mode is the default for multi-tenant Pueblos that serve tenants
who require third-party verifiability.
The Escribanía is additive. The second mode includes the first mode
plus the anchoring layer. The internal architecture consists of one
engine with one chain. The second mode is a configurable layer on
top. The notary historically did not seal every utterance. The
notary batched signing sessions in which multiple documents
received seals at once. The second mode follows that pattern
exactly. The platform does not anchor every Posta individually. It
batches Postas into periodic closing records.
The customer-facing artifact produced by the Escribanía is the
verification artifact. The cryptographic primitive applied to each
record is the seal. Open architectural questions that remain
deferred to the design phase include the scope of notarization, the
choice of public chain for the second mode, key custody for both
modes, and the anchoring cadence.
3.15. Sello
Sello names the cryptographic signature. It is the seal applied to
each notarized record. A sello is a seal. Historically it was the
wax impression that a notary or an official applied to a document to
certify its authenticity. The Sello is the cryptographic primitive
that the notary service applies. It is a signature that links a
Posta or an audit ledger entry into the tamper-evident chain.
Each record carries its Sello. Each Sello incorporates the hash of
the previous Sello and thereby forms the chain. In deployments that
use the second mode of the notary service, periodic Merkle roots
over batches of Sellos are anchored to the public chain through
closing records. The verb form "sellar" is also useful in code and
in conversation. The notary service sella a Posta when it applies
the cryptographic seal.
3.16. Testimonio
Testimonio names the verification artifact. It is what a tenant
holds to prove a Posta's authenticity. A testimonio in colonial
Spanish notarial practice was the certified copy of a notarial act
that the notary gave to a party as proof of the original. It was the
document a person could carry, present in court, present to a buyer,
or present to a regulator as evidence that something had been
recorded.
The Testimonio is the customer-facing proof artifact produced by the
notary service. When a tenant asks the platform to prove that a
given Posta existed at a given time and has not been altered, the
platform produces a Testimonio. In the first mode of the notary
service the Testimonio is an internal certificate signed by the
operational ledger. In the second mode the Testimonio is a Merkle
inclusion proof plus the public-chain transaction hash. The tenant
can verify the proof independently with any blockchain explorer.
The Testimonio is what the tenant waves in court. The Testimonio is
what a regulator inspects. The Testimonio is what a counterparty in
a dispute is shown. It is the externalized form of the seal. It is
the proof the tenant can hold.
3.17. Bóveda
Bóveda names the long-term storage layer. It is the cold archive
used for compliance retention. A bóveda is a vault. It is the
secure, sealed, climate-controlled space where valuables and
important documents are kept for the long term. In financial and
notarial contexts the bóveda is where deeds, wills, and titles rest
after the active business with them has concluded.
The Bóveda is the long-term storage layer of the platform. After
Postas and audit ledger entries have aged out of the active
operational tier, they migrate to the Bóveda for compliance
retention, regulatory retrieval, and historical query. Bóveda
storage is optimized for cost and durability rather than for query
latency. Records in the Bóveda remain sealed. Their seals travel
with them. Testimonios over Bóveda records remain producible.
The Bóveda may be implemented as object-store cold tiers or as
offline media in highest-compliance scenarios. Each Pueblo and each
Campamento maintains its own Bóveda. Retention policies are set per
tenant and per regulatory regime.
3.18. Mercado
Mercado names the data exchange. It handles ingest, export,
integrations, and contracts. The mercado is the marketplace where
goods are exchanged under public rules. Markets in the period were
heavily regulated spaces. Certified scales verified weights. Prices
were posted. Weights were standardized. Inspectors patrolled. A
person did not simply walk into a mercado and grab things. There
were rules of weights and measures, certified scales, public posting
of terms, and sanctions for false dealing.
The Mercado is the platform's data exchange surface. All ingest and
all export pass through the Mercado. Every integration with a
tenant's data lake, every connection to an external historian, every
regulatory reporting feed, every third-party application that
consumes platform data, and every tenant's pluggable upstream
destination is mediated by the Mercado. The Mercado defines the
contracts. It specifies what data is exchanged, in what formats, under
what authorization, with what attestation, and against which seals.
It enforces the rules of weights and measures. It logs every
transaction in the audit ledger.
The choice of Mercado over flatter words such as integrations or
application programming interface is deliberate. The metaphor
encodes the architectural truth that data exchange is negotiated and
ruled rather than free-form. A tenant does not simply pull data. The
tenant enters a contract with the Mercado. That contract is
recorded, attested, and audited.
3.19. Correo
Correo names the messaging service. It handles mail, notifications,
and alerts within one Pueblo or one Campamento. The correo is the
post office. It is the institution that handles routine mail and
messages. Within a single Pueblo or Campamento the Correo is the
messaging and notification layer. It delivers alerts to recipients,
system notifications, asynchronous events to applications, and email
or short message service bridges to human users.
The Correo handles traffic that stays inside one Pueblo or inside
one Campamento. Traffic that must cross between independently
operated environments is governed by the federation governance layer
and is transported by the federation transport layer.
3.20. Correo Mayor
Correo Mayor names the federation governance layer. It defines the
rules and the trust framework for mail that travels between Pueblos
or between a Pueblo and a Campamento. The 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, who was authorized to carry it, what routes were
sanctioned, and what records had to be kept.
Correo Mayor is the platform's inter-environment federation
governance layer. When a tenant with operations in multiple regions
has Postas that must cross between Pueblos, or when a Campamento
federates with a Pueblo, Correo Mayor defines the rules. It
specifies which Pueblo holds canonical authority for which Postas.
It defines how credentials travel and are honored across boundaries.
It establishes how trust is created between independently operated
environments. It defines the addressing scheme that identifies
records across the federation. It specifies which seals are mutually
recognized.
Correo Mayor does not transport messages. It governs transport. The
actual movement is performed by the federation transport layer. The
distinction between the intra-environment messaging service, the
federation governance layer, and the federation transport layer is a
three-tier separation that mirrors how messaging works in real
distributed systems. Local delivery, federation policy, and
federation transport are three different concerns that should not be
conflated.
3.21. Diligencias
Diligencias name the federation transport layer. They are the actual
mechanism for inter-environment messaging. La diligencia was the
stagecoach service that ran fixed routes on schedules between
pueblos in 19th-century Latin America. It carried mail, packages,
and passengers. It was the vehicle. The federation governance layer
was the rulebook.
Diligencias are the actual scheduled transports that move Postas and
other messages between Pueblos, between Campamentos, and between
Pueblos and Campamentos. A Diligencia carries a batch of messages
along a defined route, on a defined schedule or on demand for high-
priority traffic, under the authority of the federation governance
layer's trust framework.
The Spanish word diligencia also carries a second meaning. It
denotes an act performed with care and authority. A notary performs
a diligencia when the notary executes a legal step. This double
meaning strengthens the metaphor. The Diligencias between
environments are not merely transport. They are acts of careful,
trusted, attested delivery.
3.22. Centro
Centro names the administrative interface. It is the control plane
where configuration, approvals, and oversight occur. The centro is
the center, the town hall, the administrative seat. It is where the
work of running the institution gets done. Configuration, approvals,
user management, tenant provisioning, fleet management dashboards,
and the human-operated controls of the platform all live in Centro.
Centro is the administrative interface of the Pueblo or the
Campamento. Operators and approvers do their work in Centro. Routine
operational queries and views go to the operational ledger.
Administrative acts go to Centro. Every action performed in Centro
is recorded in the audit ledger together with the actor's
credential.
3.23. Foro
Foro names the documentation portal. It provides interactive
examples and reference material. The foro was the Roman public space
for discussion and ruling. The word survives in Spanish for any
place of formal discussion. The Foro is the platform's documentation
portal. It contains the application programming interface reference,
conceptual guides, tutorials, interactive examples, and sandbox
environments for developers who are learning the platform.
The Foro may be interactive. It may offer runnable examples, live
application programming interface exploration, and artificial
intelligence assisted documentation that answers questions against
the live specification. It is the public-facing, knowledge-oriented
institution of the Pueblo. The Foro is distinct from Centro. Centro
is for operating the system. Foro is for learning about the system.
An operator works in Centro. A developer evaluating the platform
reads the Foro.
3.24. Padrón
Padrón names the identity registry. It is the roll of recognized
citizens. The padrón is the citizen registry. It is the official
list of who is enrolled in a town's civil life. To be empadronado is
to be officially recognized. The padrón is checked at elections, at
administrative offices, and at any moment when the question arises
of who counts as a member of the community.
The Padrón is the platform's identity registry. Every human user,
every autonomous agent, every Baqueano, every Capataz, every
operational ledger instance, and every component that authenticates
is enrolled in the Padrón of its Pueblo or its Campamento. The
Padrón records who exists, what each entity is, which roles each
entity may hold, and the lifecycle of each enrollment. Across
federation the Padrón of one Pueblo may recognize credentials from
another Pueblo's Padrón under the rules established by the
federation governance layer.
3.25. Cartilla
Cartilla names the identity credential. It is the record-bearing
document that each citizen carries. The cartilla was the older
credential booklet used in the region. It predated the modern
national identity document. Each citizen carried a cartilla. The
cartilla contained more than a name and a number. It contained
history. It recorded military service performed, votes cast, and
civic acts marked by stamps that the bearer accumulated over a
lifetime.
The Cartilla is the platform's identity credential. Where the Padrón
is the registry of who is enrolled, the Cartilla is what an enrolled
entity carries to prove enrollment and to accumulate audit history.
A human's Cartilla, an agent's Cartilla, and a Baqueano's Cartilla
each accumulate a record of acts performed by the bearer. Each act
is sealed by the notary service over time.
The choice of Cartilla over a simple national identity document is
deliberate. A national identity document is a snapshot. It
identifies but does not record history. A Cartilla is a record-
bearing document. It identifies and accumulates the history of acts
performed by the bearer. The latter is what an identity credential
in this platform actually is. Every action a Cartilla holder
performs in the system becomes part of the accumulated provenance
trail. The Cartilla is closer to a passport with stamps than to an
identification card. The metaphor is exact. In the historical
context a person presented a cartilla and an official could read the
accumulated civic life from its pages. In the platform an audit
examiner inspecting a Cartilla can read the accumulated operational
and administrative history of its bearer from the entries that
reference it in the ledgers.
3.26. Careo
Careo names the conflict resolution process. It is the formal
confrontation of conflicting Postas. A careo is the legal term for
the formal confrontation of two conflicting witnesses. The witnesses
are brought face to face. Each is made to repeat the account in the
presence of the other and of the judge. It is a specific procedure
with specific rules. It is used when testimony diverges and the
truth must be adjudicated.
A Careo in the platform is the formal process that begins when two
Postas that observe the same physical phenomenon disagree. The
operational ledger records both Postas. It links them. It flags the
disagreement. The Careo is the procedure that follows. Both Postas
are presented to the conflict resolver together with their full
provenance. The resolver rules on which Posta is canonical, whether
both should remain unresolved, or whether new evidence must be
sought before resolution. The Careo and its outcome are recorded in
the audit ledger and are sealed by the notary service. Careo is the
act. The resolver is the Árbitro.
3.27. Árbitro
Árbitro names the conflict resolver. It is the service that rules on
Careos. The árbitro is the arbitrator. The word carries the right
register. It denotes authority without grandeur and decisiveness
without judicial formality in the criminal sense. An árbitro rules
in commercial disputes, in sports, and in informal conflicts brought
before a trusted third party.
The Árbitro is the service that hears Careos and rules. The Árbitro
implements a justice of the peace pattern. It takes both Postas. It
examines their provenance. It produces a ruling. In some
configurations the Árbitro may be automated through rules or machine
learning assistance. In other configurations it escalates to a human
approver. The choice is per tenant. The Árbitro's ruling is itself a
Posta-class event. It is sealed by the notary service and is
recorded in the audit ledger. The accumulated record of an Árbitro's
rulings is auditable and may be reviewed for consistency. The full
role description in prose may use the justice of the peace phrase,
yet the codename remains the single word Árbitro.
4. How the Metaphor Generates New Names
The vocabulary presented above is not a closed list. The rural
pueblo metaphor is a generator. When a new architectural concern
emerges that does not yet have a name, the rule is to identify the
corresponding institution in the historical rural pueblo of post-
colonial Spanish America and to adopt its name.
Examples of latent names that the metaphor would produce naturally
if needed include the following. Aduana would name the customs
house and could serve as the name for the inspection and validation
layer at the boundary of the data exchange. Feria would name the
periodic fair and could serve as the name for a third-party plugin
marketplace that is distinct from the negotiated bilateral exchanges
of the data exchange. Tribunal would name the court and could serve
as the name for higher-stakes dispute resolution that exceeds the
scope of the conflict resolver. Hospital would name the place of
healing and could serve as the name for diagnostic and remediation
tooling for failed components. Estancia would name the working ranch
and could serve as the name for a specific tenant's full operational
footprint across all of its remote sites and its dedicated fleet
management agents. Pulpero would name the keeper of the pulpería and
could serve as the name for the human or service role that operates
an instance of the operational ledger.
These examples are not committed. They are illustrations of how the
metaphor extends. New names should be added to this lexicon when
they are committed to the architecture, not before.
5. Conventions for Use
In source code the names appear in lowercase snake case without
diacritics. Examples include pulperia, correo_mayor, arbitro, and
cartilla. Diacritics are dropped to avoid encoding issues across
systems. The canonical form in this document retains diacritics for
documentation prose.
In documentation prose the canonical Spanish form appears with
diacritics. Examples include Pulpería, Correo Mayor, Árbitro, and
Cartilla. The name is italicized when it is first introduced in a
document and appears in plain text thereafter.
In conversation and in chat the form that feels comfortable is
acceptable. The vocabulary is meant to be lived in. It is not meant
to be policed.
In customer-facing material these codenames should not appear in
customer documentation, in sales material, in contracts, or in
product user interfaces. The exception is the case in which the
customer has been explicitly briefed on the vocabulary as part of
the integration. The platform's commercial naming for customer-
facing surfaces remains a separate decision.
6. Status of This Document
This document is the canonical reference for the codename vocabulary
as of the date of its publication. It supersedes any earlier
informal notes, conversational summaries, or partial glossaries.
Changes to the lexicon, whether they consist of new terms,
refinements to existing definitions, or deprecations, must be made
by editing this document directly and with a clear commit message
that describes the change. This document is the source of truth.
The vocabulary is the product of an extended naming session that
arrived at its conclusions through careful filtering of cultural
fit, semantic precision, architectural mapping, and bilingual
sensibility. It encodes both technical and cultural commitments that
have been thought through. New contributors should treat the
existing terms as load-bearing and the metaphor as living. They
should contribute additions that respect the spirit of what was
built.
7. Translation, Loss, and the International Audience
7.1. Why Translation Loses Nuance
The lexicon defined in this document is, by design, untranslated.
Each term remains in Spanish in code, in documentation prose, and in
conversation. The decision to leave the vocabulary untranslated 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 and
the connotation is incidental. For the vocabulary in this document
the connotation is what makes the term useful, and translation
therefore strips the term of its function.
Consider Pulpería. The denotational translation is "country store"
or "general store." Both are correct and both are useless. The
pulpería of the rural Argentine and broader Southern Cone tradition
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 before being granted
trust. The pulpero kept records on a board behind the counter.
Disputes over those records were resolved on the spot, in public,
with the storekeeper and the regulars as witnesses. 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. Translation, in this case, would be
equivalent to discarding the reason the term was chosen at all.
This pattern recurs throughout the lexicon. Cabildo translates as
"town council" and loses the colonial Spanish-American institutional
weight that distinguished cabildo decisions from informal community
agreements. Escribanía translates as "notary's office" and loses the
civil-law tradition in which the escribano did not merely witness
documents but conferred legal force upon them by sealing them.
Cartilla translates as "booklet" or "ID card" and loses the
accumulating-history character that distinguished a cartilla from a
modern identity document. In each case the translation captures
what the term refers to and discards what the term means.
The lexicon therefore retains the original Spanish forms. Readers
who do not yet know these terms learn them through their definitions
in this document. Readers who already know these terms recognize
them and inherit the connotation immediately.
7.2. The Proliferation of Imperfect Terms
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. Both speakers feel they are using the same
word, and yet they are not.
This phenomenon has been studied extensively in the context of
English-Spanish technical translation. The literature on false
cognates and "false friends" documents systematic categories of
error that arise when terms appear similar but are not. Less
commonly studied, but perhaps more consequential for the design of
technical vocabularies, is the case in which a term is adopted
correctly in form but incorrectly in nuance, with the incorrect
nuance then propagating through the technical community until it
becomes the de facto standard.
For an internal codename vocabulary such as the present lexicon,
this phenomenon presents a specific risk: as the vocabulary spreads
from its original speakers 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. This document therefore offers two illustrative examples
of how this phenomenon affects terms in the present vocabulary, so
that future adopters can recognize and resist the drift.
7.3. Example: "Posta" Mistranslated as "Post"
The term Posta in this lexicon names the unit of data in transit
from a Baqueano to a Pulpería. The term carries two essential
meanings simultaneously: the historical denotation, in which a
posta was the relay station where messengers changed horses on long
routes, and the colloquial connotation, in which "posta" in
contemporary Spanish, particularly Argentine Spanish, means
authoritative truth. The phrase "es posta" means "it is true." The
phrase "está en la posta" doubles in meaning to "it has been
delivered to the relay station" and "it is the authoritative
record." This double meaning is precisely why the term was chosen.
When the term is adopted by speakers who know only the historical
denotation, or who learn the term from a translation rather than
from native usage, the connotation evaporates. Posta becomes
synonymous with "post" in the sense of a posted message, a forum
post, or a stop on a route. The architectural claim encoded in the
original term, that a Posta is both message and truth, is lost.
Subsequent adopters who learn from these reduced uses inherit the
reduced meaning. Within a few generations of secondary adoption
the term retains only its denotational content and the reason for
its selection has been forgotten.
The defense against this drift is the documentation of the
connotational meaning in the lexicon itself, as has been done in
Section 3.10 of this document. Adopters who consult the canonical
reference will encounter both meanings explicitly. Adopters who
take the term from secondary or tertiary sources may not.
7.4. Example: "Cabildo" Conflated with "Council"
The term Cabildo in this lexicon names the audit ledger, in which
acts performed upon the system itself are recorded with full
authority. The choice of term draws on the colonial Spanish-American
institutional history in which the cabildo was the seat of municipal
authority, distinct from informal community gatherings, distinct
from royal authority, and the locus where decisions of formal
consequence were ratified and recorded. The cabildo's records
carried legal weight precisely because the cabildo was an
institution with defined authority and defined procedures.
When the term is translated as "council" or "town council" and then
re-adopted from the translation, the institutional specificity is
lost. "Council" in English denotes a wide range of advisory and
deliberative bodies, many without formal authority. A Cabildo so
misunderstood becomes a generic discussion forum or advisory layer.
The architectural meaning of the original term, that the Cabildo is
the authoritative recorder of acts upon the system, with retention
policies and access controls reflecting that authority, is degraded
into a softer notion of "the place where decisions are noted."
In a system where audit weight is precisely the property the term
was chosen to encode, this drift has architectural consequences.
Engineers who inherit the softened term may implement softer audit
guarantees. The vocabulary, intended to encode discipline, would
then come to license its absence.
7.5. Loss in the Other Direction
Translation loss is not unique to Spanish-to-English. The lexicon
borrows from Spanish institutional vocabulary precisely because
that vocabulary carries weight that English-language technical
vocabulary does not. The term "ledger" in English is closer to
accounting than to operational truth; the term "audit log" suggests
passivity and post-hoc inspection rather than living authority.
English technical vocabulary in the data-platform space has been
shaped by decades of pragmatic engineering use, and the words have
acquired the texture of that use, which is functional but flat.
The Spanish vocabulary chosen here predates that engineering use by
centuries and carries the texture of legal, institutional, and
communal life. This texture is not a luxury. It is an instrument.
The lexicon does not propose Spanish as superior to English in the
abstract; it proposes that for the specific purpose of naming a
distributed data platform whose central architectural claim is
authoritativeness, the Spanish vocabulary contains words that do
the work better than the available English alternatives.
7.6. Implications for Adoption
Three implications follow for adopters of this lexicon.
First, adopters should consult the canonical definitions in
Section 3 of this document directly, not paraphrases or
translations. The canonical form of each term carries its full
meaning; reduced forms do not.
Second, adopters should resist the temptation to translate terms
into local equivalents in their own working language, even when
such equivalents exist. A team in Tokyo working with this lexicon
should use Pulpería, not 雑貨店 or "general store." The friction
of using an unfamiliar term is the price of preserving the
metaphor's integrity.
Third, adopters should treat the lexicon as a living vocabulary
that may extend, but should resist contracting it. New terms added
in the spirit of the metaphor strengthen it. Substituting existing
terms for translated equivalents weakens it.
8. Similar and Opposing Approaches in the Literature
The use of metaphor to name and structure software architectures is
well established. The deliberate use of a non-English vocabulary to
preserve nuance lost in translation is less common but not without
precedent. This section places the present lexicon in the context
of similar and opposing approaches.
8.1. Similar Approaches
The "city metaphor" tradition in software visualization, surveyed
in [City-Metaphor], maps software systems to urban geography in a
manner closely related to the pueblo metaphor used here. 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
pueblo metaphor differs in scope: rather than a visualization aid
for one codebase, it is a generative vocabulary for a distributed
platform's architecture. The two approaches share the conviction
that spatial-institutional metaphors carry useful inferential
structure when their internal relationships mirror architectural
relationships.
Kruchten's survey of metaphors in software architecture
[Kruchten-Metaphors] catalogs the systematic use of ontological,
structural, and procedural metaphors throughout the discipline.
Kruchten observes that good metaphors carry inferential power: a
reader who understands the source domain can reason about the
target domain by analogy. The survey also catalogs failure modes,
including the breakdown of mixed metaphors and the abuse of
inference where the source-target mapping is incomplete. The
present lexicon is constructed with these failure modes in view:
the source domain is unitary (the rural Spanish-American pueblo,
not a blend of metaphors), and care has been taken to map only
relationships that hold cleanly in both domains.
The Extreme Programming "system metaphor" practice, documented in
[XP-Metaphor], proposes that an architectural metaphor should be
chosen early in a project to provide a shared vocabulary for the
team. 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 present lexicon endorses the underlying claim and addresses the
risk by documenting the metaphor explicitly, identifying its
generative axes (Section 4), and flagging its limits implicitly
through the precision of individual term definitions.
In the Spanish-language technical community, the bilingual glossary
tradition represented by [ATI-Glosario] and [Diccionario-Politecnico]
provides a parallel: these works exist precisely because Spanish
speakers working with English-dominated technical vocabularies need
reference materials that preserve precision across the language
boundary. The present lexicon extends that tradition by going
further and refusing translation entirely for the architectural
vocabulary, on the grounds that translation loss exceeds
translation gain for the load-bearing terms.
8.2. Opposing Approaches and Cautions
The dominant approach in software architecture remains
English-language vocabulary, often based on simple structural
metaphors (layers, pipes, services, containers) that have become
technical terms in their own right. This approach has the
advantage of universality: any working software engineer recognizes
"service" and "container" without further explanation. It has the
disadvantage that the metaphors have been worn smooth by use; they
no longer carry inferential power, and they cannot encode
architectural commitments that go beyond what the worn metaphor
already implies.
A more pointed opposition comes from the literature on metaphor in
cross-cultural contexts. Designers of interaction metaphors have
long observed that metaphors are cultural; a metaphor that resonates
with one cultural audience may be inert or actively confusing to
another. The "desktop" metaphor for personal computing relies on a
reader who has used a physical desktop. The pueblo metaphor in this
lexicon relies on a reader who knows, or is willing to learn, the
institutional life of the rural Spanish-American pueblo of the
nineteenth and early twentieth centuries. For readers without this
background the terms function as opaque labels, and the metaphor's
inferential power is reduced.
This document accepts this trade-off. The decision rests on the
observation that opaque labels can be learned, while drained
metaphors cannot be re-charged. A reader new to the pueblo
vocabulary can read the definitions in Section 3 and acquire the
meaning. A reader using a drained English vocabulary cannot recover
the connotational weight that has been worn off through decades of
imprecise use.
A final caution comes from the postcolonial-architecture literature.
The deliberate use of non-Anglophone vocabulary to encode
architectural meaning is, in some readings, a reclamation of
cultural authority that has been historically marginalized in
technical fields. The present authors locate themselves in this
tradition with care: the vocabulary is offered for adoption by
anyone who finds it useful, and the metaphor is generative rather
than possessive. The lexicon does not claim that distributed data
platforms must be named in Spanish. It claims that this distributed
data platform is named in Spanish, and that the choice has technical
consequences worth documenting.
8.3. Position of This Lexicon
The present lexicon takes a definite position on a contested
trade-off. It chooses connotational density over universal
accessibility. It chooses metaphor coherence over metaphor breadth.
It chooses one cultural and linguistic tradition over the dominant
English-language default. Each of these choices is defensible on
its own merits, and the document offers the reasons in Sections 1
through 7.
The position is not that all technical vocabularies should be
constructed this way. The position is that this particular
architecture, with its particular commitments to authoritativeness,
provenance, and audit, benefits from a vocabulary that encodes those
commitments in single words. The pueblo vocabulary does this. The
available English vocabulary does not.
9. Security Considerations
This document defines only names and does not specify protocols or
algorithms. Security considerations that apply to the platform as a
whole are addressed in the architecture documents that define the
actual mechanisms.
One observation is worth noting in the context of this lexicon. A
vocabulary that encodes architectural commitments in single words
places those commitments in the foreground of every conversation
that uses the vocabulary. Engineers who say "Cabildo" and mean it
are reminded, every time they use the word, that the audit ledger
is an institution with authority and discipline, not a debug log.
Engineers who say "Escribanía" are reminded that cryptographic
notarization is a notarial act with externalized proof, not an
internal hash. The vocabulary's effect on security posture is
indirect but real: it shapes the discipline with which the system
is implemented and operated.
10. IANA Considerations
10.1. Rationale for No Registry Action
This document requests no actions from IANA. The terms defined in
this document are internal codenames for a single distributed data
platform. They are not protocol identifiers, namespace assignments,
media types, port numbers, parameter values, or any other category
of identifier for which IANA maintains registries. They do not
appear on the wire. They do not need to be globally unique across
the Internet. They need to be unique and consistently used within
the platform that adopts them.
Other vocabularies in adjacent areas have likewise required no
IANA action. [RFC4949] defines a security glossary intended for
use in IETF documents and requires no IANA action. [RFC6365],
which obsoletes [RFC3536], defines internationalization terminology
and requires no IANA action. The pattern is established: a
document whose purpose is to fix vocabulary, rather than to allocate
identifiers, does not engage the IANA registry function.
10.2. Future Work
Should the vocabulary defined in this document be adopted by
multiple independent platforms, and should those platforms need to
federate with one another using the vocabulary as a shared
reference, a future revision of this document, or a successor
document, may define a registry of canonical term spellings,
diacritic-stripped code forms, and version markers. Such a
registry would serve to disambiguate between distinct uses of the
same term across platforms and to track approved extensions to the
metaphor.
A registry of this kind is not currently warranted. The vocabulary
is in use within one platform and a small set of related
deployments. Coordination at this scale is direct and does not
require IANA mediation. The present document records this
determination explicitly so that future adopters can revisit it if
the conditions change.
11. References
11.1. Informative References
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in
the IETF", RFC 3536, DOI 10.17487/RFC3536, October 2003,
<https://www.rfc-editor.org/info/rfc3536>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365,
DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.
[ATI-Glosario]
Carrión Tavárez, Á., "Glosario básico inglés-español de
informática y tecnología", multiple editions, Asociación
de Técnicos de Informática (ATI),
<https://www.ati.es/novatica/glointv2.html>.
[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.
[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.
[Kruchten-Metaphors]
Kruchten, P., "Metaphors in Software Architecture",
philippe.kruchten.com, July 2009,
<https://philippe.kruchten.com/2009/07/21/
metaphors-in-software-architecture/>.
[XP-Metaphor]
Beck, K., "Extreme Programming Explained: Embrace
Change", Addison-Wesley, 1999. See also "System
metaphor", Wikibooks, Software Engineering with an Agile
Development Framework,
<https://en.wikibooks.org/wiki/Software_Engineering_
with_an_Agile_Development_Framework/Iteration_One/
System_metaphor>.
[Lakoff-Johnson]
Lakoff, G. and M. Johnson, "Metaphors We Live By",
University of Chicago Press, 1980.
[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.
[False-Cognates]
Various authors. The literature on Spanish-English false
cognates ("false friends") is extensive and well
established in applied linguistics. Representative
treatments include the work cited in the Applied
Linguistics study of Spanish-English cognates and false
cognates in academic spoken vocabulary, Oxford Academic,
2025, <https://academic.oup.com/applij/advance-article/
doi/10.1093/applin/amaf041/8172911>.
This document contains no normative references. All citations above
are informative and point to established practices in terminology
definition, metaphor use in technical fields, and the linguistics
of cross-language vocabulary adoption.
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
The El Mundo Architecture Working Group
Email: info@roderickc.com