Capítulo 68 — Glossário Expandido

68.1 Objetivo do Capítulo

Este capítulo consolida e expande o glossário técnico e de negócio da Plataforma de Relacionamento Digital com o Cidadão. O objetivo é fornecer definições precisas, unívocas e contextualizadas para todos os termos utilizados ao longo dos 67 capítulos anteriores deste documento.

Um glossário expandido serve três propósitos distintos. Primeiro, eliminação de ambiguidade: termos como "usuário", "serviço", "canal" e "protocolo" têm significados específicos na plataforma que diferem de seus usos cotidianos — a definição formal evita mal-entendidos durante a avaliação técnica. Segundo, rastreabilidade terminológica: avaliadores e auditores da PRODEMGE podem verificar que a terminologia utilizada na proposta é internamente consistente. Terceiro, onboarding operacional: equipes técnicas que ingressarem na operação da plataforma durante a parceria encontram aqui o vocabulário comum necessário para comunicação eficaz.

As definições são organizadas em domínios temáticos e apresentadas em ordem alfabética dentro de cada domínio. Termos que aparecem em múltiplos domínios são definidos no domínio de sua origem e referenciados nos demais.

---

68.2 Contexto e Escopo

O glossário cobre integralmente a terminologia utilizada nas seguintes partes do documento:

• Parte I — Apresentação e Visão Executiva (Capítulos 1–9)
• Parte II — Arquitetura (Capítulos 10–17)
• Parte III — Módulos Funcionais (Capítulos 18–30)
• Parte IV — Tecnologia (Capítulos 31–41)
• Parte V — Segurança e Conformidade (Capítulos 42–47)
• Parte VI — Operação (Capítulos 48–55)
• Parte VII — Gestão (Capítulos 56–62)
• Parte VIII — Qualificação PRODEMGE (Capítulos 63–67)

Termos originados diretamente dos Anexos do Chamamento Público nº 001/2026 (Anexos I, II, III, IV, V, VI e VII) são identificados com a referência ao anexo correspondente.

---

68.3 Convenções de Notação

As entradas do glossário seguem o formato:

Termo — Definição. [Referência ao capítulo onde o termo é aprofundado, quando aplicável.]

Termos em negrito dentro das definições indicam que o termo referenciado tem entrada própria neste glossário. Siglas são definidas por extenso na primeira ocorrência de cada seção e utilizadas de forma abreviada nas demais.

---

68.4 Domínio: Plataforma e Arquitetura Geral

Acoplamento — Grau de dependência entre dois componentes de software. Acoplamento baixo é uma propriedade arquitetural desejável: permite que cada componente evolua e seja substituído independentemente. A comunicação assíncrona por eventos (RabbitMQ) reduz acoplamento entre microsserviços. [Capítulos 12, 13.]

ADR (Architecture Decision Record) — Registro formal de uma decisão arquitetural significativa, incluindo o contexto que motivou a decisão, as alternativas avaliadas, a decisão tomada e suas consequências. A plataforma mantém numeração sequencial de ADRs (ADR-001, ADR-046, ADR-101, etc.) para rastreabilidade das escolhas de design ao longo do tempo. [Referenciado em todos os capítulos de arquitetura.]

API Gateway — Componente que atua como ponto de entrada unificado para requisições externas à plataforma, responsável por autenticação, autorização, roteamento, controle de taxa (rate limiting), transformação de requisições e coleta de métricas. Protege os microsserviços internos de exposição direta. [Capítulo 14.]

Arquitetura Hexagonal (Ports & Adapters) — Padrão arquitetural onde a lógica de domínio (núcleo) é isolada de tecnologias externas (banco de dados, mensageria, HTTP) por meio de interfaces abstratas (portas). As implementações concretas dessas interfaces (adaptadores) podem ser substituídas sem alterar a lógica de negócio. Adotada no backend Java + Spring Boot. [Capítulo 31.]

C4 Model — Framework de diagramação arquitetural com quatro níveis de abstração: Contexto (visão sistêmica), Contêineres (visão de processo/componente), Componentes (visão interna de um contêiner) e Código (visão de implementação). Utilizado como linguagem padrão de modelagem neste documento. [Capítulos 8, 11.]

Camada — Agrupamento lógico de componentes com responsabilidade homogênea dentro da arquitetura da plataforma. As dez camadas lógicas definidas incluem: canais, API Gateway, serviços de domínio, mensageria, persistência, cache, busca, IA, infraestrutura e observabilidade. [Capítulo 11.]

Circuit Breaker — Padrão de resiliência que interrompe chamadas a um componente que está falhando, evitando que falhas em cascata degradem toda a plataforma. Após um tempo configurável, permite tentativas graduais de recuperação. Implementado nos microsserviços com bibliotecas de resiliência (ex.: Resilience4j). [Capítulo 12.]

Cloud-Native — Característica de uma aplicação projetada desde sua concepção para operar em infraestruturas de nuvem, aproveitando serviços gerenciados, escalabilidade elástica, contêineres e orquestração. A plataforma é cloud-native e também suporta operação on-premise. [Capítulo 37.]

Componentização — Princípio de design que divide um sistema em unidades reutilizáveis, testáveis e substituíveis. Na plataforma, manifestado tanto na granularidade de microsserviços (backend) quanto em componentes de interface (frontend React). [Capítulos 11, 12, 32.]

Consistência Eventual — Modelo de consistência onde réplicas de dados convergem para o mesmo estado ao longo do tempo, sem garantia de sincronização imediata. Adotado nos fluxos assíncronos por RabbitMQ: um evento publicado eventualmente alcança todos os consumidores registrados. [Capítulo 13.]

Container (contêiner) — Unidade de empacotamento de software que inclui o código da aplicação, suas dependências e configurações em uma imagem portátil e isolada. Executados e orquestrados pelo Kubernetes. Não confundir com o nível "Contêiner" do C4 Model, que é um nível de abstração arquitetural. [Capítulo 39.]

DDD (Domain-Driven Design) — Abordagem de desenvolvimento de software onde a modelagem é orientada pelo domínio de negócio, com terminologia compartilhada entre especialistas de domínio e desenvolvedores (Linguagem Ubíqua) e fronteiras explícitas entre contextos de negócio (Bounded Contexts). Aplicado na decomposição dos microsserviços. [Capítulos 11, 12.]

Degradação Controlada (Graceful Degradation) — Capacidade de um sistema de continuar operando, com funcionalidade reduzida, quando componentes falham. Exemplo: o assistente de IA pode estar indisponível sem afetar o fluxo de abertura de solicitações. [Capítulos 12, 16, 47.]

Deploy — Ato de disponibilizar uma nova versão de um componente de software em um ambiente (produção, homologação, desenvolvimento). A plataforma adota deploy progressivo com estratégias canary e blue-green. [Capítulo 40.]

Deploy Blue-Green — Estratégia de deploy onde dois ambientes idênticos (azul e verde) são mantidos. O novo release é deployado no ambiente inativo; após validação, o tráfego é redirecionado integralmente. Permite rollback instantâneo. [Capítulo 40.]

Deploy Canary — Estratégia de deploy onde o novo release é disponibilizado para uma fração pequena do tráfego real (ex.: 5%) antes de expansão gradual a 100%. Permite detecção precoce de problemas com impacto limitado. [Capítulo 40.]

DevSecOps — Integração das práticas de segurança ao ciclo de desenvolvimento e operações (DevOps), com segurança verificada automaticamente a cada commit por meio de ferramentas como SAST, SCA e container scanning. [Capítulo 40.]

Domínio de Negócio — Área de responsabilidade funcional com fronteiras claras, modelo de dados próprio e conjunto de regras de negócio coesos. A plataforma organiza-se em 17 domínios (CRM, BPM, Identidade, Catálogo de Serviços, Solicitações, etc.), cada um implementado por um ou mais microsserviços. [Capítulos 8, 12.]

Escalabilidade Horizontal — Capacidade de aumentar a capacidade computacional adicionando mais instâncias de um componente em vez de aumentar os recursos de uma única instância. Suportada pela arquitetura de microsserviços sem estado local e pelo Kubernetes. [Capítulos 11, 38.]

Event-Driven Architecture (Arquitetura Orientada a Eventos) — Estilo arquitetural onde componentes comunicam-se por meio da publicação e consumo de eventos assíncronos. Permite desacoplamento, resiliência e escalabilidade. Implementado com RabbitMQ. [Capítulo 13.]

Hexagonal Architecture — Ver Arquitetura Hexagonal.

IaC (Infrastructure as Code) — Prática de descrever e gerenciar infraestrutura por meio de código versionado (ex.: Terraform, Helm) em vez de configuração manual. Garante repetibilidade, auditabilidade e rastreabilidade de mudanças. [Capítulos 37, 40.]

Idempotência — Propriedade de uma operação que produz o mesmo resultado independentemente de quantas vezes é executada com os mesmos parâmetros. Crítica em consumidores de eventos para evitar efeitos colaterais em caso de reentrega de mensagens. [Capítulo 13.]

Imutabilidade de Infraestrutura — Princípio pelo qual recursos de infraestrutura são substituídos (recriados a partir de imagem atualizada) em vez de modificados em operação. Elimina deriva de configuração e garante reprodutibilidade. [Capítulo 37.]

Linguagem Ubíqua (Ubiquitous Language) — Vocabulário compartilhado entre especialistas de domínio e equipe técnica, utilizado tanto na modelagem quanto no código. Parte fundamental do DDD. Este glossário é a materialização da Linguagem Ubíqua da plataforma.

Microsserviço — Serviço de software com responsabilidade de negócio delimitada, que possui seus próprios dados, API e ciclo de deploy independente. A plataforma é composta por 24 microsserviços de domínio. [Capítulo 12.]

Modelo C4 — Ver C4 Model.

Monólito — Arquitetura onde toda a lógica de negócio é implementada em um único artefato de deploy. A plataforma adota arquitetura de microsserviços como alternativa ao monólito, preservando autonomia de evolução por domínio.

On-Premise — Modelo de implantação onde a infraestrutura reside em datacenter próprio da organização, em contraste com ambientes de nuvem pública. A plataforma suporta tanto cloud pública quanto on-premise. [Capítulo 37.]

Orquestrador de Contêineres — Ver Kubernetes.

Padrão Outbox (Transactional Outbox) — Padrão de integração confiável entre banco de dados e mensageria. Em vez de publicar um evento diretamente ao RabbitMQ após uma transação, o evento é gravado em uma tabela de outbox dentro da mesma transação de banco. Um processo separado (relay) publica os eventos da outbox ao broker. Garante consistência entre estado e eventos. [Capítulo 12.]

Plataforma — Neste documento, refere-se exclusivamente à Plataforma de Relacionamento Digital com o Cidadão, objeto do Chamamento Público nº 001/2026, desenvolvida e operada pela Parceira em parceria com a PRODEMGE.

Resilience4j — Biblioteca Java de resiliência que implementa padrões como Circuit Breaker, Rate Limiter, Retry, Bulkhead e TimeLimiter. Adotada nos microsserviços backend. [Capítulo 12.]

Rollback — Reversão de um deploy para a versão anterior de um componente, executada quando problemas são detectados após a liberação de uma nova versão. [Capítulos 40, 47.]

SBOM (Software Bill of Materials) — Inventário formal de todas as dependências de software de um componente, incluindo versões e licenças. Gerado automaticamente no pipeline de CI/CD e entregue à PRODEMGE como parte do protocolo de custódia. [Capítulos 40, 58.]

SLA (Service Level Agreement — Acordo de Nível de Serviço) — Documento formal que estabelece os compromissos de disponibilidade, desempenho e qualidade de serviço entre a Parceira e a PRODEMGE. [Capítulo 53.]

SLO (Service Level Objective) — Objetivo mensurável de nível de serviço, derivado do SLA. Exemplos: disponibilidade ≥ 99,5%; latência P95 ≤ 2 segundos. [Capítulo 53.]

Stack Tecnológica — Conjunto de tecnologias, frameworks e ferramentas adotados para desenvolvimento e operação da plataforma. Confirmada pelo código-fonte: React Native (mobile), React (web), Java + Spring Boot (backend), RabbitMQ (mensageria), PostgreSQL (banco), Redis (cache), Kubernetes (orquestração).

---

68.5 Domínio: Multi-Tenancy e Isolamento

Contexto de Tenant (Tenant Context) — Informação de qual tenant está associado a uma requisição, derivada obrigatoriamente da identidade autenticada do usuário. Propagado de forma transparente por todos os componentes da plataforma, garantindo que nenhuma operação acesse dados fora do escopo do tenant corrente. [Capítulo 30.]

Cross-Tenant — Situação em que dados ou operações de um tenant são acessados por outro tenant — violação estrita do modelo de isolamento. A arquitetura multi-tenant da plataforma previne cross-tenant em múltiplas camadas independentes: aplicação, banco de dados, cache, mensageria e busca. [Capítulo 30.]

Isolamento de Dados — Garantia de que os dados de um tenant não são acessíveis a outro tenant. Implementado por meio de identificação universal de dados com tenant_id, filtros obrigatórios em toda query, verificação de Tenant Context em toda operação e criptografia independente. [Capítulo 30.]

Isolamento Físico — Modelo de isolamento onde cada tenant opera em infraestrutura separada (banco de dados, cluster Kubernetes, rede). Oferece máximo isolamento ao custo de multiplicação de infraestrutura. Não adotado na plataforma.

Isolamento Lógico — Modelo de isolamento adotado pela plataforma, onde múltiplos tenants compartilham a mesma infraestrutura, mas seus dados são segregados por identificação, controles de acesso e auditoria. Confirmado pelos esclarecimentos PRODEMGE como suficiente para os requisitos do edital. [Capítulo 30.]

Multi-Tenant — Característica arquitetural que permite que múltiplos tenants (órgãos públicos) utilizem a mesma instância da plataforma com isolamento completo de dados, configurações e usuários. [Capítulo 30.]

Namespace de Tenant — Prefixo ou particionamento lógico que segrega os dados de um tenant no contexto de cada tecnologia: prefixo de chave no Redis ({tenantId}:{tipo}:{id}), índice próprio no ElasticSearch (platform-v1-tenant-{tenantId}-{tipo}), prefixo de objeto no storage ({tenantId}/{documento}), tópico de exchange no RabbitMQ. [Capítulo 30.]

Onboarding de Tenant — Processo de integração de um novo órgão público (tenant) à plataforma, incluindo provisionamento de recursos, configuração de identidade visual, definição de perfis, treinamento de equipes e go-live supervisionado. [Capítulo 48.]

Órgão — Neste documento, refere-se a órgão público estadual ou municipal (secretaria, autarquia, fundação, prefeitura) que participa da plataforma como tenant. É o controlador dos dados pessoais dos cidadãos que atende. [Capítulos 1, 30.]

Segregação Lógica — Ver Isolamento Lógico.

tenant_id — Identificador único e imutável de um tenant na plataforma, representado como UUID. Presente como coluna em todas as tabelas de negócio, como campo em todos os eventos de mensageria, como metadado em todos os vetores do vector store e como prefixo em todas as chaves de cache. [Capítulo 30.]

Tenant — Unidade organizacional isolada logicamente, representando um órgão público participante da plataforma. Possui identidade única, namespace próprio para dados, configurações específicas, usuários e perfis próprios. Todo dado criado na plataforma pertence a um e somente um tenant. [Capítulos 1, 30.]

---

68.6 Domínio: Identidade, Acesso e Segurança

ABAC (Attribute-Based Access Control) — Modelo de controle de acesso onde as decisões de autorização consideram atributos do sujeito, do recurso e do contexto (ex.: perfil do usuário, tenant, unidade, horário). Complementa o RBAC em cenários de granularidade fina. [Capítulo 29.]

Autenticação — Processo de verificação da identidade de um usuário ou sistema. A plataforma suporta autenticação via IAM próprio (usuários internos dos órgãos) e via GOV.BR (cidadãos). [Capítulos 28, 43.]

Autorização — Processo de verificação se uma identidade autenticada tem permissão para executar uma operação sobre um recurso. Separada e posterior à autenticação. [Capítulos 28, 29, 43.]

Break Glass — Mecanismo de acesso de emergência a recursos críticos que normalmente requer autorização prévia formal. Utilizado em situações de crise que demandam intervenção imediata. Todo uso de break glass é auditado com registro de quem acessou, quando e o que foi executado. [Capítulo 45.]

Certificado Digital — Documento eletrônico que vincula uma chave pública a uma identidade. Utilizado para TLS, mTLS e assinatura digital de artefatos. Gerenciado com inventário e alertas de vencimento. [Capítulo 46.]

Cofre de Segredos (Secrets Manager) — Componente centralizado de armazenamento seguro e rotação de segredos (senhas, tokens, chaves de API, certificados). Implementado com External Secrets Operator integrado ao Kubernetes. Nenhum segredo é armazenado em código ou variáveis de ambiente não criptografadas. [Capítulo 42.]

Criptografia em Repouso — Proteção de dados armazenados (banco de dados, backups, arquivos) por meio de algoritmos criptográficos. Algoritmo adotado: AES-256-GCM. [Capítulo 46.]

Criptografia em Trânsito — Proteção de dados transmitidos em rede por meio de protocolos criptográficos. Protocolo obrigatório: TLS 1.3 para comunicações externas; mTLS para comunicações internas entre serviços. [Capítulo 46.]

CSP (Content Security Policy) — Cabeçalho HTTP que instrui o navegador sobre quais recursos externos podem ser carregados, mitigando ataques de Cross-Site Scripting (XSS). Implementado no Portal Web. [Capítulo 42.]

DPO (Data Protection Officer — Encarregado de Dados) — Papel responsável pela supervisão da conformidade com a LGPD dentro da organização. Ponto de contato com a ANPD e com os titulares de dados. [Capítulo 44.]

GOV.BR — Identidade digital federal do cidadão brasileiro, gerenciada pelo Governo Federal. A plataforma integra-se ao GOV.BR via OIDC para autenticação de cidadãos sem necessidade de cadastro adicional. [Capítulos 28, 43.]

HSM (Hardware Security Module) — Dispositivo físico especializado em operações criptográficas seguras, protegendo chaves criptográficas contra extração. Referenciado como opção para gestão de chaves de alto valor. [Capítulo 46.]

IAM (Identity and Access Management) — Sistema de gestão de identidade e acesso da plataforma, responsável por autenticação, emissão de tokens, autorização, gestão de sessões e integração com provedores externos (GOV.BR). [Capítulo 43.]

JWT (JSON Web Token) — Padrão de token de acesso compacto e autocontido, assinado digitalmente. Carrega as informações de identidade e autorização do usuário autenticado. Utilizado na plataforma para propagação de identidade entre componentes. [Capítulos 14, 43.]

KMS (Key Management Service) — Serviço de gestão de ciclo de vida de chaves criptográficas, incluindo geração, armazenamento, rotação e revogação. [Capítulo 46.]

LGPD (Lei Geral de Proteção de Dados Pessoais) — Lei nº 13.709/2018, que estabelece regras para coleta, armazenamento, tratamento e compartilhamento de dados pessoais no Brasil. A plataforma implementa conformidade com a LGPD como requisito estrutural. [Capítulo 44.]

MFA (Multi-Factor Authentication — Autenticação Multifator) — Mecanismo de autenticação que exige dois ou mais fatores independentes para verificar a identidade: algo que o usuário sabe (senha), algo que possui (dispositivo) e algo que é (biometria). Obrigatório para perfis administrativos. [Capítulos 28, 43.]

mTLS (Mutual TLS) — Variante do protocolo TLS onde tanto o cliente quanto o servidor apresentam certificados para autenticação mútua. Adotado para comunicação entre microsserviços internos. [Capítulo 42.]

OAuth 2.0 — Protocolo de autorização que permite que aplicações obtenham acesso limitado a recursos em nome de um usuário sem expor suas credenciais. Base dos fluxos de autenticação da plataforma. [Capítulo 43.]

OIDC (OpenID Connect) — Camada de identidade sobre OAuth 2.0 que padroniza a obtenção de informações do usuário autenticado via token de identidade (ID Token). Protocolo utilizado na integração com GOV.BR. [Capítulos 28, 43.]

OWASP Top 10 — Lista das dez vulnerabilidades de segurança de aplicações web mais críticas, publicada pela Open Web Application Security Project. Referência normativa para os controles de segurança implementados na plataforma. [Capítulo 42.]

PKCE (Proof Key for Code Exchange) — Extensão do fluxo de autorização OAuth 2.0 que mitiga ataques de interceptação de código de autorização em clientes públicos (SPAs, aplicativos mobile). Obrigatório na integração com GOV.BR. [Capítulo 43.]

Privacy by Default — Princípio de proteção de dados pelo qual as configurações padrão de um sistema oferecem o nível mais restritivo de privacidade, sem necessidade de ação adicional do usuário. Complementar ao Privacy by Design. [Capítulo 44.]

Privacy by Design — Princípio de proteção de dados pelo qual a privacidade é incorporada ao design do sistema desde sua concepção, não adicionada como camada posterior. Orientador de todas as decisões de arquitetura envolvendo dados pessoais. [Capítulo 44.]

RBAC (Role-Based Access Control) — Modelo de controle de acesso onde as permissões são associadas a papéis (perfis), e os usuários recebem permissões por meio de atribuição de papéis. Modelo principal de autorização da plataforma, estendido com ABAC para cenários complexos. [Capítulo 29.]

SAST (Static Application Security Testing) — Análise estática de código-fonte em busca de vulnerabilidades de segurança, executada automaticamente no pipeline de CI/CD antes do deploy. [Capítulo 40.]

SCA (Software Composition Analysis) — Análise das dependências de terceiros de um componente em busca de vulnerabilidades conhecidas (CVEs) e problemas de licenciamento. Parte do pipeline DevSecOps. [Capítulo 40.]

Sessão — Estado mantido entre o sistema e um usuário autenticado durante um período de atividade. Gerenciada por token com tempo de expiração, refresh controlado e revogação possível por evento de segurança. [Capítulo 43.]

SSO (Single Sign-On) — Mecanismo que permite que um usuário autentique-se uma vez e acesse múltiplos sistemas sem necessidade de novas autenticações. A integração com GOV.BR habilita SSO para cidadãos. [Capítulo 43.]

Threat Model (Modelo de Ameaças) — Exercício estruturado de identificação de ameaças potenciais a um sistema, avaliação de seus impactos e definição de controles de mitigação. Praticado como parte do ciclo de desenvolvimento seguro. [Capítulo 42.]

TLS (Transport Layer Security) — Protocolo criptográfico que garante confidencialidade e integridade das comunicações em rede. Versão mínima exigida: TLS 1.3. [Capítulo 46.]

Token de Acesso (Access Token) — Credencial de curta duração emitida pelo IAM após autenticação bem-sucedida, que autoriza o portador a acessar recursos específicos. Implementado como JWT assinado. [Capítulos 43, 14.]

WAF (Web Application Firewall) — Componente de segurança de borda que inspeciona e filtra o tráfego HTTP/HTTPS, bloqueando padrões de ataque conhecidos (injeção, XSS, bots maliciosos) antes que alcancem a aplicação. [Capítulo 42.]

Zero Trust — Modelo de segurança baseado no princípio de "nunca confiar, sempre verificar": nenhuma requisição é considerada confiável apenas por sua origem, mesmo dentro da rede corporativa. Toda comunicação requer autenticação e autorização explícitas. Princípio transversal da arquitetura de segurança da plataforma. [Capítulo 42.]

---

68.7 Domínio: Dados, Persistência e Cache

ACID (Atomicity, Consistency, Isolation, Durability) — Propriedades que garantem confiabilidade de transações em bancos de dados relacionais: atomicidade (tudo ou nada), consistência (regras de integridade preservadas), isolamento (transações não interferem entre si) e durabilidade (dados confirmados sobrevivem a falhas). [Capítulo 34.]

Backup — Cópia de segurança de dados realizada periodicamente para possibilitar restauração em caso de falha. Executado com frequência e retenção definidas por política, criptografado, testado regularmente via restore em ambiente isolado. [Capítulo 47.]

Business Glossary — Repositório centralizado de definições oficiais de termos de negócio, garantindo que métricas e relatórios utilizem a mesma definição em todos os contextos. Componente do Data Catalog. [Capítulo 23.]

Cache — Armazenamento temporário de dados de alta frequência de acesso para redução de latência e carga no banco de dados primário. Implementado com Redis. [Capítulo 35.]

Cache Hit Ratio — Proporção de requisições respondidas diretamente pelo cache sem necessidade de consulta ao banco de dados. Métrica de eficiência do cache monitorada continuamente. [Capítulo 35.]

Data Catalog — Sistema de descoberta e documentação de ativos de dados, incluindo metadados técnicos, funcionais, operacionais e de segurança. Componente do Data Lake. [Capítulo 23.]

Data Lake — Repositório centralizado de dados brutos e processados em múltiplos formatos, utilizado para analytics avançado e alimentação de dashboards. Integrado ao DATALAKE MG do ecossistema PRODEMGE. [Capítulo 23.]

Data Lineage (Linhagem de Dados) — Rastreabilidade da origem e das transformações de um dado ao longo de seu ciclo de vida, desde a fonte até os dashboards de consumo. Permite impact analysis em mudanças de schema. [Capítulo 23.]

Data Product — Conjunto de dados disponibilizado com owner definido, finalidade documentada, contrato, métricas de qualidade e ciclo de vida gerenciado. Unidade de governança no Data Lake. [Capítulo 23.]

DATALAKE MG — Data Lake centralizado do Estado de Minas Gerais, mantido pela PRODEMGE. A plataforma integra-se ao DATALAKE MG para compartilhamento de dados analíticos agregados. [Capítulo 23.]

Dead Letter Queue (DLQ) — Fila especial no RabbitMQ que recebe mensagens que não puderam ser processadas com sucesso após o número máximo de tentativas. Permite investigação e reprocessamento controlado de mensagens com falha. [Capítulo 13.]

ETL (Extract, Transform, Load) — Processo de extração de dados de fontes, transformação para o formato analítico desejado e carga no destino (Data Lake). Executado em pipelines automatizados. [Capítulo 23.]

Idempotência de Consumidor — Ver Idempotência na seção de Arquitetura Geral, aplicada especificamente ao consumo de mensagens: processar a mesma mensagem duas vezes produz o mesmo efeito que processá-la uma vez. [Capítulo 13.]

Índice (banco de dados) — Estrutura de dados que acelera consultas em colunas específicas de uma tabela. Na plataforma, índices multi-coluna incluem obrigatoriamente tenant_id como primeira coluna para garantir isolamento e performance. [Capítulos 30, 34.]

ORM (Object-Relational Mapper) — Biblioteca que mapeia entre objetos Java e tabelas relacionais, abstraindo queries SQL. Implementado com Spring Data JPA e Hibernate. [Capítulo 31.]

Particionamento — Divisão de uma tabela grande em subconjuntos menores (partições) com base em critérios como data ou tenant_id, para melhor performance em queries e gestão de ciclo de vida de dados. [Capítulo 34.]

Pipeline de Dados — Sequência de transformações automatizadas que movem e processam dados de uma fonte para um destino, com controles de qualidade, monitoramento e rastreabilidade em cada etapa. [Capítulo 23.]

PostgreSQL — Sistema de gerenciamento de banco de dados relacional de código aberto, adotado como banco operacional principal da plataforma. Suporta ACID, JSON nativo, extensões e Row-Level Security. [Capítulo 34.]

Quality SLO — Objetivo mensurável de qualidade de dados em um Data Product, cobrindo completude, atualidade (freshness) e unicidade. Violações geram alertas e são reportadas no Dashboard de Qualidade de Dados. [Capítulo 23.]

Quarantine Zone — Área isolada no pipeline de dados onde registros que violam regras de qualidade são depositados para análise e reprocessamento, sem contaminar dados válidos. [Capítulo 23.]

Read Replica — Cópia somente leitura do banco de dados primário, utilizada para segregar carga analítica (dashboards, relatórios) da carga transacional. Aceita latência de replicação tipicamente inferior a um segundo. [Capítulo 34.]

Redis — Banco de dados em memória de alta performance utilizado como cache distribuído. Chaves incluem obrigatoriamente tenant_id para isolamento. [Capítulo 35.]

Retenção de Dados — Política que define por quanto tempo dados são mantidos em cada nível de armazenamento antes de serem arquivados ou excluídos. Configurável por tenant conforme requisitos legais e regulatórios. [Capítulos 23, 44.]

Row-Level Security (RLS) — Funcionalidade de banco de dados que restringe quais linhas um usuário pode acessar com base em políticas definidas. Camada adicional de proteção de isolamento multi-tenant. [Capítulo 34.]

Schema — Definição estrutural de um banco de dados ou tabela, incluindo colunas, tipos de dados, restrições e relacionamentos. Gerenciado com ferramentas de migração versionadas. [Capítulo 34.]

Serving Zone — Camada final do Data Lake onde dados estão prontos para consumo por dashboards e aplicações analíticas, com alta disponibilidade e baixa latência de consulta. [Capítulo 23.]

TTL (Time-To-Live) — Tempo de expiração de uma entrada em cache ou mensagem em fila, após o qual é automaticamente removida. Configurável por tipo de dado e por tenant. [Capítulos 13, 35.]

---

68.8 Domínio: Inteligência Artificial e RAG

Agente de IA — Capacidade de IA que executa sequências de ações (ferramentas) de forma autônoma para atingir um objetivo, com planejamento iterativo entre etapas. Distinto de uma simples geração de resposta. A plataforma inclui agentes com número máximo de passos e orçamento de tokens controlados. [Capítulo 16.]

AI Gateway — Componente central que medeia toda comunicação entre os microsserviços de negócio e os provedores de modelos de linguagem. Responsável por roteamento, metering, aplicação de políticas de dados, circuit breaker e rastreabilidade. Nenhum serviço chama um provedor de IA diretamente. [Capítulo 16.]

AI Request ID — Identificador único de cada requisição ao sistema de IA, vinculado ao correlationId distribuído. Permite rastreabilidade completa de qual prompt gerou qual resposta, com qual versão de modelo e prompt. [Capítulo 16.]

Assistente do Cidadão — Capacidade de IA (CITIZEN_ASSISTANT) que interpreta perguntas em linguagem natural, orienta o cidadão nos serviços disponíveis, explica requisitos e recupera situação de protocolos. Não executa ações transacionais sem confirmação explícita. [Capítulos 16, 22.]

Chunking — Divisão de documentos em segmentos menores (chunks) para indexação vetorial. Cada chunk tem tamanho e overlap configurados por tipo de conteúdo para maximizar qualidade de recuperação no RAG. [Capítulos 16, 36.]

Copiloto de IA — Assistente inteligente integrado às interfaces da plataforma, que apoia cidadãos (orientação de serviços) e atendentes internos (sugestões contextualizadas). Implementado com roteamento semântico pelo pacote @brasfy/core/assistente. [Capítulos 16, 22.]

Embedding — Representação numérica vetorial de um texto em alta dimensionalidade, capturando o significado semântico. Textos semanticamente similares têm embeddings próximos no espaço vetorial. Base da busca semântica e do RAG. [Capítulos 16, 36.]

Embedding Service — Serviço responsável por gerar embeddings a partir de texto, utilizando um modelo de embedding versionado e gerenciado. [Capítulo 16.]

Evaluation Gate — Etapa obrigatória no ciclo de vida de prompts e modelos de IA que verifica métricas de qualidade (precisão de retrieval, groundedness, relevância) antes de autorizar deploy em produção. [Capítulo 16.]

Few-Shot Examples — Exemplos de entrada e saída esperada incluídos no prompt de um modelo de linguagem para orientar seu comportamento sem fine-tuning. Gerenciados no Prompt Registry com revisão de viés e privacidade. [Capítulo 16.]

Fine-Tuning — Processo de treinamento adicional de um modelo de linguagem pré-treinado com dados específicos de um domínio. Diferente de RAG: fine-tuning altera os pesos do modelo; RAG recupera contexto externo em tempo de inferência.

Groundedness — Propriedade de uma resposta gerada por IA que mede o grau de aderência ao contexto recuperado via RAG, sem afirmações que extrapolam o conteúdo fornecido. Monitorada por avaliação contínua. [Capítulo 16.]

Guardrail — Controle de validação aplicado à entrada ou saída de um modelo de linguagem para bloquear conteúdo inadequado, dados pessoais, informações fora do escopo e outros riscos. [Capítulo 16.]

Indirect Prompt Injection — Ataque onde conteúdo malicioso inserido em um documento indexado instrui o modelo de linguagem a executar ações não autorizadas quando esse conteúdo é recuperado via RAG. Mitigado tratando conteúdo recuperado como dado, não como instrução. [Capítulo 16.]

Knowledge Base — Conjunto governado de conhecimento com identificador, tenant, propósito, classificação e política de retrieval, utilizado pelo RAG. Exemplos: catálogo de serviços, FAQ do cidadão, procedimentos internos do órgão. [Capítulo 16.]

Knowledge Builder — Componente responsável pela ingestão, chunking, embedding e indexação de conteúdo autorizado nas bases de conhecimento dos tenants. Acionado por eventos e executa de forma assíncrona. [Capítulo 16.]

Knowledge Policy — Política que define quais bases de conhecimento uma capacidade de IA pode acessar em um contexto específico de tenant. Garante que o RAG recupere apenas conteúdo autorizado. [Capítulo 16.]

LLM (Large Language Model) — Modelo de linguagem de grande escala treinado em corpus extenso de texto, capaz de gerar, resumir e transformar texto com alta qualidade. Acessado exclusivamente pelo AI Gateway. [Capítulo 16.]

LLM Gateway — Ver AI Gateway.

Model Abstraction Layer — Camada que abstrai as diferenças de API entre provedores de modelos de linguagem, permitindo que os serviços de negócio utilizem modelos distintos sem alteração de código. [Capítulo 16.]

Model Registry — Repositório centralizado de modelos de IA disponíveis na plataforma, incluindo identificador, provedor, capacidades, políticas de dados e status. Insumo para o Model Router. [Capítulo 16.]

Model Router — Componente do AI Gateway que seleciona o provedor e modelo adequados para cada requisição com base em critérios como latência, custo, política de dados e capacidade requerida. [Capítulo 16.]

Prompt — Instrução textual fornecida a um LLM para orientar a geração de resposta, incluindo contexto, exemplos e restrições. Gerenciado com versionamento obrigatório no Prompt Registry. [Capítulo 16.]

Prompt Registry — Sistema de versionamento e governança de prompts, com ciclo de vida definido (draft → evaluation → approval → active → deprecated) e rastreabilidade de qual versão gerou qual comportamento. [Capítulo 16.]

RAG (Retrieval-Augmented Generation) — Técnica de IA que combina recuperação de informação relevante de uma base de conhecimento (retrieval) com geração de resposta por um LLM (generation). Garante que as respostas sejam fundamentadas em conhecimento institucional controlado, não em conhecimento genérico do modelo. [Capítulos 16, 36.]

Reranking — Etapa no pipeline RAG que reordena os chunks recuperados por relevância semântica antes da montagem do contexto para o LLM, melhorando a qualidade da resposta. [Capítulo 16.]

Roteamento Semântico — Mecanismo que interpreta a intenção de uma mensagem do usuário e direciona para a capacidade de IA ou fluxo de negócio mais adequado. Implementado pelo pacote @brasfy/core/assistente. [Capítulos 16, 22.]

Tool Calling (Function Calling) — Capacidade de um LLM de identificar quando deve invocar uma ferramenta externa (API, banco de dados, sistema) em vez de gerar uma resposta de texto puro. Controlado pelo Tool Execution Gateway com autorização independente. [Capítulo 16.]

Tool Execution Gateway — Componente que intercepta as chamadas de ferramentas solicitadas por agentes de IA, validando autorização de forma independente do modelo antes de executar cada ação. [Capítulo 16.]

Vector Store — Banco de dados especializado em armazenamento e consulta de embeddings por similaridade vetorial (distância cosseno, produto interno). Segregado por tenant. Exemplos de tecnologia: Weaviate, Pinecone, Milvus. [Capítulos 16, 36.]

---

68.9 Domínio: Módulos Funcionais

Agendamento — Marcação de horário para atendimento presencial ou remoto com um órgão. Funcionalidade suportada pelo módulo de Agendamentos com gestão de agenda, disponibilidade, confirmação e remarcação. [Capítulo 22.]

Atendimento — Interação formal de um servidor público ou atendente com um cidadão no contexto de uma fila ou solicitação. Registrado no CRM com histórico auditável. [Capítulos 18, 22.]

BPM (Business Process Management) — Gestão e automação de processos de negócio. Na plataforma, implementado pelo Workflow Service que suporta modelagem, versionamento e execução de processos com tarefas humanas e automáticas. [Capítulo 19.]

Catálogo de Serviços — Repositório estruturado de todos os serviços públicos disponibilizados por um tenant, com nome, descrição, requisitos, documentos necessários, canais disponíveis e formulário associado. [Capítulo 12.]

Cidadão — Usuário externo da plataforma: pessoa física ou representante de pessoa jurídica que utiliza os serviços públicos digitais disponibilizados pelos órgãos participantes. Autenticado via GOV.BR ou cadastro local. [Capítulo 1.]

CRM (Customer Relationship Management) — Módulo de gestão de relacionamento com o cidadão, que centraliza o histórico de interações, solicitações, protocolos e atendimentos de cada cidadão em cada tenant. [Capítulo 18.]

ECM (Enterprise Content Management) — Gestão empresarial de conteúdo e documentos. Na plataforma, implementado pelo módulo GED que provê armazenamento, metadados, versionamento e controle de acesso a documentos. [Capítulo 20.]

Formulário Dinâmico — Formulário configurável com seções, campos, validações, condicionais e máscaras, definido pelo catálogo de serviços para cada tipo de solicitação. Versões são imutáveis após publicação. [Capítulos 12, 19.]

GED (Gestão Eletrônica de Documentos) — Módulo de armazenamento e gestão de documentos, incluindo upload, versionamento, metadados, busca, controle de acesso e integração com SEI!MG. [Capítulo 20.]

Manifestação — Tipo de comunicação do cidadão com um órgão por meio do módulo de Ouvidoria: reclamação, sugestão, elogio, denúncia ou solicitação de acesso à informação. [Capítulo 22.]

Omnichannel — Estratégia de atendimento que oferece experiência consistente ao cidadão independentemente do canal utilizado (portal web, aplicativo mobile, e-mail, SMS, WhatsApp). O histórico de interações é unificado. [Capítulo 21.]

Ouvidoria — Canal formal de manifestação do cidadão com o órgão, com triagem, atribuição, resposta no prazo e possibilidade de anonimato. Integrado ao MG-Ouv do ecossistema PRODEMGE. [Capítulo 22.]

Portal Web — Interface de acesso à plataforma via navegador, desenvolvida em React. Disponibiliza o catálogo de serviços, abertura de solicitações, acompanhamento de protocolos e painel de gestão para usuários internos. [Capítulos 25, 32.]

Protocolo — Identificador único e imutável de uma solicitação, gerado no momento de sua submissão. Utilizado pelo cidadão para acompanhamento e pelo órgão para referência. Formato configurável por tenant. [Capítulo 12.]

Solicitação — Registro formal de demanda de um cidadão a um órgão, vinculada a um serviço do catálogo. Possui ciclo de vida com estados definidos (rascunho, submetida, em análise, complementação requerida, concluída, cancelada) e protocolo único. [Capítulo 12.]

Tarefa Humana — Atividade em um processo de BPM que requer intervenção de um operador humano antes de prosseguir. Gerenciada pelo Task Service com filas, distribuição e controle de SLA. [Capítulos 12, 19.]

Usuário Interno — Servidor público ou colaborador que opera a plataforma em nome de um órgão: atendente, analista, gestor, administrador. Autenticado pelo IAM próprio da plataforma. [Capítulo 1.]

Visão 360º do Cidadão — Consolidação de todas as informações de um cidadão em uma única interface: dados cadastrais, histórico de solicitações, protocolos, interações, documentos, agendamentos e manifestações. [Capítulo 18.]

---

68.10 Domínio: Infraestrutura e Operação

Availability Zone (Zona de Disponibilidade) — Localização física isolada dentro de uma região de nuvem, com energia, refrigeração e rede independentes. A plataforma opera em múltiplas zonas de disponibilidade para eliminar pontos únicos de falha. [Capítulo 37.]

CI/CD (Continuous Integration / Continuous Delivery) — Pipeline automatizado que valida, testa, verifica segurança, empacota e entrega software de forma contínua. Cada commit dispara o pipeline; apenas artefatos aprovados em todos os gates chegam a produção. [Capítulo 40.]

Cluster Kubernetes — Ver Kubernetes.

Correlação ID (correlationId) — Identificador único propagado por todos os componentes durante o processamento de uma requisição, permitindo que logs, métricas e traces de diferentes serviços sejam correlacionados em uma visão única. [Capítulo 41.]

DDoS (Distributed Denial of Service) — Ataque que sobrecarrega um sistema com tráfego malicioso massivo, tornando-o indisponível. Mitigado por controles de borda (WAF, CDN, rate limiting). [Capítulo 42.]

Disaster Recovery (DR) — Conjunto de políticas, ferramentas e procedimentos para restaurar operações de TI após um desastre. Inclui RPO e RTO definidos. [Capítulo 47.]

Helm — Gerenciador de pacotes para Kubernetes que empacota configurações em charts versionados e reutilizáveis. Utilizado para deploy de todos os componentes da plataforma. [Capítulo 38.]

HPA (Horizontal Pod Autoscaler) — Componente do Kubernetes que ajusta automaticamente o número de réplicas de um deployment com base em métricas de utilização (CPU, memória, métricas customizadas). [Capítulo 38.]

Helm Chart — Pacote de configuração do Helm que descreve um conjunto de recursos Kubernetes para implantação de uma aplicação. [Capítulo 38.]

Imagem de Container — Artefato imutável que contém o código de uma aplicação e suas dependências, construída por Dockerfile e armazenada em registry. [Capítulo 39.]

Kubernetes (K8s) — Plataforma de orquestração de contêineres que automatiza deploy, escalonamento e gestão de aplicações containerizadas. Camada de execução de todos os componentes da plataforma. [Capítulo 38.]

Namespace Kubernetes — Particionamento lógico de recursos dentro de um cluster Kubernetes, utilizado para separar componentes por ambiente ou contexto. [Capítulo 38.]

Observabilidade — Capacidade de entender o estado interno de um sistema a partir de suas saídas externas: métricas, logs e traces. Os três pilares são coletados pela plataforma via OpenTelemetry. [Capítulo 41.]

OpenTelemetry — Framework de observabilidade de código aberto que padroniza a coleta de métricas, logs e traces distribuídos. Adotado como padrão único de instrumentação na plataforma. [Capítulo 41.]

Pod — Unidade mínima de execução no Kubernetes, que encapsula um ou mais contêineres que compartilham rede e armazenamento. [Capítulo 38.]

Prometheus — Sistema de monitoramento e alerta que coleta métricas de componentes da plataforma em formato padronizado. Integrado ao OpenTelemetry. [Capítulo 41.]

Registry de Contêineres — Repositório centralizado para armazenamento, versionamento e distribuição de imagens de contêiner. [Capítulo 39.]

RPO (Recovery Point Objective) — Quantidade máxima de dados que pode ser perdida em um evento de desastre, expressa em tempo. Define a frequência mínima de backup. [Capítulo 47.]

Runbook — Documento operacional que descreve procedimentos passo a passo para situações específicas: resposta a incidentes, deploy de emergência, rollback, restart de consumidores. [Capítulos 51, 52.]

RTO (Recovery Time Objective) — Tempo máximo aceitável de indisponibilidade antes que o serviço seja restaurado após um evento de desastre. [Capítulo 47.]

Smoke Test — Conjunto mínimo de testes executados imediatamente após um deploy para verificar se as funcionalidades críticas estão operacionais antes da liberação de tráfego completo. [Capítulo 40.]

SRE (Site Reliability Engineering) — Disciplina de engenharia que aplica princípios de software ao gerenciamento de operações, com ênfase em automação, observabilidade e gestão de SLOs. [Capítulo 51.]

Terraform — Ferramenta de IaC para provisionamento declarativo de infraestrutura em nuvem e on-premise. Utilizada para provisionar toda a infraestrutura da plataforma de forma versionada. [Capítulos 37, 40.]

Tracing Distribuído — Técnica de observabilidade que rastreia o percurso de uma requisição através de múltiplos microsserviços, construindo uma visão de ponta a ponta com latências por etapa. [Capítulo 41.]

---

68.11 Domínio: Mensageria e Integração

Consumer (Consumidor) — Componente que se inscreve em uma fila ou exchange do RabbitMQ e processa mensagens publicadas por um producer. [Capítulo 13.]

DLQ (Dead Letter Queue) — Ver Dead Letter Queue.

Envelope de Evento — Estrutura padronizada que envolve o payload de um evento, incluindo metadados obrigatórios: eventId, eventType, tenantId, timestamp, correlationId, version. [Capítulo 13.]

Event Type (Tipo de Evento) — Identificador semântico do tipo de evento publicado, incluindo versionamento explícito. Formato adotado: dominio.entidade.acao.vN (ex.: request.submitted.v1). [Capítulo 13.]

Exchange — Componente do RabbitMQ que recebe mensagens de producers e as roteia para filas com base em regras de binding (fanout, direct, topic, headers). [Capítulo 13.]

Fila (Queue) — Estrutura de armazenamento temporário de mensagens no RabbitMQ até que sejam processadas por um consumer. Suporta durabilidade, TTL e dead lettering. [Capítulo 13.]

GOV.BR — Ver seção de Identidade.

Inbox Pattern — Padrão de garantia de idempotência em consumidores de eventos: cada mensagem recebida é registrada com seu ID em uma tabela de inbox antes do processamento; mensagens já processadas são ignoradas. [Capítulo 13.]

MG API — Gateway de APIs do ecossistema PRODEMGE, que concentra APIs de serviços estaduais. A plataforma consome MG API para integração com sistemas de terceiros do Estado de Minas Gerais. [Capítulo 14.]

MG-Ouv — Sistema de ouvidoria do Estado de Minas Gerais, mantido pela PRODEMGE. Integrado ao módulo de Ouvidoria da plataforma. [Capítulo 22.]

OpenAPI — Especificação para descrição de APIs REST em formato padronizado (JSON ou YAML). Todos os endpoints da plataforma são documentados com OpenAPI. [Capítulo 14.]

Producer (Produtor) — Componente que publica mensagens em um exchange do RabbitMQ. Cada microsserviço é produtor dos eventos de seu domínio. [Capítulo 13.]

PRO SMTP — Serviço de entrega de e-mail transacional do ecossistema PRODEMGE. Utilizado pela plataforma para comunicações por e-mail com cidadãos. [Capítulo 21.]

PRODEMGE — Companhia de Tecnologia da Informação do Estado de Minas Gerais. Contratante da parceria tecnológica, controladora dos dados pessoais tratados pela plataforma. [Capítulo 1.]

RabbitMQ — Broker de mensageria open source que implementa o protocolo AMQP. Adotado como backbone de comunicação assíncrona entre microsserviços da plataforma. [Capítulo 13.]

REST (Representational State Transfer) — Estilo arquitetural para APIs web baseado em recursos, verbos HTTP e representações em JSON. Padrão de comunicação síncrona entre componentes da plataforma. [Capítulo 14.]

SEI!MG — Sistema Eletrônico de Informações do Estado de Minas Gerais. A plataforma integra-se ao SEI!MG para gestão documental governamental e tramitação de processos. [Capítulo 20.]

SEG.ID — Serviço de verificação de identidade do ecossistema PRODEMGE. Integrado ao fluxo de autenticação da plataforma. [Capítulo 43.]

Versioning de API — Prática de versionar contratos de API para permitir evolução sem quebrar consumidores existentes. Adotado com prefixo de versão na URL (ex.: /api/v1/) e versionamento explícito em eventos de mensageria. [Capítulo 14.]

Webhook — Mecanismo de notificação de eventos por HTTP onde o produtor faz uma chamada HTTP ao consumidor quando um evento ocorre. Suportado pela plataforma para integrações externas. [Capítulo 14.]

---

68.12 Domínio: Proteção de Dados e Conformidade

AIPD (Avaliação de Impacto à Proteção de Dados) — Processo de avaliação de riscos para os titulares de dados em processamentos de alto risco, com documentação de base legal, riscos e medidas de mitigação. Equivalente ao DPIA do GDPR europeu. [Capítulo 44.]

Anonimização — Processo irreversível de transformação de dados pessoais de forma que a identificação do titular não seja possível por meios razoáveis. Diferente de pseudonimização: dado anonimizado não é mais dado pessoal. [Capítulo 44.]

ANPD (Autoridade Nacional de Proteção de Dados) — Órgão regulador responsável pela fiscalização do cumprimento da LGPD no Brasil. A plataforma mantém processo de notificação de incidentes à ANPD nos prazos legais. [Capítulo 44.]

Base Legal — Fundamento jurídico que legitima o tratamento de dados pessoais nos termos da LGPD: consentimento, cumprimento de obrigação legal, execução de políticas públicas, estudos e pesquisas, execução de contratos, exercício regular de direitos, proteção da vida, tutela da saúde, interesse legítimo e proteção ao crédito. [Capítulo 44.]

Controlador — Pessoa ou entidade responsável pelas decisões sobre o tratamento de dados pessoais. Na relação da plataforma, os órgãos participantes são controladores dos dados dos cidadãos que atendem; a PRODEMGE é controladora nos termos do Contrato. [Capítulo 44.]

Dado Pessoal — Informação relacionada a pessoa natural identificada ou identificável. Categoria regulada pela LGPD. [Capítulo 44.]

Dado Sensível — Subcategoria de dado pessoal que exige proteção adicional: origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, saúde, vida sexual, dados genéticos ou biométricos. [Capítulo 44.]

Direitos do Titular — Direitos garantidos pela LGPD ao titular de dados pessoais: confirmação de tratamento, acesso, correção, anonimização/bloqueio/eliminação, portabilidade, informação sobre compartilhamento, revogação de consentimento e revisão de decisões automatizadas. [Capítulo 44.]

DPO (Data Protection Officer) — Ver na seção de Identidade, Acesso e Segurança.

Encarregado de Dados — Ver DPO.

Incidente de Segurança — Evento que resulta em acesso não autorizado, divulgação, alteração ou destruição de dados pessoais. Deve ser notificado à ANPD sem demora injustificada. [Capítulo 44.]

Minimização de Dados — Princípio da LGPD pelo qual apenas os dados estritamente necessários para a finalidade declarada devem ser coletados e processados. Orientador de todas as decisões de modelagem de dados da plataforma. [Capítulo 44.]

Operador — Pessoa ou entidade que trata dados pessoais em nome do controlador. A Parceira atua como operadora de dados em relação aos órgãos participantes. [Capítulo 44.]

Portabilidade de Dados — Direito do titular de receber seus dados pessoais em formato estruturado e interoperável para transferência a outro controlador. [Capítulo 44.]

Propagação de Exclusão — Mecanismo técnico que garante a exclusão de dados pessoais de um titular em todas as camadas onde podem residir: banco de dados, cache, índices de busca, vetores e Data Lake. Acionado por workflow rastreável. [Capítulos 44, 17.]

Pseudonimização — Processo de substituição de dados pessoais identificáveis por identificadores artificiais (pseudônimos), mantendo a possibilidade de reversão com informação adicional mantida separadamente. Diferente de anonimização. [Capítulo 44.]

Redaction (Redação) — Processo de supressão ou mascaramento de dados pessoais antes de envio a sistemas externos (ex.: LLM externo). Garantia de minimização de exposição de PII. [Capítulos 16, 44.]

Retenção — Ver Retenção de Dados na seção de Dados.

Titular de Dados — Pessoa natural a quem se referem os dados pessoais tratados. Na plataforma, corresponde primariamente ao cidadão. [Capítulo 44.]

---

68.13 Domínio: Governança e Gestão

ADR — Ver Architecture Decision Record na seção de Arquitetura Geral.

Chamamento Público — Instrumento jurídico de seleção de parceiro privado para parceria com entidade pública sem fins lucrativos ou com fins lucrativos em atividades de interesse público. No contexto deste documento: Chamamento Público nº 001/2026 promovido pela PRODEMGE.

Custódia de Código — Entrega periódica à PRODEMGE de cópia do código-fonte e artefatos desenvolvidos no âmbito da parceria, garantindo continuidade de acesso ao conhecimento produzido. [Capítulo 58.]

Débito Técnico — Custo implícito resultante de decisões técnicas de curto prazo (workarounds, soluções não ideais) que precisarão ser resolvidas no futuro. Workarounds temporários são registrados como débito técnico ativo com prazo de resolução. [Capítulo 52.]

Errata — Documento oficial que corrige ou complementa o edital original. No contexto do Chamamento 001/2026, as erratas publicadas pela PRODEMGE têm força normativa equivalente ao edital. [Documentos 02_.]*

Esclarecimento — Resposta oficial da PRODEMGE a questões técnicas submetidas por potenciais parceiros durante o período de consultas do chamamento. Tem força interpretativa sobre o edital. [Documentos 02_.]*

Gestão de Configuração — Controle do estado de todos os componentes de software e infraestrutura ao longo do tempo, incluindo versionamento, rastreabilidade e governança de mudanças. [Capítulo 58.]

Gestão de Mudanças — Processo formal para avaliar, aprovar e implementar alterações em componentes da plataforma em produção, minimizando riscos de impacto negativo. [Capítulo 59.]

Indicadores de Desempenho (KPIs) — Métricas quantitativas que medem o desempenho da plataforma e da parceria em dimensões técnicas, operacionais e de negócio. [Capítulo 62.]

Matriz de Responsabilidades (RACI) — Documento que define, para cada atividade ou entrega, quem é Responsável, quem é Aprovador, quem deve ser Consultado e quem deve ser Informado. [Capítulo 61.]

Parceira — Empresa privada selecionada pelo Chamamento Público nº 001/2026 para a parceria tecnológica com a PRODEMGE no desenvolvimento e operação da plataforma.

Plano de Negócio Referencial (PNR) — Documento elaborado pela PRODEMGE (Anexo I do Chamamento) que define as diretrizes, requisitos de negócio e modelo esperado para a parceria. [Capítulo 63.]

Propriedade Intelectual — Direitos sobre criações intelectuais desenvolvidas no âmbito da parceria. Componentes desenvolvidos especificamente para a parceria constituem propriedade intelectual conjunta, com custódia na PRODEMGE. [Capítulo 58.]

Rastreabilidade — Capacidade de vincular cada decisão, componente ou entrega aos requisitos que a motivaram e às evidências de atendimento. Princípio central deste documento. [Capítulos 67, 68.]

Release Notes — Documentação de cada versão de software entregue, descrevendo funcionalidades incluídas, correções, mudanças de infraestrutura e procedimentos de deploy. [Capítulo 58.]

Roadmap — Planejamento de evolução tecnológica e funcional da plataforma ao longo do tempo, com marcos, dependências e critérios de sucesso. [Capítulo 54.]

---

68.14 Domínio: Siglas e Abreviações

A tabela a seguir consolida as siglas utilizadas ao longo deste documento para referência rápida:

---

68.15 Considerações Finais

Este Glossário Expandido é um documento vivo. Ao longo da parceria, novos termos serão incorporados à medida que componentes adicionais forem implantados e o vocabulário operacional for amadurecendo. A manutenção do glossário é responsabilidade conjunta da Parceira e da PRODEMGE, com revisão formal a cada ciclo de release maior.

A precisão terminológica documentada aqui não é um exercício formal: ela reduz o custo de comunicação entre equipes técnicas, jurídicas e de negócio, previne mal-entendidos durante a operação e constitui evidência de maturidade arquitetural da solução proposta.

---

68.16 Controle de Versão

---

68.17 Rastreabilidade PRODEMGE

Edital CP 001/2026:

• Item 3.1 — Definições do edital consolidadas e expandidas com contexto técnico da solução proposta.

Plano de Negócio (Anexo I):

• Seção 3.1 — Terminologia de arquitetura alinhada às definições do Plano de Negócio Referencial.

Funcionalidades (Anexo III):

• Todos os blocos — Termos funcionais (solicitação, protocolo, atendimento, cidadão, omnichannel, BPM, GED) definidos com precisão técnica compatível com os requisitos do Anexo III.

Capacidades (Anexo IV):

• Todos os itens — Termos de capacidades técnicas (multi-tenant, IAM, RAG, microsserviços, DevSecOps, Kubernetes) definidos com profundidade compatível com os critérios de avaliação do Anexo IV.

Sustentabilidade (Anexo V):

• Item 2.2 e 2.3 — Terminologia de LGPD, proteção de dados, minimização, anonimização e direitos do titular alinhada às exigências do Anexo V.

Esclarecimentos pertinentes:

• Montreal (02/07/2026) — Terminologia de multi-tenant e segregação lógica adotada conforme esclarecimento.
• Valtech (03/07/2026) — Definições técnicas de capacidades alinhadas às confirmações do esclarecimento.

Erratas:

• Errata nº 002 (10/07/2026) — Não aplicável a este capítulo.

---

68.18 Próximo Capítulo

O Capítulo 69 — Diagramas de Referência apresenta os diagramas arquiteturais canônicos da plataforma em notação C4, cobrindo as visões de contexto, contêineres e componentes dos principais subsistemas, complementando a descrição textual dos capítulos de arquitetura.