El Mundo — Lexicon of Internal Codenames

Status: canonical reference, permanent record Purpose: establish the working vocabulary for the platform's architecture, components, and operational concepts Scope: internal use only — these are codenames, not commercial brand names, not trademarks, not customer-facing product names

Preamble

This document is the canonical reference for the names by which the platform's architecture, components, and concepts are known internally at RCI. The vocabulary is drawn from the social, geographic, and institutional life of the 19th-century rural Argentine pueblo, and the metaphor was chosen deliberately: the relationships between historical pueblo institutions map cleanly onto the relationships between architectural components in a modern distributed data platform. The metaphor is load-bearing — these names encode architectural meaning, not decoration.

These are internal codenames. They are used in code, documentation, internal conversation, design diagrams, and architectural decision records. They are not commercial product names. The platform's commercial naming — for trademarks, domains, and customer-facing brand identity — remains an open question to be resolved separately, when budget for proper trademark clearance is available and customer-pilot feedback has matured. Until then, all code, internal docs, and engineering conversation use the codenames in this document.

The metaphor produces names organically as new components arise. When new architectural concerns emerge that aren't yet named here, the rule is to look for the corresponding institution in the rural Argentine pueblo and adopt its name. The metaphor is a generator, not a fixed list.

Architectural overview: the three ledgers

Before the term-by-term reference, one structural observation that orients everything below. The platform's cloud tier is built around three ledgers, each recording a different kind of truth:

Pulpería — the operational ledger. Records what was observed (raw Postas arriving from the Campo: sensor readings, operator entries, configuration events). Empirical truth.
Contaduría — the corporate ledger. Records what was derived (Asientos computed from Postas under a versioned Plan de Cuentas, sealed at each Cierre). Interpretive truth.
Cabildo — the audit ledger. Records what was done to the system itself (configuration changes, authorizations, methodology version registrations, dispute resolutions, every administrative act). Administrative truth.

All three are append-only. All three are sealed by the Escribanía. All three feed the Bóveda for long-term retention. Each carries a different epistemic commitment, and the architecture's central discipline is that these three kinds of truth are kept distinct — never silently merged, never silently overwritten, always queryable by their respective primitives (Postas, Asientos, Cabildo events). The remaining institutions (Escribanía, Bóveda, Mercado, Correo, Centro, Foro, Padrón) exist to support, attest to, federate, or serve from the three ledgers.

Terms

Mundo

The whole system. Field plus cloud. The entire universe of the platform.

Mundo — Spanish for "world" — names the totality. Everything the platform encompasses, from a sensor in a remote oilfield to the API serving an analytics application in Houston, is part of el Mundo. The term is used when speaking of the system as a single integrated whole, when discussing platform-wide concerns (identity, federation, narrative), or when distinguishing what is inside the platform from what is outside.

The split between Campo and Pueblo (the field environment and the cloud environment) is the primary internal division of Mundo. Everything else lives in one or the other or moves between them.

The Spanish narrative anchor is: "Resguardamos la Verdad" — we safeguard the Truth (the operational truth our customers entrust to the platform). The English narrative is: "We are the Ledger." The pair is asymmetric on purpose: English makes an identity claim about the platform; Spanish makes a custodial claim about what the platform protects.

Campo

The field-side environment. Where operations physically happen.

El Campo is the half of Mundo that exists at customer sites — drilling rigs, fracturing pads, well heads, gathering systems, processing facilities, refineries, pipelines. It is the territory where operational reality unfolds, where sensors observe, where operators work, where the data the platform records actually originates. Campo is not the platform; Campo is one half of the platform. The other half is Pueblo (or Campamento).

Each customer site is un campo. The aggregate of all customer sites under platform management is el Campo in the collective sense.

Baqueanos work en el campo. Postas originate en el campo. The phrase "trabajar en el campo" in Spanish carries a long resonance — it is what rural Argentines have always said about doing the real, physical, weather-exposed work of agriculture, ranching, or oilfield operations. The metaphor honors that the field side is where the actual work happens, regardless of where the records eventually rest.

Pueblo

The cloud-side environment. The multi-tenant SaaS deployment, RCI-operated.

El Pueblo is the public, shared, multi-tenant cloud environment operated by RCI. It is the town to which postas travel from the campo to be recorded, validated, sealed, archived, and served to applications and humans. Multiple customers' postas live in the same Pueblo, isolated by tenancy controls but sharing the underlying infrastructure.

Pueblos are plural. There may be a Pueblo de Houston and a Pueblo de Buenos Aires and a Pueblo de Madrid, each serving its regional customers, each independently operated, each capable of federating with the others through Correo Mayor and Diligencias when a customer's data must cross regional boundaries.

A pueblo contains many institutions: the Pulpería (operational ledger), Contaduría (corporate ledger), Cabildo (audit ledger), Escribanía (notary), Bóveda (archive), Mercado (data exchange), Correo (messaging), Centro (admin), Foro (documentation), Padrón (identity registry). Each institution is a service or service group; together they constitute the pueblo.

A pueblo serves many customers. This is its defining characteristic, and what distinguishes it from a Campamento.

Campamento

The cloud-side environment. The single-tenant on-prem deployment, customer-operated.

El Campamento is the private, single-tenant deployment installed at a customer's own infrastructure — their data center, their cloud account, their isolated network. The customer operates the campamento; RCI provides the software and supports it. Architecturally, a campamento is parallel to a pueblo: it contains the same institutions (its own Pulpería, its own Correo, its own Escribanía, its own Bóveda) scoped to one customer's operations.

The word is exact. Campamento petrolero is the established Spanish phrase for an oil company's operational base — self-contained, single-purpose, operated by the company that owns it. It is what an Argentine oilfield engineer calls the place they sleep when posted to a remote site. The metaphor maps the on-prem deployment to that exact concept: a self-contained operational base, run by the customer for their own purposes, distinct from the public pueblo.

A campamento can federate with a pueblo through Correo Mayor — a customer with on-prem campamentos in three regions can have them coordinate via Diligencias if Correo Mayor's trust framework permits. But a campamento is fundamentally single-tenant by design: it serves only the customer that operates it.

The dual-mode operation of Escribanía (tamper-evident vs. publicly verifiable) was informed in part by the campamento case: customers who run on-prem campamentos may forbid outbound traffic to public blockchains, and Escribanía's Mode 1 (tamper-evident only) must work fully offline to serve them. Mode 1 is the platform default for every deployment — Pueblo or Campamento — so the Campamento case is one important consumer of Mode 1's offline-friendliness rather than the design driver. (See Escribanía entry for the Mode default policy committed at D-019.)

Baqueano

The field tier — software. The intelligence deployed at the customer site.

The baqueano is the historical figure of the rural Argentine pampas: the local guide who knows the terrain because he lives in it. Sarmiento described him in Facundo as one of the four archetypal figures of the pampas. The baqueano was indispensable to military campaigns, cattle drives, and travelers because he could read weather, terrain, water, and danger in places where maps failed. Crucially, the baqueano was not a scout sent out from headquarters — he was already there, a permanent presence in his territory.

This maps exactly to the field tier of the platform. The Baqueano software is not a probe dropped in from the cloud; it is a permanent intelligent presence at the customer site, with deep local knowledge of which sensors are reliable, which transports degrade at which times of day, what the operators actually do at shift change. The cloud tier neither has nor should second-guess this local knowledge.

The Baqueano is the intelligence — the software, the firmware, the autonomous logic that runs at the field. It is paired with its Aperos (the hardware it inhabits), and it produces Rastros (its perceptions of the campo).

A single Baqueano serves a single physical deployment. Multiple Baqueanos at the same site cooperate as a Cuadrilla. Many Baqueanos across many campos may be commanded by a Capataz.

Aperos

The field tier — hardware. The physical gear belonging to the Baqueano.

The aperos are the gaucho's complete kit — saddle, bridle, reins, blanket, knife, lasso, everything he carries on his horse. Synonym of recado, slightly more general. The word is unmistakably rural Argentine; an Argentine reading it in a codebase will smile.

In the platform, the Aperos are the physical hardware on which the Baqueano runs: the embedded board, the enclosure, the antennas, the cabling, the sensor interfaces, the power conditioning, the field-deployable ports. The full set of physical gear strapped to the field deployment.

The relationship between Baqueano and Aperos is deliberate: the Baqueano owns the Aperos, in the same way a gaucho owns his recado. The software defines what the hardware is for; the hardware without the software is dead metal. This is why the codename for the field tier is the worker (Baqueano), not the box — the intelligence is what gives the box its identity. The phrase "el Baqueano y sus Aperos" is the natural Spanish construction and the correct architectural framing.

The word is grammatically plural by default in Spanish — los aperos — because the gear is always a set, never a single piece. This carries through: the platform speaks of Aperos in the plural, even when referring to one deployment's hardware kit.

Rastro

Field functionality. What the Baqueano reads and perceives.

A rastro is a track, a trail, a sign read in the dirt. The baqueano's most important skill was the reading of rastros: the broken twig, the hoofprint, the disturbed grass, the smoke on the horizon. He didn't just see the campo; he interpreted it.

The Rastro layer is the perceptive function of the Baqueano: the protocol decoding, the sensor reading, the timestamp resolution, the unit-of-measurement preservation, the provenance assembly. It is what the Baqueano does with what its Aperos receive. Sensor inputs become Rastros — interpreted observations carrying full context — and Rastros become Postas when the Baqueano forwards them along Senderos toward the Pueblo or Campamento.

The word also has a quiet poetic resonance: the platform reads the rastros the campo leaves behind. Every datum is a sign the operational reality has left for the system to find.

Cuadrilla

Field mesh. Cooperating Baqueanos at the same site.

A cuadrilla is a work crew — historically a small group working together under shared task and shared territory. Mining cuadrillas, construction cuadrillas, agricultural cuadrillas. The word implies peer cooperation: members of a cuadrilla are equals working together, not subordinates working under a single superior.

When multiple Baqueanos are deployed at the same customer site (for redundancy, load distribution, reach extension across a large facility), they cooperate as una Cuadrilla. They negotiate which Baqueano forwards which Postas, they relay each other's traffic when one has lost backhaul, they share sensor inventory and avoid duplicate Postas, they coordinate over local mesh transports.

The Cuadrilla is peer cooperation. This is distinct from Capataz, which is vertical command. The two concepts are different, both real, both named.

Capataz

Fleet management. Agents commanding fleets of Baqueanos.

The capataz is the foreman of the estancia, the ranch boss who commands the gauchos and baqueanos who work the land. He plans the day's work, decides who goes where, sets priorities, intervenes in disputes among his crew, reports to the estanciero (the owner) but has authority over the workers.

In the platform, Capataces are the fleet-management agents that command groups of Baqueanos. A Capataz dispatches updates to its fleet, monitors health, decides which Baqueano takes over when another fails, allocates work across Cuadrillas, escalates problems to human Centro operators, and (where authorized) acts autonomously. Capataces are themselves software agents, possibly AI agents, operating as tenants of the platform with their own Cartillas and their own provenance trails — every action a Capataz takes is recorded in the Cabildo with the same discipline applied to human Configurators.

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 be commanded by a single Capataz, who is one of several Capataces working under the broader fleet operation.

Posta

The unit of data in transit. A single message. Also: the truth.

In rural Argentina, posta meant the relay station where messengers changed horses on long routes — but the word doubled in everyday speech to mean the authoritative version, the truth itself. "¿Es posta?" — "Is it true?" — is a phrase any Argentine still uses today. "Está en la posta" — "It's in the posta" — means simultaneously "it has been delivered to the relay station" and "it is 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, a single configuration event — each is a Posta carrying full provenance: who or what produced it, when (source-asserted), when received, on what transport, in what units, against what authority. Postas are immutable once written. Postas accumulate into the Pulpería 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 Pulpería records Postas; the Bóveda preserves Postas; the Testimonio attests to Postas. Every layer of the architecture handles the same atomic unit of data, and that unit's name encodes the platform's commitment to authoritativeness.

This is the most semantically loaded codename in the lexicon, and it is held in reserve specifically for this purpose. No other concept in the platform may be called Posta.

Postas carry observed truth. Their derived counterpart in the Contaduría is the Asiento (which see) — a value computed from one or more Postas under a versioned Plan de Cuentas. Postas and Asientos are not parallel atoms; they sit at different layers and have different epistemic statuses. See the Asiento entry for the full asymmetry.

Senderos

Wire transport. The physical paths Postas travel from Campo to Pueblo or Campamento.

Senderos are paths, trails — informal routes worn by use across the open land. The word evokes paths through the campo that exist because they are walked, not because they were planned. Some are wide, some are narrow, some are reliable, some are seasonal. A baqueano knows them all and chooses the right one for the conditions.

In the platform, Senderos are the transport mechanisms by which Postas travel from a Baqueano to its destination Pueblo or Campamento. The Senderos layer is responsible for: choosing the available transport (Starlink, customer WAN, cellular, microwave), compressing the payload, securing the connection (mTLS), batching where appropriate, retrying on failure, replaying on reconnection, and acknowledging delivery. Senderos are transport-agnostic at the application layer — the Posta does not know which Sendero it traveled.

The plural form is the standard. Los Senderos are the collection of paths available to a Baqueano; the layer chooses among them dynamically.

Pulpería

The cloud ledger. The canonical operational record.

The pulpería was the country general store, bar, post office, and meeting place of the rural Argentine pueblo of the 18th and 19th centuries. Baqueanos and gauchos rode in from the campo to the pulpería to drink, exchange news, pick up mail, and conduct trade. The pulpería was 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 being trusted.

The Pulpería is the canonical operational ledger — the layer in the Pueblo or Campamento that receives Postas from Baqueanos and records them as the authoritative operational record. Postas arrive at the Pulpería; they are validated, sealed by the Escribanía, recorded, and made available for query. The Pulpería is append-only: Postas are never altered, never deleted, only added. Conflicts between simultaneous Postas (the two-witness disagreement case) are recorded as both Postas linked together with a disagreement flag, never silently reconciled — which is 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's operational layer. Its peer ledgers — the Contaduría (derived/interpretive truth) and the Cabildo (administrative truth) — exist to interpret and audit what the Pulpería records. See the Architectural overview: the three ledgers section above for the full structural framing.

The Pulpería is holistic — the term names the institution as a whole: data store, API surface, governance, keeper, all one thing. When disambiguation is needed inside the architecture, use natural Spanish genitive constructions, not prefix/suffix neologisms: the books of the Pulpería for the data layer, the counter of the Pulpería for the API surface, the Pulpero for the keeper / service-account role. The architecture inherits the historical pulpería's holism — it was building, books, keeper, and social function as one thing — and resists fragmentation into PulperíaService, PulperíaAPI, PulperíaDB neologisms.

The keeper of the Pulpería is the Pulpero. This role-naming convention generalizes to every keeper-of-institution in the lexicon — see § Convention for use.

Contaduría

The corporate ledger. The accountancy office that derives balanced conclusions from the Pulpería's records.

The contaduría was the historically documented accounting office attached to colonial Spanish-American institutions — cabildos, religious orders, commercial houses — that read from the day-to-day operational books of the pulpería and produced balanced derivations under a chart of accounts. The Contador General of the colonial era audited municipal funds, certified accounts, ruled on tax allocations. The contaduría's books were derivative: they did not record what was observed (that was the pulpería's role); they recorded what was concluded under a stated methodology.

The Contaduría is the platform's corporate ledger. It reads Postas from the Pulpería and produces Asientos — derived entries — under a Plan de Cuentas (chart of accounts / methodology specification). The Plan de Cuentas is version-stamped and immutable per Cierre (periodic close); when methodology changes, a new Plan de Cuentas version takes effect at the next Cierre forward, and the prior version's Asientos remain queryable in perpetuity.

The Contaduría is append-only by version: each Cierre commits an immutable set of Asientos under the active Plan de Cuentas; subsequent re-derivations under a newer Plan de Cuentas produce additional Asiento sets rather than replacing prior ones. The same operational data may be re-interpreted later under new methodology — both old and new conclusions remain in the Contaduría, queryable by Plan de Cuentas version.

The Contaduría is distinct from the Pulpería: the Pulpería records what was observed (empirical truth); the Contaduría records what was concluded (interpretive truth). Both are sealed by the Escribanía. Both are audited by the Cabildo. Both are preserved by the Bóveda.

The keeper of the Contaduría is the Contador — the service or role that produces and seals Asientos under the active Plan de Cuentas. The Contador may be automated (rules-based, pure computation), assisted (with human Approver oversight per Cierre), or fully human (the historical role). The choice is per-tenant.

Asiento

A single derived entry in the Contaduría. The atomic unit of corporate-ledger truth.

Asiento is real Spanish accounting vocabulary — asiento contable, the atomic unit of bookkeeping. In real Spanish accountancy, an asiento is a balanced ledger entry under a chart of accounts that records "on this date, under this methodology, this amount is allocated this way."

The Asiento is the platform's corporate-ledger atomic unit — the derived counterpart of the Pulpería's Posta. Posta and Asiento are not parallel atoms at the same level; they sit at different layers and have different epistemic statuses. A Posta is observed truth (a measurement made in the world, a sensor reading, a human form submission — produced outside the platform and arriving inward). An Asiento is computed truth (a value derived from one or more Postas under a specific Plan de Cuentas at a specific Cierre — produced inside the Contaduría and staying there). Postas originate in the Campo and travel inward along Senderos; Asientos originate inside the Contaduría and are addressed by ID, never moved.

Each Asiento references one or more Postas by ID; it never copies Posta content. This preserves the architectural separation: the Pulpería holds the empirical truth; the Contaduría holds the interpretive truth. Each Asiento carries: the Plan de Cuentas version that produced it, the Cierre under which it was sealed, the Contador identity (Cartilla) that authored it, the set of Posta IDs it derives from, and the methodology trace.

Asientos are born sealed. The act of producing an Asiento is itself a Cierre event, sealed by the Escribanía and recorded in the Cabildo as a Configurator-class event with the Contador's Cartilla as the authoring identity. Asientos are immutable per Plan de Cuentas version: recomputation under a new methodology produces parallel Asientos rather than overwriting prior ones — the same architectural property that the Pulpería applies to two-witness disagreements (both readings preserved, never silently reconciled), applied here to methodology versions (both interpretations preserved, never silently superseded).

Queryability survives deactivation of the producing Plan de Cuentas version. When a PdC version is superseded or its lineage is soft-deleted (per the Plan de Cuentas lifecycle-state model), the Asientos sealed under that version remain queryable for audit under the methodology in force when they were sealed. The deactivation closes the lineage to new Asientos; it does not retract the historical record. Dormant tracks remain available to auditors, regulators, and customers asking "what did the books say in Q3 of 2026 under the methodology in force then?" — the answer is in the Asientos, sealed and unchanged.

Cierre

A periodic close. The act of ruling Asientos canonical for a period under the active Plan de Cuentas.

A cierre is a closing — historically the act by which the Contador General closed the books at the end of a period (month, quarter, fiscal year), declaring "these are the canonical accounts for this period under the methodology in force." After the Cierre, Asientos for that period are sealed; new Asientos for the closed period require a formal re-opening procedure recorded in the Cabildo.

The Cierre is the platform's periodic-close primitive. Each Cierre fixes a temporal window, an active Plan de Cuentas version, and the set of Asientos derived during that window. The Cierre itself is a Cabildo event, sealed by the Escribanía and signed by an Approver (human or autonomous, per tenant configuration).

A Cierre may be canonical (the new normal for that period) or replacement (re-deriving the same period under a newer Plan de Cuentas version). Replacement Cierres produce parallel Asientos; they never delete priors. Both sets — the original Asientos under the version that ruled at the time, and the re-derived Asientos under the new version — remain queryable forever. The platform never silently overwrites methodology-versioned conclusions.

Plan de Cuentas

The chart of accounts. The methodology specification for how Postas become Asientos.

A plan de cuentas — chart of accounts — is the structured taxonomy of accounts under which derived ledger entries are recorded. In real Spanish accountancy, the plan de cuentas defines the account hierarchy, the mapping rules, the validation criteria, and the inter-account transformations.

The Plan de Cuentas is the platform's methodology specification. It defines: the account structure, the rules by which Postas (operational observations) become Asientos (derived conclusions), the validation criteria, the inter-Asiento transformations. Each Plan de Cuentas is version-stamped; each version is immutable per Cierre — you may author the next version, but you cannot retroactively alter the version that closed last quarter.

When methodology changes — new regulatory rule, new business interpretation, new analytical model — a new Plan de Cuentas version is authored, reviewed, signed by an Approver, and takes effect when activated. The prior version remains the canonical methodology for all earlier closed periods. The Cabildo records the version transition; the Escribanía seals the new Plan de Cuentas; queries against the Contaduría specify the Plan de Cuentas version under which they wish to interpret.

Authoring authority — who has authority to create or version a Plan de Cuentas, who reviews, who approves — is per-tenant per D-016 (three patterns: Contador-only / Configurator-Contador-Approver / pair-authoring; default Contador-only).

Lifecycle-state model (per D-021)

active is an attribute derived from Cabildo entries, not stored anywhere. The current active status of any Plan de Cuentas version at any moment is computed by walking the Cabildo for registration and deactivation entries pertaining to that version. There is no active flag on the PdC record itself, on any Asiento, or anywhere else. The Cabildo is the sole source of truth.

Constraint: at most one version of a lineage may be active at any time. A lineage is the chain of PdC versions registered in one tenant for one purpose (for example, the production-volume aggregation methodology for Pueblo Houston). Within a lineage, the active set has cardinality 0 or 1 — never 2.

A given lineage may be in exactly one of three legitimate states at any moment. The fourth combinatorial cell is forbidden by the atomic-edits rule.

Lifecycle state	Meaning	Diagram cell
(active, current)	A version is in force; no successor exists. New Cierres seal under it.	Legitimate
(inactive, superseded)	A version was replaced by an active successor in the same atomic Cabildo edit. Historical, queryable, no new writes.	Legitimate
(inactive, no current successor)	A version was deactivated without a successor; every version in the lineage is inactive. The lineage is dormant. Soft-delete.	Legitimate
(active, superseded)	—	Forbidden by the atomic-edits rule

Supersession

Supersession and deactivation are decoupled events but must occur atomically when a successor is registered. A new PdC version that supersedes a predecessor is registered in one Cabildo entry whose effect is compound: register-and-activate the new version and deactivate the predecessor. There is no intermediate state in which both are active. The atomicity is what enforces the at-most-one-active rule.

The Cabildo entry kind for this shape is plan_de_cuentas_supersession. Its payload identifies the new version, the predecessor it supersedes, and the methodology trace.

Soft-delete (a derived predicate, not a stored state)

Soft-delete is a derived predicate, not a stored state. A version is "soft-deleted" iff it is inactive and no version in its lineage is currently active. The condition is computed by querying the Cabildo, never stored as a flag. The append-only commitment is preserved: dormant Asientos remain queryable for audit under the methodology in force when sealed; the lineage simply accepts no new Cierres.

The condition "every version in lineage is inactive" is reachable only via a Cabildo entry that deactivates an active version without an accompanying registration — a distinct Cabildo edit shape (kind plan_de_cuentas_soft_delete) from the compound atomic edit of supersession.

Rollback (re-registration, not reactivation)

Rollback is implemented as registering a new version, not reactivating an old one. A superseded version cannot be reactivated. To return to v1's rules after running v2, register a new PdC v3 whose computation rules mirror v1's, atomically deactivating v2. The old v1 track stays (inactive, superseded by v2); a fresh v3 track begins. The Cabildo records a deliberate choice with its own version stamp — not a reversion that pretends v2 didn't happen.

This discipline preserves the Cabildo as a faithful chronicle: every methodology choice is its own act of record, with attribution to its authoring Cartilla and its own moment in time.

Worked example (single PdC lineage across t₁..t₄)

Time	Cabildo entry	v1	v2	v3
t₁	`plan_de_cuentas_register_initial`: v1 registered, activated	(active, current)	—	—
t₂	`plan_de_cuentas_supersession`: atomic register v2 + deactivate v1	(inactive, superseded by v2)	(active, current)	—
t₃	`plan_de_cuentas_supersession`: atomic register v3 + deactivate v2	(inactive, superseded by v2)	(inactive, superseded by v3)	(active, current)
t₄	`plan_de_cuentas_soft_delete`: deactivate v3, no successor	(inactive, superseded by v2)	(inactive, superseded by v3)	(inactive, no current successor)

After t₄ the lineage is dormant. The Pulpería continues to receive Postas; the Contaduría stops accepting new Cierres on this lineage entirely. Historical Asientos (sealed under v1, v2, or v3) remain queryable forever; new Asientos cannot be derived against a dormant lineage. A future methodology — even one closely related to this one — is a new lineage (different plan_de_cuentas_id), not a revival of a dormant one.

The three states are visible across t₁–t₄. The forbidden (active, superseded) cell never appears.

Methodology versioning generalizes

This is the methodology-versioning architectural commitment in concrete form. The same Postas may be re-interpreted later under a new Plan de Cuentas; both the original Asientos (under the version that ruled at the time) and the re-derived Asientos (under the new version) coexist permanently. The platform never silently changes a methodology under the customer's feet.

The lifecycle-state model — active as a Cabildo-derived attribute, at-most-one-active per lineage, supersession as compound atomic edit, soft-delete as derived predicate, rollback as re-registration — generalizes to any versioned lineage in the platform: Mercado contracts, Sello signing keys, agent definitions, egress policies. Plan de Cuentas is the canonical case the lexicon describes in detail; other lineages inherit the discipline. Their entries reference this section rather than restating it.

Out of scope: physical erasure (GDPR / right-to-be-forgotten)

Architectural soft-delete (above) is queryability shutdown for new writes — the lineage stops accepting new Cierres while historical records remain queryable. Physical erasure — bytes-from-storage removal for legal compliance with GDPR Article 17 or analogous regimes — is orthogonal and not addressed by this model. Deferred to Round 5+ as a compliance design problem; the platform's append-only commitment may need a narrowly-scoped exception with strong evidentiary controls (e.g., crypto-shredding of subject-specific keys, with a Cabildo entry attesting to the shredding act). Do not conflate the two; the architectural soft-delete predicate above is not a GDPR mechanism.

Cabildo

The audit ledger. Where official decisions are recorded.

The cabildo was the colonial-era town council, the seat of municipal authority. Decisions of consequence — the appointment of officials, the issuance of ordinances, 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 had 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 Careo resolved by an Árbitro, every Capataz deployment, every Cartilla revoked — every act upon the system is recorded in the Cabildo. The Cabildo is distinct from the Pulpería: the Pulpería records what was observed (operational truth); the Cabildo records what was done to the system itself (administrative truth). Both are append-only; both are sealed by the Escribanía; both feed the Bóveda for long-term retention.

Cierres land here too. Every Cierre of the Contaduría is itself a Cabildo event, sealed by the Escribanía and signed by an Approver — the Cabildo is therefore the audit trail of methodology transitions as well as the audit trail of administrative acts. Plan de Cuentas version registrations, Cierre acts, and re-derivation Cierres all appear in the Cabildo with the Contador's Cartilla as the authoring identity.

The Cabildo is the SOC 2 evidence layer. Its retention policies are independent of the Pulpería's. Its access controls are stricter; reads are themselves logged in the Cabildo.

The keeper of the Cabildo is the Secretario — the role / service that records acts of record into the Cabildo, signs the books, certifies the proceedings of council sessions, and reads prior decisions aloud at new sessions when relevant. The historical Secretario del Cabildo of colonial Spanish America performed exactly this function: the council made decisions; the Secretario wrote them down, kept the books, and was the authoritative voice of what had been recorded. The Secretario is distinct from the Escribano: the Escribano applies the cryptographic Sello (creates the seal); the Secretario records the act (writes it in the book). One institution, one keeper; the architecture's role-naming convention applies.

Methodology-lifecycle edits in the Cabildo come in two distinct shapes (per the Plan de Cuentas lifecycle-state model). Auditors and the platform itself distinguish them by event kind and payload:

Compound atomic edit — kind <lineage>_supersession (e.g., plan_de_cuentas_supersession, mercado_contract_supersession). One Cabildo entry; two effects, indivisible: register-and-activate the new version and deactivate the predecessor. Both commit together or neither does.
Standalone deactivation — kind <lineage>_soft_delete. One Cabildo entry; one effect: deactivate the active version with no successor. The lineage goes dormant.

These are the only two shapes of methodology-lifecycle edit. There is no deletion shape — the Cabildo is append-only and never removes a version's record. Reactivation is also not a shape — rollback is implemented as a fresh <lineage>_supersession registering a new version, not as a re-activation of an old one (per the Plan de Cuentas lifecycle-state model § Rollback).

Escribanía

Cryptographic notary. Dual-mode: tamper-evident plus, optionally, publicly verifiable.

The escribanía was the notary's office in colonial and republican-era Spanish-speaking countries. The escribano (notary) witnessed, sealed, and certified documents — contracts, wills, deeds of sale, official acts — giving them legal force. An escribano did not produce the truth; an escribano sealed the truth others produced, so that no one could later argue about what had been recorded.

The Escribanía is the cryptographic notarization layer. Postas and Cabildo entries pass through the Escribanía to receive a Sello — a cryptographic signature linking them into a tamper-evident chain. The Escribanía operates in two modes, configurable per deployment:

Mode 1 — Tamper-evident. Internal hash chain. Each Sello is the cryptographic seal applied to a record, with each new Sello incorporating the hash of the previous, so any alteration of past records breaks the chain forward and is detectable. Entirely internal, no external dependencies, no public exposure. Customer claim: "if anyone tampered with this record, we can prove it." Mode 1 is the platform default — every deployment, Pueblo or Campamento, runs Mode 1 from the moment it is provisioned. This is the floor of the platform's notarization commitment. (D-019 closed the D-015 deferral on Mode default; see version history below.)
Mode 2 — Publicly verifiable. Mode 1 plus periodic anchoring of merkle roots to a public blockchain. Postas and Cabildo entries are batched into merkle trees; the root of each batch is published to the public chain on a defined cadence (the acta de cierre, the closing record). Customer or regulator can independently verify that any given Posta existed at a given time and has not been altered, without trusting RCI. Mode 2 is opt-in per tenant, available from day one. Tenants requiring third-party verifiability — typically SaaS Pueblo customers under regulatory scrutiny — enable Mode 2 at provisioning time or later by configuration change recorded in the Cabildo. Campamentos that forbid outbound traffic to public chains can decline Mode 2 entirely and run Mode 1 only.

The Escribanía is additive: Mode 2 includes Mode 1 plus anchoring. The internal architecture is one engine with one chain; Mode 2 is a configurable layer on top.

The escribano historically did not seal every utterance — he batched signing sessions where multiple documents got sealed at once. Mode 2's batched merkle anchoring follows that pattern exactly: the platform does not anchor every Posta individually but batches them into periodic actas de cierre.

The customer-facing artifact produced by the Escribanía is the Testimonio. The cryptographic primitive applied to each record is the Sello.

The keeper of the Escribanía is the Escribano — the role / service that authors Sellos and Testimonios. May be a human notary (rare, high-stakes Testimonios), a service account (default), or an autonomous agent (with full Cartilla provenance like any other tenant of the platform).

Open architectural questions deferred to the design phase: scope of notarization (every Posta, only Cabildo entries, or threshold-based), choice of public chain for Mode 2 (Ethereum primary, Bitcoin optional, or permissioned alternative), key custody for both modes, anchoring cadence.

Sello

The cryptographic signature. The seal applied to each notarized record.

A sello is a seal — historically the wax impression a notary or official applied to a document to certify its authenticity. The Sello is the cryptographic primitive the Escribanía applies: a signature linking a Posta or Cabildo entry into the tamper-evident chain.

Each record carries its Sello. Each Sello incorporates the hash of the previous Sello, forming the chain. In Mode 2 deployments, periodic merkle roots over batches of Sellos are anchored to the public chain via actas de cierre.

The verb form sellar (to seal) is also useful in code and conversation: the Escribanía sella a Posta when it applies the cryptographic seal.

Testimonio

The verification artifact. What a customer holds to prove a Posta's authenticity.

A testimonio in colonial Spanish notarial practice was the certified copy of a notarial act that the escribano gave to a party as proof of the original. It was the document a person could carry, present in court, present to a buyer, present to a regulator, as evidence that something had been recorded.

The Testimonio is the customer-facing proof artifact produced by the Escribanía. When a customer 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 Mode 1, an internal certificate signed by the Pulpería; in Mode 2, a merkle inclusion proof plus the public-chain transaction hash, which the customer can verify themselves with any blockchain explorer.

The Testimonio is what the customer waves in court. The Testimonio is what a regulator inspects. The Testimonio is what a counterparty in a royalty dispute is shown. It is the externalized form of the Sello — the proof the customer can hold in their hand.

Bóveda

Long-term storage. Cold archive, compliance retention.

A bóveda is a vault — 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 is concluded.

The Bóveda is the long-term storage layer of the platform. After Postas, Asientos, and Cabildo entries have aged out of the active operational tier of the Pulpería, Contaduría, and Cabildo, they migrate to the Bóveda for compliance retention, regulatory retrieval, and historical query. Bóveda storage is optimized for cost and durability, not for query latency. Records in the Bóveda remain sealed (their Sellos travel with them) and Testimonios over Bóveda records remain producible.

The Bóveda may be implemented as object-store cold tiers (S3 Glacier, Azure Archive, on-prem equivalents) or as offline media in highest-compliance scenarios. Each Pueblo and each Campamento has its own Bóveda, with retention policies set per tenant and per regulatory regime.

The keeper of the Bóveda is the Archivero — the role / service responsible for migration into the archive, retention enforcement, and producing Testimonios over Bóveda records. Archivero is the standard Spanish term for archivist; it is preferred over a Bovedero neologism. The role-naming convention (§ Convention for use) prefers natural Spanish agent nouns even when they don't share the institution's root.

Mercado

The data exchange. Ingest, export, integrations, contracts.

The mercado — the marketplace — is where goods are exchanged under public rules. Argentine mercados were and are heavily regulated spaces: the fiel contraste certified the scales, prices were posted, weights were standardized, inspectors patrolled. You did not just walk into a mercado and grab things. There were rules of weights and measures, certified scales, public posting of terms, sanctions for false dealing.

The Mercado is the platform's data exchange surface. All ingest and all export — every integration with a customer's data lake, every connection to a SCADA historian, every regulatory reporting feed, every third-party application that consumes platform data, every customer's pluggable upstream destination — is mediated by the Mercado. The Mercado defines the contracts: what data is exchanged, in what formats, under what authorization, with what attestation, against which Sellos. It enforces the rules of weights and measures. It logs every transaction in the Cabildo.

The choice of Mercado over flatter words like Integraciones or API is deliberate: the metaphor encodes the architectural truth that data exchange is negotiated and ruled, not free-form. A customer does not simply pull data; they enter a contract with the Mercado, which is recorded, attested, and audited.

Correo

Messaging. Mail, notifications, alerts within one Pueblo or Campamento.

The correo is the post office — the institution that handles routine mail and messages. Within a single Pueblo or Campamento, the Correo is the messaging and notification layer: alerts to Recipients, system notifications, asynchronous events delivered to applications, email and SMS bridges to humans.

Correo handles intra-Pueblo and intra-Campamento traffic. Inter-Pueblo and inter-Campamento traffic — when a posta or message must cross between independently-operated environments — is governed by Correo Mayor and transported by Diligencias.

Correo Mayor

Federation governance. The rules and trust framework for inter-Pueblo mail.

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, what records had to be kept.

Correo Mayor is the platform's inter-Pueblo federation governance layer. When a customer 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: which Pueblo holds canonical authority for which Postas, how Cartillas (identities) travel and are honored across boundaries, how trust is established between independently-operated environments, what addressing scheme identifies records across the federation, what Sellos are mutually recognized.

Correo Mayor does not transport messages. It governs transport. The actual movement is performed by Diligencias.

The distinction between Correo (intra-Pueblo), Correo Mayor (inter-Pueblo governance), and Diligencias (inter-Pueblo transport) 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.

Diligencias

Federation transport. The actual mechanism for inter-Pueblo messaging.

La diligencia was the stagecoach service that ran fixed routes on schedules between pueblos in 19th-century Latin America, carrying mail, packages, and passengers. It was the vehicle, while the Correo Mayor 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 Correo Mayor's trust framework.

The Spanish word diligencia also carries a second meaning: an act performed with care and authority. A notary performs una diligencia when they execute a legal step. This double meaning strengthens the metaphor: the Diligencias between Pueblos are not just transport; they are acts of careful, trusted, attested delivery.

Centro

Admin. The control plane, configuration, approvals.

The centro — the center, the town hall, the administrative seat — is where the work of running the institution gets done. Configuration, approvals, user management, tenant provisioning, fleet management dashboards, the human-operated controls of the platform.

Centro is the administrative interface of the Pueblo or Campamento. Configurators (in the five-roles framing) and Approvers do their work in Centro. Routine operational queries and views go to the Pulpería; administrative acts go to Centro. Every Centro action is recorded in the Cabildo with the actor's Cartilla.

Foro

Documentation. The docs portal, interactive examples.

The foro — the forum — was the Roman public space for discussion and ruling, and the word survives 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 for developers learning the platform.

The Foro may be interactive — runnable examples, live API exploration, AI-assisted documentation that answers questions against the live spec. 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 it. A Configurator works in Centro; a developer evaluating the platform reads the Foro.

Padrón

The identity registry. The roll of recognized citizens.

The padrón is the citizen registry — 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, at any moment when the question is who counts as a member of this community.

The Padrón is the platform's identity registry: 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 Pueblo or Campamento. The Padrón records who exists, what they are (human, agent, service, device), which roles they may hold (Reporter, Annotator, Configurator, Approver, Recipient), and the lifecycle of their enrollment (issued, suspended, revoked).

Across federation, the Padrón of one Pueblo may recognize Cartillas from another Pueblo's Padrón under the rules of Correo Mayor.

Cartilla

Identity credential. The record-bearing document each citizen carries.

The cartilla — historically cartilla de enrolamiento or libreta cívica — was the older Argentine credential booklet, predating the modern DNI. Each citizen carried their cartilla; it contained more than just their name and number — it carried history: military service performed, votes cast, civic acts recorded by stamps the bearer accumulated over a lifetime.

The Cartilla is the platform's identity credential. Where the Padrón is the registry (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, a Baqueano's Cartilla — each accumulates a record of acts performed by the bearer, sealed by the Escribanía over time.

The choice of Cartilla over DNI is deliberate. A DNI 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, because every action a Cartilla-holder performs in the system is part of their accumulated provenance trail. The Cartilla is closer to a passport with stamps than to an ID card.

The metaphor is exact: in colonial and republican Argentina, you presented your cartilla, and the official inspecting it could read your 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 Cabildo and Pulpería entries that reference it.

Careo

Conflict resolution process. The formal confrontation of conflicting Postas.

A careo is the Spanish legal term for the formal confrontation of two conflicting witnesses, where they are brought face to face and each made to repeat their account in the presence of the other and the judge. It is a specific procedure with specific rules, used when testimony diverges and the truth must be adjudicated.

A Careo in the platform is the formal process that begins when two Postas observing the same physical phenomenon disagree. The Pulpería records both Postas, links them, flags the disagreement; the Careo is the procedure that follows. Both Postas are presented to the Árbitro, with their full provenance, and the Árbitro rules: 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 Cabildo and sealed by the Escribanía.

Careo is the act. Árbitro is the resolver.

Árbitro

The conflict resolver. The service that rules on Careos.

The árbitro is the arbitrator — the role that decides between conflicting parties. The word carries the right register: authority without grandeur, decisive without being judicial in the criminal sense. An árbitro rules in commercial disputes, in sports, in informal conflicts brought before a trusted third party.

The Árbitro is the service that hears Careos and rules. The Árbitro implements a juez de paz pattern — the historical justice of the peace, a local low-stakes mediation-flavored authority — taking both Postas, examining their provenance, and producing a ruling. In some configurations the Árbitro may be automated (rules-based, ML-assisted); in others it escalates to a human Approver. The choice is per-tenant.

The Árbitro's ruling is itself a Posta-class event, sealed by the Escribanía and recorded in the Cabildo. 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 juez de paz phrase — "the Árbitro implements a juez-de-paz pattern" — but for the codename, the single word is Árbitro.

How the metaphor generates new names

The vocabulary above is not a closed list. The Argentine 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 pueblo and adopt its name.

The 2026-05-03 addition of Contaduría / Asiento / Cierre / Plan de Cuentas is exactly this generativity at work — the architecture demanded methodology-versioned derivations, and the source domain (colonial accountancy) supplied the precise vocabulary. New names are added to this lexicon when they are committed to the architecture, not before.

Examples of latent names the metaphor would produce naturally if needed:

Aduana — the customs house. A possible name for the inspection/validation layer at the boundary of Mercado, where data crossing in or out is checked for compliance with contract terms.
Feria — the periodic fair. A possible name for a third-party plugin marketplace, distinct from the negotiated bilateral exchanges of the Mercado.
Tribunal — the court. A possible name for higher-stakes dispute resolution that exceeds an Árbitro's scope.
Hospital — the place of healing. A possible name for the diagnostic and remediation tooling for failed components.
Estancia — the working ranch. A possible name for a specific customer's full operational footprint across all their campos and their dedicated Capataces.

These names are NOT in the vocabulary; they are illustrations only. Do not use any of these names in code, documentation, design discussions, or architectural decision records until they are committed to this document with their own term entries. The metaphor is a generator, not a permission slip.

Convention for use

In code: lowercase, snake_case, no diacritics. pulperia, correo_mayor, arbitro, cartilla, plan_de_cuentas. Diacritics are dropped to avoid encoding issues across systems; the canonical form in this lexicon retains them for documentation prose.

In documentation prose: the canonical Spanish form with diacritics. Pulpería, Correo Mayor, Árbitro, Cartilla, Plan de Cuentas. Italicized when first introduced in a document, plain thereafter.

In conversation and chat: whichever form is comfortable. The vocabulary is meant to be lived in, not policed.

Holism by default

Each named institution names the institution as a whole — building, books, keeper, social function, all one thing. Disambiguation comes from natural Spanish genitive constructions, not from prefix/suffix neologisms.

Layer	Construction	Avoid
Data store	the books of the Pulpería	PulperíaDB, PulperíaStore
API surface	the counter of the Pulpería	PulperíaService, PulperíaAPI
Keeper / service-account	the Pulpero	PulperíaWorker, PulperíaAgent

The same pattern applies to Cabildo, Contaduría, Escribanía, Bóveda, Mercado, Correo, Centro, Foro, Padrón, every named institution. The architecture inherits the historical institution's holism; it resists fragmentation.

Role-naming convention (keeper of institution)

Principle: every institution that has a keeper gets the corresponding natural Spanish agent noun. Do not invent neologistic role names. Do not coin new Spanish words that don't exist in standard usage.

The convention generalizes. The keepers of the three ledgers come first; the keepers of supporting institutions follow:

Pulpero keeps the Pulpería (operational ledger).
Contador keeps the Contaduría (corporate ledger).
Secretario keeps the Cabildo (audit ledger). The historical Secretario del Cabildo recorded council acts and certified the proceedings; the architecture inherits the role.
Escribano keeps the Escribanía (notarial cluster — applies the Sello).
Archivero keeps the Bóveda (long-term archive). Archivero is standard Spanish for archivist; do not coin Bovedero.

Secretario and Escribano are distinct roles — one institution, one keeper, no conflation. The Secretario records the act in the Cabildo's books; the Escribano seals it cryptographically. In some periods of colonial history a single person could occupy both roles, but the architecture treats them as separate keepers of separate institutions, and the role-naming convention follows that separation.

Capataz already exists for fleet management — foreman, not institution-keeper, a different role-shape (vertical command over Baqueanos). Baqueano is a peer-level worker in the Cuadrilla — also not an institution-keeper. These role-shapes coexist with the keeper-of-institution shape; they are distinct.

When a new institution is added by extending the metaphor (per § How the metaphor generates new names), use the natural Spanish agent noun for its keeper. If the institution's name doesn't generate a natural keeper noun (Bóveda → Bovedero would be invented), find the standard Spanish term that already names the role (archivist → Archivero). Do not coin. Do not anglicize. Do not append generic suffixes (PulperíaWorker, ContaduríaService, etc.). The role-naming convention is itself an instance of generativity: the architecture asks for a name; the source domain supplies it. When the source domain doesn't supply one, find an adjacent Spanish term that does, rather than inventing.

Customer-facing material

These are internal codenames and should not appear in customer documentation, sales material, contracts, or product UI, except where the customer has been explicitly briefed on the vocabulary as part of their integration. The platform's commercial naming for customer-facing surfaces remains a separate decision.

Status of this document

Version: v2026-05-07 (D-021 lifecycle-state model: at-most-one-active per lineage; supersession vs soft-delete as distinct atomic Cabildo-edit shapes).

Version history:

v2026-05-07 (D-021) — Lifecycle-state model for versioned lineages. Surfaced during the Diagram 5 design session for the Asiento track preservation question ("what does it mean for an Asiento track to be 'preserved' after supersession?"). Five architectural commitments, encoded across the Plan de Cuentas, Asiento, and Cabildo entries:
1. active is an attribute derived from Cabildo entries — never stored as a flag anywhere. The Cabildo is the sole source of truth for active state.
2. At most one version of a lineage may be active at any time.
3. Supersession and deactivation are decoupled events but bound to occur atomically when a successor is registered. One Cabildo entry, compound effect.
4. Soft-delete is a derived predicate (every version in lineage is inactive), not a stored state. Reachable via a standalone-deactivation Cabildo entry; queryability of historical Asientos survives.
5. Rollback is implemented as registering a new version (not reactivating an old one).
The 2×2 state matrix has three legitimate cells — (active, current) / (inactive, superseded) / (inactive, no current successor) — and one forbidden cell (active, superseded), eliminated by atomicity. The Cabildo gains two distinct event-shape names: <lineage>_supersession (compound atomic) and <lineage>_soft_delete (standalone deactivation). The Plan de Cuentas entry adds the full lifecycle-state model, the worked example (t₁..t₄), and dedicated sub-paragraphs for soft-delete (derived predicate) and rollback (re-registration). The Asiento entry gains a paragraph noting that queryability survives PdC deactivation. The Cabildo entry gains a paragraph naming the two methodology-lifecycle edit shapes. The lifecycle-state model generalizes to other versioned lineages (Mercado contracts, Sello signing keys, agent definitions, egress policies); their entries reference Plan de Cuentas rather than restating. GDPR / physical erasure flagged as deferred to Round 5+ — orthogonal to architectural soft-delete; not addressed by this model. The "Authoring rules deferred to Round 4" deferral note removed; superseded by the explicit reference to D-016. "Takes effect at the next Cierre" replaced by "takes effect when activated" — activation is the relevant moment, not a subsequent Cierre.
v2026-05-06 — Reconciled Escribanía Mode language with Round 4 decision D-019. The D-015 deferral on "Escribanía Mode default per pilot" is closed: Mode 1 is the platform default for every deployment from the moment of provisioning; Mode 2 is opt-in per tenant, available from day one. Removed the "expected default... subject to confirmation in Round 4" hedging on both modes. Adjusted the Campamento entry to reflect that Mode 1's offline-friendliness was informed by rather than driven by the campamento case — Mode 1 is universally the default, with Campamentos being one important consumer rather than the design driver. No new terms; no architectural additions; closure of an outstanding deferral plus the framing tightening that follows from it.
v2026-05-05 — Committed Secretario as the keeper of the Cabildo, completing the three-ledger keeper symmetry (Pulpero / Contador / Secretario for the operational / corporate / audit ledgers). The historical Secretario del Cabildo of colonial Spanish-American councils recorded acts of record, certified proceedings, signed the books, and read prior decisions aloud — the architecture inherits exactly this role for the Cabildo. Cabildo entry expanded with a keeper paragraph that defends the choice (why Secretario rather than Cronista, Notario, or a conflation with Escribano). Role-naming convention list reordered to put the three ledger keepers first, supporting-institution keepers (Escribano, Archivero) below — the new order mirrors the three-ledger framing introduced in v2026-05-04. Note that Secretario and Escribano are distinct roles: the Secretario records the act; the Escribano seals it cryptographically.
v2026-05-04 — Consistency refinements following lexicon review. Added Architectural overview: the three ledgers section before the term-by-term reference, naming the Pulpería / Contaduría / Cabildo three-ledger architecture and the truth-modes each carries (observed / derived / audited). Cabildo entry expanded to note that every Cierre is a Cabildo event, mirroring the Cierre entry's framing from the Cabildo's perspective. Posta entry closed with a forward reference to Asiento, completing the bidirectional cross-reference. Escribanía Mode 1 / Mode 2 default language softened to "expected default" with explicit Round 4 D-015 deferral notes attached. Latent-names list got a "do not pre-commit" warning; the historical Pulpero-was-latent reconciliation note was retired (Pulpero has been committed for two days; the note had become noise). Pueblo entry's institutions list updated to include Contaduría. Bóveda entry updated to mention Asientos as part of the long-term archive set.
v2026-05-03 (D-015) — Added Contaduría / Asiento / Cierre / Plan de Cuentas (Corporate Ledger institution + supporting terms). Committed Pulpero (keeper of the Pulpería). Added two convention sub-sections: holism-by-default (genitive disambiguation, no PulperíaService neologisms) and role-naming convention (Pulpero / Escribano / Contador / Archivero — natural Spanish agent nouns, no invented role names). Mentioned Escribano (keeper of Escribanía) and Archivero (keeper of Bóveda). Refinement pass same day after Ramon's review: Asiento entry rewritten to make the Posta/Asiento asymmetry explicit (observed vs. computed; arrives-from-outside vs. born-inside; sealed-on-arrival vs. born-sealed). Role-naming-convention principle strengthened to "do not invent neologistic role names." Cierre's parallel-Asientos commitment promoted to a sharp one-liner. Plan de Cuentas entry adds an explicit deferral that authoring rules are pending Round 4 — no Plan de Cuentas should be authored in production until those rules are committed.
v2026-05-02 (D-014) — Initial lexicon committed at /data/rci/mundo/docs/lexicon.md. 27 terms: Mundo / Campo / Pueblo / Campamento / Baqueano / Aperos / Rastro / Cuadrilla / Capataz / Posta / Senderos / Pulpería / Cabildo / Escribanía / Sello / Testimonio / Bóveda / Mercado / Correo / Correo Mayor / Diligencias / Centro / Foro / Padrón / Cartilla / Careo / Árbitro.

Derivative documents (design docs, code, diagrams) should reference the specific lexicon version they reflect (e.g., el-mundo-lexicon v2026-05-07). When a derivative document was authored against an older version, it carries that version stamp until updated.

This document is the canonical reference for the codename vocabulary as of its current version. It supersedes any earlier informal notes, conversational summaries, or partial glossaries.

Changes to the lexicon — new terms, refinements to existing definitions, deprecations — must be made by editing this document directly, with a clear commit message describing the change and a bumped version stamp. The document is the source of truth.

The vocabulary is the work of an extended naming session that arrived at its conclusions through careful filtering of cultural fit, semantic precision, architectural mapping, and the bilingual ear of the principal user. 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, contributing additions that respect the spirit of what was built.

Download the lexicon as Markdown