Cómo está hecho Milpa, de sus archivos de evidencia a la app
Cada respuesta que da Milpa se remonta a una regla calificada y con fuentes, guardada en un conjunto de archivos de texto sin formato. La app es una capa delgada encima de ese registro.
Por qué esto te importa
Cada respuesta que te da el planificador se puede rastrear hasta una regla, y cada regla dice qué tan seguros estamos de ella, cómo funciona y en qué se apoya. Eso solo es posible por cómo está armado el proyecto: el conocimiento va primero, y la app se construye encima.
La mayoría de los planificadores de huerto son una app con algunos datos dentro. Este es un conjunto de datos con una app delante. Suena a distinción académica, y decide todo lo que viene después.
Los datos viven en lo que llamamos el corpus: una carpeta de archivos de texto sin formato (escritos en YAML, un formato sencillo que pueden leer tanto las personas como los programas) con 109 especies, 38 equipos de plantas, 123 reglas y 35 creencias populares. Está hecho para ser correcto, fácil de comprobar y capaz de sobrevivir a que se reescriba por completo todo lo que lo rodea. Si mañana se borrara la app web, lo que vale la pena tener seguiría aquí.
Cada regla dice su razón, o no es una regla
El proyecto se obliga a cuatro promesas que no negocia. La primera es la que más le da forma al contenido:
Ninguna regla se aplica sin un mecanismo con nombre. Si una regla no puede enunciar su mecanismo en una oración sin la palabra “ayuda”, no es una regla de la calificación más alta. Bájale la calificación o elimínala.
Dicho más sencillo: una regla solo puede calificarse como bien establecida o prometedora si puede decir, en una oración, cómo funciona. “Ayuda” es la señal. Es la palabra que deja pasar una afirmación sin examinar disfrazada de afirmación comprobada, y prohibirla en ese único campo tumba de un solo golpe la mayor parte del canon de la asociación de cultivos.
Las otras tres: un equipo de plantas que no cabe en tu cama se muestra en gris con la razón y nunca se cambia por otro en silencio; el motor no inventa una cifra de fertilizante y te dice que hagas un análisis de suelo; y una fuente que nadie ha leído no se puede marcar como verificada.
Dos de esas cuatro se hacen cumplir de forma automática, con un programa de verificación que corre en cada cambio. La cuarta no se puede, y de esa trata la sección siguiente.
Verificada quiere decir que una persona leyó la fuente
Cada regla lleva un estado de evidencia. unverified (sin verificar) quiere decir que un modelo de lenguaje hizo la afirmación a partir de conocimiento general y nadie la ha comprobado. Subir una regla a verified (verificada) requiere una fuente real en las notas de la propia regla, leída por una persona.
Ningún proceso automático puede tomar esa decisión, incluido el que escribió la mayor parte de este código. Ahora mismo hay 0 reglas que siguen sin verificar. Ese número se publica porque un corpus que no reconoce sus propias afirmaciones sin comprobar no es realmente auditable.
Las fuentes se guardan como texto sin formato, palabra por palabra, por lo general con la oración que sostiene la afirmación y la fecha en que alguien la leyó. Cuando abres una fuente en cualquier parte de este sitio, ves lo que anotó el corpus. No se retoca para convertirlo en un resumen.
Bajar de calificación es una virtud
Las calificaciones se mueven en los dos sentidos. Que una regla baje de un nivel de confianza alto a uno más débil, porque la investigación era más floja de lo que suponíamos, es el sistema funcionando exactamente como debe. La bajada se registra, y la regla no se borra.
Por eso el corpus se guarda como archivos sin formato en git, un sistema de control de versiones que registra cada cambio. Las filas de una base de datos no conservarían esta historia. Cada cambio de calificación es su propio commit, con la fuente que lo causó escrita en el mensaje del commit. El historial de versiones es la historia de lo que el proyecto creía y por qué: puedes preguntar cuándo se confió en una afirmación, por qué cambió y qué leyó alguien para cambiarla.
Dos motores que tienen que coincidir
El motor de reglas existe dos veces. La versión de referencia está en Python; la app usa una versión en TypeScript dentro de tu navegador. El código duplicado se desvía con el tiempo, así que el lado de Python genera las respuestas y el motor de TypeScript se compara con ellas en cada cambio. Si los dos llegan a no estar de acuerdo sobre lo que hace una regla, la compilación se pone en rojo.
El mismo truco mantiene exactas estas páginas. El sitio que estás leyendo presenta el corpus una segunda vez, justo al lado de la app, y una prueba lee el propio código de la app y falla si los dos llegan a describir la evidencia de manera distinta.
Sin servidor, sin API del clima
La app no tiene servidor. Los datos del clima se calculan de antemano en un archivo estático al compilar y se guardan en el repositorio como cualquier otro archivo. Eso quiere decir que el planificador funciona sin conexión, que los cambios en la capa del clima se pueden comparar línea por línea como el código, y que la única dependencia externa de todo el sistema se actualiza más o menos una vez por década en lugar de una vez por consulta.
Lo que falta a propósito
- Ninguna tabla de asociación de cultivos, nunca.
- Ningún lienzo de arrastrar y soltar, salvo en un lugar con una razón concreta.
- Ninguna cifra de fertilizante sin un análisis de suelo.
- Ningún equipo de plantas sacado de blogs de permacultura. La lista de los reales es corta, y está pensada para serlo.
Léelo por tu cuenta
La página de evidencia de la app enumera cada regla y cada creencia con su calificación, su razón y sus fuentes. Este sitio pone ese mismo material en páginas a las que puede llegar un buscador.