Mapa de arquitetura modular do Endoflow para alinhamento técnico do time de desenvolvimento. Mostra como o pré-screening, o M0 validado (Chapron 2022 · C-index 0.81) e os módulos clínicos complementares se compõem em camadas hierárquicas que se adaptam por instância — NR-1, SUS, Autogestão — e geram acompanhamento longitudinal via Δt de re-aplicação.
Cada anel é um nível de compromisso clínico. O pré-screening é o portal — ele define se a paciente deve seguir adiante e como. O M0 é a âncora científica imutável que carrega a validação. Os módulos complementares (M1–M8) são camadas configuráveis por produto. Os longitudinais (M9–M10) são ativados em janelas Δt para sustentar o acompanhamento prospectivo.
Cada módulo é um contrato clínico independente. Tem ID estável, peso de pontuação fixo e um agente Sof.IA correspondente. Devs podem ligar/desligar módulos por instância sem tocar no núcleo. A âncora científica (M0) e os módulos com override regulatório (M6, M7) são não-removíveis.
O score do M0 (0–100) atravessa quatro faixas de risco. Cada faixa dispara um conjunto diferente de ações, módulos adicionais e SLAs. Os módulos complementares modulam o relatório R1 sem alterar o score primário — preservando a citação científica.
O núcleo (Pré-Screening + M0) é idêntico nas três instâncias. O que muda é o contexto injetado, o canal de entrada, a estrutura de monetização e a composição modular default. Devs configuram instância por arquivo de feature flags, não por fork de código.
A partir do baseline (T₀), o sistema reaplica módulos em janelas Δt definidas no contrato, gerando relatórios subsequentes (R3, R4, R5...) que comparam estado atual com o screening anterior. É assim que transformamos triagem pontual em vigilância clínica longitudinal e produzimos KPIs prospectivos para o gestor — o que diferencia um produto de saúde digital sério de um questionário online.
A modularidade só funciona porque há um sistema agêntico que costura módulos, score e contexto territorial, e porque cada interação produz um artefato (.md auditável + PDF portátil). Devs trabalham em interfaces contra a Sof.IA — não diretamente contra a paciente.
Cada módulo respondido alimenta um ou mais agentes que mantêm o contexto longitudinal da paciente.
Cada relatório é PDF portátil + .md auditável. PII anonimizada via PIIGuard antes de qualquer agregação.
Quatro princípios técnicos não-negociáveis para preservar a modularidade. Tudo o mais é detalhe de implementação.
Cada módulo é definido em arquivo declarativo module.yaml com schema fixo: ID,
itens, pesos, branching rules, output relatorial, agente Sof.IA associado. Nunca codificar
módulo no core do app — apenas o motor que interpreta os yamls.
endoflow_nr1, endoflow_sus e endoflow_aut são
arquivos de configuração, não branches de código. Definem quais módulos estão
ativos, opcionais ou desabilitados,
qual é o canal de entrada e quais textos são renderizados.
A dimensão longitudinal é um job orquestrador que percorre a base de pacientes,
checa last_screening_at contra a janela Δt configurada na instância,
e dispara a re-aplicação modular via Sof.IA. Cada janela gera um
relatório novo (R3, R4...) com diff em relação ao screening anterior.
Implicação: schema do banco precisa ter screening_round indexado
por paciente, com timestamp imutável e snapshot do score. Multi-tenant
via schemas separados por instância.
Qualquer alteração no M0 (itens, pesos, branching) invalida a
citação Chapron 2022 e exige revalidação independente — custo regulatório
incompatível com o cronograma. Os módulos M1–M10 podem evoluir por sprint;
o M0 é versionado em major apenas com aprovação do Medical Board.
Implicação técnica: o motor de scoring do M0 deve viver em pacote isolado
(endoflow_core/m0_engine), com testes congelados e contrato de API
estável. Mudanças nele são PR especiais com code freeze obrigatório.