Copiloto de alocação de aeronaves em posições de pátio, operado do lado da companhia aérea. A cada janela de planejamento, o motor propõe a malha inteira do aeroporto, com a justificativa de cada posição, e o planejador ajusta, publica e deixa rastro do que mudou.
É este o trabalho: encaixar cada voo numa posição que respeite envergadura, contato, tempo de solo e as duas regras mandatórias, e, quando dois voos querem a mesma posição, escolher qual sai e dizer por quê.
Esquema ilustrativo do comportamento do motor, não a malha real de uma operação.
arraste o diagrama para o lado para ver o pátio inteiro
O Gantt é onde o planejador confere o que o mapa não mostra: quanto tempo cada posição fica presa, e onde sobra folga para o atraso que sempre chega.
O planejamento de estacionamento roda hoje costurado entre o sistema de planejamento, Excel, Teams, e-mail e rádio. As premissas existem por escrito, mas sem peso e sem regra de desempate, então a decisão muda de turno para turno e de pessoa para pessoa.
Alocar aeronave em pátio parece um quebra-cabeça de encaixe. Não é: é um problema de ordenação sob restrição, em que quase toda escolha boa para um critério é ruim para outro, e a janela seguinte herda o erro.
Posição em ponte e posição remota não se substituem. Cada uma tem categoria máxima de aeronave, pátio, gate associado, estadia permitida e vocação. Uma aeronave de fuselagem larga ocupa o espaço de duas estreitas.
A janela encenada no protótipo tem 44 voos disputando as 53 posições. Entre a saída de um e a chegada do próximo há um intervalo mínimo a respeitar, e posições vizinhas não podem liberar aeronave ao mesmo tempo.
Trocar uma posição raramente é uma troca só: puxa a seguinte, que puxa a próxima. O protótipo trata isso como cascata e a limita, uma sugestão que provoca remanejo demais deixa de ser sugestão.
Conexão de passageiro pede o mesmo pier. Carga pede posição específica. Passageiro com mobilidade reduzida pede ponte. Pernoite pede pátio de estacionamento. Todas legítimas, e sem regra de desempate escrita.
No aeroporto, quem confirma a alocação é a administradora. A companhia propõe, recebe a devolutiva e reage, o que transforma a qualidade do argumento em parte do resultado.
As alternativas consideradas, o motivo da troca e quem decidiu se perdem entre a conversa de rádio e o e-mail. Sem esse rastro não há como medir aderência nem defender uma posição na reunião seguinte.
Importa os dados sozinho, aplica as regras mandatórias e a fila priorizada, e devolve a proposta da janela pronta para revisão.
É preciso convencer um time que aloca por experiência há anos: cada sugestão expõe o porquê, as alternativas e o que se ganha, em no máximo um clique.
Proposta, aceite, override e motivo ficam registrados. É esse histórico que sustenta o planejado × executado e o argumento com a administradora.
O protótipo abre direto, sem login, e é dele que os cards abaixo saem. A aplicação real roda ao lado, com banco próprio, login, permissão por papel e auditoria campo a campo.
Cadastro do aeroporto com as posições do pátio, importação da malha, motor de alocação com regras versionadas, plano da janela, mapa do pátio, registro do turno e a trilha de auditoria.
O primeiro administrador nasce de uma migração, e o sistema obriga a trocar a senha no primeiro acesso, a inicial não é aceita de novo depois disso. As credenciais ficam com quem opera; não são publicadas aqui.
Ele é a maquete: mostra as telas cheias, com dados de exemplo, sem login e sem depender de importar nada. Para demonstrar, é o caminho curto, o produto exige entrar e ter dado carregado.
Cada card é uma tela do protótipo, com a pergunta que ela responde.
| Grupo | Tela | Pergunta que responde | Peça principal |
|---|---|---|---|
| planejamento | Mapa do pátio | Como isso se parece no chão, e por que esta posição? | Planta do aeroporto com o Gantt embaixo; o painel do voo traz o ranking das opções e a justificativa. Absorveu as telas de Gantt e de detalhe do voo. |
| planejamento | Plano da janela | Em que pé está a janela e o que exige atenção agora? | Bancada de conferência da proposta, com nota por premissa, aceite e override com motivo. |
| planejamento | Registro do turno | O que mudou no mundo real que o plano precisa saber? | Entradas manuais com vigência e autor: restrição, bloqueio, manutenção, evento, ônibus. |
| planejamento | Devolutiva da administradora | Quanto da nossa proposta foi aceito? | Comparação proposta × devolutiva por voo e percentual atendido. |
| configuração | Regras de alocação | Com que critério o plano é montado? | Regras mandatórias, fila de prioridades reordenável e árvore de decisão. |
| configuração | Cadastro do aeroporto | O que cada posição aceita? | Tabela de posições com tipo, pátio, categoria máxima, gate, estadia, vocação e origem documental. |
| configuração | Importação de dados | De onde vêm os voos e as posições? | Recebimento de planilha com detecção de tipo, validação e histórico de arquivos. |
| medição | Planejado × executado | O plano se sustentou? | Aderência ao longo dos dias e para onde as divergências foram. |
| medição | Trilha de decisão | Quem mudou o quê, quando e por quê? | Versões do plano com diferença entre elas e overrides por regra. |
| administração | Usuários | Quem pode operar o sistema? | Criação com senha inicial e troca obrigatória, papéis e status. |
| administração | Papéis | Quem pode ver e fazer o quê? | Permissão por papel, aplicada por endpoint e por rota da tela. |
| administração | Alterações | O que mudou no cadastro, e quem mudou? | Log campo a campo com antes e depois, agrupado por operação. |
Além das 11, há três peças transversais presentes em qualquer tela: o seletor global de janela (executada, publicada, rascunho), o painel lateral do copiloto e a animação do motor ao gerar um plano.
A tela bonita é o começo. O que sustenta o produto é o que acontece quando o analista discorda, quando a manutenção derruba metade da malha e quando alguém pergunta, três dias depois, por que aquele voo foi para lá.
O planejamento é feito por bloco de horas. O motor recebe a malha da janela e devolve a alocação completa, com recálculo sob demanda quando algo muda.
Clicar num voo abre o ranking das quatro melhores posições no horário, a nota de cada uma em cada premissa e uma justificativa escrita em português.
Grade de posição por tempo, agrupada por pier, com o bloco de cada operação colorido por tipo: turn rápido, pernoite, internacional, aeronave em espera e conflito.
Planta esquemática do aeroporto, pista, taxiways, piers e zonas, com as aeronaves posicionadas no instante escolhido.
As regras mandatórias eliminam posições; a fila de prioridades ordena as que sobraram. A ordem da fila é arrastável e cada regra tem seus próprios cortes e buffers.
As posições vivem numa tabela com tipo, pátio, categoria máxima de aeronave, gate associado, estadia permitida, vocação e, a coluna que mais importa, a origem documental de cada restrição.
Manutenção, bloqueio administrativo, evento, aeronave em espera e demanda de ônibus entram como registro de primeira classe, com vigência, autor e efeito imediato sobre o plano.
Aderência do planejado ao executado ao longo dos dias, o destino das divergências e quais regras mais provocam override, a calibração que diz se a fila está bem ordenada.
A escolha técnica central foi feita cedo, por exigência do domínio: determinístico, não aprendizado de máquina. A mesma entrada produz sempre a mesma saída, e cada saída pode ser rastreada até a regra que a produziu. Um plano que não se explica não é aceito por quem aloca há anos.
Para um único voo, o XX3390, B738, chegada 08:15, solo de 1h30. Cada regra descarta um grupo inteiro; o que sobra é ordenado pela fila de prioridades. Contagens ilustrativas do comportamento, não a malha real de uma operação.
Malha de chegadas e partidas, cadastro de posições, restrições vigentes e entradas do turno. No protótipo isso chega por planilha, com o tipo detectado pelo cabeçalho e validação antes de gravar.
encenado no protótipoAntes de pontuar, o motor elimina. Categoria da aeronave é pré-condição; restrição de posição inutiliza o box no período; evento com vigência trava a posição e fura a fila. O que sobra é o conjunto de pares voo × posição viáveis.
regras cadastradas, motor pendenteEntre as posições viáveis, a fila ordinal decide. Cada premissa entra na ordem cadastrada, com seus próprios cortes; premissa sem fonte de dado confirmada fica desligada em vez de chutar.
fila parametrizável no protótipoO motor monta a alocação da janela inteira e marca o que não fechou: intervalo insuficiente entre operações, adjacência apertada, mobilidade em posição remota. Conflito aparece como alerta, não como silêncio.
alertas encenadosA justificativa é gerada a partir das regras que decidiram, e é aqui, e só aqui, que um modelo de linguagem entraria no produto final: para redigir a explicação, nunca para escolher a posição.
textos escritos à mão no protótipoO analista aceita, ajusta ou rejeita. Todo ajuste vira override com motivo. Publicar congela uma versão do plano e gera a casadinha no formato do relatório que a administradora já recebe hoje.
navegável no protótipoVersões, diferenças entre elas, autor e motivo de cada override. Depois do dia, o executado volta e alimenta a aderência, que realimenta a calibração da fila.
navegável no protótipoNenhum motor cria regra sobre dado que ainda não foi ingerido. Por isso a lista de fontes é curta e cada regra aponta para a sua, quando a fonte não existe, a regra fica desligada e isso aparece na tela.
| Dado | Origem | Como chega no protótipo | Alimenta |
|---|---|---|---|
| Malha de chegadas e partidas | Relatório operacional da companhia | Planilha importada, validada antes de gravar | Toda a alocação da janela |
| Cadastro de posições | Documentos do aeroporto e da administradora | Tabela editável com origem documental por linha | Elegibilidade e categoria máxima |
| Restrições e bloqueios | Administradora e manutenção | Registro do turno, com vigência | Regras mandatórias |
| Conexão, bagagem, mobilidade e carga | Sistemas internos da companhia | Parâmetros da fila de prioridades | Ordenação entre posições viáveis |
| Devolutiva da administradora | E-mail, hoje redigitado à mão | Conferência em lote com diferença por voo | Percentual atendido e argumento |
| Executado do dia | Registro pós-operação | Comparador de planejado × executado | Aderência e calibração da fila |
É quem opera a tela. Gera a janela, revisa o que o motor propôs, discorda quando precisa e publica. O ganho dele é tempo e a chance de argumentar com dado em vez de memória.
Chega e precisa saber o que mudou desde a última passagem. A trilha com diferença entre versões substitui a conversa de corredor e o e-mail perdido.
Registra bloqueio e posição travada com vigência, em vez de combinar por rádio. O efeito no plano aparece na hora, para todo mundo.
Enxerga aderência, percentual atendido pela administradora e onde as divergências se concentram. É a base do plano de ação, e não uma impressão.
Cuida da ingestão, do cadastro e da parametrização. O contrato é claro: regra vira cadastro, fonte de dado vira coluna, nada de aeroporto escrito em código.
Quem conversa com o aeroporto passa a levar uma proposta justificada, a comparação do que foi aceito e o histórico, três coisas que hoje não existem em formato apresentável.
O produto só serve se o que sai dele couber no processo que já existe. Por isso o formato de saída é o do relatório atual, não um formato novo que obrigaria todo mundo a mudar.
Agora são duas coisas no ar, com riscos diferentes: o produto, que guarda dado e tem sessão, e o protótipo, que não guarda nada. Vale a mesma disciplina para os dois, em alguns pontos, mais.
A lista abaixo não é uma lista de defeitos. É o contorno honesto do que cada peça faz hoje: a maquete à esquerda, que existe para validar decisão de produto, e o software à direita, que já roda mas ainda não opera aeroporto sozinho.
Não. O que está no ar é um protótipo navegável de alta fidelidade: as telas reagem, dá para abrir o porquê de um voo, mover um bloco e trocar a janela, mas não há motor, banco nem integração por trás. Ele existe para alinhar o desenho do produto antes de construí-lo.
No protótipo, nenhum. E no produto planejado a IA tem um papel deliberadamente pequeno: a decisão é de uma árvore de decisão determinística, e um modelo de linguagem entraria apenas para redigir a explicação em português.
A exigência é do domínio: quem aloca precisa poder discordar de uma regra nomeada, não de uma probabilidade.
Três motivos práticos. Auditabilidade: a mesma entrada tem que dar a mesma saída, sempre. Explicabilidade: a justificativa precisa nomear a regra, não citar uma correlação. E governança: mudar o comportamento do sistema tem que ser uma edição de cadastro registrada, não um retreinamento.
O cenário encenado parte de material operacional anonimizado, feito para a demonstração. Por isso esta página não reproduz prefixos, números de voo reais nem nomes, e por isso o restante do material não é publicado junto com o protótipo.
Sobra quase tudo que dá para melhorar. A companhia controla a qualidade da proposta, o tempo para chegar nela, a consistência entre turnos e a capacidade de argumentar com histórico.
Por isso a alocação final aceita pela administradora não é usada como critério isolado de sucesso: seria medir o produto por uma variável que ele não controla.
Essa é a razão de existir a tela de cadastro do aeroporto: posições, categorias, gates e restrições são dado, com origem documental declarada, e não regra escrita no código. Replicar para outras bases é evolução prevista, depois de o primeiro aeroporto estar de pé.
Ele muda. O ajuste vira um override registrado, com motivo, autor, versão e a diferença em relação ao plano anterior. Override não é tratado como erro do humano nem como erro da máquina: é sinal de calibração, e as regras que mais provocam override aparecem na tela de medição.
Por quatro números que hoje ninguém tem juntos: tempo para produzir o plano da janela, aderência do planejado ao executado, percentual da proposta atendido pela administradora e volume de trocas herdadas na virada de turno.
Não para começar. A porta de entrada prevista é arquivo, a mesma planilha que já circula hoje -, com detecção do tipo pelo cabeçalho e validação antes de gravar. Integração direta é ganho de fluidez, não pré-requisito.
Um arquivo HTML estático de cerca de 107 KB, com todo o CSS e o JavaScript embutidos, servido por nginx a partir de uma pasta montada em modo somente leitura. Sem build, sem dependência, sem chamada de rede. É por isso que ele abre rápido e continua igual amanhã.
O protótipo fala a língua de quem opera, não a língua genérica de manual. Os termos abaixo são os que aparecem nas telas.