--- title: La unidad de trabajo normalizada description: "Por qué ALLAN mide el esfuerzo agéntico con una escala construida y versionada en vez de facturar el recurso crudo: anclaje, redenominación, compatibilidad de incentivos frente al razonamiento oculto, aritmética entera y la separación tajante entre la unidad y el dinero." allan.topic: foundation allan.service: allan-economics allan.date: 08/04/2026 allan.fuente: [Economics/economics/domain/rating.py, Economics/economics/domain/lint.py, Economics/economics/services/rating_config.py, Economics/economics/services/rating_admin.py, Economics/economics/worker.py, Economics/economics/config.py, Platform Server/internal/economics/rating.go, Platform Server/internal/economics/budget.go, Platform Server/cmd/allan-server/economics.go, Platform Server/internal/models/openai.go, testdata/wu_rating_vectors.json] allan.audiencia: [desarrollador] allan.madurez: asentado --- Vender capacidad de cómputo agéntico obliga a responder una pregunta que parece contable y es de metrología: ¿en qué se mide el trabajo que hace un agente? La respuesta ingenua —en tokens— falla por tres motivos independientes, y conviene enunciarlos por separado porque cada uno mata una solución distinta. El primero es la **inconmensurabilidad**. Un turno agéntico consume tokens de entrada frescos, tokens de entrada leídos de caché, tokens de salida visible, tokens de razonamiento invisibles, llamadas a herramientas que no producen token alguno, minutos de CPU en un sandbox y efectos externos que no consumen cómputo pero sí gobernanza. Nada de eso se suma. Un techo de gasto necesita un escalar, y no existe ninguno observable. El segundo es la **inestabilidad de la unidad aparente**. El token no es una magnitud estable ni siquiera dentro de un mismo proveedor: la propia documentación de Anthropic advierte que sus modelos recientes usan un tokenizador nuevo que «produce aproximadamente un 30 % más de tokens para el mismo texto». Un contrato expresado en tokens cambia de valor cuando el proveedor cambia de tokenizador, sin que el cliente haya hecho nada. Y el precio del token tampoco es una constante: sobre el precio base de entrada se aplican multiplicadores de caché (1,25×, 2×, 0,1× según escritura de cinco minutos, de una hora o lectura), de lote y de residencia de datos, y la documentación dice expresamente que se componen entre sí. El tercero, y el más incómodo, es que **una parte del consumo no es observable por quien paga**. Los tokens de razonamiento se facturan como salida y no se devuelven en la respuesta. OpenAI lo dice sin rodeos: los tokens de razonamiento no son visibles a través de la API, ocupan sitio en la ventana de contexto y se facturan como tokens de salida. Anthropic va más lejos y lo convierte en una advertencia explícita: el número de tokens de salida facturados no coincide con el número visible en la respuesta, porque se factura el proceso de pensamiento completo y no el resumen que se devuelve. Cualquier medidor que se limite a contar lo que ve premia sistemáticamente al proveedor más opaco. De ahí la decisión de fondo de ALLAN: no facturar el recurso crudo, sino construir una escala propia —la **Work Unit**— sobre la que definir techos, presupuestos y contratos. La escala no es física; es convención versionada. Toda la dificultad del diseño consiste en que una convención pueda ser, aun así, auditable. ## La escala construida no es una invención de ALLAN La industria de infraestructura resolvió el mismo problema antes, y merece la pena leer cómo lo documenta, porque la letra pequeña es donde está el aprendizaje. Azure SQL define su DTU como «una medida mezclada de CPU, memoria, lecturas y escrituras», y añade que las características físicas asociadas a cada DTU «se calibran usando un benchmark que simula una carga de trabajo real de base de datos». Es medición por procedimiento público, no por física. Lo interesante es el alcance de la garantía que Microsoft se atreve a dar: el modelo DTU garantiza que el rendimiento y el tiempo de respuesta *del benchmark* permanecen «sustancialmente idénticos» cuando la base se mueve a otro hardware, siempre que el número de DTU no cambie. Y a continuación desactiva la generalización: la documentación del propio benchmark advierte que «todos los benchmarks son representativos e indicativos únicamente» y que «no hay garantía de que una base de datos concreta escale de la misma manera que el benchmark». La escala construida garantiza su ancla, no la carga de usted. Cosmos DB es todavía más cercano al caso agéntico. Microsoft llama a la Request Unit «una moneda de rendimiento que abstrae los recursos del sistema como procesamiento (CPU), operaciones de entrada/salida por segundo (IOPS) y memoria» y afirma que normaliza el coste de todas las operaciones de base de datos, de modo que «tanto si la operación es una escritura, una lectura puntual o una consulta, las operaciones se miden siempre en RU». Dos propiedades importan aquí. La primera es el determinismo, enunciado como compromiso operativo: «la misma consulta sobre los mismos datos cuesta siempre el mismo número de RU en ejecuciones repetidas». La segunda es que la RU está **anclada** a una operación de referencia legible: leer un único elemento por su identificador y clave de partición cuesta una RU, y ese elemento debe pesar en torno a 1 KB. Conviene corregir aquí una creencia extendida y que este ensayo no puede sostener. Se repite que la propiedad clave de la RU es su invariancia respecto a la región o a la partición física. La documentación recuperada no dice eso: dice que el coste es determinista para una operación dada sobre un conjunto de datos dado, y de hecho el aprovisionamiento sí es por región (con *N* regiones, la capacidad total es *R × N*). Lo que la RU garantiza es reproducibilidad de la medida, no independencia del despliegue. El contraejemplo útil es el crédito de CPU de las instancias *burstable* de EC2, que AWS define dimensionalmente: «1 crédito de CPU = 1 vCPU × 100 % de utilización × 1 minuto». Esa sí es una unidad física, y por eso mismo no sirve para medir trabajo heterogéneo: sólo mide una cosa. Y para la separación entre unidad y dinero existe un precedente reciente y directamente pertinente: la Claude Consumption Unit. Anthropic tarifica en dólares, aplica descuentos y **después** convierte a una unidad abstracta —«cien (100) CCU representan 1,00 USD de tarifas»— cuyo precio es fijo; los descuentos se aplican metiendo menos CCU, nunca cambiando el precio de la CCU. Es la operación inversa a la de ALLAN, y precisamente por eso ilumina el contraste: la CCU es dinero disfrazado de unidad, mientras que el WU está construido para que la conversión a dinero no exista en ningún sentido. ## Lo que ALLAN descartó, y con qué motivo El corpus de diseño registra los descartes con su motivo textual, que es lo que permite reabrirlos sin repetir la discusión. El modelo previo de *rating* por créditos-token fue abandonado en la versión 4 del diseño porque conservaba equivalencias WU↔USD —una restricción de precio contra COGS y una calibración de K contra `$/WU`— que contradecían el objetivo: «el dinero jamás define, deriva ni calibra la unidad de trabajo» (`docs/economia/work-units-design.md:8`). El modelo v6 lo eleva a prohibición estructural, incluyendo la de usar `$/WU` «como definición u objetivo de calibración» y la de publicar cualquier equivalencia WC↔dinero (`docs/economia/economic-model-redesign.md:60-63`). El factor de clase de ejecución κ se aplica **sólo a la entrada**: «el razonamiento ya se contabiliza por su volumen en la salida a peso 4; multiplicar también la salida por κ sería doble incremento» (`work-units-design.md:174-176`). El razonamiento no entra en crudo sino convertido a `T_reasoning_rated`, «para que un proveedor que oculta el razonamiento no parezca artificialmente más eficiente que otro que lo declara» (`:150-152`). El tiempo de reloj queda fuera del medidor porque «pertenece al SLA de los tamaños, no al medidor» (`:49`), con la única excepción del minuto de CPU de sandbox. Cada operación tiene exactamente una base más modificadores acumulables, lo que «evita que CRM-vía-MCP sume HTTP+MCP+acción externa por separado» (`:215`). El almacenamiento se declara «stock, no flujo» y queda fuera de la unidad (`:270`). Y el tope de salida por clase no puede ser la defensa principal, porque un tope que sirve el exceso gratis «invitaría a pedir salidas enormes pagando siempre el techo» (`:275`): de ahí que la reserva por llamada exista, y que el tope quede documentado en el código como un simple respaldo (`Economics/economics/domain/rating.py:145-148`). ## El ancla es una identidad, no un parámetro La definición operativa es breve. Una llamada cognitiva se tarifica como ``` WU_cog = [ κ_in·(w_in·T_in_nc + w_cache·T_in_c) + w_out·(T_visible + T_razonamiento_tarifado) ] / N ``` con `w_in = 1,0`, `w_cache = 0,1`, `w_out = 4,0` y `N = 4.000` (`rating.py:122-127`). El valor de `N` no se elige: se despeja. La primera llamada de referencia del dominio —2.000 tokens de entrada no cacheada y 500 de salida visible en clase *fast*— **es** la definición del ancla (`rating.py:533-543`), y `derive_n_anchor` resuelve la única `N` que hace que esa llamada valga exactamente 1 WU (`Economics/economics/domain/lint.py:180-201`). La regla ANCHOR-001 vuelve a tarificar el ancla con la función autoritativa y bloquea la escritura si el resultado no es 1.000 milliWU, con el remedio literal: «n_anchor debe ser {derived} con estos pesos (es una identidad, no una elección)» (`lint.py:443-467`). Ejecutando el rateador puro contra los vectores compartidos, el ancla tarifa hoy en 1.000 milliWU exactos y los catorce vectores cognitivos reproducen sin discrepancia. Es la misma construcción que la lectura puntual de 1 KB que vale una RU: un acto de referencia elegido para que la unidad sea legible por una persona («esta misión costó 141 turnos de chat de trabajo»), no un descubrimiento empírico. ## Redenominar sin romper lo firmado Si los pesos se mueven, la unidad compra otra cosa. El diseño lo llama por su nombre —redenominación— y lo instrumenta. `_max_drift_permille` vuelve a tarificar un conjunto de sondas con la configuración activa y con la propuesta, y mide el mayor movimiento relativo (`lint.py:235-248`). Por encima de cinco por mil, la regla ANCHOR-002 declara: «El cambio mueve el valor de la unidad: es una redenominación», con la consecuencia enunciada —«la capacidad que concede cada plan pasaría a comprar una cantidad de trabajo distinta sin que el plan haya cambiado»— y el remedio: reexpresar la capacidad mensual de todos los planes en el mismo cambio (`lint.py:469-500`). Lo que protege lo ya firmado no es el validador, sino la inmutabilidad. Las filas de `wu_config` son inmutables y un cambio es una versión nueva, no una edición (`Economics/economics/services/rating_config.py:1-8`); `create_version` se niega a sobrescribir con un mensaje que explica por qué —«una versión publicada es una promesa sobre lo que se cobró a una misión pasada»— (`rating_admin.py:193-212`); cada misión congela la versión con la que abrió y se lleva los pesos dentro del contrato (`missions.py:216,241-245`; `Platform Server/internal/economics/client.go:131-159`); y `config_for_version` devuelve `None` antes que sustituir por la activa, porque «recalcular un cargo pasado con los pesos de hoy produce un número que nunca ocurrió» (`rating_config.py:77-88`). La denominación K está congelada por la regla UNIT-001, que es bloqueante (`lint.py:394-412`), y el diseño prohíbe además el ajuste encubierto: «"K no cambia" pero los pesos hacen que las mismas tareas gasten el doble» (`work-units-design.md:420`). ## Compatibilidad de incentivos frente al razonamiento oculto El medidor no puede premiar la opacidad. `reasoning_measurement` distingue cuatro calidades —`native`, `budgeted`, `estimated`, `unavailable`— y `rated_reasoning_tokens` resuelve, para cada una, qué cifra entra en la fórmula (`rating.py:50-62`, `:225-242`). Si el proveedor declara, se usa lo declarado. Si se autorizó un presupuesto de razonamiento y no vuelve nada, se usa el presupuesto. Si no hay nada, se aplica el valor por defecto conservador de la clase: 2.000 tokens en las clases de razonamiento, cero en `fast`, y cero en `embeddings` porque ahí «es un hecho, no una suposición» (`rating.py:163-175`). Las fuentes recuperadas confirman que el problema es real y añaden dos matices que el diseño no modela. El primero: un presupuesto de razonamiento no es un tope. Anthropic dice que «el presupuesto es un objetivo, no un límite estricto» y que el modelo puede detenerse mucho antes de agotarlo; usar el presupuesto como cifra tarifada, que es lo que hace el modo `budgeted`, sobrecarga en ese caso. El segundo, más profundo: los bloques de razonamiento de turnos anteriores que permanecen en contexto «se facturan como tokens de entrada» en los modelos que los conservan. En la fórmula de ALLAN el razonamiento pesa 4,0 sin κ cuando sale, y pesa κ·1,0 cuando vuelve como entrada en el turno siguiente. No es un error de cálculo, pero sí una asimetría que el diseño no discute. ## Aritmética entera y una sola división Dos implementaciones tarifan: la autoritativa en Python (`Economics/economics/domain/rating.py`) y la del camino caliente en Go (`Platform Server/internal/economics/rating.go`), porque el motor necesita tarifar antes de emitir la llamada y no puede esperar a un viaje de red. Ambas están ancladas a los mismos vectores de conformidad (`testdata/wu_rating_vectors.json`), que la migración semilla replica en la base para que un despliegue nuevo tarife igual desde la primera petición (`Economics/migrations/versions/0002_seed_rating_and_plans.py:7-8`). Todo es aritmética entera en milliWU, y hay exactamente **una** división. Los dos términos se escalan a un factor común de 10⁶ antes de dividir, porque «el redondeo intermedio es lo que hace que dos implementaciones se separen» (`rating.py:245-272`; `rating.go:219-241`). El redondeo es *half-up* explícito y propio, y el motivo está documentado en los dos ficheros: el `round` de Python redondea al par y el `math.Round` de Go redondea alejándose de cero, y ambos discrepan en las mitades exactas. Las dos documentaciones oficiales lo confirman: Python dice que «si dos múltiplos están igual de cerca, el redondeo se hace hacia la opción par (de modo que, por ejemplo, tanto `round(0.5)` como `round(-0.5)` son `0`)», y Go dice que «Round devuelve el entero más cercano, redondeando las mitades alejándose de cero». Verificado en esta sesión: `round(0.5)` devuelve `0` en Python, mientras que el vector `rounding_half_up` —dos tokens de entrada en clase *fast*, valor exacto 0,5 milliWU— exige 1 y el rateador devuelve 1. La conversión a la unidad comercial se hace una sola vez, al liquidar: `1 WC = K × 1.000 milliWU`, exacta para K = 10 (`rating.py:475-485`). Redondear por evento dejaría miles de restos deambulando por un total que nadie podría conciliar (`work-units-design.md:399-409`). ## El dinero entra por un solo sitio La separación es la razón de ser de la arquitectura de tres capas: la capa de trabajo produce WU sin dinero; la capa comercial vende WC, y el dinero aparece sólo en el precio del plan y del pack; la capa de costes vigila la viabilidad por plan y no toca jamás la definición de la unidad. El rateador es puro por construcción —sin E/S, sin reloj, sin base de datos— y su docstring enuncia el invariante como segundo de tres: «Nada aquí sabe de dólares, precios de proveedor ni planes» (`rating.py:11-23`). La consola lo repite como invariante de producto: no muestra ni deja calcular un `$/WC` (`docs/economia/economics-console-design.md:530-535`). ## Invariantes, enunciados de forma falsable Un lector puede refutar cualquiera de estos con el repositorio delante. Misma telemetría y misma versión de rating producen los mismos milliWU en Python y en Go, y una discrepancia rompe las dos suites porque ambas leen el mismo fichero de vectores. La llamada ancla tarifa exactamente 1.000 milliWU o la escritura se rechaza como BLOCKING. `k_denomination` distinto de 10 se rechaza como BLOCKING. `w_cache` mayor o igual que `w_in` se rechaza como BLOCKING (`lint.py:375-392`). Ninguna función del módulo de rating consulta un precio, una divisa ni un identificador comercial de modelo. Toda operación tiene exactamente una base. En la fórmula, κ multiplica el término de entrada y sólo ese. Una versión de rating publicada no se edita: se crea otra. Una misión conserva la versión con la que abrió aunque se active otra a mitad de ejecución. ## Lo que está roto, sin terminar o sin evidencia **La reserva por llamada no está cableada.** `ClampCall` existe, está probada y no la invoca ningún punto de producción: la búsqueda en todo el repositorio devuelve únicamente su definición (`internal/economics/budget.go:275-280`) y dos tests. El mecanismo que el diseño presenta como defensa principal contra la salida enorme —y que justifica que el tope por clase sea sólo un respaldo— hoy no se ejecuta. **Dos de las cuatro calidades de medición del razonamiento son código muerto en el motor.** `reasoningMeasurementFor` sólo devuelve `native` o `unavailable` (`internal/models/openai.go:599-613`), `ReasoningBudgetTokens` no se asigna en ningún sitio de producción, y `normalizedUsageFrom` no rellena ni `ConfiguredEffort` ni `EstimatorVersion` (`cmd/allan-server/economics.go:201-228`). El estimador versionado, que el diseño presenta como la pieza que impide que una actualización de adaptador cambie en silencio lo que costó una misión pasada, no tiene hoy ninguna llamada que lo active. **El guardián de redenominación es ciego al peso de la caché.** Las sondas de `extended_reference_usages` se generan replicando la llamada ancla, que tiene `input_cached_tokens = 0`; las veinte sondas comparten ese cero. Comprobado ejecutando el validador: subir `w_cache_milli` de 100 a 900 arroja una deriva medida de **0 por mil** y `lint_rating_config` no devuelve ningún problema, de modo que la versión se escribe y se activa limpia. Sobre una conversación larga con caché (1.000 tokens frescos, 20.000 cacheados, 600 de salida) ese mismo cambio pasa de 1.350 a 5.350 milliWU: casi cuatro veces más por el mismo trabajo. CACHE-001 no lo detiene porque sólo exige que `w_cache` sea estrictamente menor que `w_in`. **La redenominación se avisa pero no se ejecuta.** ANCHOR-002 tiene severidad `error`, no `blocking`, y `raise_if_blocking` sólo detiene lo bloqueante (`lint.py:145-156`). La decisión es explícita y está razonada —bloquear todo movimiento «congelaría la calibración del shadow-rating que el propio modelo prescribe» (`Economics/economics/config.py:103-105`)—, pero la segunda mitad de la regla, reexpresar la capacidad de todos los planes en el mismo cambio, no tiene ningún código detrás: la búsqueda de «redenominat» en todo el árbol sólo encuentra el validador, sus umbrales y comentarios. **La auditoría de re-tarifado compara contra la versión equivocada.** `audit_rating_sample` recupera eventos recientes y los vuelve a tarifar con `rating_config.active(deps)` (`Economics/economics/worker.py:116`), aunque tiene en la mano `event.rating_config_version` —lo registra en el log de la discrepancia, línea 141— y aunque existe `config_for_version` escrito precisamente para esto. En cuanto haya una segunda versión activa, todo evento tarifado con la anterior se registrará como `rating_divergence` sin que los dos rateadores discrepen en nada. **Los vectores compartidos no cubren la entrada malformada, y ahí las dos implementaciones divergen.** Ante una base de operación desconocida, Python lanza `ValueError` (`rating.py:368-372`) y Go devuelve cero (`rating.go:311-315`); ante un modificador desconocido, Python lanza y Go lo ignora; ante una versión de estimador desconocida, Python lanza y Go cae a `v1`. Las tres decisiones de Go están comentadas y son defendibles en el camino caliente, pero significan que una herramienta mal clasificada se cobra a cero en el motor mientras el servicio la habría rechazado. Los vectores no lo detectan porque sólo contienen entradas bien formadas. **Un turno no retenido se tarifa con los pesos compilados.** Cuando Economics no responde, o no está midiendo, `authorizeTurn` devuelve un estado sin presupuesto (`cmd/allan-server/economics.go:389-413`) y `RatingConfig()` cae a `DefaultRatingConfig()` (`internal/economics/budget.go:81-86`). El evento llega al ledger sellado como `wu-config-v1` aunque la versión activa del despliegue sea otra. Es honesto —dice con qué se midió— y a la vez es una vía por la que la tabla publicada deja de gobernar el camino más transitado del producto. **El ancla no está validada contra tráfico real.** El diseño reserva la calibración definitiva a la fase B del shadow-rating (`work-units-design.md:493`), y esa fase no ha producido números contractuales visibles en el código. Hoy el ancla se comprueba contra sí misma: ANCHOR-001 verifica que la llamada de referencia vale 1 WU con los pesos declarados, que es una identidad algebraica, no una medida. La advertencia de Microsoft sobre su propio benchmark —representativo e indicativo únicamente— se aplica aquí con más fuerza todavía, porque en ALLAN el benchmark ni siquiera se ha corrido. **El corpus se contradice a sí mismo en el punto más sensible.** El propio documento que prohíbe publicar equivalencias WC↔dinero publica una: «crédito=$0.01, GM 75-80%» (`work-units-design.md:530`). No es una inconsistencia menor: es exactamente la clase de frase que, citada fuera de contexto, convierte la unidad en dinero disfrazado. Queda, por último, un defecto adyacente que afecta a lo que la unidad mide: `open_mission` calcula el presupuesto con la variante ya degradada por el plan pero pide los límites de recursos con la variante *solicitada* (`Economics/economics/services/missions.py:138` frente a `:237`). Un tenant degradado de M a S recibe presupuesto de S con envolvente de M. ## Referencias - Microsoft. 2026. *DTU-Based Purchasing Model — Azure SQL Database*. . «A database transaction unit (DTU) represents a blended measure of CPU, memory, reads, and writes.» Y sobre el alcance de la garantía: «The DTU model guarantees that the throughput and response time of the DTU benchmark workload will remain substantially identical as the database moves to a different hardware type, as long as its service objective (the number of DTUs) stays the same.» - Microsoft. 2025. *DTU Benchmark — Azure SQL Database*. . «Physical characteristics (CPU, memory, IO) associated with each DTU measure are calibrated using a benchmark that simulates real-world database workload.» Y la cautela que este ensayo usa contra el propio anclaje de ALLAN: «It's important to understand that all benchmarks are representative and indicative only. […] There is no guarantee that any particular database will scale in the same way as the benchmark under increasing load.» - Microsoft. 2025. *Request Units as a throughput and performance currency — Azure Cosmos DB*. . «A request unit is a performance currency that abstracts the system resources such as processing (CPU), input/output operations per second (IOPS), and memory that are required to perform the database operations supported by Azure Cosmos DB.» Sobre la unidad única: «Whether the database operation is a write, point read, or query, operations are always measured in RUs.» Sobre el determinismo: «The same query on the same data always costs the same number of RUs on repeated executions.» Sobre el ancla: «reading a single item by its ID and partition key uses one request unit. The item should be about 1 KB in size.» Nota de rigor: esta página **no** afirma invariancia por región o partición, al contrario de lo que suele repetirse; la afirmación se ha retirado del texto. - Amazon Web Services. *Key concepts for burstable performance instances*. . Definición dimensional, usada aquí como contraejemplo de escala construida: «**CPU credit** A unit of vCPU-time. Examples: 1 CPU credit = 1 vCPU \* 100% utilization \* 1 minute.» - Anthropic. 2026. *Pricing*. . Sobre la inestabilidad del token: «This tokenizer produces approximately 30% more tokens for the same text.» Sobre los multiplicadores de caché y su composición: «A cache hit costs 10% of the standard input price, which means caching pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write).» Sobre la separación entre unidad y dinero: «A CCU is a unit of measure used solely for Marketplace Platform invoicing. One hundred (100) CCU represents $1.00 USD of fees owed for the Services, calculated at the applicable prices […] after application of any discounts.» - Anthropic. 2026. *Steering thinking*. . «The billed output token count does **not** match the visible token count in the response. You are billed for the full thinking process, not the thinking content visible in the response.» Y sobre el razonamiento que vuelve como entrada: «Thinking blocks from prior assistant turns that remain in context […] (billed as input tokens)». - Anthropic. 2026. *Extended thinking*. . La frase que matiza el modo `budgeted` de ALLAN: «The budget is a target rather than a strict cap. Actual token usage varies with the task, and Claude may stop reasoning well before the budget is exhausted; `max_tokens` remains the hard ceiling on total output.» - OpenAI. *Reasoning*. . «While reasoning tokens are not visible via the API, they still occupy space in the model's context window and are billed as output tokens.» - Python Software Foundation. *Built-in Functions — `round`*. . «For the built-in types supporting `round()`, values are rounded to the closest multiple of 10 to the power minus *ndigits*; if two multiples are equally close, rounding is done toward the even choice (so, for example, both `round(0.5)` and `round(-0.5)` are `0`, and `round(1.5)` is `2`).» - The Go Authors. *Package math — `Round`*. . «Round returns the nearest integer, rounding half away from zero.» Referencias del catálogo previo que **no** se han podido recuperar y que, en consecuencia, no se citan ni se usan en el cuerpo: el Reglamento (CE) n.º 1103/97 del Consejo sobre continuidad de contratos y reglas de conversión al euro, que habría servido como precedente jurídico de redenominación —EUR-Lex devuelve la página sin texto articulado a través de las tres URL probadas, y la réplica de legislation.gov.uk no permitió extraer el texto literal—; y el artículo de Goldberg sobre aritmética de coma flotante, recuperado pero sin ninguna frase que sostenga la afirmación que se le atribuía (la acumulación de error por redondeos intermedios), por lo que el argumento de «una sola división» se apoya aquí en la documentación de los dos lenguajes y en la comprobación directa sobre los vectores.