Muito obrigado pelo feedback e pelo tempo dedicado a ler o whitepaper! Seus pontos são cirúrgicos e tocam exatamente nos desafios de engenharia que estou resolvendo agora no HOSA.

Para não deixar suas dúvidas no ar, vou detalhar a mecânica:

1. O Vetor de Estado e a Baseline
   A baseline não é um limiar estático, ela é "viva". O vetor de estado no instante t, digamos x_t, é composto por métricas coletadas via eBPF em alta frequência (ex: run queue length da CPU, page faults por milissegundo, latência de block I/O).A baseline é representada pelo vetor de médias e pela matriz de covariância epsilon. O segredo é que uso uma versão online do Algoritmo de Welford para atualizar o vetor e o epsilon a cada ciclo, sem precisar reter o histórico inteiro na memória. A anomalia é detectada quando a Distância de Mahalanobis ultrapassa um limite de desvios-padrão dessa baseline dinâmica. O nó "aprende" o próprio ritmo (habituação).

2. O Salto de Global para Local (A grande charada)
   Você tocou no ponto mais crítico. Como atuar em um cgroup se a anomalia D_M(x) foi detectada olhando o nó todo?

A arquitetura resolve isso em duas etapas:

• Detecção (Global): O modelo multivariável grita "o sistema como um todo entrou em colapso".
• Isolamento (Local): No exato milissegundo em que o alarme global soa, o agente consulta os mapas eBPF que mantêm contadores paralelos por cgroup/PID. Ele procura qual componente local gerou a maior variação na dimensão que causou o pico na matriz de covariância. É como se o reflexo medular soubesse exatamente qual músculo tensionar com base no nervo que enviou a dor.

3. A Falta do DTrace no Whitepaper
   Minha culpa total. Você tem absoluta razão. O DTrace no Solaris foi o pai da observabilidade dinâmica e a inspiração primária do Brendan Gregg antes de ele migrar esses conceitos para o eBPF no Linux. Vou adicionar um parágrafo de reverência histórica ao DTrace no Related Work na versão 2.2 do whitepaper. Obrigado por apontar isso!

4. Especialização do Kernel em Tempo de Execução
   Isso é brilhante e é o "Nível 6" dos sonhos do projeto. Usar o estado observado não apenas para conter processos (cgroups v2/signals), mas para tunar parâmetros do Kernel dinamicamente (sysctl, tcp windows, swappiness) de acordo com a carga.

Agradeço muito pelas palavras sobre o potencial de "Deep Tech" e sobre o fomento via FAPESP/Unicamp. É fácil a gente se fechar no interior de SP e achar que o projeto não tem escala global. Comentários como o seu me dão a energia necessária para transformar essa pesquisa em uma infraestrutura real e comercialmente viável.

Se quiser acompanhar as próximas PRs ou dar pitacos no código (principalmente na ponte eBPF/Go), será uma honra ter você lá no GitHub!