Versão fácil: a arquitetura do previsor Marola, com a avaliação primeiro e sem repositório novo¶
Esta é a versão fácil, em português, de MIP-0091: The Marola forecaster's architecture — the evaluation goes first, no new repo, and the design requirements from Read, Evaluate, Adopt on Operational WeatherBench.
- Vale o original. O documento em inglês é a fonte da verdade. Se este texto e o original discordarem, vale o original.
- Situação do original: Accepted (aceita), em 2026-10-13, na revisão inicial de Hoffmann. O original diz que ela precisa de refinamento antes de a lista de tarefas ser escrita.
- Feita a partir de: a versão de 2026-10-13 do original, que entra no mesmo commit que esta versão fácil.
- Para quem é: quem quer entender o que foi decidido, sem ser especialista.
- O que ficou de fora: as contas, os detalhes de implementação e os nomes dos testes. Cada trecho encurtado aponta para a seção do original.
- Escrita por: Hoffmann, com Claude Code.
Em poucas palavras¶
O marola vai citar uma previsão de vento e de onda por praia. Ela será escolhida entre vários candidatos pela habilidade verificada (verified skill): o quanto cada um acertou, medido contra o que aconteceu.
A MIP-0091 decide três coisas antes de qualquer construção. A avaliação das previsões vem primeiro, nenhum repositório novo é necessário, e a arquitetura precisa cumprir vinte requisitos.
Nada disto está construído. A MIP-0091 é um projeto, não um sistema em funcionamento. O status dela é Accepted, e ela ainda precisa de refinamento antes de virar lista de tarefas.
O gasto com nuvem é zero. A Fase 1 (o bot do Telegram) não está pronta, e nada nesta MIP move a Fase 1. A MIP é pesquisa fora da lista de fases, como a MIP-0083.
Qual é o problema?¶
Em 2026-10-13, o dono do projeto fez três perguntas. Qual módulo vem primeiro: o marola-forecaster, que escolhe a previsão, ou o marola-eval, que mede as previsões? Quantos repositórios são necessários? E o que a arquitetura precisa cumprir, aplicando o método Ler, Avaliar, Adotar (Read, Evaluate, Adopt, REA) ao Operational WeatherBench (OWB)?
O OWB é o painel da Brightband que ordena modelos de previsão do tempo por um protocolo fixo. O
original conferiu a metodologia dele em 2026-10-13 (v). O OWB não tem ondas, não compara com
boias nem com estações, e não escolhe um modelo: são três acréscimos do marola
(§4.1 do original).
Cada fonte de previsão que pode ser escolhida é um braço (arm). Três fatos respondem às duas primeiras perguntas (§2 do original):
- Nada pode ser escolhido antes de ser medido. A regra de troca da nota de política (§4.5 dela) usa os escores (scores) da avaliação. Sem eles, só funciona o recuo (fallback), que é a mediana dos braços admitidos.
- A avaliação já começou. O módulo
experiment, da MIP-0083, já está no marola-app e roda um ciclo a cada 4 h. Mas o registro (record) dele fica num cache apagado depois de 7 dias sem uso, e ainda não serve para aprender. - Um repositório "marola-eval" foi proposto e retirado em 2026-10-09 (MIP-0083 §9).
Falta a camada que decide qual braço o marola cita. É ela que a MIP-0091 projeta. A nota de política, Contextual Bandits for Weather Bench: The Marola forecaster (v0.1.0, 2026-10-12), fica privada até ter um registro no Zenodo. A MIP dela vem depois desta.
O que foi decidido¶
A avaliação vem primeiro. A recompensa da camada de decisão (marola-forecaster) é o resultado
da avaliação (marola-eval). Por isso a avaliação vem primeiro, e a camada de decisão é construída
em cima dela. Dois terços da avaliação já estão construídos, no módulo experiment da MIP-0083
(§1 do original).
Nenhum repositório novo. A camada de decisão é um módulo novo do marola-app, o forecaster.
Ele depende do experiment, e nunca o contrário. Os braços calculados (computed arms) são
rodadas de onda feitas em máquina própria, e ficam no h0ffmann/ww3-gpu, fora da organização. A
ciência vai para o marola-research, que hoje só tem um arquivo de licença
(§4.4 do original).
Um repositório novo só por dois gatilhos, e por nenhum outro. O primeiro é o ciclo do WW3 rodar sem supervisão num executor próprio, com fluxo de trabalho, ritmo de dados e portões (gates) próprios. O segundo é um acordo entregar dados num formato, ou sob termos, que não podem ser lidos em código público. O teste é o da MIP-0070 §9.
Vinte requisitos, de R1 a R20. Eles saem de ler o OWB, avaliar o que dele vale nos instrumentos brasileiros e adotar o resto. São sete assuntos, e a lista inteira está na §4.3 do original:
- medir antes de decidir (R1, R7, R9);
- regras fixas, com versão e públicas (R2, R3);
- a verdade (truth) é o que foi medido em pontos, e as ondas têm escore próprio (R4, R5, R6);
- uma regra para os braços baixados (fetched arms) e outra para os calculados (R8, R13, R14);
- troca conservadora do braço citado, sem exploração ao vivo (R10, R11);
- admissão por correção, contratos entre repositórios e gasto zero (R15, R16, R17);
- saída honesta e pública (R18, R19, R20).
O requisito R12, a segurança fora da camada de decisão, está na seção "E a segurança?".
Trocar o braço citado exige o intervalo de 95 % acima de zero contra o braço atual (incumbent), em duas rodadas semanais seguidas. Essa exigência repetida é a histerese (hysteresis). Onde há poucas amostras, ou onde o portão nunca passou, o marola publica o recuo. Uma chave de desligamento (kill switch) devolve tudo ao recuo.
Seis etapas, de 0 a 5, uma de cada vez (§5.6 do original):
- Etapa 0, em andamento: a MIP-0083 v0 pronta e o registro durável no B2 (MIP-0075, tarefa 5).
- Etapa 1: as ondas entram na avaliação. Espera a etapa 0 e os arquivos do BNDO.
- Etapa 2: o módulo
forecaster, só com o registro de vento. Espera a etapa 0. - Etapa 3: os braços calculados entram no registro. Espera um braço calculado admitido.
- Etapa 4: o marola passa a ler o arquivo com o braço escolhido. Espera a primeira aprovação no
portão num ponto
scored, em duas rodadas semanais seguidas. - Etapa 5: a ciência é publicada. Espera o aval do dono para publicar.
Tudo é determinístico. Nenhum LLM lê ou escreve nada disso. O resumo do LLM pode dizer o nome do braço citado, sob a guarda de fatos da MIP-0039, e nada além disso (§5.7 do original).
Nove alternativas foram descartadas (§9 do original). Uma era só ordenar os modelos, como o OWB, mas o marola ainda precisa escolher um número por praia. Outra era o sorteio ao vivo, que mostraria ao banhista uma previsão escolhida ao acaso.
O que muda para quem usa o marola¶
Nada, até um ponto estar scored (MIP-0083 §5.8) e o portão ter passado em duas rodadas semanais
seguidas.
Depois disso, o bloco detalhado da linha de comando ganha uma linha com rótulo, e mais tarde a página da praia também. Essa linha é calculada a partir do registro e nunca é escrita por um modelo. Ela diz qual braço é citado, por que ele venceu e se os modelos concordam. Onde ainda não há vencedor, ela mostra o recuo, com o rótulo "concordância entre modelos" (§3 do original).
E a segurança?¶
Nada muda na segurança. A nota de banho e o veto de ressaca (MIP-0062) não leem nada do que esta
MIP produz, e mostram exatamente o que mostram hoje. O programa cli não depende do módulo
forecaster.
A única mudança do lado do produto vem na etapa 4. Nela, muda qual modelo o marola pede ao Open-Meteo. Essa escolha vem de um arquivo registrado no repositório, que só muda por um PR revisado. Ao lado do número, o marola mostra o quanto os modelos discordam (MIP-0038).
O banhista só vê um braço que passou no portão de correção e foi verificado (R11). O robô que abre o PR nunca faz o merge: uma pessoa faz. O original registra que a MIP-0062 e a MIP-0038 são Draft (rascunho). O detalhe técnico está na §6 do original.
O que ainda não está pronto, e o que pode dar errado¶
Nada da MIP-0091 está construído. As tarefas esperam o refinamento, nenhuma issue foi aberta, e os testes têm nome, mas não foram escritos.
A MIP-0091 está bloqueada pela MIP-0083 e depende de quatro coisas. São a MIP-0083 v0 rodando sem supervisão, a tarefa 5 da MIP-0075, os arquivos do PNBOIA pelo BNDO e a MIP da política. Obter esses arquivos é um ato de uma pessoa. A MIP-0091 não depende de nenhum portão da Fase 1 nem de recurso pago.
Os riscos e limites da §8 do original são sete:
- O registro ainda não é durável. Até a tarefa 5 da MIP-0075, ele fica num cache apagado depois de 7 dias sem uso. A camada de decisão pode aprender com um registro que não é durável, ou é curto demais. Ela pode então trocar o braço citado por causa de ruído. Por isso o lago de dados no B2 é pré-requisito da etapa 2, e uma troca exige evidência duas vezes (R10).
- O recuo é o estado normal. O PNBOIA teve no máximo cerca de nove boias ao mesmo tempo
(MIP-0083 §4.10). Com poucas boias, a maioria das células fica
low_samplepor meses. O painel vai dizer "concordância entre modelos" muito mais vezes do que vai dar um vencedor. Esse é o resultado honesto, e a página não pode enfeitá-lo. - Um registro curto, só de El Niño. A habilidade aprendida de outubro de 2026 a março de 2027 pode não valer em anos neutros. O projeto deixa isso visível, mas não resolve.
- Um só processo escreve no lago de dados. Uma carga de dados longa atrasa uma decisão em minutos, e nunca a corrompe.
- O arquivo publicado depende de um merge humano. Uma semana sem merge é uma semana no vencedor anterior, que o portão já tinha julgado aceitável.
- O ww3-gpu é o repositório de uma pessoa. Se ele parar, a etapa 3 não é construída, e o marola escolhe só entre os braços baixados. Nada mais fica esperando.
- Três coisas estão marcadas com ⚠. São os modelos de onda do Open-Meteo nesta costa, o
formato dos arquivos do PNBOIA e os termos dos acordos. Até a conferência, cada uma é uma linha
missingou uma célula "not shown" (não mostrada), nunca um palpite.
Parte da verdade vem sob acordos que restringem a redistribuição, como o Termo de Compromisso do BNDO. Esses dados entram nos escores, mas não na exportação, e a tabela de resultados diz quantas células não pôde mostrar.
O original também lista sete itens que não foram conferidos (Not checked). Um deles é o ww3-gpu: os fatos sobre ele vêm de uma nota de 2026-10-12, não relida ⚠.
O que continua em aberto¶
São nove pontos, cada um com uma resposta padrão no original (§11 do original). Três deles:
- O nome "marola-eval" continua? Sim, como nome do benchmark. O módulo continua
experiment. - Qual boia vem primeiro? Uma boia do PNBOIA ao largo de Santa Catarina, com registro contínuo, confirmada quando os arquivos do BNDO forem lidos.
- O ww3-gpu entra na organização marola-dev? Não. O primeiro gatilho diz quando rever.
Os outros seis tratam do merge, do fluxo semanal, dos parâmetros, de serem uma MIP ou duas, e das duas MIPs seguintes.
Palavras usadas¶
- Braço: cada fonte de previsão que pode ser escolhida. O braço atual é o que o marola cita.
- Camada de decisão: a parte que escolhe o braço. No original em inglês, é "the forecaster".
- Escore e célula: o escore mede o erro de uma previsão, e não é a nota de banho. Uma célula junta os escores de um mesmo contexto.
- Portão: uma verificação que precisa passar antes do passo seguinte.
- Recuo: o que o marola publica quando não há vencedor, a mediana dos braços admitidos.
Onde ler o resto¶
- O que vale nos instrumentos brasileiros, e o que o marola já tem: §4.2.
- O mapa dos módulos e o fluxo: §5.1 e §5.2.
- O que a avaliação ganha, e os arquivos do módulo
forecaster: §5.3 e §5.4. - Os contratos, os testes e o que foi conferido ao vivo: §5.5, §7 e Checked live.
Índice remissivo¶
Este índice lista os termos desta versão fácil em ordem alfabética, e "Onde" aponta para as seções deste texto, ou para a seção do original quando este texto só remete a ela. O termo em itálico é a entrada correspondente no índice do original em inglês.
| Termo | Onde | Ver também |
|---|---|---|
| acordos de dados (licence tier) | Decidido, Riscos | BNDO, tabela de resultados |
| alternativas descartadas (alternatives) | Decidido, §9 do original | gatilhos para um repositório novo |
arquivo publicado (published-forecaster.json) |
Decidido, Segurança, Riscos | etapas 0 a 5, cli |
| avaliação, a (evaluation, the) | Em poucas palavras, Problema, Decidido | marola-eval, experiment, módulo, escore e célula |
| B2 | ver lago de dados | |
| banhista (swimmer) | Decidido, Segurança | exploração ao vivo (R11), nota de banho |
| BNDO | Decidido, Riscos, Em aberto | PNBOIA, verdade |
| boia (buoy) | Problema, Riscos, Em aberto | PNBOIA, verdade |
| braço (arm) | Problema, Decidido, Palavras usadas | braço atual, braço baixado, braço calculado, camada de decisão |
| braço atual (incumbent) | Decidido, Palavras usadas | portão, histerese |
| braço baixado (arm, fetched) | Decidido, Riscos | braço calculado, Open-Meteo |
| braço calculado (arm, computed) | Decidido | ww3-gpu, portão de correção, braço baixado |
| braços admitidos (admissible arms) | Problema, Palavras usadas | recuo, portão de correção |
| Brightband | ver OWB (Operational WeatherBench) | |
| camada de decisão (forecaster, the) | Problema, Decidido, Riscos | forecaster, módulo, marola-forecaster, braço |
| chave de desligamento (kill switch) | Decidido | recuo |
cli |
Segurança | nota de banho, forecaster, módulo |
| concordância entre modelos (model agreement) | ver recuo | |
| contratos (contracts) | Decidido, §5.5 do original | ww3-gpu |
| determinístico (deterministic) | Decidido, §5.7 do original | LLM |
| discordância entre modelos (disagreement between models) | O que muda, Segurança | MIP-0038, recuo |
| dono do projeto (Hoffmann (the owner)) | cabeçalho, Problema, Decidido | |
| El Niño | Riscos | registro |
| escore e célula (score cell) | Problema, Riscos, Palavras usadas | avaliação, a, verdade |
| etapas 0 a 5 (stages 0–5) | Decidido, Segurança, Riscos, §5.6 do original | gatilhos para um repositório novo |
experiment, módulo (experiment module) |
Problema, Decidido, Em aberto | avaliação, a, marola-eval, forecaster, módulo |
| exploração ao vivo (R11) (exploration, no live (R11)) | Decidido, Segurança | banhista, portão de correção |
| Fase 1 (o bot do Telegram) (Phase 1 (the Telegram bot)) | Em poucas palavras, Riscos | gasto zero (R17), situação da MIP (Accepted) |
forecaster, módulo (forecaster module) |
Decidido, Segurança | camada de decisão, experiment, módulo |
| gasto zero (R17) (zero spend (R17)) | Em poucas palavras, Decidido, Riscos | Fase 1 (o bot do Telegram) |
| gatilhos para um repositório novo (repository, new) | Em poucas palavras, Decidido, Em aberto | ww3-gpu, MIP-0070 |
| habilidade verificada (verified skill) | Em poucas palavras | escore e célula |
| histerese (hysteresis) | Decidido | portão, braço atual |
| intervalo de 95 % (bootstrap, paired block) | Decidido | portão, troca conservadora (R10) |
| lago de dados (lake) | Decidido, Riscos | registro, MIP-0075 |
| LLM | Decidido | determinístico, MIP-0039 |
low_sample |
Decidido, Riscos | recuo, PNBOIA |
| máquina própria (hardware, owned) | Decidido | braço calculado, gasto zero (R17) |
| marola-app | Problema, Decidido | experiment, módulo, forecaster, módulo |
| marola-eval | Problema, Decidido, Em aberto | avaliação, a, experiment, módulo |
| marola-forecaster | cabeçalho, Problema, Decidido, O que muda, Segurança, Riscos, Em aberto | camada de decisão, forecaster, módulo |
| marola-research | Decidido | Zenodo |
| MIP da política (policy MIP) | Riscos, Em aberto | nota de política |
| MIP-0038 | Segurança | discordância entre modelos |
| MIP-0039 | Decidido | LLM |
| MIP-0062 | Segurança | ressaca, veto de |
| MIP-0070 | Decidido | gatilhos para um repositório novo |
| MIP-0075 | Decidido, Riscos | lago de dados, registro |
| MIP-0083 | Em poucas palavras, Problema, Decidido, O que muda, Riscos | avaliação, a, experiment, módulo |
| modelo escolhido (model (selected)) | ver braço | |
| nota de banho (Swimability) | Segurança, Palavras usadas | ressaca, veto de, segurança fora da camada de decisão (R12) |
| nota de política (policy note) | Problema | MIP da política, Zenodo |
| Open-Meteo | Segurança, Riscos | braço baixado |
| OWB (Operational WeatherBench) | Problema, Decidido, §4.1 do original | REA (Ler, Avaliar, Adotar) |
| PNBOIA | Riscos, Em aberto | BNDO, boia, verdade |
| portão (gate) | Decidido, O que muda, Riscos, Palavras usadas | histerese, portão de correção, recuo |
| portão de correção (correctness gate) | Problema, Decidido, Segurança, Palavras usadas | braço calculado |
| previsor | ver braço | |
| questões em aberto (open questions) | Em aberto, §11 do original | MIP da política, ww3-gpu |
| REA (Ler, Avaliar, Adotar) (REA (Read, Evaluate, Adopt)) | Problema | OWB (Operational WeatherBench), requisitos R1–R20 |
| recompensa (reward) | Decidido | avaliação, a |
| recuo (fallback) | Problema, Decidido, O que muda, Riscos | chave de desligamento, low_sample, portão |
| registro (record) | Problema, Decidido, O que muda, Riscos | lago de dados, MIP-0075 |
| requisitos R1–R20 (requirements R1–R20) | Em poucas palavras, Decidido, §4.3 do original | troca conservadora (R10), segurança fora da camada de decisão (R12), gasto zero (R17) |
| ressaca, veto de (ressaca veto) | Segurança | nota de banho, MIP-0062 |
| riscos e limites (risks and limitations) | Riscos, §8 do original | registro, recuo, El Niño |
scored |
Decidido, O que muda | portão |
| segurança fora da camada de decisão (R12) (safety outside the forecaster (R12)) | Decidido, Segurança, §6 do original | nota de banho, ressaca, veto de, cli |
| situação da MIP (Accepted) (status (Accepted)) | cabeçalho, Em poucas palavras | Fase 1 (o bot do Telegram) |
| tabela de resultados (scorecard) | Riscos | acordos de dados |
| Telegram, bot do (Telegram bot) | ver Fase 1 (o bot do Telegram) | |
| Termo de Compromisso | ver BNDO | |
| testes (tests (munit specs)) | cabeçalho, Riscos, §7 do original | |
| troca conservadora (R10) (switching, conservative (R10)) | Decidido, Riscos | portão, histerese, recuo |
| verdade (truth) | Decidido, Riscos | boia, PNBOIA, BNDO |
| WW3 | Decidido | ww3-gpu |
| ww3-gpu | Decidido, Riscos, Em aberto | braço calculado, gatilhos para um repositório novo, WW3 |
| Zenodo | Problema | marola-research, nota de política |