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, . [RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, DOI 10.17487/RFC3536, October 2003, . [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, DOI 10.17487/RFC6365, September 2011, . [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), . [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, . [XP-Metaphor] Beck, K., "Extreme Programming Explained: Embrace Change", Addison-Wesley, 1999. See also "System metaphor", Wikibooks, Software Engineering with an Agile Development Framework, . [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, . 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