Zelo

O Zelo é um sistema operacional da qualidade alimentar: uma plataforma onde o consultor configura os padrões, a equipe do estabelecimento opera o dia a dia, e uma IA que entende a legislação brasileira mantém os dois em conformidade contínua — do plano de boas práticas à fiscalização. Este documento define o que vamos construir na primeira versão, para quem, por quê, em que ordem, e como saberemos que deu certo.

1. Visão do produto

A maioria das ferramentas do mercado resolve um pedaço: ou é checklist, ou é rotulagem, ou é consultoria. O Zelo une essas frentes em torno de um único princípio — conformidade não é um evento, é um estado contínuo — e coloca o consultor no centro como quem leva o sistema para dezenas de estabelecimentos.

Em uma frase: o Zelo transforma a qualidade alimentar de um esforço pontual e manual em um processo contínuo, monitorado e à prova de fiscalização — operado pela equipe do estabelecimento e orquestrado pelo consultor.

A promessa que a marca carrega resume a experiência pretendida: "No verde, todo dia." — você sempre sabe onde está e o que falta para ficar em conformidade.

2. Estado atual — o que já saiu do papel

Diferente das versões anteriores, o Zelo já é um artefato que se navega. O que existe hoje, publicado e em validação:

Protótipo navegável e clicável (estética "vidro sobre verde", PWA), com seis telas funcionais que realizam o fluxo central:

1. Painel — em modo consultor, um radar de risco da carteira inteira (cada cliente com índice e status, ordenado por quem precisa de atenção); em modo estabelecimento, um medidor do próprio índice de conformidade com tarefas do dia e temperaturas.
2. Gerador de planos por IA — fluxo guiado (dados do estabelecimento → geração → plano de ação), demonstrando o diferencial de montar documentos a partir da norma.
3. Inspeção / checklist — aplicação com itens conformes/não conformes e score parcial ao vivo.
4. Ficha & rótulo editável — recálculo ao vivo de custo, CMV e preço sugerido, com rótulo nutricional no padrão ANVISA e selos de advertência frontal (RDC 429) que aparecem/somem conforme os limites.
5. Documentos — carteira de documentos com selo de validade por item (válido / vence em X dias / vencido), filtrada por estabelecimento.
6. Indicadores — evolução da carteira vs. média, com mapa de não-conformidades.

(Há ainda a página por cliente, com índice, conformidade por categoria, documentos e focos de atenção.)

Portal de validação para a consultoria (zelo.portalgsemp.com.br): convite, resumo do estudo de mercado, checklist de validação, um canal de devolutiva em tempo real e um tour guiado em modal que percorre as telas e levanta, em cada passo, "o que avaliar aqui".

Manual da marca (Brandbook v1.0) e o design system "vidro sobre verde", também publicados como PWA — a fonte canônica da identidade e da UI (detalhe na seção 10).

Infraestrutura no ar: PWA instalável com casca offline (service worker), backend Supabase (região São Paulo) e deploy contínuo via Cloudflare Pages a partir do repositório no GitHub. Na prática, isso já prova que o caminho PWA/offline/Supabase é viável — o que reduz risco técnico antes mesmo do build do produto.

Status: em validação técnica com a consultoria (Qualimab / Mariana Amabile). As devolutivas entram pelo canal do portal e viram requisito aqui.

3. O problema

3.1 O mercado hoje

O setor está fragmentado em quatro frentes que não conversam entre si: apps de consultoria (Food Checker, ProApp), plataformas de checklist para redes (SULTS, Checklist Fácil), softwares de rotulagem e ficha técnica (Nutrimenu), e plataformas internacionais de food safety (FoodDocs). Nenhuma junta as quatro — e o consultor brasileiro acaba operando com planilha, PDF e WhatsApp.

3.2 As quatro dores centrais

• Offline real. A inspeção acontece na cozinha, na câmara fria, no estoque — onde quase nunca há Wi-Fi. Ferramentas que dependem de conexão travam no momento de uso.
• IA que entende a legislação local. Montar Manual de BPF, plano APPCC e POPs adaptados à RDC 216 e às normas municipais é trabalhoso e manual. As soluções com IA de ponta não falam português nem conhecem a norma brasileira.
• A ponte consultor ↔ estabelecimento. Hoje o monitoramento diário depende do consultor estar presente. Falta uma camada em que a equipe do cliente opere o dia a dia e o consultor veja tudo à distância, no mesmo dado.
• Inteligência de dados. Ninguém transforma as inspeções em score de risco, tendência e priorização. O dado morre no papel.

3.3 Por que ainda não foi resolvido

O ProApp acertou no offline e no custo, mas não tem IA nem analytics. O FoodDocs tem a IA do futuro, mas não atende o Brasil. As plataformas de checklist são genéricas e ignoram a figura do consultor. O espaço da interseção está aberto.

4. Público-alvo

4.1 Persona A — O Consultor (usuário-âncora)

Profissional de qualidade/segurança de alimentos (nutricionista, eng. de alimentos, RT) que atende uma carteira de estabelecimentos. Dores: trabalho manual e repetitivo, dificuldade de escalar a carteira, pouca diferenciação, monitoramento dependente de presença física. O que precisa resolver (jobs-to-be-done): padronizar e acelerar a geração de documentos, acompanhar vários clientes à distância, provar valor com dados, fortalecer a própria marca/autoridade.

4.2 Persona B — O Estabelecimento e a equipe operacional

Restaurante, padaria, lanchonete, cozinha industrial e sua equipe (gerente, encarregado, manipuladores). Dores: medo de fiscalização, falta de método no dia a dia, rotatividade de equipe, documentos vencendo sem aviso. Jobs-to-be-done: cumprir a rotina de boas práticas sem complicação, ter tranquilidade na fiscalização, registrar o que foi feito.

4.3 Persona C — O Gestor/proprietário

Quem assina o cheque e responde pelo risco. Jobs-to-be-done: enxergar o nível de conformidade e o risco de cada unidade, justificar o investimento, dormir tranquilo.

5. Objetivos e métricas de sucesso

5.1 North Star Metric

Estabelecimentos com conformidade ativamente monitorada por mês — a métrica que captura valor real entregue (não só cadastro, mas uso recorrente).

5.2 KPIs por dimensão

5.3 Metas iniciais (hipóteses a validar)

Números de partida — hipóteses, não metas fechadas. Servem para dar direção e serão calibrados pela validação e pelo uso real:

6. Proposta de valor e diferenciais

Quatro diferenciais que, juntos, nenhum concorrente nacional tem: (1) IA localizada na legislação brasileira, (2) offline-first de verdade, (3) a ponte consultor↔estabelecimento, (4) score de risco e analytics. O fosso defensável é a base legal estruturada (RDC 216, RDC 429, IN 75 e normas municipais) que alimenta a IA — é o que segura o concorrente internacional na fronteira e o que mais demora para copiar.

7. Escopo

7.1 Dentro do MVP (v1) — priorizado

1. Gerador de planos por IA (BPF, APPCC, POPs) — o diferencial que mais economiza tempo do consultor. (demonstrado no protótipo)
2. Inspeção/checklist offline com scoring e plano de ação — o coração do uso diário. (demonstrado no protótipo)
3. Ponte consultor↔estabelecimento (multiusuário com papéis) — sem isso, não há modelo de receita dupla. (modos consultor/estabelecimento no protótipo)
4. Painel de risco e indicadores (versão essencial) — o que prova valor. (demonstrado no protótipo)
5. Controle de documentos com alerta de vencimento. (demonstrado no protótipo)
6. Controle de validades de insumos/estoque (origem: validação Mariana — marcado como essencial).

7.2 Fora de escopo por enquanto (v2+)

Fichas técnicas e rotulagem RDC 429 completas (entra como módulo dedicado depois — embora a prova de conceito já apareça no protótipo, na tela de ficha & rótulo); marketplace/white-label; integrações com PDV/ERP; app de cliente final; relatórios avançados de BI. Motivo: focar a v1 nos diferenciais e no fluxo que gera recorrência, sem inflar o escopo.

7.3 Princípios de priorização

Offline e IA primeiro (são os diferenciais). Nada entra na v1 se não servir ao fluxo consultor→equipe→dado. Profundidade vem por iteração, guiada pela validação.

8. Requisitos funcionais

Notação: RF = requisito funcional. Cada bloco traz objetivo e critérios de aceite (o que precisa ser verdade para considerarmos pronto). A nota "No protótipo" aponta a tela que já demonstra a ideia — útil para alinhar visual e interação antes do build.

8.1 Gerador de planos por IA

Objetivo: gerar Manual de BPF, plano APPCC e POPs adaptados ao tipo de estabelecimento e à legislação aplicável — não por "achismo do modelo", mas a partir de uma base legal estruturada. No protótipo: tela Gerador IA (fluxo guiado → plano de ação).

Como a base legal vira dado consultável (o coração do diferencial): A legislação não fica "solta" na cabeça do modelo. Cada norma é decomposta em requisitos e armazenada numa base estruturada, em que cada requisito carrega metadados: esfera (federal/estadual/municipal), tipo de estabelecimento a que se aplica, tema (edificação, manipulação, higiene, controle de temperatura, documentação, etc.) e a referência exata (norma, artigo/item). Ao gerar um plano, a IA recupera os requisitos aplicáveis àquele estabelecimento e município e monta o documento citando a fonte — e o consultor revisa. Assim, o conteúdo é rastreável, atualizável e defensável.

• RF-1.1 Coletar dados do estabelecimento (tipo, porte, processos, município) por formulário guiado.
• RF-1.2 Manter uma base legal estruturada e versionada (requisitos com metadados e referência normativa).
• RF-1.3 Sobreposição municipal: aplicar a base federal (RDC 216) e sobrepor a norma do município, que prevalece/complementa quando existir.
• RF-1.4 Gerar o documento recuperando os requisitos aplicáveis e citando a fonte normativa de cada exigência.
• RF-1.5 Permitir edição do consultor antes de finalizar (a IA propõe, o consultor decide).
• RF-1.6 Sinalizar quando a base legal mudar e permitir regerar/atualizar documentos afetados.
• RF-1.7 Exportar em PDF com a identidade do consultor.
• Critérios de aceite: um plano é gerado em < 5 min; cada exigência traz a referência normativa; ao trocar o município, o conteúdo muda conforme a norma local; o consultor consegue editar qualquer trecho; quando uma norma é atualizada, o sistema avisa quais documentos podem estar desatualizados.

8.2 Inspeção / Checklist offline

Objetivo: aplicar inspeções sem internet, com pontuação e plano de ação automático — é o coração do uso diário e o requisito de engenharia mais sensível. No protótipo: tela Inspeção (itens conformes/não conformes + score parcial ao vivo).

• RF-2.1 Funcionar 100% offline: abrir, preencher e concluir uma inspeção sem nenhuma conexão.
• RF-2.2 Salvar automaticamente (auto-save local) a cada resposta, sem o usuário precisar "salvar".
• RF-2.3 Checklist configurável por categoria, com itens classificados por criticidade (crítico / necessário / recomendável) e ponderados — o score reflete o peso de cada item.
• RF-2.4 Cálculo de score ao vivo conforme o preenchimento avança.
• RF-2.5 Para cada item, registrar conformidade (conforme / não conforme / não aplicável) e anexar foto como evidência, com data/hora.
• RF-2.6 Gerar plano de ação automático a partir das não conformidades (o quê, prazo sugerido, responsável).
• RF-2.7 Modelos de checklist reutilizáveis: o consultor cria/edita um modelo e aplica em vários estabelecimentos.
• RF-2.8 Campo de assinatura do responsável técnico/responsável pela inspeção (origem: validação Mariana).
• RF-2.9 Permitir reabrir uma inspeção concluída para correção (mantendo histórico da alteração).

Sincronização (quando volta a conexão):

• RF-2.10 Inspeções feitas offline entram numa fila local e sincronizam automaticamente ao reconectar.
• RF-2.11 Indicador visível de status de sincronização (pendente / enviado) por inspeção.
• RF-2.12 Conflitos resolvidos de forma previsível (a versão mais recente prevalece) e registrados em log — nunca apagar dado silenciosamente.

Estados de uma inspeção: rascunho → em andamento → concluída → sincronizada → (reaberta →) arquivada.

Critérios de aceite: uma inspeção completa é aplicável em modo avião e sincroniza sem perda ao reconectar; o score aparece em tempo real e reflete a criticidade dos itens; cada não conformidade gera item no plano de ação; a assinatura e as fotos ficam no relatório; o status de sincronização é sempre visível.

8.3 Painel de risco e indicadores

Objetivo: transformar inspeções em decisão — o que prova valor para o consultor. No protótipo: telas Painel (radar de risco da carteira) e Indicadores (evolução vs. média + mapa de não-conformes).

• RF-3.1 Score de conformidade por estabelecimento e da carteira inteira.
• RF-3.2 Mapa de calor por categoria e ranking de estabelecimentos por risco.
• RF-3.3 Não conformidades mais frequentes e tendência no tempo.
• RF-3.4 Filtros (por estabelecimento, período, categoria) e drill-down do score até a inspeção que o originou.
• RF-3.5 Alertas consolidados (documentos/insumos vencendo, unidades sem sincronização recente).
• RF-3.6 Indicador de última sincronização por estabelecimento (transparência do dado).
• Critérios de aceite: o consultor identifica em < 30s quais clientes precisam de atenção; clicar num score leva à inspeção de origem; o painel deixa claro quando um dado está desatualizado.

8.4 Controle de documentos

Objetivo: nunca deixar um documento vencer sem aviso. No protótipo: tela Documentos (selo de validade por documento, filtrado por estabelecimento).

• RF-4.1 Cadastro de documentos com data de validade (alvará, AVCB, laudos de água, atestados de saúde).
• RF-4.2 Alerta de vencimento com antecedência configurável.
• Critérios de aceite: o sistema avisa antes do vencimento; o status fica visível no painel.

8.5 Controle de validades de insumos/estoque (origem: validação Mariana)

Objetivo: acompanhar a validade dos produtos em uso/estoque.

• RF-5.1 Cadastro de insumos com data de validade e lote.
• RF-5.2 Alerta de itens próximos do vencimento.
• Critérios de aceite: a equipe vê o que está perto de vencer; o consultor enxerga isso como item de risco. Profundidade exata a refinar com a consultoria (item da seção 15).

8.6 Ponte consultor ↔ estabelecimento

Objetivo: equipe opera, consultor supervisiona, no mesmo dado. No protótipo: alternância modo consultor / modo estabelecimento (mesma base, visões distintas).

• RF-6.1 Multiusuário com papéis e permissões (consultor, gestor, operador).
• RF-6.2 A equipe do estabelecimento registra rotinas/inspeções; o consultor vê em tempo real.
• RF-6.3 O consultor gerencia sua carteira de estabelecimentos a partir de um único acesso.
• Critérios de aceite: um operador só vê o que lhe cabe; o consultor vê todos os seus clientes; os dados são os mesmos para ambos.

Matriz de permissões (papéis × capacidades):

8.7 Relatórios e fiscalização

Objetivo: no momento da fiscalização (ou de uma auditoria interna), provar conformidade na hora — com histórico, não com promessas. No protótipo: página do cliente consolida índice, categorias, documentos e focos de atenção — a base visual do relatório.

• RF-7.1 Gerar, sob demanda, um relatório consolidado de um estabelecimento contendo: identificação da unidade; histórico de inspeções com scores e datas; não conformidades e seus planos de ação (com status); situação de documentos e validades; e assinaturas registradas.
• RF-7.2 Exportar em PDF pronto para apresentar/imprimir.
• RF-7.3 Filtrar o relatório por período.
• RF-7.4 Relatório consolidado da carteira para o consultor (visão gerencial).
• Critérios de aceite: o relatório é gerado em segundos; reflete fielmente o histórico registrado; inclui as assinaturas; e serve como evidência de conformidade perante a vigilância sanitária. (O conteúdo exato exigido pela fiscalização é um dos pontos a confirmar com a consultoria.)

9. Requisitos não-funcionais

• Offline-first & sincronização confiável, com resolução de conflitos previsível.
• Multiplataforma: PWA instalável e experiência mobile de primeira (o uso é no celular, em campo). O build de validação já é um PWA instalável com casca offline — a base existe.
• Segurança & autenticação: login real por usuário, com papéis. Hoje o portal de validação usa senha simples; para o produto, autenticação real (Supabase Auth ou equivalente) é requisito — substitui o gate atual.
• LGPD & privacidade: dados de estabelecimentos e equipes tratados conforme a LGPD; consentimento e finalidade claros.
• Desempenho: telas críticas (inspeção, painel) respondem em < 1s.
• Auditoria/logs: registro de quem fez o quê e quando (essencial para fiscalização).
• Disponibilidade & backup: dados não se perdem; histórico preservado.
• Acessibilidade: segue o padrão do design system (seção 10) — contraste AA/AAA, corpo ≥ 16px, alvo de toque ≥ 44px, status nunca dependem só de cor.

10. Design System e identidade da marca

A marca tem manual próprio (Brandbook v1.0), publicado e versionado, que é a fonte canônica da UI: toda tela nova nasce dele. Os pilares:

• Marca e símbolo. O logotipo é "zelo." em minúsculas (Onest Extrabold). O ponto não é pontuação — é o ponto de conformidade, sempre na cor verde de conformidade (#159C68), nunca recolorido nem removido. Tagline: "No verde, todo dia."
• Cor com função. Verde significa "em conformidade" — cor para informar, não decorar. Status sempre como cor + ícone + rótulo (nunca só cor): Conforme #159C68, Atenção #D98A12 (sempre com texto escuro), Risco #D44A40, Informação #2C6E8E. Proporção de uso 60 neutros / 30 verdes / 10 status.
• Tipografia. Uma só família, Onest (pesos 300–900), com números tabulares em dados e painéis.
• Design system do app — "vidro sobre verde". Camada de vidro fosco (--glass, --blur) sobre fundo verde vivo; cartão branco sólido reservado só para "papéis" (rótulo e documento); curvas de gráfico suaves com pontos circulares.
• Acessibilidade embutida. Contrastes AA/AAA, corpo mínimo 16px, alvo de toque 44px, status independentes de cor.

O protótipo e o portal já aplicam esse sistema; o brandbook completo está publicado (inclusive como PWA) para consulta da equipe e de quem for desenvolver.

11. Modelo de negócio

Receita dupla: assinatura do consultor + um seat por estabelecimento. O consultor vira canal de distribuição — cada cliente que ele leva é uma recorrência nova, e ele pode repassar o seat com margem.

Âncoras de mercado (o que existe hoje): Food Checker ~R$22/mês (web, sem offline/IA); ProApp (offline, foco em custo); FoodDocs ~US$169/mês (IA, sem Brasil); SafetyCulture ~US$24/usuário/mês. O Zelo entrega bem mais que o Food Checker (IA localizada + offline + ponte + dados), o que justifica posicionar acima dele — sem chegar ao preço dos internacionais.

Estrutura de preço proposta (hipótese a validar com disposição a pagar):

Estes números são proposta ancorada no mercado, não preço final. O teste de disposição a pagar dos dois lados — central na validação com a Mariana — é o que fecha as faixas. A lógica: o consultor paga pela alavanca (IA + gestão da carteira); o estabelecimento paga pela tranquilidade na fiscalização.

12. Fluxos principais

Cada fluxo traz pré-condição, passos e o que acontece quando algo foge do caminho feliz.

12.1 Onboarding de um novo cliente (o fluxo que destrava a ativação)

Pré-condição: consultor com conta ativa.

1. Consultor cadastra o estabelecimento (tipo, porte, município).
2. Gera o plano por IA (BPF/APPCC/POPs) e revisa.
3. Convida a equipe do estabelecimento (envio de convite → vira seat).
4. Define o primeiro modelo de checklist para aquela unidade.
5. A equipe instala o app (PWA) e faz a primeira inspeção.

Exceções: equipe não aceita o convite → lembrete automático ao consultor; município sem base legal cadastrada → usa base federal (RDC 216) e sinaliza pendência. Sucesso = ativação: 1º plano gerado e 1ª inspeção concluída.

12.2 Rotina diária da equipe (offline)

Pré-condição: operador com seat, app instalado.

1. Abre o checklist do dia no celular — sem depender de internet.
2. Registra item a item (conforme/não conforme/N.A.), anexa foto onde precisa.
3. Conclui e assina.
4. Ao reconectar, a inspeção sincroniza sozinha.

Exceções: ficou sem bateria/fechou o app → o auto-save preserva o rascunho; sem sinal por horas → fica na fila e envia depois, sem perda.

12.3 Supervisão do consultor

Pré-condição: estabelecimentos com inspeções sincronizadas.

1. Abre o painel da carteira.
2. Vê scores, ranking e alertas; identifica em segundos quem precisa de atenção.
3. Entra no estabelecimento de risco, revisa não conformidades e aciona o plano de ação.

Exceções: dado desatualizado (unidade sem sincronizar) → painel marca "sem sincronização recente".

12.4 Documento/insumo vencendo

1. Sistema detecta proximidade do vencimento (alvará, laudo, atestado, insumo).
2. Dispara alerta (consultor e/ou gestor) com antecedência configurável.
3. Responsável renova e atualiza → status volta ao verde.

Exceções: venceu sem renovação → item entra como risco no painel até regularizar.

12.5 Fiscalização (o momento da verdade)

1. Gera, na hora, um relatório consolidado da unidade: histórico de inspeções, planos de ação, documentos e assinaturas.
2. Exporta em PDF.

Valor: transforma "torcer para estar tudo certo" em "provar que está", com histórico assinado.

13. Direção técnica

PWA + experiência mobile; backend com banco multi-tenant; camada de IA ancorada em uma base legal estruturada (a norma vira dado consultável, não "achismo do modelo"); motor de sincronização offline.

O que a validação já provou na prática: o build atual roda essa direção — PWA instalável com casca offline (service worker), backend Supabase (São Paulo) e deploy contínuo via Cloudflare Pages a partir do GitHub. Isso valida o caminho técnico e reduz risco. A arquitetura final do produto evolui a partir daí: multi-tenant com isolamento por consultor/estabelecimento, motor de sincronização com fila e resolução de conflitos, e autenticação real por papéis (que substitui a senha simples do portal de validação).

Isto é direção, não decisão final de arquitetura — serve para orientar quem for desenvolver.

14. Base regulatória (a confirmar com a consultoria)

Base de partida: RDC 216/2004 (boas práticas para serviços de alimentação), POPs e APPCC; RDC 429/2020 + IN 75/2020 (rotulagem nutricional, para o módulo futuro de rótulos — cuja prova de conceito já aparece no protótipo); e normas municipais da vigilância sanitária, que variam por cidade. A precisão e a atualização dessas referências é exatamente o terreno da Mariana — este é um dos pontos onde a validação dela é insubstituível.

Cobertura inicial: a base municipal começa pelo Sul e Sudeste (capitais e principais municípios de SP, RJ, MG, ES, RS, SC e PR), acompanhando a meta de carteira-piloto. Novos municípios entram por demanda.

15. Plano de validação

A validação não é uma etapa abstrata — ela está acontecendo, com instrumento próprio.

Como acontece. A consultora recebe o protótipo navegável e um tour guiado em modal que percorre as telas; cada passo traz um "o que avaliar aqui". A devolutiva entra pelo canal no portal (zelo.portalgsemp.com.br) e cada ponto levantado vira requisito aqui — como já aconteceu com a assinatura do RT (RF-2.8) e o controle de validades (8.5).

As cinco perguntas centrais (o que precisa fechar):

1. Disposição a pagar dos dois lados — confirma/ajusta as faixas propostas (consultor ~R$149, seat ~R$49).
2. Priorização de municípios dentro do Sul/Sudeste (capitais antes do interior?).
3. Profundidade real necessária do controle de estoque/validades.
4. Quais relatórios a fiscalização efetivamente exige.
5. Fluxo ideal de convite e adoção da equipe operacional.

Critério de saída da validação: ter as faixas de preço confirmadas ou ajustadas, a lista de municípios-piloto definida, e o escopo fino de estoque e de relatórios fechado. Isso encerra a v0.5 e libera o início do build.

16. Riscos e mitigações

17. Roadmap em fases

• Fase 0 — Validação (em curso): protótipo navegável + portal + tour em validação com a consultoria; fechar as cinco perguntas da seção 15.
• Fase 1 — MVP: gerador por IA, inspeção offline, ponte consultor↔estabelecimento, painel essencial, controle de documentos e validades, relatórios de fiscalização. Cobertura legal inicial: Sul e Sudeste.
• Fase 2: fichas técnicas e rotulagem (RDC 429), relatórios avançados, refinamento de IA.
• Fase 3: white-label/marca do consultor, integrações (PDV/ERP), expansão de cobertura legal.

18. Glossário

BPF Boas Práticas de Fabricação · APPCC Análise de Perigos e Pontos Críticos de Controle · POP Procedimento Operacional Padronizado · RDC Resolução da Diretoria Colegiada (ANVISA) · IN Instrução Normativa · CMV Custo da Mercadoria Vendida · Visa Vigilância Sanitária · RT Responsável Técnico · Seat assento/licença paga por estabelecimento · PWA Progressive Web App (app instalável que roda no navegador, com modo offline) · MRR receita recorrente mensal · Churn taxa de cancelamento.

Anexo A — Modelo de dados (conceitual)

Visão de alto nível das entidades e como se relacionam. Não é o desenho final do banco — é o mapa para quem for construir.

Relações principais: um Consultor tem muitos Estabelecimentos; um Estabelecimento tem muitos Membros, Inspeções, Documentos, Insumos e Planos; uma Inspeção usa um Modelo de checklist, tem muitos Itens e gera itens de Plano de ação.

Changelog

• v0.4 — Documento ancorado no que já existe: nova seção Estado atual (protótipo navegável com seis telas, portal de validação, brandbook e infra publicada); nova seção Design System e identidade (o brandbook como fonte canônica da UI); nova seção Plano de validação (instrumento, as cinco perguntas e o critério de saída); requisitos amarrados às telas do protótipo; direção técnica atualizada com o stack já provado (PWA/offline/Supabase/Cloudflare); seções renumeradas para acomodar as novas.
• v0.3 — Gerador por IA detalhado (base legal estruturada e consultável); módulo de relatórios e fiscalização; painel expandido; modelo de negócio com proposta de preço ancorada no mercado (consultor ~R$149, seat ~R$49); meta de carteira-piloto e cobertura legal inicial no Sul/Sudeste.
• v0.2 — Detalhamento: inspeção offline com estados e sincronização; matriz de permissões por papel; métricas com hipóteses numéricas + decisões pendentes; fluxos principais passo a passo (com onboarding e exceções); modelo de dados conceitual.
• v0 — Primeira versão, a partir da auditoria competitiva, do blueprint, do protótipo e da estrutura de validação.

Como este documento evolui

Esta é a versão 0.4 — rascunho em detalhamento. Não precisa estar perfeito: é um documento vivo. Os comentários e pedidos da consultoria entram pelo canal em zelo.portalgsemp.com.br, e cada ponto levantado vira requisito aqui (como já aconteceu com a assinatura do RT e o controle de validades). Fechadas as cinco perguntas da seção 15, sobe a v0.5 e começa o build.