# Fermenty — El mentor incorporado
> **Documento fundacional de producto** · Vision, modelo y plan tecnico
> ZYMOLAB SLU · Fermenty (fermenty.es) · **v0.8** · documento vivo
> Uso interno · Desarrollo creativo
> Tagline: *la guia inteligente del fermentista*
**Nota sobre este documento.** Documento interno de trabajo, no material de venta. Incluye a propósito la *cocina interna*: los porqués, las dudas y las decisiones de diseño. Está pensado para releerse en frío y servir de piedra de toque frente a decisiones futuras.
**Qué cambia en la v0.8.** Correcciones a la tesis comercial: el número de 2.600 productores **acotado a lo que de verdad mide** (marcas embotelladas, no fermentistas artesanos — LIRONA no estaría ahí); los **caseros reencuadrados** como embudo y fuente de datos, con el problema del churn-por-éxito dicho en voz alta; y la asimetría **el motor generaliza, el valor no** (en kombucha el mentor formula; en vegetales acompaña). Además: por qué no se venden los datos a la industria, y el **backtest** como primera acción — el test más barato de la hipótesis más cara.
**Estado del documento:** suficientemente terminado. Las decisiones de esquema están tomadas y el diseño está cerrado. Lo que falta ya no es pensar: es **validar contra obrador real**. La próxima versión no debería traer más diseño — debería traer números que hayan sobrevivido al backtest.
## 1 Qué es Fermenty
Fermenty es un **mentor fermentista incorporado**. No es una calculadora que ejecuta lo que el usuario ya sabe, ni un gestor de producción a secas. Es una guía que **guarda dentro la lógica del fermentista experto** y se la presta al usuario dosificada según lo que él aún no sabe.
El usuario no aporta el conocimiento técnico: lo *recibe*. Dice qué producto quiere lograr —en lenguaje humano, no en parámetros— y Fermenty formula el camino completo, lo acompaña durante la fermentación, y aprende de cada tanda para afinar la próxima propuesta a su cepa, su cocina y su temperatura.
**En una frase:** *Fermenty es un mentor fermentista que guarda la lógica del experto por dentro, se la presta al usuario dosificada según lo que aún no sabe, y se vuelve más suyo cuanto más fermenta. Acompaña con honestidad de oficio, no con certezas huecas. El novato toca una carta; el productor afina el plano; los dos usan el mismo cerebro.*
## 2 La filosofía: guía inteligente, no herramienta
El planteamiento habitual es: *el usuario sabe lo que quiere y la herramienta ejecuta*. Eso es una calculadora. Fermenty invierte la flecha: **la inteligencia vive en el producto, no en el usuario**. El principiante no llega sabiendo cuánto azúcar ni a qué temperatura; llega sabiendo, como mucho, si quiere algo «suave y dulce» o «fuerte y ácido». Esa es la única pregunta que entiende y la única que Fermenty le hace.
No es un eslogan: es una decisión de diseño con consecuencias. La complejidad técnica se *esconde*, no se elimina. El motor sigue manejando los parámetros reales; lo que cambia es que el usuario nunca los ve hasta que quiere verlos. La tagline elegida hace tiempo ya lo anticipaba: **«la guía inteligente del fermentista»**. Guía para el que empieza, inteligencia para el que profundiza.
## 3 El mentor incorporado y la humildad calibrada
Que la lógica del experto viva dentro del producto convierte a Fermenty en un mentor. Pero un mentor tiene una fragilidad que una calculadora no tiene: **la confianza**. Una calculadora que se equivoca es un bug; un mentor que se equivoca pierde su autoridad de golpe.
Si Fermenty promete «estará en tu punto el día 6» con voz de experto y sale avinagrada, el usuario no piensa «vaya, variabilidad biológica»: piensa *«esta app no tiene ni idea»* y se va. La fermentación es biología: **se va a desviar**. El problema no es la desviación; es haberla presentado como imposible.
La defensa es de tono y es gratis si se incorpora desde el principio: **humildad calibrada**. No «estará lista el día 6», sino «suele estar en punto sobre el día 6 — pruébala y me dices». Y el giro clave: enmarcar la variabilidad como *parte del oficio que se está enseñando*. Así, cuando la fermentación se desvía, no rompe la confianza: la **refuerza**. El mejor mentor no es el que nunca falla, sino el que te preparó para la variabilidad.
## 4 La lógica por dentro
### De reactivo a generativo
La primera versión de la idea era **reactiva**: «tengo esto fermentando, ¿cuándo estará?». La buena es **generativa**: «quiero este resultado, dime cómo llegar». Eso no es una calculadora: es un **formulador**. Responde la pregunta que quita el sueño al que quiere producir en serio: «¿cómo consigo que me salga igual cada vez, y cómo diseño un sabor nuevo sin arruinar diez tandas probando?».
### Formulación de destino hacia atrás
El motor no piensa hacia delante desde los ingredientes; piensa **hacia atrás desde el vaso final**. Se consulta el destino —el perfil deseado, con el gas incluido— y desde ahí se planifica toda la receta como una sola pieza. Esto importa porque las fases están **acopladas**: el gas lo produce la levadura comiéndose azúcar en el recipiente cerrado, así que cuánto gas quieres al final condiciona cuán temprano cortas la primera fermentación. La sección 5 lo cuantifica.
### El bucle que lo cierra todo
El recetador **propone** → el usuario **fermenta** → **registra** cómo le salió → el sistema **calibra** la próxima propuesta. Ese registro no es una tarea burocrática que haya que vender: es un mentor preguntándote cómo va tu tanda. Para el usuario es acompañamiento; para Fermenty es el dato de trazabilidad entrando solo. El mismo gesto sirve para las dos cosas. Ese bucle *es* el producto.
## 5 El modelo de la kombucha
Esta sección es nueva y es el corazón técnico. Sale de sesiones de trabajo contra la experiencia real de obrador (LIRONA), y corrige varios errores de las versiones anteriores.
> **Nota de reconciliación (2026-07-25).** Este doc es fundacional: se conserva como el
> «porqué». El modelo IMPLEMENTADO usa **cuatro ejes** en el perfil —intensidad,
> equilibrio, **gas** y **complejidad**—, no dos. El «plano de dos ejes» que describe §5
> (intensidad × equilibrio = S₀ × progreso) es el **núcleo fundamental** del que salen los
> otros: el gas es el tercer destino del mismo presupuesto de carbohidrato (ya aparece más
> abajo), y la complejidad determina el arrancador (léela como «lento ↔ rápido», no «simple
> ↔ complejo»). La verdad vigente y calculable está en `docs/Matematica_Motor.md` y en
> `docs/Lexico.md` (§4, entrada *Complejidad*). Aquí no se reescribe el razonamiento.
### Por qué kombucha primero (y no chucrut)
Contra el instinto de «empieza por lo simple»: para diseñar un *motor*, el caso más rico define el esqueleto y los pobres son subconjuntos. La kombucha es una fermentación compleja —dos fases, dos ejes, recipiente cerrado, saborizantes que además son combustible—. Si el esqueleto se diseña contra el chucrut (una fase, un eje, sin cierre), al llegar la kombucha hay que rehacerlo entero. Si se diseña contra la kombucha, **el chucrut es un caso degenerado**: se salta el paso de cerrar y usa un solo eje. Todo lo demás encaja hacia abajo.
### La idea central: un presupuesto de carbohidrato repartido en el tiempo
Todo el motor cabe en una frase: **reparte un presupuesto de carbohidrato a lo largo del proceso**. Y lo que decide en qué se convierte cada gramo no es el gramo: es **cuándo entra**.
- **Azúcar en la F1 (recipiente abierto) → se va en ÁCIDO.**
- **Azúcar al cerrar (anaeróbico) → se va en GAS.**
La misma molécula, destino distinto según el momento en que llega. Con eso, las tres salidas salen de un solo presupuesto asignado en el tiempo: **cuánto en total** = intensidad · **cuánto se convierte antes de cerrar** = equilibrio · **cuánto queda o llega al cerrar** = gas.
**De dónde salió esto:** de un detalle de obrador. «Cuando hay fruta en F2 corto antes un día, pero también bajo el azúcar inicial en F1 un poco.» Si la fruta solo aportara gas, no habría por qué tocar el azúcar de la F1. Que se baje significa que la fruta también aporta INTENSIDAD — y por tanto que S₀ no es «el azúcar de la F1», sino un presupuesto total. Son dos compensaciones distintas por dos razones distintas: cortar antes compensa la ACIDEZ PERCIBIDA que traerá el gas; bajar el azúcar compensa la INTENSIDAD que traerá la fruta.
### Los dos ejes: intensidad × equilibrio
Corrección sobre la v0.3, que decía que el segundo eje era la carbonatación. **No lo es.** Llamando **S₀** al presupuesto total y **progreso** a la fracción ya convertida en ácido:
- **El equilibrio percibido (dulce↔ácido)** es la relación entre lo que queda y lo que se hizo ácido → depende del progreso, es decir, de dónde cortas.
- **La intensidad** es cuánto hay de todo (azúcar y ácido a la vez) → depende de S₀. Por eso más azúcar «crea más acidez» y a la vez «es más potente»: sube todo junto.
- **El gas** es el carbohidrato disponible al cerrar → S₀ × (1 − progreso), más lo añadido. Es una consecuencia, no un eje.
- **El tiempo** es cuánto tarda en convertir esa cantidad absoluta → más S₀, más trabajo, más días. Es una predicción, no un ajuste.
```mermaid
quadrantChart
title El plano real de la kombucha
x-axis "dulce (corte temprano)" --> "acida (corte tardio)"
y-axis "ligera (S0 bajo)" --> "potente (S0 alto)"
quadrant-1 fuerte - intensa, acida, AUN con gas
quadrant-2 comercial - dulce, gas alto
quadrant-3 suave
quadrant-4 acida - seca, SIN gas propio
suave: [0.25, 0.32]
comercial: [0.23, 0.75]
equilibrada: [0.50, 0.50]
fuerte: [0.75, 0.78]
acida: [0.83, 0.42]
```
Ejes: **X = equilibrio** (progreso: donde cortas la F1) · **Y = intensidad** (S0: azucar inicial).
El **gas NO es un eje**: gas de base = S0 x (1 - progreso), mas lo anadido al cerrar. Es la zona superior-izquierda del plano.
"fuerte" solo existe con S0 alto: hay que llegar lejos en acidez Y que aun sobre azucar. Con S0 bajo, ir lejos deja seco -> eso es "acida", sin gas.
*Fig. 1 — El plano real. El gas es una zona del plano, no un eje.*
Los cinco perfiles propuestos al principio de todo —suave, comercial, ácida, fuerte— resultan ser **coordenadas legítimas en este plano**. La v0.2 los colapsó mal: no vivían en aquel eje porque *faltaba el otro*. Y sale una barandilla de la pura geometría: **«fuerte» solo es posible con S₀ alto**, porque hace falta llegar lejos en acidez y que aún sobre azúcar. Con S₀ bajo, ir lejos te deja seco — eso es «ácida», y por eso cae fuera de la zona con gas.
### El gas aporta acidez percibida: hay dos rutas al mismo punzante
Los ejes no son tan ortogonales como parecían. El CO₂ disuelto forma **ácido carbónico**, y además la burbuja estimula por vía física esa sensación punzante. Así que el gas **no es neutro en el sabor**. Hay un lazo: el gas nace del plano y luego modifica cómo se percibe la posición en el plano.
**acidez percibida = ácido real (progreso × S₀) + acidez del carbónico (gas)**
Y es buena noticia, porque significa que **el gas hace parte del trabajo de la acidez**: no hace falta ir tan lejos en la curva. Cortas antes, te queda residual, el residual te da gas, y el gas te devuelve el punzante que no fuiste a buscar fermentando. *Cambias progreso por carbónico.*
- **Ruta A — más progreso, menos gas.** Vas lejos en la curva. El ácido es real, orgánico. Sale seca, avinagrada, plana. Eso es «ácida».
- **Ruta B — menos progreso, más gas.** Cortas antes, conservas azúcar, cebas. El punzante viene del carbónico. Sale dulce y punzante a la vez, viva, con burbuja. Eso es «comercial», y también «fuerte».
**Esto explica la kombucha del mercado.** El gas le da el mordiente sin tener que sacrificar el azúcar: puedes ser dulce y refrescante a la vez sin que sepa a jarabe. Es literalmente la fórmula del sector, y ha caído del modelo sin que la buscáramos. Consecuencia práctica y confirmada en obrador: cuando se va a cebar con fruta, se corta la F1 aproximadamente un día antes de lo que se cortaría si fuera a quedarse tranquila.
Nota sobre el vocabulario del eje: llamarlo «dulce ↔ ácida» mezcla dos espacios. El eje X del motor es **dónde cortas**. La acidez que el usuario sale a buscar se sirve por dos caminos. Hay **dos espacios**: el del motor (S₀ y progreso, donde sí son independientes) y el del usuario (intensidad, acidez percibida, gas, textura, donde el gas está enredado con la acidez). Que no coincidan no es un defecto: *es la razón de existir del mentor*. Si coincidieran, bastaría una calculadora.
### El arrancador: compra velocidad, paga aroma
Palanca propia, y rompe una simplificación: **el tiempo no es solo el coste de llegar al destino. El tiempo es un ingrediente.**
Dos tandas que acaban en la *misma coordenada* del plano —una con 10 % de arrancador en 9 días, otra con 20 % en 6— **no son la misma bebida**. Una es profunda y aromática; la otra, plana. Hay **dos relojes**: el progreso determina DÓNDE acabas; el tiempo transcurrido determina CUÁNTO aroma se desarrolla por el camino. **El arrancador es lo que despega esos dos relojes**: no cambia el destino, cambia la ruta.
- **El 10 % estándar** no es solo seguridad (bajar de pH 5 al arrancar): es también la decisión de a qué velocidad viajas.
- **Al 20 %** se gana al menos un día para el mismo resultado, y se pierde percepción aromática. Se usa para un perfil suave y plano, y para consistencia.
- **Con menos arrancador y más tiempo** sale un sabor más profundo y complejo: da tiempo a un abanico más ancho de ácidos orgánicos y de aromáticos de levadura. Suma un efecto mecánico: 20 % de arrancador es 20 % de líquido ya gastado, así que diluye el té y el azúcar frescos, que son la materia prima del aroma.
**Y así «comercial» encaja entero, sin haberlo diseñado.** Mucho azúcar + corte temprano + fruta al cerrar + arrancador alto = rápida, reproducible, plana, dulce, y con el gas poniendo el mordiente. Eso ES la kombucha industrial. El opuesto —poco arrancador, mucho tiempo, poco gas, profunda— es lo artesano. Cuando un modelo predice sin querer una categoría que existe en el mercado real, suele ser señal de que va bien encaminado.
### La temperatura: una banda, no un dial
Corrección a una simplificación anterior: arrancador y temperatura **no compran lo mismo**. Si la temperatura fuera solo un dial de velocidad, ir muy despacio daría la kombucha más compleja posible. Pasa lo contrario.
- **El arrancador es monótono:** más = más rápido = más plano. Un trueque limpio, sin precipicio.
- **La temperatura tiene banda de viabilidad:** dentro, cambia velocidad por complejidad. Fuera, la calidad se cae por los dos lados, y por motivos que no se parecen.
Por debajo de 16 °C **el consorcio se descompensa**: las levaduras duermen, no hay etanol para las bacterias, y queda acidez sin la parte aromática. No está «poco hecha»: está desequilibrada, y sabe a vinagre. Eso corrige la regla del tiempo: la complejidad no la compran los días, la compran **los días con el consorcio trabajando en equilibrio**. A 12 °C tienes todos los días del mundo y no compras nada.
**El techo de 30 °C no es un límite de sabor: es un límite de CONTROL.** Por encima, la fermentación va tan rápida que pasa a demasiado ácido —o a vinagre, o a explosividad— entre dos catas. El problema no es la bebida: es que el proceso corre más rápido que la atención del usuario. Y de ahí una salida nueva del motor: LA FRECUENCIA DEL CHECK-IN TIENE QUE ESCALAR CON LA TEMPERATURA. A 20 °C una cata diaria sobra; a 28 °C puede llegar tarde. El ritmo de acompañamiento se calcula, no es una constante. Así, el techo de 30 deja de ser arbitrario: es el punto donde ningún ritmo razonable de cata alcanza. Es un límite del humano en el bucle.
Banda ideal confirmada en obrador: **20–25 °C**. Los extremos de la banda viable (16 y 30) no son sitios donde recomendar: son sitios donde todavía se puede. Y la frase que resume la ficha entera: *«cada fermento tiene un rango de temperaturas ideal, mín y máx, que afectan al tiempo y su potencia»* — eso es esqueleto (universal) y ficha (16/20/25/30 son de la kombucha) en una línea.
### El tiempo mínimo biológico: el suelo que no se puede saltar
Descubrimiento estructural, y el modelo no lo tenía. Existe un **tiempo mínimo que no es cinética**: una kombucha necesita **al menos 4 días** — unas 36 h para que trabajen las levaduras y otras 36 h para las bacterias acéticas. Es una **secuencia**, no una velocidad. No se acelera con temperatura, ni con arrancador, ni con nada. Por debajo de eso, sencillamente no es kombucha.
Esto es un tipo de barandilla nuevo, distinto de los tres que ya teníamos (seguridad, identidad por acidez, presión): un **suelo temporal de identidad**. Y no es exclusivo de la kombucha — generaliza limpiamente: *«un chucrut no se puede hacer en 5 días, da igual la temperatura o la sal que tenga; no es chucrut fuera del rango mínimo de 10 a 30 días»*. Cada fermento tiene su ventana temporal de identidad.
**Consecuencia para la ficha: un campo nuevo, «días mín / máx».** Es esqueleto (todo fermento tiene una ventana temporal por debajo y por encima de la cual deja de ser ese producto) más ficha (4–30 días son de la kombucha; 10–30 son del chucrut). Otra vez: añadir un fermento sigue siendo escribir una fila.
Y tiene una consecuencia elegante que el modelo no había anticipado: **si la cinética llegaría a tu punto en 3 días, esperar los 4 obligatorios te empuja PASADO tu objetivo**. Sale más ácida de lo que pediste. Por eso *no existe la kombucha rápida y dulce*: subir la temperatura y el arrancador para ir deprisa choca contra el suelo, y el suelo te pasa de largo. El mentor tiene que decirlo: «llegarías en 3 días, pero hacen falta 4 — te va a salir más ácida. Baja el arrancador, baja la temperatura, o sube el azúcar».
### La burbuja es consecuencia, no mando
Corrección a la v0.5, que la ponía como destino elegible. No lo es: **el tamaño de burbuja depende de la temperatura de la fase cerrada**, y esa temperatura es la del ambiente donde dejas las botellas — contexto, no palanca. Así que la burbuja **sale del panel de mandos y pasa a las características previstas**. Caliente → gruesa y basta; fría → fina, y se paga con días.
Lo que sí puede hacer el mentor es *sugerir*: «a 24 °C la burbuja saldrá gruesa; si la quieres fina, deja las botellas por debajo de 19 °C — pero tardará más». Eso es un consejo sobre el contexto, no una perilla. Y encaja con la filosofía: el usuario no toca la temperatura, pero el mentor le dice qué gana y qué pierde si la mueve.
### La complejidad no la fija solo el arrancador
La v0.5 hacía «carácter» = arrancador, y era demasiado simple. La complejidad aromática prevista depende de **cuatro cosas**:
- **Los días transcurridos —** el factor dominante, y por eso el arrancador la mueve: más arrancador = menos días = menos aroma.
- **El azúcar inicial —** más S₀ = más tiempo necesario y más sustrato del que desarrollar. Empuja hacia arriba. Es decir: la INTENSIDAD también mueve el carácter, y eso acopla dos mandos que parecían independientes.
- **La banda térmica —** los días solo cuentan si el consorcio está en equilibrio. Fuera de 20–25 °C, los días compran menos.
- **La dosis del saborizante —** sube la complejidad aromática un poco. Efecto menor pero real.
Y hay un matiz fino del arrancador que va más allá del tiempo: **subir el arrancador baja la complejidad sobre todo cuando además acorta el tiempo**; si el tiempo se alarga por otra vía, la complejidad recupera un poco. Suma el efecto mecánico de dilución: 20 % de arrancador es 20 % de líquido ya gastado, o sea menos té y azúcar frescos, que son la materia prima del aroma.
### El potencial de gas se mueve
Otra corrección del prototipo: el gas no es solo un objetivo que se pide, es también un **potencial que el contexto te da o te quita**. Sube con la temperatura (más calor, más gas en el mismo tiempo) y sube con el saborizante si trae azúcares. Por eso hay que mostrarlo como **salida prevista** —junto a la acidez percibida y la complejidad— y no solo como mando de entrada. Un usuario a 26 °C con fruta liofilizada tiene un potencial de gas altísimo aunque no lo haya pedido: eso es justo lo que hay que avisarle.
### El volumen también cuenta
Más volumen es menos superficie por litro, y por tanto menos oxígeno disponible para las acéticas: la fermentación se ralentiza. Regla de obrador: **unas 12 horas más por cada 100 L** para el mismo resultado. En lotes domésticos y de obrador (1–50 L) el efecto es pequeño pero real y conviene modelarlo.
**Y marca un límite del modelo, que conviene declarar:** en tanques de 1000 L la oxigenación deja de dar y el comportamiento cambia de naturaleza, no de grado. El modelo se declara válido para lotes de 1 a 50 L. Fuera de ahí no es que prediga mal: es que no aplica. Un límite honesto y explícito vale más que una extrapolación silenciosa — y es exactamente la humildad calibrada aplicada al alcance del propio modelo.
### El gas en unidades reales: volúmenes, bares y alcohol
Hasta la v0.6 el gas iba en una escala inventada. Ahora va en unidades verificadas contra el estándar cervecero y enológico:
- **1 g/L de azúcar → 0,25 volúmenes de CO₂** (o sea, 1 volumen = ~4 g/L; dextrosa 4,0, sacarosa 3,83, miel 5,0).
- **1 g/L de azúcar → ~0,06 % ABV** (o sea, 1 % = ~17 g/L, la regla estándar en vino). Química: 1 g de glucosa da 0,51 g de etanol y 0,49 g de CO₂ en teoría; en la práctica la levadura desvía un 5–10 % a biomasa.
**De ahí sale lo más importante de todo el modelo del gas:** CADA VOLUMEN DE CO₂ VIENE CON ~0,24 % DE ALCOHOL. SIEMPRE. Es la misma reacción: la levadura no puede hacerte gas sin hacerte etanol. Gas y alcohol no son dos salidas que se ajustan por separado — están soldados por la estequiometría.
Y la presión no es proporcional a los volúmenes: depende de la temperatura. Un líquido a 20 °C aguanta ~0,88 volúmenes disueltos por bar absoluto; a 25 °C, ~0,76. **Consecuencia práctica: el mismo gas es más presión cuando hace calor.** El calor te quita margen dos veces — produce más rápido y aguanta menos.
### La convergencia: el envase y la ley se acaban a la vez
Dato de obrador: la botella de LIRONA aguanta **8 bar**. Al convertirlo aparece algo que no buscábamos:
| | | | |
|-----------------|----------------|----------------------|-------------|
| **Temperatura** | **Revienta a** | **Azúcar consumido** | **Alcohol** |
| 18 °C | 8,5 volúmenes | 32 g/L | 1,43 % |
| 23 °C | 7,2 volúmenes | 27 g/L | 1,20 % |
| 28 °C | 6,1 volúmenes | 22 g/L | 1,01 % |
**A temperatura ambiente, la botella revienta exactamente al 1,20 % ABV — el umbral legal.** No puede ser casualidad: el 1,2 % probablemente refleja lo que una bebida naturalmente carbonatada puede alcanzar antes de que el envase deje de aguantar. Física y regulación convergen. Y tiene una consecuencia operativa fuerte: NO HACE FALTA MEDIR ALCOHOL PARA CONTROLAR EL ALCOHOL. Basta con controlar la presión — y la presión sí se puede medir, o incluso tocar con el dedo. El manómetro es el alcoholímetro.
### La ventana de reacción: no es priming, es parar una fuga
Un cervecero añade una dosis medida (unos 6 g/L) y deja que termine. Un fermentista no: **tiene 30–35 g/L de residual disponibles y lo que hace es parar la reacción a tiempo**. Con esos números, el potencial si te olvidas la botella son 8–9 volúmenes: muy por encima de los 8 bar. *La nevera no es un paso del proceso: es el freno de una reacción que no se pararía sola hasta reventar.*
Por eso la barandilla de presión de la v0.6 estaba mal planteada. No sirve avisar del *potencial* —casi toda kombucha lo tiene— sino del **margen**: cuántas horas van de «perfecta» a «revienta». A 26 °C con fruta, horas. A 18 °C sin fruta, días. Y eso enlaza directo con el ritmo de cata: **el techo de 30 °C es el punto donde ningún ritmo razonable de cata alcanza**.
### El alcohol no se mide, se deduce
Hallazgo incómodo y verificado: **el sector no sabe medir el alcohol de la kombucha**. No es un problema de un obrador: está documentado. Que AOAC tuviera que escribir un estándar *específico para etanol en kombucha* (SMPR 2016.001) ya lo dice todo — si los métodos generales de bebidas funcionaran, no haría falta uno propio. Y la Kombucha Brewers International mantiene una lista de métodos «aprobados» tras comparar cuatro tecnologías.
- **Un estudio brasileño:** 30 marcas comerciales, todas etiquetadas «hasta 0,5 %». El 60 % lo superaba, con valores de 0,10 % a 1,70 %.
- **Otro con 20 kombuchas de 9 productores:** la mayoría por encima de 0,5 %.
- **Un trabajo de Kansas State** demuestra la inexactitud de los ensayos de la industria frente a la etiqueta — y añade algo revelador: la tasa de conversión de sacarosa a etanol en kombucha NUNCA SE HA ESTUDIADO.
- **En LIRONA:** dos laboratorios, dos verdades — 0 % en uno, 1 % en otro. Eso no es mala suerte: es el estado del arte.
Hipótesis de por qué salen justo esos dos extremos. El método de referencia es cromatografía de gases con espacio de cabeza (GC-MS o GC-FID); todo lo demás sufre con esta matriz —mucho ácido, poco alcohol, CO₂ disuelto—. El **1 %** huele a método por densidad: el CO₂ disuelto baja la densidad y el cálculo la interpreta como alcohol. El **0 %** es más traicionero: el etanol es volátil, y si se desgasifica con brío se va el CO₂ *y el etanol con él*. Los dos laboratorios miden bien... otra cosa.
**Qué le hace esto al motor, en dos direcciones.** MALA: el bucle de calibración se rompe aquí. Todo lo demás se afina contra el obrador porque el paladar es la magnitud real; el ABV no tiene verdad contra la que ajustar. Con 0 % y 1 % sobre la mesa, no hay hacia dónde mover los coeficientes. Así que el ABV sale marcado como ESTIMACIÓN ESTEQUIOMÉTRICA, NO MEDICIÓN, y con rango. Es humildad calibrada aplicada a un sitio nuevo: no a la variabilidad del proceso, sino a la imposibilidad de verificar. BUENA: la estequiometría no tiene efectos de matriz. El gas y el etanol salen de la misma reacción en proporción fija, y eso no depende de la acidez ni del té ni de si desgasificaste bien. En un producto donde medir alcohol es un desastre, el camino más limpio hacia el etanol pasa por el CO₂. Fermenty no sustituye a un GC para la etiqueta — pero da algo que hoy no existe: CONSISTENCIA. Dos laboratorios dan dos verdades; el motor da siempre la misma.
### Dos caminos al vinagre, con arreglos opuestos
El eco exacto de las dos rutas a la acidez, y lo más útil que el mentor puede saber:
- **Camino A — te pasaste.** Fuiste demasiado lejos en la curva. Exceso de ácido real. Solución: corta antes.
- **Camino B — tu cocina está fría.** Acidez normal, pero sin el aroma que la equilibra, así que se percibe como vinagre. Solución: sube la temperatura. Cortar antes NO arregla nada: empeora.
Misma queja del usuario («me sabe a vinagre»), diagnóstico opuesto, consejo opuesto. Si el modelo no distingue, el mentor da el consejo equivocado *con confianza*, que es lo peor que puede pasarle. Por eso necesita saber a qué temperatura corrió la tanda antes de opinar: ahí el registro deja de ser burocracia y se vuelve diagnóstico.
Y los dos fracasos **no son simétricos**, así que el mentor no debe tratarlos igual. El **frío** falla despacio y predecible: sale mediocre, no peligroso → es un **aviso de calidad** que el avanzado puede ignorar bajo su responsabilidad. El **calor** falla rápido y puede reventar → es una **negativa**: «a 32 °C no puedo acompañarte». Una protege el producto; la otra protege al usuario.
### El pH es un faro, no un objetivo
La pregunta que bloqueaba todo era «con qué se mide el punto de corte». La respuesta real: **se mide con el paladar; el pH es el faro.**
El paladar no percibe pH. El pH mide la *fuerza* del ácido libre en escala logarítmica; lo que la lengua percibe se parece mucho más a la **relación azúcar/ácido**, porque el azúcar enmascara el ácido. Por eso, en la práctica, una kombucha a pH 3.7 puede tener acidez suficiente y otra a 3.2 parecer perfecta.
Y hay una razón estructural: el pH depende del ácido, y el ácido es S₀ × progreso. **Dos variables, un número.** El mismo 3.2 no significa lo mismo con 100 g/L de partida que con 60 — en un caso vas por la mitad de la curva, en el otro casi al final. **El pH solo se traduce a progreso si se conoce el azúcar de partida** — y el motor lo sabe, porque lo fijó él al formular. El faro funciona porque el motor tiene el mapa.
```mermaid
flowchart TD
T["Tiempo y temperatura
lo tiene todo el mundo — sensor por defecto"]
PH["pH
solo ~10%, y con ruido — es un faro"]
PA["Paladar
lo tiene todo el mundo — y es el objetivo real"]
PR["Progreso de la curva
fraccion de azucar convertida en acido"]
S0["Azucar inicial S0
cuanto hay que gastar"]
PE["Perfil percibido
relacion azucar / acido"]
T --> PR
PH --> PR
PA --> PR
PR --> PE
S0 --> PE
```
Los tres son **sensores de una misma variable oculta**. El pH depende del acido, y el acido = S0 x progreso: **dos variables, un numero** — por eso el mismo 3.2 no significa lo mismo con 100 g/L que con 60. El motor SI conoce S0 (lo fijo el al formular), asi que el faro le sirve.
**El pH nunca es obligatorio**: si lo fuera, el 90% de los usuarios queda fuera.
*Fig. 2 — Tres sensores sobre una variable oculta. El que todos tienen es la lengua.*
- **Tiempo + temperatura:** el sensor por defecto del motor. Lo tiene todo el mundo. Rudo pero universal.
- **pH:** mejora de precisión para quien lo tenga. Ruidoso (deriva, calibración, dependencia de temperatura) y en manos de ~10% de los usuarios.
- **Paladar:** lo tiene todo el mundo, y no es un sucedáneo pobre: es la magnitud real, porque es lo que el usuario quiere. Es la señal de calibración.
**Consecuencia de producto, no negociable: el pH no puede ser obligatorio.** Si el modelo lo exige, el 90% de los usuarios —el imán entero— queda fuera. El motor corre por defecto con tiempo + temperatura, se calibra contra el paladar, y el pH entra como precisión opcional. No es una feature de pago: es que el profesional tiene instrumentos. La línea gratis/pago se dibuja sola.
De ahí una conclusión que simplifica mucho: **la unidad del eje no es el pH, es la categoría de cata**. El motor no predice pH; predice *cuándo llegarás a tu punto*. Y eso hace que el motor sea más honesto de lo que temíamos: **no es un modelo químico, es una curva paladar-tiempo calibrada**, con la temperatura como variable dominante y S₀ como contexto. La ficha aporta el prior genérico (ventana ancha); las tandas del usuario la estrechan. Cero química falsa.
### Dos cortes, no uno: el paso es «cerrar», no «F2»
La práctica real: se embotella, se dejan 1–3 días a temperatura ambiente y se mete en nevera. **La nevera no es almacenamiento: es un freno.** Ese gesto es exactamente el mismo que cortar la primera fermentación — decides que ya está y lo paras. Hay **dos cortes**, no uno.
La fase cerrada es otra fermentación en miniatura, con la misma estructura: un sustrato (el residual más lo añadido), la temperatura mandando sobre la velocidad, una ventana y un corte. **Es el mismo motor corriendo dos veces** — cambia el sustrato y cambia el sensor (en vez de la lengua, la botella dura). Y el segundo corte se decide igual que el primero: se prueba cada día y se mete en nevera cuando está en el punto. Tampoco hay días fijos.
Se puede cerrar el fermentador o se pueden cerrar botellas. Por eso el marco no lleva un bloque «F2»: lleva dos pasos honestos, **cerrar** (con o sin fruta, en botella o en el propio fermentador) y **parar** (frío). La variación de presencia deja de ser «¿hay F2?» y pasa a ser «¿se cierra o se bebe abierto?».
### El saborizante es sabor y combustible a la vez
Casi nadie añade azúcar puro al cerrar; se añade fruta. Y la fruta es, a la vez, **el saborizante y el combustible**. No existe un mando de gas independiente: existe un mando de saborizante, y el gas viene de propina. No se puede echar cereza sin echar gas.
De ahí sale sola la distinción de catálogo, y no como etiqueta sino como **consecuencia medible del ingrediente**: las hierbas, especias y florales (lavanda, menta, jengibre seco) apenas aportan carbohidrato fermentable; la fruta sí. *Kombucha de hierbas* = sabor sin gas añadido, vive del residual y tarda más. *Kombucha de frutas* = sabor con combustible, y en un día ya tiene bastante gas. Esto le da nombre concreto al primer y más importante modificador de variante de un saborizante: **su carbohidrato fermentable**. El motor no necesita saber qué es «cereza»: necesita saber cuánto aporta.
### La textura del gas: un destino, no un mando
Dato de obrador que resuelve algo que la v0.2 había descartado por «abrumador»: en la fase cerrada, **temperatura alta → burbuja grande e intensa; temperatura baja (y más lenta) → burbuja fina**. Es decir, el tamaño de burbuja no es una perilla: es una consecuencia de la temperatura de cierre.
Y eso encaja con el principio de la casa: el usuario no toca la temperatura, **elige el destino**. «La quiero de burbuja fina» → el motor formula hacia atrás: cierra a 18 °C y dale 4 días, en vez de 23 °C y uno. No añade un mando; añade un destino que el motor traduce. La fase cerrada tiene por tanto **dos salidas**: cantidad de gas (del carbohidrato disponible y el tiempo) y textura de gas (de la temperatura). Y hay un intercambio real: quien quiere burbuja fina paga con días.
### Barandilla dura ≠ estilo de casa
Distinción nueva y crítica para la estructura. Durante el trabajo estuvimos a punto de meter en la ficha de kombucha un criterio que no era de la kombucha, sino de LIRONA.
- **Barandilla dura (de la ficha, universal, el motor no la cruza jamás):** acidificar lo suficiente para ser seguro (≈ pH 4.2 es el umbral que se suele citar; pendiente de fijar), y no pasar de ≈ 2.8 — ahí ya es vinagre y deja de ser kombucha. Esto último no es seguridad: es identidad de producto.
- **Techo de presión (barandilla dura):** residual + añadido + temperatura + tiempo cerrado empujan todos en la misma dirección, y pasarse no es que salga raro: revienta. Ironía incómoda — el perfil que más quiere un principiante («comercial»: S₀ alto + corte temprano + fruta) es la esquina de máxima presión del plano.
- **Suelo temporal de identidad (barandilla dura):** 4 días mínimo. No es velocidad, es secuencia: 36 h de levaduras y 36 h de acéticas. No se acelera con nada.
- **Estilo de casa (del productor, NO del fermento):** «mi kombucha comercial no baja de 3.2». Eso es una restricción de LIRONA. En casa, 3.2 con cereza puede ser buenísimo. Va en el Nivel 3, colgando de la formulación guardada del productor — nunca en la ficha universal.
**Por qué esta distinción vale oro:** un criterio comercial hardcodeado en la ficha se le endosa a todos los usuarios del mundo, en silencio y para siempre. La ficha lleva física e identidad; el perfil del productor lleva su exigencia. Es la cuarta tolerancia de la sección 6 tomando forma concreta.
## 6 Parámetros y esquema del mentor
### Tres familias de parámetros
El error natural es meter «azúcar, temperatura, dulzor, tiempo, gas…» en un solo saco. No son de la misma naturaleza: unos los **decide el usuario**, otros los **calcula Fermenty**, y otros **son del entorno** y no los decide nadie.
- **Familia 1 — Lo que el usuario DECIDE (el destino).** El perfil objetivo (intensidad + equilibrio; para el novato, una carta), la escala o volumen (un multiplicador, no un eje de sabor), la textura de gas deseada, y —solo en avanzado— restricciones. Es input.
- **Familia 2 — Lo que Fermenty PROPONE (las palancas).** Azúcar inicial, té, arrancador, carbohidrato añadido al cerrar, temperaturas objetivo. Es output del motor.
- **Familia 3 — Lo que es del ENTORNO (el contexto).** Temperatura real del obrador (la reina; manda sobre la velocidad y cambia con las estaciones), vigor de la cepa, agua. Ni se decide ni se calcula: se conoce o se aprende. Es estado persistente que se calibra.
**La clave técnica escondida:** la Familia 1 es input del usuario, la 2 es output del motor, la 3 es estado persistente que se calibra. Tres orígenes de dato distintos, tres tratamientos distintos, tres sitios distintos en el esquema.
### Palanca vs. predicción — la trampa que ya está en el código
Algunos parámetros se **fijan** (azúcar, arrancador, té); otros son **consecuencias que se predicen**, no perillas que se giran. El caso central es el **tiempo**: nadie «pone» que la kombucha tarde 7 días. El tiempo es la respuesta a «¿cuándo alcanzará tu perfil, dada esta fórmula y esta temperatura?». Por eso nunca es un número: es un **rango**.
**Esto ya está mal en el código actual y hay que revertirlo.** Existe ferment_types.default_duration_days (Kombucha = 14): una predicción guardada como configuración. Y recipe_ingredients.quantity: una cantidad soldada a la receta cuando debería ser output del motor. Si el nuevo esquema conserva cualquiera de las dos, se habrá reconstruido el mundo de las recetas fijas con otro nombre. El tiempo SALE, no entra.
Caso legítimo para más adelante: «la quiero para el sábado». Eso no es una palanca, es una **restricción**, y el motor la resuelve hacia atrás moviendo otra cosa: «a 23 °C el sábado te sale dulce; para que esté en punto, súbela a 26». Elegante y coherente con formular desde el destino, pero es nivel avanzado. En v1, el tiempo sale.
### Los cuatro tipos de tolerancia
- **1. Rango de predicción (incertidumbre).** Todo lo que se predice sale como ventana. Al principio ancha (genérica); con las tandas del usuario se estrecha a su obrador. Ese estrechamiento visible es la recompensa de registrar: «antes día 6–9; ahora que te conozco, día 7–8».
- **2. Banda de tolerancia del perfil.** Un preset es una zona aceptable del plano, no un punto exacto.
- **3. Barandilla dura (límite, no rango).** Seguridad, identidad y presión. El motor no las cruza jamás. Invisibles para el novato.
- **4. Exigencia del usuario.** El novato tiene tolerancia ancha (cualquier cosa bebible es victoria); el productor que vende, estrecha (la consistencia es su negocio). No cambia la fórmula: cambia cómo comunica Fermenty, y es donde vive el «estilo de casa».
## 7 La estructura: clasificación, guía, receta
Cambio de estructura respecto a la v0.3, decidido contra el código real. Los niveles pasan a ser **tres**, y la capa «Fermento» **desaparece**.
```mermaid
flowchart TD
CL["Clasificacion
navegacion y SEO"]
GU["Guia
marco, papeles, formula, coeficientes, barandillas"]
RE["Receta
que clase en cada papel + variaciones"]
PO["Perfil objetivo
intensidad + equilibrio"]
MO["Motor
formula hacia atras"]
CX["Contexto
temperatura, cepa, calibracion"]
FO["Formula
cantidades + ventanas previstas"]
TA["Tanda
snapshot congelado"]
LO["Lote
una tanda = un lote"]
TR["Trazabilidad
el desague de la columna"]
CL --> GU --> RE --> MO
PO --> MO
CX --> MO
MO --> FO --> TA --> LO --> TR
TA -- "check-ins" --> CX
```
La capa **Fermento (FermentType) desaparece**: "Kombucha" ES su guia. Un "fermento" entendido como receta inicial no es una capa, es una **marca sobre una receta** (is_default).
El **bucle de check-ins es la unica flecha que sube**; todo lo demas desemboca en el lote. La trazabilidad **no se construye: se evita romper**.
*Fig. 3 — La columna vertebral, de la clasificacion a la trazabilidad.*
### Por qué muere la capa Fermento
Hoy el código tiene FermentationCategory → FermentType → Recipe, con la Guía colgando del tipo. Pero «Kombucha» *es* su guía: sus pasos, sus parámetros, sus barandillas. No hay nada que un FermentType aporte que la Guía no tenga ya. Y un «fermento» entendido como «la receta inicial de una guía» tampoco es una capa: es **una marca sobre una receta** (un is_default, o un puntero guia.receta_por_defecto_id). «Kombucha clásica» no es el padre de «Kombucha de cereza y lavanda»: es su hermana, con la etiqueta de «esta es la que sirvo si no eliges nada».
Sus datos actuales se reparten: notification_rules.ferment_type_id cuelga de la Guía (y ahí está la semilla de los check-ins), plan_required pasa a la Guía, y **default_duration_days muere** (ver sección 6).
### Qué hace cada capa
- **Clasificación —** navegación y SEO. Bebidas, bebidas alcohólicas, vegetales, panes y masas, fermentos largos. No necesita rigor microbiológico: necesita ser comprensible. Reutiliza la tabla FermentationCategory existente cambiando su CONTENIDO (hoy: láctica/acética/alcohólica/fúngica).
- **Guía — el esqueleto.** Los pasos (infusionar → disolver → enfriar → arrancar → fermentar → cortar → cerrar → parar), qué papeles existen (medio, sustrato, arrancador, saborizante), la fórmula, los coeficientes, las barandillas y los defaults (23 °C, objetivo de equilibrio). Es también la frontera de coeficientes.
- **Receta — la variación.** Qué clase ocupa cada papel (medio = té negro, sustrato = azúcar blanco), qué pasos se saltan o añaden, y el objetivo por defecto. NO tiene pasos propios, ni cantidades, ni tiempos: es un objeto ligero.
**Regalo colateral: la Guía resuelve la segunda taxonomía.** Si los coeficientes viven en la guía, la «familia del motor» desaparece como dimensión separada: la regla «nunca compartas coeficientes entre familias» se cumple sola, porque cada guía tiene los suyos. Compartir = compartir guía (chucrut y kimchi podrían colgar de una misma guía «vegetal en salmuera», con recetas distintas). Clasificación = navegación; Guía = frontera del motor. Dos taxonomías, pero la segunda no es una taxonomía: es la guía.
### El alcohol: estante, no propiedad
«Alcohol» a secas sería un *cómo*, no un *qué*, y la hidromiel caería en dos sitios a la vez. La categoría es **«bebidas alcohólicas»** (cerveza, hidromiel), que es un estante legítimo. El ABV sigue existiendo por debajo como atributo calculado con sus umbrales normativos (0,5% y 1,2%). El estante ordena el catálogo; el atributo hace el trabajo regulatorio. No se pisan.
### Cultivos: la otra forma de ficha
Ginger bug, masa madre y SCOBY no son cosas que te bebes buscando un perfil: son **cultivos** — lo que fabricas es el arrancador. «Listo» no significa «llegó a tu punto», significa «está vigoroso». **El marco de una receta es una línea** (empieza, pasos, termina); **el marco de un cultivo es un círculo** — lo creas, lo alimentas, lo usas, lo vuelves a alimentar, sin final. Una tanda tiene final; un cultivo tiene estado continuo y vigor. Es una mascota, no una tanda.
Y hay una relación que unifica: **un cultivo es un ingrediente** — lo que ocupa el papel de arrancador. No hace falta un mecanismo especial de «enlace entre recetas»: el cultivo es un ingrediente que además tiene su propia receta y su propio ciclo de vida. «Para esta soda necesitas un ginger bug — ¿tienes uno, o te guío a hacerlo?» no es una feature: es un ingrediente que sabe cómo fabricarse. En el caso de LIRONA, ese arrancador se hace *o se compra*.
## 8 De la receta a la tanda
Esta sección responde lo que hasta ahora estaba sin definir: cómo se lleva una receta a la tanda de un usuario, cómo se vincula con los ingredientes y productos, y qué volumen de datos genera.
### El flujo, paso a paso
- 1\. El usuario aterriza en una RECETA (desde el catálogo o desde una landing SEO). Nunca elige una categoría: elige una receta.
- 2\. Elige PERFIL OBJETIVO y ESCALA. Nivel 1: una carta (preset). Nivel 2: deslizador por el plano. Nivel 3: parámetros.
- 3\. El MOTOR lee: guía (marco, papeles, fórmula, coeficientes, barandillas) + receta (qué clase por papel, qué pasos) + perfil + contexto (temperatura del obrador, calibración del usuario).
- 4\. El motor devuelve la FÓRMULA: cantidades por ingrediente, ventanas previstas por paso, avisos. Nada de esto está guardado en la receta: se calcula ahora.
- 5\. El usuario confirma («empecé mi tanda») → se CONGELA la tanda: cabecera + pasos + ingredientes con cantidades + ventanas.
- 6\. CHECK-INS durante la tanda: cata → el mentor interpreta, actúa en esta misma tanda, y registra para calibrar la próxima.
- 7\. Cierre → LOTE → TRAZABILIDAD.
**La receta es el punto de partida, no la que manda.** La receta define el QUÉ (esto lleva té verde, cereza y lavanda, y sí se cierra). La fórmula resuelve el CUÁNTO y el CUÁNDO. La tanda congela ambos. Si la receta mandara, habríamos reconstruido las recetas fijas con otro nombre.
### Las dos duplicaciones: una enferma, una sana
El criterio para distinguirlas es limpio: **la guía es una definición; la tanda es un hecho.**
- **La enferma (muere): Guía ↔ Receta.** Hoy guide_steps y recipe_steps guardan los dos los pasos completos, y guide_ingredients ↔ recipe_ingredients igual. Ocho recetas de kombucha = ocho copias de los mismos pasos; corriges una errata y la corriges ocho veces. Una definición duplicada es un bug: te condena a arreglar lo mismo N veces y a que las copias diverjan en silencio. Con el nuevo esquema, la receta referencia los pasos de la guía y solo guarda sus diferencias.
- **La sana (se queda): Guía → Tanda.** Al arrancar, se congela una copia dentro del lote (BatchStep ya lo hace bien: «editar la guía no afecta tandas ya creadas»). Un hecho ya ocurrió.
Sin el snapshot, editar la guía en agosto **rompería la trazabilidad** —el registro afirmaría retroactivamente que hiciste algo que no hiciste, y eso es exactamente lo que un lote no puede hacer: para un inspector, un registro que cambia solo no vale nada—, **confundiría al usuario** (va por el día 4 y los pasos le cambian bajo los pies) y **corrompería la calibración** (aprenderías de una curva que no fue la que corrió).
**El test rápido:** si arreglarlo en un sitio DEBERÍA arreglarlo en todos → la duplicación está enferma. Si cambiarlo NO debería cambiar el pasado → el snapshot es lo correcto. La copia de la receta falla el primero; la copia de la tanda pasa el segundo. El snapshot no es sobrecoste: es el producto.
Y de ahí un regalo: **si cada tanda lleva su copia congelada, no hace falta versionar las guías**. El historial ya vive en las tandas. Eso permite matar la complejidad de currentGuide() y dejar la guía como una definición mutable a secas.
### El vínculo con ingredientes y productos
```mermaid
flowchart TD
PAP["Papel
sustrato, arrancador, medio, saborizante"]
CLA["Clase
azucar, te, agua, cultivo, jengibre"]
VAR["Variante
blanco, moreno, panela / verde, negro"]
PRO["Producto de proveedor
marca, lote de compra, certificado"]
MOD["Modificadores
ajustan la prediccion del motor"]
TRZ["Trazabilidad
de donde vino"]
PAP -->|"esqueleto — solo el motor lo entiende"| CLA
CLA -->|"lo define la ficha de la guia"| VAR
VAR -->|"lo elige el usuario (niveles 1-3)"| PRO
VAR --> MOD
PRO --> TRZ
```
Quien ve cada capa: `Papel` = solo el motor (es un **campo del vinculo guia-ingrediente**, no una tabla) · `Clase` = la ficha · `Variante` = el usuario (**es el unico detalle que tiene el gratuito**) · `Producto` = solo el Nivel 3.
**Implementacion**: una sola tabla con `parent_id` (Azucar padre -> blanco/moreno/panela hijos). La linea de ingrediente de la tanda referencia SIEMPRE la variante y **opcionalmente** un lote de compra: esa columna nullable ES el puente gratis->pago.
**Las cantidades no viven en ninguna capa**: las calcula el motor.
*Fig. 4 — Las cuatro capas del ingrediente.*
- **Papel (esqueleto):** sustrato, arrancador, medio, saborizante. NO necesita ser una capa —con fórmula por guía sobra— pero sí un campo del vínculo guía↔ingrediente. Hoy «el arrancador se mete como una línea de texto más, indistinguible del agua»: sin papel, el mentor no puede preguntar «¿tienes un SCOBY vivo?». Es una columna, no una tabla.
- **Clase:** azúcar, té, agua, cultivo, jengibre, zanahoria. La tabla de ingredientes generales. La guía referencia la clase.
- **Variante:** blanco, moreno, panela; verde, negro, oolong. Con modificadores que ajustan la predicción.
- **Producto de proveedor (solo Nivel 3):** marca, lote de compra, certificado, caducidad, stock.
**Por qué la variante NO se puede dejar caer:** (1) es el único detalle de ingrediente que tiene el usuario gratuito — sin ella, panela y blanco son lo mismo y el motor predice genérico justo donde vive el imán; (2) el producto de proveedor debe enlazar a la VARIANTE, no a la clase: si «azúcar moreno eco, proveedor X» cuelga de «azúcar» a secas, se pierde que es moreno y el profesional recibiría PEORES predicciones que el doméstico; (3) las incompatibilidades viven ahí: «té» es compatible con el SCOBY, «té de hierbas» no — con solo la clase no se puede expresar la barandilla.
Implementación barata que conserva todo: **una sola tabla con parent_id**. «Azúcar» padre → blanco / moreno / panela hijos. La guía referencia al padre (genérico); el usuario elige el hijo; el profesional enlaza el hijo a un producto de proveedor. Mantiene el instinto de «tabla de ingredientes generales» sin perder precisión.
Y el puente gratis→pago cabe en **una columna nullable**: la línea de ingrediente de la tanda referencia siempre la variante, y *opcionalmente* un lote de compra. Nivel 1–2: null. Nivel 3: enlazado, y consumir la tanda descuenta stock. Misma entidad, distinta profundidad.
**Corrección a la v0.3: la capa 4 NO existe.** El documento anterior afirmaba que «la capa 4 ya existe en Fermenty (proveedores, lotes)». Es falso. El diagnóstico lo demuestra: no hay tabla maestra de ingredientes, no hay ingredient_id, no hay proveedores, ni lotes de compra, ni stock. El ingrediente es texto libre repetido en tres tablas — el «azúcar» de la receta A y el de la B son dos cadenas distintas. Es campo verde por los DOS extremos. Lo bueno: no hay legado que pelear. Lo malo: es más trabajo del que suponíamos.
### ¿Cuántos datos genera esto? (la duda del volumen)
La intuición de que «esto puede crear muchos datos» es buena higiene, pero los números dicen que **el volumen no es el problema**. Conviene separar los datos en tres capas según cómo crecen:
| | | |
|----------------|--------------------------------------|----------------------------------------------------------------------------------------------------|
| **Capa** | **Cómo crece** | **Tamaño real** |
| Catálogo | Con el contenido, no con el uso | Cientos de filas. Nunca es un problema. |
| Tandas | Lineal con el uso; acotado por tanda | ≈ 20–35 filas por tanda (1 tanda + ~9 pasos + ~6 ingredientes + check-ins). |
| Serie temporal | Uso × duración × frecuencia | La única que puede dispararse. Se acota con la frecuencia: los check-ins son diarios, no horarios. |
Con eso, las cuentas: un usuario doméstico con 2–3 tandas al mes genera ≈ 900 filas al año. **Diez mil usuarios activos ≈ 9 millones de filas al año**. Un productor con 30 tandas al mes, ≈ 11.000 al año. Para MariaDB con índices correctos, decenas de millones de filas es rutina — una tabla bien indexada aguanta cientos de millones. **No hay problema de volumen.**
El riesgo real no es el volumen, es el **patrón de acceso**: consultas N+1 al listar tandas (se resuelve con eager loading), series temporales sin tope de frecuencia, y las fotos —que son coste de almacenamiento, no de filas—.
**Y la alternativa es mucho peor.** No congelar la tanda ahorra ~15 filas y destruye la trazabilidad, que es el producto. Si aun así se quiere comprimir: los PASOS de la tanda podrían guardarse como una columna JSON (1 fila en vez de 9), porque nadie consulta «dame todas las tandas cuyo paso 3 fue X» — los pasos se leen siempre enteros y en el contexto de una tanda. Pero los INGREDIENTES de la tanda deben seguir siendo filas relacionales indexadas, porque son exactamente lo que pregunta una traza regulatoria: «¿qué tandas usaron el lote 2026-114 de azúcar?». Esa consulta contra JSON es un escaneo completo. La trazabilidad decide el formato.
## 9 Los bucles y la calibración
No hay un bucle: hay **tres, a velocidades distintas**. Confundirlos pierde la mayor parte del valor.
```mermaid
flowchart TD
CX["Contexto
tu obrador y tu cepa"]
FO["Formula
cantidades + ventana"]
TA["Tanda
fermentando"]
CH["Check-in
dulce / en punto / acida?"]
CO["Corte
y a la nevera"]
VA["Valoracion
era lo que querias?"]
CX --> FO --> TA --> CH --> CO --> VA
CH -- "BUCLE 1 (horas): sigue 2 dias — actua en ESTA tanda" --> TA
VA -- "BUCLE 2 (semanas): calibra tu obrador y tu paladar" --> CX
```
**Bucle 1 · horas** — el check-in resuelve la tanda EN CURSO. Si solo apunta, es un formulario, no un mentor.
**Bucle 2 · semanas** — se calibra el CONTEXTO, no la formula: no aprendes que quiere otra cosa, aprendes que su obrador es mas rapido.
**Bucle 3 · meses** — el agregado mejora el prior de la ficha, y eso hace que el usuario NUEVO reciba una primera propuesta mejor.
*Fig. 5 — Los tres bucles. El corto es el que convierte esto en un mentor.*
### Bucle 1 — dentro de la tanda (horas). El que casi se olvida
El check-in no registra para luego: **resuelve la tanda en curso**. Si el mentor solo apunta y el consejo llega al final, durante ocho días no ha hecho nada — es un formulario.
- **«Aún dulce» + objetivo ácido →** «va en rumbo, dale 2 días más, te aviso».
- **«En su punto» →** «¡córtala ahora! aquí van los pasos para embotellar».
- **«Muy ácida» →** «se pasó un pelín, córtala ya — y lo apunto para la próxima».
Un solo gesto hace tres cosas: acompaña (ayuda hoy), enseña a catar en vez de mirar el reloj, y captura el dato. *El valor es inmediato; la calibración es el poso que queda.*
### Bucle 2 — entre tandas (semanas). Y aquí la corrección importante
**No calibramos la fórmula. Calibramos el contexto.** Cuando alguien pide «ácida» y le sale ácida el día 7 en vez del 9, NO has aprendido que quiere otra cosa: has aprendido que su obrador es más rápido de lo que asumías. Si «modificas la fórmula», cambias lo que el usuario pidió. Lo que hay que mover es el CONTEXTO (Familia 3), y entonces la misma petición produce una predicción mejor. Esa es la diferencia entre «la app aprende lo que te gusta» (un recomendador) y «la app aprende cómo es tu cocina» (un mentor). Fermenty es lo segundo — y por eso el foso funciona: tu calibración no es transferible a nadie.
**Se calibran dos cosas, y ninguna es la fórmula:**
- **Su obrador → mueve la VELOCIDAD.** Cuándo llegará. La ventana se estrecha: «antes te decía día 6–9; ahora que te conozco, día 7–8». Ese estrechamiento visible es la recompensa de registrar.
- **Su paladar → mueve el OBJETIVO.** Si dice «en su punto» donde el motor predecía «aún dulce», su «en punto» no está donde el nuestro. Se ajusta el mapa de su lengua al eje.
### Bucle 3 — entre usuarios (meses)
Miles de tandas mejoran el **prior genérico** de la ficha, y eso hace que el usuario NUEVO reciba una primera propuesta mejor. Es el que compone con el tiempo. Con dos cautelas: el dato viene sesgado (quien registra no es representativo) y el agregado debe estar despersonalizado. Ver sección 10 para el gobierno.
### La personalización doble
Los dos primeros bucles son en realidad las dos personalizaciones que operan a la vez:
- **Según lo que el usuario SABE (su nivel).** Nivel 1: ve 3–5 cartas-preset, cero decisiones técnicas. Nivel 2: el plano como deslizadores, sin números. Nivel 3: las palancas, sus formulaciones guardadas, proveedores y lotes, y su «estilo de casa». Un motor, tres vestidos. El nivel es una LENTE, no una casta: se sube por invitación, nunca a la fuerza, y se puede bajar.
- **Según lo que el usuario ha VIVIDO (sus tandas).** La misma carta le propone a él algo distinto que a otro usuario, porque ha aprendido su obrador.
**Por qué importa:** el primer eje hace a Fermenty accesible; un competidor lo copia en una tarde. El segundo lo hace imposible de abandonar —irse significa perder tu calibración, tu histórico, el mentor que ya te conoce— y solo se construye con el tiempo del usuario dentro. Eso no se copia.
## 10 El cerebro: qué es y cómo se mantiene
«El cerebro» no es una cosa. Son cinco o seis tipos de conocimiento distintos, y el error clásico —el que hace que estos sistemas se pudran— es meterlos todos en el mismo sitio. Cada tipo tiene **dueño distinto, ritmo distinto y riesgo distinto** si se equivoca.
| | | | |
|-------------------------------------------------|---------------------------|---------------------------|------------|
| **Conocimiento** | **Dónde vive** | **Quién lo cambia** | **Ritmo** |
| La estructura — qué depende de qué | Código, un servicio | Tú, con revisión | Rara vez |
| Los coeficientes — los números | BBDD, la ficha | Tuyos; los datos proponen | Meses |
| Las barandillas — seguridad, identidad, presión | BBDD, la ficha | Solo tú | Casi nunca |
| El criterio — «si vas a cebar, corta antes» | Reglas (NotificationRule) | Tú | Ocasional |
| La calibración — tu obrador, tu paladar | BBDD, por usuario | Los datos, solos | Cada tanda |
| La voz — cómo habla | Plantillas | Tú | Ocasional |
### La regla de gobierno: lo autorado y lo aprendido no comparten cajón
Si el aprendizaje escribe encima del conocimiento autorado, **pierdes al experto** — los datos se comen tu oficio y no hay vuelta atrás. Si no aprende nada, tienes una calculadora con buena prosa. La línea correcta: **el experto pone los raíles y el punto de partida; los datos mueven los números dentro de los raíles.**
- **La calibración de un usuario se automatiza sin miedo.** Si se equivoca, afecta a uno, y el siguiente check-in la corrige.
- **La ficha NO se auto-escribe.** El agregado PROPONE, tú DISPONES. Los datos vienen sesgados y un cambio silencioso ahí mueve la predicción de todo el mundo a la vez.
- **Las barandillas NUNCA se aprenden.** Jamás. Aunque mil usuarios sobrevivan a un pH 4.5, eso no significa que sea seguro: significa que tuvieron suerte. La seguridad no se infiere de datos observacionales.
### Cómo se documenta la experiencia
No hay forma de volcar un cerebro: se extrae a base de preguntas. La sección 5 de este documento *es* esa experiencia extraída y hecha modelo — el gas que aporta acidez, las dos rutas al punzante, la fruta como combustible, la burbuja fina por frío, el arrancador que cuesta aroma. Nada de eso está en los libros.
**Pero cuidado con el formato: la prosa no la ejecuta nadie.** Un documento bonito se lee una vez y se pudre. El formato correcto de la documentación ES LA FICHA: «S₀ por defecto 70 g/L · equilibrada a 23 °C: ventana 7–9 días · carbohidrato fermentable de la cereza liofilizada: alto · de la lavanda: cero · suelo de seguridad 4.2 · techo de identidad 2.8 · banda ideal 20–25». Eso es a la vez documentación Y conocimiento que corre. El documento explica el PORQUÉ; la ficha lleva el QUÉ.
### El arranque: no hace falta tener buenos números para salir
Los primeros coeficientes son una estimación y serán regulares. No pasa nada: **son un prior, no una verdad**. Lo que salva es la humildad calibrada, que ya queríamos por otras razones: una ventana ancha y honesta («suele estar entre el día 6 y el 10») es correcta desde el día uno; una estrecha y equivocada te mata. Así el mentor puede ser **honesto en el mes 1 y preciso en el mes 12**, y el usuario no percibe un producto malo que mejora: percibe un mentor que le va conociendo.
Y hay una semilla gratis: **LIRONA tiene historia**. Si existe cualquier registro de tandas pasadas —aunque sea un cuaderno con fechas y resultados— se puede hacer **backtest**: alimentarlas al afinador y preguntar «¿habría predicho lo que de verdad pasó?». Ahí salen los primeros coeficientes sin adivinar. Con el matiz de siempre: la calibración de LIRONA es de LIRONA, no de la kombucha. Va al perfil de usuario, no a la ficha universal.
### El límite: el cerebro no es un LLM
- **Lo que un LLM NO debe tocar:** la formulación, las barandillas, la calibración. Un lote es un registro regulatorio: la misma entrada debe dar la misma salida, siempre, y ser explicable ante un inspector. Un techo de presión no puede depender de lo que un modelo decida hoy.
- **Dónde sí aporta:** convertir la salida estructurada en prosa cálida, e interpretar notas libres de cata («me sabe a vinagre pero con un toque raro») traduciéndolas a categorías.
O sea: **el LLM es la boca, no el cerebro**. El cerebro es un modelo pequeño, determinista, con la física del oficio dentro. Y es más defendible que cualquier IA — porque los pesos los tienes tú, no un proveedor.
## 11 El motor como servicio
Ya hay cuatro consumidores: el enrutado por host existe (*fermenty.es* landing, *erp.fermenty.\**, *api.fermenty.\**, *app.fermenty.\** móvil). Sin un servicio compartido, el motor se escribe cuatro veces y diverge.
```mermaid
flowchart TD
L["Landing SEO"]
E["ERP web"]
A["API"]
M["App movil"]
APP["Capa de aplicacion (Laravel)
carga ficha y contexto · aplica barandillas · persiste la tanda"]
DB[("BBDD
fichas y tandas")]
MOT["MOTOR DE FORMULACION
funcion pura — sin BBDD, sin estado"]
L --> APP
E --> APP
A --> APP
M --> APP
DB --> APP
APP <--> MOT
```
**Lo importante es la flecha que NO existe: entre la BBDD y el motor.** La ficha y la calibracion no las *busca* el motor: se le **pasan como parametro**. Por eso puede ser a la vez determinista y un sistema que aprende.
Decide la **pureza** ahora, el **despliegue** nunca: una funcion pura se mueve a otro proceso casi gratis. Lo irreversible es dejar que el motor toque la BBDD.
*Fig. 6 — El motor puro y sus cuatro consumidores.*
La ficha y la calibración no las *busca* el motor: se le **pasan como parámetro**. Eso es lo que le permite ser a la vez determinista y un sistema que aprende: lo que cambia con el tiempo no es el motor, es lo que le das de comer.
### Servicio, no microservicio
«Externo» esconde dos decisiones. **(a)** Servicio puro dentro del proceso, en app/Services/, expuesto además como endpoint HTTP. **(b)** Despliegue separado, con Laravel hablándole por HTTP. La (a) ya da lo que se busca —usable desde cualquier punto— porque el endpoint HTTP ES la API. La (b) añade salto de red, latencia, autenticación entre servicios, versionado de contrato, otro despliegue, otra cosa que monitorizar, y nada de transacciones cruzando la frontera.
**Decide la pureza ahora, el despliegue nunca.** Una función pura sin BBDD ni estado se mueve a otro proceso el día que haga falta, casi gratis: LA PUREZA ES LO QUE PRESERVA LA OPCIÓN. Lo que no tiene vuelta atrás es dejar que el motor toque la base de datos — ahí ya lo has clavado al sitio. Para un fundador en solitario, con la deuda que describe el diagnóstico y un VPS recién reinstalado tras un compromiso, montar un sistema distribuido es un impuesto diario a cambio de algo que hoy no se necesita.
### El contrato
- **Entra:** la ficha (coeficientes, rangos, barandillas) · la receta (qué clase en cada papel) · el perfil objetivo (intensidad, equilibrio, gas, textura, complejidad) · volumen · contexto (temperatura, calibración) · restricciones.
- **Sale — cantidades:** té, azúcar de F1, arrancador, saborizante, temperaturas objetivo de F1 y de cierre.
- **Sale — características previstas:** ventana de corte, ventana de cierre, gas esperado, textura de burbuja, complejidad, acidez percibida, pH estimado como faro — y con qué incertidumbre.
- **Sale — avisos:** barandillas rozadas, trueques que el motor ha decidido, y el RITMO DE CATA recomendado (que a 28 °C no es el mismo que a 20 °C).
El motor no sabe qué es la kombucha: **recibe una ficha**. Por eso el mismo servicio formula chucrut cuando se le pasa otra fila.
### Versionado: reproducibilidad regulatoria
**La tanda debe guardar CON QUÉ VERSIÓN del motor y de la ficha se formuló.** En el mes 12 los coeficientes habrán mejorado. Si alguien pregunta «¿por qué esta tanda de marzo decía 7 días?», la respuesta debe ser reconstruible con los números que estaban vivos entonces, no con los de hoy. Sin eso, cada mejora del motor REESCRIBE SILENCIOSAMENTE EL PASADO — que es exactamente lo que un registro de lote no puede hacer. Es barato si se pone desde el principio y un infierno de retrofitear. Va al snapshot.
### El prototipo
Existe un afinador funcional (artefacto React) con la ficha de kombucha completa: presupuesto de carbohidrato, arrancador que cuesta aroma, gas que aporta acidez, banda térmica, saborizante por forma, y las barandillas. La zona con gas del plano **no está dibujada: se calcula** con el mismo modelo que la fórmula. Sirve para dos cosas: validar la arquitectura (la ficha separada del motor demuestra que añadir un fermento es escribir datos) y **romper los coeficientes a mano** contra obrador real antes de escribir una línea de PHP.
## 12 Seguridad, exposición y el foso real
Hay un instinto correcto —«esto afinado es un secreto empresarial»— con un objetivo equivocado. Conviene fijarlo ahora porque **condiciona el diseño del API y del backend**, y retrofitearlo es caro.
### Los coeficientes no son el secreto (y no pueden serlo)
**Un modelo expuesto se filtra solo.** Si el afinador es público —y tiene que serlo, es el imán—, cualquiera puede llamarlo unos cientos de veces variando los mandos y RECONSTRUIR LOS COEFICIENTES POR REGRESIÓN. No hace falta robar nada: cada fórmula emitida es un punto de datos sobre el propio modelo. No se puede tener a la vez el imán y el secreto: son la misma cosa vista por delante y por detrás. Y aunque nadie lo hiciera, esos números son derivables: un fermentista competente con 50 tandas registradas llega a algo parecido. Duro de conseguir, sí. Secreto, no.
Lo que sí es inaccesible desde fuera es lo que **no está en el modelo, sino en los datos**: la calibración de cada usuario y el agregado de tandas reales con sus resultados. Eso no se puede consultar, ni derivar, ni comprar. Solo se acumula. Es el foso, y ahora con el motivo técnico debajo.
Cuidado con el momento, además: hoy no hay nada que proteger — los coeficientes son estimaciones. Y el riesgo real es que el instinto protector lleve a **no exponer el afinador** o a exponer una versión degradada. Eso cuesta justo la cosa que se convierte en el foso: el tráfico, los usuarios, las tandas, la calibración. **El secretismo y la acumulación de datos tiran en direcciones opuestas, y aquí gana la acumulación.** (Y dar un modelo peor al gratuito para «proteger» apaga el imán y convierte al mentor en deshonesto, que es lo único que no se puede permitir.)
### Reglas de exposición — a prever en el diseño del API
- **1. El endpoint devuelve FÓRMULAS, no PARÁMETROS.** Nunca serializar la ficha (coeficientes, exponentes, umbrales) en una respuesta. El cliente recibe cantidades y ventanas, no el modelo. Corolario: no existe un GET /fichas/kombucha.
- **2. La ficha no viaja al cliente.** Ni al móvil ni al front. Si el front calculara en local, el modelo se regala en el bundle JS. Toda formulación es server-side.
- **3. Las barandillas se aplican en el servidor.** Si valida el cliente, el cliente puede saltárselas. Y aquí hay seguridad física de por medio (techo de presión), no solo calidad.
- **4. Rate limiting en el endpoint público.** Por IP y por sesión. No impide la ingeniería inversa: la encarece y la ralentiza. Que es todo a lo que se puede aspirar con un modelo público.
- **5. Cuantizar y redondear la salida.** Devolver «7.3184 días» da mucha más señal que «7–9 días». La humildad calibrada, que ya se quería por producto, además reduce la señal que se regala: la honestidad y la protección coinciden.
- **6. Registrar barridos anómalos.** Quien llama 500 veces en una hora variando sistemáticamente no está formulando: está muestreando el modelo.
- **7. Autenticación por niveles.** El afinador público sin auth pero con rate limit duro; la calibración, el histórico y las formulaciones guardadas, siempre autenticados.
- **8. Versionar motor y ficha en la tanda.** No es seguridad, es reproducibilidad — pero cae en el mismo diseño de API y hay que preverlo a la vez.
### El activo que sí hay que proteger
La **base de tandas**. Ese es el activo, y crece solo. También el agregado calibrado. Cifrado en reposo, backups, acceso mínimo, y despersonalización del agregado que alimenta el prior.
**Y esto enlaza con algo práctico e incómodo.** Hubo un compromiso de root en el VPS de OVH. Mientras Fermenty era un gestor de recetas, el daño era un susto. Cuando la base de tandas sea la joya de la corona —y encima con datos personales de usuarios, con el RGPD detrás— la seguridad deja de ser higiene y pasa a ser PROTECCIÓN DEL ACTIVO. Esa es la caja fuerte, no los coeficientes. Nota RGPD: las tandas son datos personales y revelan hábitos; aplica minimización.
### La app móvil: cliente, no isla
Móvil sí — *app.fermenty.\** ya existe y es uno de los cuatro consumidores del mismo servicio. Pero **sola** vuelve a ser la trampa de siempre: sin registro no hay calibración, sin calibración no te conoce, y sin conocerte no es un mentor. Sería una calculadora que usas una vez y capturas la pantalla. Además, una app móvil no tiene SEO: los usuarios costarían dinero en vez de traerlos Google.
## 13 Motor genérico + fichas de fermento
Cada fermento tiene parámetros propios. Modelar uno por fermento no escala; un único modelo para todos miente. La salida es **separar la estructura de los parámetros**: la estructura se comparte casi entera, los parámetros son propios. No se pierde exactitud, porque la exactitud vive en los parámetros. **Un motor, muchos fermentos**: mismo esqueleto, distinta ficha.
**Lo que TODOS comparten (el motor genérico):**
- **Una curva de transformación en el tiempo.** Un sustrato que unos microbios convierten en algo. «Listo» es dónde cortas esa curva.
- **La temperatura manda sobre la velocidad.** Cambian los grados óptimos y los límites, no la relación.
- **Un eje de perfil que es «cuándo cortas».** La etiqueta cambia; la mecánica no.
- **Un arranque que modula.** Arrancador, salmuera, cultivo previo, levadura: distinto nombre, misma función.
**Lo que cada fermento trae PROPIO (la ficha — datos, no código nuevo):**
- Sus ejes y sus nombres (kombucha tiene dos; el chucrut, uno dominante y sin paso de cerrar).
- Sus rangos de temperatura: viable, ideal, y qué pasa fuera por cada lado.
- Su VENTANA TEMPORAL DE IDENTIDAD (días mín / máx): kombucha 4–30, chucrut 10–30. No es cinética: es la secuencia del consorcio, y no se acelera. Hidromiel en semanas o meses; kéfir en un día.
- Su rango de volumen válido: fuera de él el modelo no aplica (kombucha: 1–50 L; por encima falla la oxigenación).
- Su indicador de corte: paladar siempre; pH/acidez como faro en lácticos y kombucha; densidad en hidromiel (hoy NO existe en el enum de mediciones: es un hueco conocido).
- Sus barandillas: seguridad, identidad, presión.
- Sus coeficientes de velocidad, que salen de datos, no de teoría.
**La regla que protege la exactitud:** comparte estructura libremente, pero nunca compartas coeficientes entre guías distintas. Los ácido-lácticos (chucrut, kimchi) son primos hermanos y podrían compartir guía. La hidromiel es la oveja distinta —alcohólica, escala larga, densidad como faro— y cabe en el mismo esqueleto, pero forzarla a compartir parámetros con la kombucha rompería la predicción.
## 14 Cómo encaja en el Fermenty real
Esta sección incorpora el diagnóstico de integración contra el código y el esquema de erp.fermenty.es (julio 2026). **Titular: lo que hay hoy es un gestor de recetas fijas con producción y trazabilidad de proceso, bien construido en su capa de ciclo de vida del lote, pero estructuralmente la forma invertida del mentor.**
### El mentor es la puerta de entrada, no un producto hermano
El problema clásico de un ERP es que la gente solo entra cuando *tiene* que hacer una tarea, y lo que solo se abre por obligación se cancela. El mentor da una razón para volver. Y su acompañamiento produce **registros**: cada check-in captura un dato, y esos registros *son* el cuaderno de lotes. La herramienta gratuita regala el cálculo; el producto de pago cobra por **recordar**.
Forma correcta de construirlo: un **módulo autocontenido** que se *sienta* independiente de cara al usuario (su propia página, su guía SEO, entrada limpia desde Google) pero que por dentro *es* Fermenty. Una puerta lateral bonita a la misma casa.
### Lo que ya existe y sirve
- **El ciclo de vida del lote.** BatchService, ScalingService, UnitService (sólido, métrico canónico), NotificationService. La capa de servicios está bien separada aquí.
- **El snapshot de tanda.** BatchStep self-contained: editar la guía no afecta tandas ya creadas. Es la duplicación sana y ya está bien hecha.
- **La semilla de los check-ins.** NotificationRule con disparadores day/step/measurement y acciones notify/suggest/warn — literalmente «check-ins enganchados a pasos del marco». Más DailyLog.mood (caritas) y BatchEvent de tipo mood/taste/measure.
- **El vocabulario de los ejes.** FlavorResult / BatchReview ya existen — pero como salida registrada, no como entrada que dirija la formulación. Invertir esa flecha es el corazón del trabajo.
- **El enrutado por host.** fermenty.es (landing), erp.fermenty.\*, api.fermenty.\*, app.fermenty.\* — la puerta gratuita es un grupo de rutas públicas más, llamando al mismo servicio-motor.
- **La infraestructura de pago.** Cashier/Stripe, plan/premium_until, BillingService: sólida y reutilizable. Lo que habría que rehacer algún día es DÓNDE se dibuja el muro, no CÓMO se cobra.
### Lo que hay que revertir, no construir encima
- **La cantidad soldada a la receta.** recipe_ingredients.quantity es fija; la cantidad debe ser output del motor. Invertirlo toca el snapshot, el escalado y toda la siembra de recetas.
- **El ingrediente como texto libre.** Sin entidad maestra, sin ingredient_id, sin proveedor. Ya hubo un bug que DOBLABA cantidades al crear lotes, parcheado con SQL crudo — exactamente lo que pasa cuando no hay identidad de ingrediente.
- **La doble capa Guía↔Receta a medio migrar.** Dos estructuras paralelas vivas; recipe_steps cambió de «overlay fino» a «full ownership» con dos migraciones de filosofía contradictoria.
- **La taxonomía microbiológica usada para navegar.** FermentationCategory (láctica/acética/alcohólica/fúngica) es lo que el usuario navega hoy en RecipeCatalogueController. Es tabla administrable, así que el cambio es de contenido + un barrido de ~14 puntos. Cuidado con dos falsos positivos: BlogCategory y el enum de AbvCompliance.
- **Los cuatro clásicos sin ingredientes estructurados.** Kombucha, kéfir, chucrut y kimchi tienen sus cantidades como PROSA dentro de StepAction.description («Disolver 80g de azúcar»). La punta de lanza es la que peor dato tiene.
- **El mentor como stub.** Insight existe, se consume en la vista, y NADIE lo crea. Hay un roadmap de herramientas anunciado y vacío. Riesgo de asumir que hay más motor del que hay.
### Dónde va cada cosa
- **El motor → un servicio en app/Services/.** Sin estado de request: recibe (guía, receta, perfil, contexto) y devuelve fórmula + ventanas. Igual que BatchService orquesta apoyándose en ScalingService/UnitService. El riesgo no es dónde ponerlo, sino dejar que la lógica se filtre a controllers y blades — como ya pasa con la salmuera, que invoca BrineCalculator dentro de un @php en la vista.
- **La estructura del modelo → clases de servicio,** versionada en código.
- **Los coeficientes y rangos → BBDD,** una ficha por guía, editable desde acp como ya lo son categorías y fermentos. NO en config, NO hardcodeados (hoy tempFactor, BrineCalculator::TEMP_SLOPE y AbvCalculator::SG_FACTOR están en clases). Así «añadir un fermento = escribir una ficha» se cumple literalmente.
- **Los ingredientes → tabla maestra con parent_id,** papel en el vínculo con la guía, y lote de compra nullable en la línea de la tanda.
## 15 Plan de ataque
Orden propuesto. Las decisiones conceptuales van primero porque son **decisiones de esquema, no de implementación**: tomarlas tarde condena a rehacer.
**Fase 0 — El backtest (sin código, y primero)**
**La suposición más arriesgada del proyecto es que EL MOTOR PREDICE.** Todo lo demás cuelga de ahí: sin eso no hay mentor, hay una calculadora con buena prosa. Y se puede comprobar sin escribir una línea de código: coger el histórico de tandas de LIRONA —cuadernos con fechas, temperaturas y cómo salió cada una—, meterlo al prototipo del afinador y preguntar si habría acertado. ES EL TEST MÁS BARATO DE LA HIPÓTESIS MÁS CARA. Si acierta, hay un motor validado y todo lo demás es ejecución. Si falla, mejor saberlo ahora que tras tres meses de PHP. No hace falta producto básico: el prototipo existe y los datos ya existen.
- Recuperar el histórico de tandas de LIRONA: fecha, temperatura, azúcar, arrancador, cuándo se cortó, cómo salió.
- Pasarlas por el afinador y comparar predicción contra realidad. Ajustar diasRef y los exponentes hasta que el error sea razonable.
- Si el modelo no predice el pasado, no hay motor. Volver al modelo antes de tocar nada más.
**Fase 1 — Cerrar en producto (sin código)**
- Los presets de arranque con su frase de andar por casa (es literalmente la interfaz del Nivel 1).
- Los umbrales de las barandillas duras: suelo de seguridad, techo de identidad (vinagre), techo de presión.
- La forma «cultivo»: qué registra, qué predice, cómo se acompaña algo sin final.
**Fase 2 — Fundaciones de esquema**
- Tabla maestra de ingredientes (clase + variante vía parent_id) y papel en el vínculo con la guía. Es la decisión más cara de revertir: va primero.
- Consolidar Guía↔Receta: matar la duplicación enferma, la receta pasa a ser variaciones. Conservar el snapshot de tanda.
- Sustituir el contenido de la clasificación (navegación/SEO) y disolver FermentType en la Guía. Matar default_duration_days.
- Migrar las cantidades de los cuatro clásicos de prosa a estructura (bloquea todo lo demás para kombucha).
**Fase 3 — El motor**
- Servicio de formulación puro: (guía, receta, perfil, contexto) → fórmula + ventanas. Kombucha primero, con el plano intensidad×equilibrio.
- Ficha de kombucha en BBDD: coeficientes, rangos, barandillas, defaults.
- Desoldar la cantidad de la receta: la tanda recibe cantidades de la fórmula, no de la receta.
**Fase 4 — El bucle**
- Check-ins programados de cata enganchados a pasos, reutilizando NotificationRule y mood. Estado pendiente/respondido.
- Insight con productor real: interpretar la cata y actuar en esta misma tanda.
- Almacén de calibración por (usuario × guía) que consuma FlavorResult/BatchReview. La flecha que sube.
**Fase 5 — El profesional**
- Proveedores, lotes de compra, stock, caducidad. La columna nullable se rellena.
- Propagación de atributos (alérgenos, vegano, eco, ABV) desde la sustancia al producto final.
- Formulaciones guardadas del productor, con su «estilo de casa».
**Lo que NO se toca ahora: el sistema de pago.** Se queda como está (suscripción mensual/trimestral/anual; premium abre catálogo completo, imágenes, tracking ampliado y más de 2 elaboraciones). El gating está descentralizado (~30 isPremium() sueltos, sin gate central) y la línea está puesta en «iniciar-lote-de-fermento-premium» en vez de sobre los verbos guardar/historizar/calibrar/escalar/trazar. Es deuda conocida y aparcada a propósito: la energía va al mentor. Queda anotado que premium hoy tapa «ver todas las recetas», lo que choca con la decisión de que la receta es el imán SEO.
## 16 Por qué esto es defendible
- **Insider + constructor.** Alguien que vive dentro de un mercado pequeño, regulado y desatendido y que además sabe programar. La mayoría tiene una de las dos cosas.
- **El conocimiento traducido a lógica.** Cualquiera calcula una salmuera. Casi nadie sabe traducir «quiero algo suave y comercial» en una fórmula que funcione a escala. Todo el modelo de la sección 5 sale de obrador real, no de libros.
- **La calibración por usuario.** El foso que crece con el tiempo. No se copia con dinero; solo con el tiempo del usuario dentro.
- **Las recetas son el imán, no el producto.** Están gratis en todo internet: no se puede vender lo que Google regala. Lo que no existe en ningún sitio es TU cereza-lavanda, la que sale bien en tu cocina en agosto, calibrada con tus 12 tandas.
El mercado de software de cumplimiento está saturado en la capa alta, pero **nadie atiende bien al micro-productor ni al fermentista doméstico**. Ese hueco es el terreno de Fermenty.
## 17 La tesis comercial
**Aviso previo: este documento NO se le enseña a un inversor.** Es interno y lleva la cocina dentro — premisas que resultaron falsas, barandillas mal calibradas, un compromiso de root en el servidor. Esta sección es MATERIA PRIMA para un dossier aparte, no el dossier. Lo que sigue es el argumento honesto; el pulido va en otro sitio.
### Qué se está construyendo, en una frase de inversor
No una app de kombucha. Un **motor de formulación que codifica conocimiento tácito de fermentación, se calibra al entorno de cada usuario, y se vuelve más valioso cuanto más se usa**. La kombucha es el primer fermento, no el mercado.
### El tamaño de mercado: la honestidad primero
Los informes de mercado de kombucha para 2026 van de **2,9 a 5,5 mil millones de dólares**, con CAGR de **7,6 % a 20,5 %** según quién publique. Ese diferencial —casi el doble en tamaño, casi el triple en crecimiento— los invalida como base de decisión. Citar uno y callar los otros es escoger el que conviene.
Pero el problema de fondo es otro: **es el número equivocado**. Fermenty no vende kombucha. Que el mercado de la bebida crezca no dice nada sobre cuánta gente pagaría por software para fabricarla. «El mercado es de 5.000 M\$ y captaremos el 1 %» es la aritmética que un inversor serio descarta en diez segundos.
**El número correcto se construye de abajo arriba:**
- **~2.600 productores comerciales de kombucha en el mundo** (directorio Booch News). La Kombucha Brewers International agrupa ~300–400 empresas que representan ~1.700 brewers, y dice cubrir más del 90 % de la kombucha embotellada en tienda.
**Pero ojo con lo que ese número mide de verdad.** Cuenta MARCAS DE KOMBUCHA EMBOTELLADA. No cuenta al fermentista artesanal que vende en mercado, en ecotienda o por cajas — LIRONA probablemente no está en ese directorio. Así que la capa artesanal es bastante mayor de lo que sugiere el 2.600. El problema es que NO SE PUEDE MEDIR: no existe un censo de fermentistas artesanos. Y un dossier no puede dimensionar un mercado que nadie ha contado. La salida honesta es un bottom-up desde otro lado (productores de alimento registrados, mercados locales, asociaciones), pero eso es trabajo de campo, no una búsqueda. Hasta entonces: el 2.600 es un SUELO, no el tamaño.
**La cuenta fría, y hay que hacerla en voz alta:** 2.600 productores × 100 €/mes = ~3,1 M€/año de mercado total direccionable. Y eso asumiendo el 100 % de cuota, que no pasa. EL MERCADO DE PRODUCTORES COMERCIALES DE KOMBUCHA NO SOSTIENE UNA TESIS DE CAPITAL RIESGO. Es un negocio de estilo de vida excelente y un producto rentable — pero si el dossier dice «kombucha», un inversor hace esta misma cuenta y se va. La tesis NO puede ser kombucha: tiene que ser el motor y su generalización. Kombucha es la cabeza de puente.
### Las tres capas de mercado
- **1. Productores comerciales de kombucha (~2.600).** La cabeza de puente. Dolor alto (trazabilidad + el problema del ABV), disposición a pagar alta, alcanzables uno a uno. Pequeño, pero es donde se prueba que el motor acierta.
- **2. Fermentistas domésticos y caseros.** Órdenes de magnitud más gente. NO son un mercado: son ADQUISICIÓN Y DATOS. Traen el SEO, traen volumen, y sobre todo traen las tandas que calibran el motor —el foso—. Eso vale mucho, pero no paga.
**Y tienen un problema que el mentor no puede resolver: el doméstico CHURNA POR ÉXITO.** Cuando ha hecho veinte tandas, ya sabe. Ya conoce su cocina. El mentor le sobra — porque el mentor cumplió. Un ERP no tiene ese problema: el productor necesita consistencia para siempre, porque es su negocio. Dicho crudo: EL DOMÉSTICO SE VA CUANDO EL PRODUCTO FUNCIONA; EL ARTESANO SE QUEDA PORQUE LE HACE FALTA. Los dos están bien, pero solo uno paga. Si el target principal fueran los caseros, la pregunta no sería «cuántos hay» sino «qué les retiene cuando ya han aprendido» — y ahí el mentor NO es la respuesta. Las candidatas: el registro histórico, la comunidad, o el salto a vender. Está sin resolver.
- **3. Productores artesanos de alimento fermentado en general.** Quesos, encurtidos, panes, embutidos, conservas. AQUÍ está el mercado que justifica una inversión — y solo se alcanza si el motor generaliza de verdad. Esa es la apuesta, y está diseñada (motor genérico + fichas) pero no probada.
### El motor generaliza. El valor no generaliza igual.
Distinción crítica para la tesis, y son dos afirmaciones distintas de las que solo una está diseñada. Después de la kombucha vienen los vegetales, y la secuencia es correcta **por la razón buena**: kombucha es el caso rico y el chucrut es el caso degenerado que encaja hacia abajo (§10). Pero el valor del mentor cambia de forma:
- **En kombucha el mentor FORMULA.** Cuatro palancas acopladas, dos fases, riesgo de presión, ambigüedad de corte. Hay muchísimo que decidir, y el usuario no puede. Ahí el motor vale oro.
- **En vegetales el mentor ACOMPAÑA.** Sal, temperatura, tiempo. Ventana de 10–30 días, mucho más perdón, poco que formular. Pero tiene sus propios dolores: el moho y la kahm —el fallo número uno en casa, donde la gente entra en pánico—, la sal, que casi todos calculan mal, y las tres semanas de espera, donde se abandona.
Buena noticia para la arquitectura: el bucle de check-ins —la misma maquinaria— sirve para los dos casos. Lo que varía es cuánto pesa la fórmula frente al acompañamiento. Pero para el dossier importa: **«el motor generaliza» no implica «el valor generaliza»**. La segunda hay que demostrarla fermento a fermento.
### Por qué es defendible, en lenguaje de inversor
- **El conocimiento no está en la literatura.** No es que sea difícil de encontrar: es que no existe. Un trabajo de Kansas State afirma literalmente que la tasa de conversión de sacarosa a etanol en kombucha nunca se ha estudiado. Todo el modelo de la sección 5 —el presupuesto de carbohidrato, el gas que aporta acidez, el arrancador que cuesta aroma, el suelo de 4 días— sale de obrador real, no de papers. Eso no se compra.
- **El foso no es el modelo: son los datos.** Y eso es una ventaja, no una debilidad. Los coeficientes se pueden reconstruir por regresión desde cualquier API pública (§12), así que no hay secreto que proteger. Lo que no se puede copiar es la calibración acumulada de cada usuario: irse significa perder el mentor que ya te conoce.
- **Insider + constructor.** Alguien que vive dentro de un mercado pequeño, regulado y desatendido, y que además sabe programar. La mayoría tiene una de las dos cosas.
### El dolor que sí paga: el ABV
De todos los dolores del sector, este es el más caro y el peor resuelto. **El 60 % de las marcas mide mal su propio alcohol** (§5). Dos laboratorios dan 0 % y 1 % sobre la misma bebida. El límite legal es 1,2 %, así que el cumplimiento depende de a quién mandes la muestra.
Fermenty no puede sustituir un cromatógrafo para la etiqueta, y no debe prometerlo. Pero puede dar dos cosas que hoy no existen: **consistencia** (el motor da siempre el mismo número; el laboratorio no) y **causalidad** (qué decisión de proceso te empuja al límite). Y apoyado en la convergencia de la §5: si controlas la presión, controlas el alcohol. Eso es un control interno reproducible sobre un problema que hoy se gestiona a ciegas.
### Monetización
- **Suscripción (existe hoy):** mensual, trimestral, anual. Doméstico y prosumer.
- **Nivel profesional:** trazabilidad, cumplimiento, formulaciones guardadas con su «estilo de casa», escalado, proveedores y lotes. Es donde vive el ticket alto.
- **Extensión río abajo:** pedido mayorista, ruta de reparto y facturación — la costura entre producción y venta, donde el software genérico se rompe. No está construido, pero el modelo de datos lo contempla.
- **Lo que NO se monetiza, y es deliberado:** las recetas (son el imán y están gratis en Google), la API (regala el prior), los coeficientes (se filtran solos). Ver §9 y §12.
**Y una tentación que hay que cerrar por escrito: vender los datos de los caseros a la industria.** Suena a que el uso doméstico genera tanta inteligencia que serviría de modelo para la industria — perfiles, sabores demandados. Falla por tres sitios. (1) EL DATO NO ES EL QUE QUIEREN: cocinas sin control, cata autoinformada en tres categorías, cero validación instrumental; la industria trabaja con paneles entrenados. (2) LA POBLACIÓN ESTÁ SESGADA: quien fermenta kombucha en casa es un entusiasta, y sus preferencias predicen las de otros entusiastas, no las de quien compra la botella en el súper — que es el que le importa a la industria. (3) ROMPE EL TRATO: la gente registra porque el mentor le ayuda A ELLA; si esos registros se venden y se sabe, se acaba el registro, y con él el foso. Más el RGPD detrás. Es la trampa clásica del «nuestro verdadero negocio son los datos»: casi nunca funciona, y aquí encima canibaliza lo que sí funciona. El dato compone HACIA DENTRO (bucle 3, §9), no hacia fuera.
### Comparables
- **Software de brewing (BeerSmith, Brewfather y similares):** suscripción, camino hobbyista→profesional, formulación + registro de lotes. Demuestra que el modelo de negocio funciona en fermentación y que el puente doméstico→pro es real. Pero son de cerveza: un mundo con literatura, estándares y datos publicados. Fermenty opera donde no los hay.
- **ERP de alimentación:** caros, pesados, pensados para volumen industrial. No bajan al micro-productor porque no les compensa.
- **El hueco:** nada vertical para el fermentado artesano. Ni formulación con calibración, ni trazabilidad ligera. El mercado de software de cumplimiento está saturado en la capa alta y vacío en la baja.
### Los riesgos, dichos en voz alta
Un dossier que no los liste pierde credibilidad ante quien sepa mirar. Estos son los reales:
- **El TAM de kombucha no sostiene capital riesgo.** ~3 M€/año con cuota total. La tesis depende de una generalización que está diseñada pero no probada.
- **Los coeficientes no están calibrados.** Hay un punto de referencia validado (70 g/L, 10 %, 23 °C → 7–8 días) y un prototipo funcional. El resto es estimación pendiente de backtest.
- **El código actual es la forma invertida del producto.** El diagnóstico (§14) es claro: cantidades soldadas a la receta, ingrediente como texto libre sin entidad maestra, doble capa a medio migrar. Hay que revertir, no construir encima.
- **El ABV no se puede validar.** El bucle de calibración se rompe justo en la métrica de mayor valor comercial.
- **Fundador único.** El conocimiento de dominio y la capacidad de construir están en la misma persona. Es la ventaja y es el riesgo.
- **La seguridad ya falló una vez.** Compromiso de root en el VPS. Cuando la base de tandas sea el activo —con datos personales y RGPD detrás— eso deja de ser un susto.
### Qué financiaría una inversión
Por orden de lo que desbloquea: **(1)** calibrar los coeficientes contra datos reales —backtest del histórico de LIRONA y las primeras tandas de usuarios—, que es lo único que separa un modelo bonito de un mentor que acierta; **(2)** construir el motor y el bucle de check-ins sobre las fundaciones de esquema que hay que revertir; **(3)** escribir las fichas de los siguientes fermentos, que es donde se prueba —o se cae— la tesis de la generalización. **El hito que de verdad importa no es tener usuarios: es demostrar que el motor predice, y que un fermento nuevo es una fila de datos y no un proyecto.**
## 18 Qué queda por definir
*Resueltos hasta aquí: el presupuesto de carbohidrato en el tiempo, el gas que aporta acidez percibida y las dos rutas al punzante, el arrancador como palanca, la banda térmica y el techo de control, el suelo temporal de identidad, la burbuja como consecuencia, la complejidad multifactorial, el volumen, los dos caminos al vinagre, los tres bucles, la calibración del contexto (no de la fórmula), el gobierno del cerebro, el motor como servicio puro con su contrato, y las reglas de exposición del API.*
- **EL BACKTEST.** Lo único que importa ahora. ¿Predice el motor el histórico real de LIRONA? Es la hipótesis de la que cuelga todo el proyecto y se puede responder sin código, con el prototipo y los cuadernos que ya existen. Punto de referencia ya validado: 70 g/L, 6 g/L de té, 10 % de arrancador, pH inicial 5, 23 °C → 7–8 días (el modelo da 7,9). Falta el resto de la curva.
- **Los coeficientes de la ficha de kombucha.** La forma del modelo es sólida; muchos números siguen siendo un dedo. Salen del backtest, no de discutirlos.
- **Qué retiene a un casero que ya sabe.** Sin respuesta, la capa doméstica es embudo y no negocio — y el dossier debe decirlo así. Candidatas: el histórico, la comunidad, el salto a vender.
- **El censo real de fermentistas artesanos.** El 2.600 es un suelo que cuenta marcas embotelladas, no artesanos. Sin un bottom-up de campo, el mercado intermedio no está dimensionado.
- **Los presets con su frase de andar por casa.** Los cinco ya tienen coordenada en el plano. Falta la frase de cada carta y decidir cuántas ve el Nivel 1. Es literalmente la interfaz del principiante.
- **El techo de presión.** La única barandilla que puede hacer daño físico, y la peor definida. Qué combinación de carbohidrato al cerrar + temperatura + días es la línea roja. Ironía a vigilar: el perfil que más quiere un novato («comercial») es la esquina de máxima presión del plano.
- **Los umbrales de identidad.** Suelo de seguridad ≈ 4.2 (por confirmar) y techo de vinagre ≈ 2.8. Recordar la distinción: el «no bajo de 3.2» de LIRONA es ESTILO DE CASA, no barandilla — va al perfil del productor, nunca a la ficha universal.
- **El carbohidrato fermentable por saborizante y forma.** Cereza fresca / seca / liofilizada / extracto hacen cosas opuestas con el mismo peso: una presuriza la botella y la otra ni la mueve. Y la que puede reventar es la que un novato compraría por «práctica». Es dato de ficha, se autora, no se adivina.
- **La ficha de cultivo.** Marco circular, medida = vigor. Choca de frente con Batch, que asume status terminal y actual_end_date. Laguna estructural completa.
- **El diseño fino de los check-ins.** A qué pasos se enganchan, qué preguntan, el camino «algo va mal» (moho, olor), y el ritmo variable con la temperatura. El check-in del cierre tiene una respuesta física obvia: «¿la botella está dura?».
- **El versionado de guías.** Si el snapshot de tanda ya guarda el historial, probablemente currentGuide() puede morir. Confirmar contra el código.
- **La línea gratis/pago sobre verbos.** Aparcada a propósito. Cuando se retome: un gate central sobre guardar/historizar/calibrar/escalar/trazar, en vez de ~30 isPremium() sueltos.
**Siguiente paso:** el backtest. Nada más. El diseño está cerrado y el documento está suficientemente terminado; más versiones no lo mejoran, lo engordan. Lo que decide si esto es un producto o un ensayo bonito es si el motor predice el pasado de LIRONA. Después de eso —y solo después— tiene sentido el segundo diagnóstico de Claude Code contra la estructura ya decidida, y empezar la Fase 2.
*— fin del documento —*