Documento Base para o Upgrade do Portal de Investimentos da Tempo
Base funcional, técnica e regulatória para 
concepção
, desenvolvimento e implementação
Controlo documental
Informação
Título
Documento Base para o Upgrade do Portal de Investimentos da Tempo
Versão
4.1 — versão documental final para materialização técnica
Data
20 de Setembro de 2026
Proprietário
Tempo, Lda.
Estado
Aprovado documentalmente; repositório e execução técnica pendentes; produção não aprovada
Fonte normativa técnica
Secção A.31 do Anexo A
Aprovadores requeridos
Comité Executivo; Arquitectura; Dados; Segurança; QA; Jurídico e Conformidade; Dono do Produto
Próxima decisão
Autorizar a Fase Zero, materializar o pacote normativo no repositório e executar a checklist Go/No-Go
Sumário executivo
O presente documento propõe o upgrade do Portal de Investimentos da Tempo para uma plataforma integrada de promoção, facilitação, transacção assistida e acompanhamento do investimento. A solução deverá divulgar oportunidades públicas e privadas, qualificar investidores, gerir manifestações de interesse, aproximar compradores e vendedores de negócios existentes e acompanhar cada oportunidade no CRM. O desenho integra a carteira do PII 2026–2030, clusters, corredores, projectos âncora, oportunidades educativas, identidade digital básica, painel do investidor, GIS, acompanhamento institucional, pós-investimento e IA explicável. A implementação deverá iniciar pela Fase Zero e por um MVP controlado, mantendo para fases posteriores a assinatura electrónica qualificada, as integrações transaccionais externas, a comparação avançada, a automação e os modelos preditivos. A aprovação do documento autoriza a preparação técnica, mas o início da construção permanece condicionado ao cumprimento dos critérios Go/No-Go, à constituição da equipa, à validação dos dados, à aprovação da arquitectura e à confirmação da carteira piloto.
Versão executiva para aprovação
Decisão solicitada:
 aprovar o documento como linha de base funcional, técnica e regulatória do upgrade do InvestMoz; autorizar a Fase Zero; confirmar a arquitectura React, Laravel e PostgreSQL/PostGIS; nomear a governação e a equipa; validar a carteira piloto; e autorizar a preparação detalhada do MVP.
Dimensão
Decisão executiva proposta
Objectivo
Evoluir o portal informativo para uma plataforma integrada de promoção, facilitação, transacção assistida e acompanhamento do investimento.
Arquitectura funcional
Unificar oportunidades, PII, negócios existentes, clusters, corredores, competências, educação, CRM, GIS, identidade, painel do investidor, pós-investimento e IA supervisionada.
Arquitectura tecnológica
Manter e actualizar React e Laravel; substituir MySQL por PostgreSQL/PostGIS através de migração incremental, reconciliável e reversível.
Fase Zero
Executar em quatro a seis semanas melhorias imediatas de pesquisa, conteúdos, PT/EN, formulários, CRM, acessibilidade, segurança, analítica e prova de conceito tecnológica.
MVP
Entregar catálogo, pesquisa, fichas, CRM, identidade básica, painel, três clusters, três corredores, oportunidades educativas, GIS, acompanhamento institucional e pós-investimento assistido, indicadores e IA explicável.
Fora do MVP
Integrações transaccionais universais, assinatura qualificada generalizada, matching autónomo, decisão automática, modelos preditivos vinculativos, gestão académica e certificação.
Governação
Instituir patrocinador, Dono do Produto, Comité Executivo, Comité de Arquitectura, Comité de IA e Dados, coordenadores, Secretariado de Dados e responsáveis institucionais.
Aprovação condicionada
O início da construção depende do cumprimento da checklist Go/No-Go, aprovação do orçamento, equipa, dados, segurança, arquitectura, carteira piloto e acordos institucionais aplicáveis.
Relatório final de inconsistências corrigidas
Área revista
Inconsistência corrigida
Estado final
Estrutura e numeração
Foram eliminados títulos vazios, espaços artificiais, duplicações de numeração e referências cruzadas desactualizadas.
Sequência principal 1–15 e subseções coerentes.
Requisitos
RF-CLU foram consolidados; RF-COR, RF-EII, RF-EDU, RF-CRM, RF-MON, RF-MIN, RF-AGR e RF-GEO foram reconciliados com as matrizes de rastreabilidade.
Sem referências claramente órfãs; o repositório técnico deverá manter unicidade global.
Escopo do MVP
O sumário foi alinhado ao desenho aprovado: balcão único, identidade, pós-investimento e IA entram no MVP em modo básico, assistido ou explicável.
Funcionalidades avançadas permanecem nas fases posteriores.
Clusters e corredores
Foi formalizada a relação território → corredor → projecto âncora → cluster → cadeia de valor → projecto complementar → investidor.
Arquitectura reflectida em requisitos, indicadores, MVP e roadmaps.
Experiência do investidor
Identidade, perfil, painel, documentos, CRM, procedimentos e pós-investimento foram reunidos numa jornada única.
MVP integrado e critérios de aceite definidos.
Formação técnica
Necessidades de competências foram transformadas em oportunidades de investimento educativo ligadas aos corredores e projectos.
RF-EDU, matriz, testes, indicadores e plano consolidados.
Tecnologia e dados
Foi resolvida a ambiguidade entre continuidade do legado e arquitectura alvo.
React e Laravel mantidos; MySQL substituído por PostgreSQL/PostGIS através de plano controlado.
Transição
Foram criadas matriz Conservar/Melhorar/Substituir/Descontinuar, Fase Zero, ondas de migração, reconciliação, corte e rollback.
Plano executável e critérios de entrega definidos.
Dados ilustrativos
Metas, pontuações, custos, capacidades e endpoints conceptuais foram separados de dados confirmados.
Fonte, data e estado de validação são obrigatórios 
antes de publicação ou uso como linha de base.
Índice e navegação
O índice foi restaurado e actualizado após as alterações estruturais.
Títulos dos níveis 1–4 incluídos e marcados para actualização.
Checklist de qualidade da versão final
Dimensão
Resultado da validação
Condição remanescente
Completude
Aprovada: visão, requisitos, dados, tecnologia, MVP, Fase Zero, migração, testes, indicadores e operação estão cobertos.
Confirmar anexos técnicos e artefactos no repositório do projecto.
Coerência
Aprovada: o sumário, o MVP e as fases foram alinhados.
Alterações futuras devem passar por controlo de versão.
Rastreabilidade
Aprovada: capacidades estão relacionadas com requisitos, dados, testes, épicos e fases.
Manter matriz actualizada em cada release.
Testabilidade
Aprovada: existem critérios de aceitação e testes positivos, negativos, de autorização, integração, recuperação e acessibilidade.
Converter os critérios em casos automatizados e evidências de execução.
Segurança e privacidade
Aprovada como especificação: MFA, consentimento, privilégios, auditoria, retenção, cifragem, recuperação e segregação estão contemplados.
Executar avaliação técnica, testes de segurança e validação jurídica.
Acessibilidade
Aprovada como requisito obrigatório da Fase Zero e do MVP.
Realizar testes com ferramentas e utilizadores.
Dados e GIS
Aprovada: fontes, qualidade, geometrias, permissões, reconciliação e PostgreSQL/PostGIS foram definidos.
Validar dados oficiais, sistemas de referência e responsáveis.
IA responsável
Aprovada: finalidade, explicação, confiança, supervisão humana, contestação, auditoria e suspensão estão previstas.
Validar datasets, métricas, modelos e limites antes da activação.
Operação
Aprovada: suporte, SLA, monitoria, contingência, formação, helpdesk e governação estão definidos.
Nomear equipa, aprovar orçamento e executar simulação operacional.
Aprovação
Documento pronto para decisão executiva condicionada.
Obter assinaturas, acta, orçamento, RACI, carteira piloto e autorizações institucionais.
Recomendação executiva:
 aprovar o documento como linha de base do programa e autorizar imediatamente a Fase Zero e a preparação técnica do MVP. A autorização para iniciar a construção deverá ser emitida apenas após evidência do cumprimento dos critérios Go/No-Go e das pendências externas registadas.
Relatório histórico de validação técnica do Anexo A
Área
Estado
Inconsistência principal
Acção necessária
SQL e ordem de execução
Não aprovado
A função set_updated_at() é usada antes da criação; o DDL não possui estratégia uniforme de reexecução; o rollback usa CASCADE e remove extensões partilháveis.
Mover a função para 001_extensions.sql; adoptar migrations versionadas e rollback inverso não destrutivo.
Integridade e geografia
Aprovação condicionada
Unicidades não tratam NULL/soft delete; geometrias não validam tipo, SRID, vazio e ST_IsValid; faltam controlos monetários e alguns índices de FK.
Criar índices parciais, CHECKs geoespaciais e monetários e matriz de índices por consulta.
Modelo relacional
Aprovação condicionada
Contacto–investidor está modelado como 1:N; documentos usam relação polimórfica sem FK; tabelas append-only recebem campos e triggers mutáveis.
Criar associações N:N tipadas, reforçar integridade documental e separar tabelas imutáveis.
Backlog TECH-001–036
Não aprovado
As secções A.19 e A.28 contêm versões incompatíveis; AUTO-* foi usado como dependência TECH; prioridades Could incluem artefactos essenciais.
Eleger A.28 como fonte normativa, regenerar uma única versão e recalibrar dependências e prioridades.
Rastreabilidade
Não aprovado
Existem RF genéricos, endpoints/telas artificiais e pacotes AUTO excessivamente agregados.
Gerar uma linha por TECH com RF existente, entidade, endpoint/evento, tela, teste e pacote AUTO específicos.
Prompts Codex
Aprovação condicionada
Há duas bibliotecas duplicadas; o prompt mestre exige 01–11 mesmo quando desnecessários; comandos ainda não são confirmados pelo repositório.
Manter uma biblioteca normativa, seleccionar prompts por âmbito e resolver comandos a partir do projecto real.
Manifesto e caminhos
Não aprovado
Divergem database/ e database/sql/, projects.json/projects.schema.json e 00-plan.md/00-master.md; checksums.sha256 não aparece na árvore normativa.
Normalizar árvore, nomes, manifesto, README e regras de checksum.
Consistência geral
Confirmada
Sequências TECH, E1–E9 e AUTO-01–12 estão completas; não foram detectados ciclos TECH explícitos.
Preservar a numeração e aplicar as correcções antes da transposição para o repositório.
Resultado actualizado:
 a secção A.31 resolveu documentalmente os quatro bloqueios críticos e constitui a única fonte normativa do pacote técnico. A especificação está aprovada para transposição ao repositório, mas ainda não está aprovada para execução em produção. Permanecem pendentes a criação física dos ficheiros, o lint de SQL, YAML, JSON e CSV, a validação do ERD, os testes de contrato, os ensaios de migração e rollback, o cálculo de checksums e a revisão conjunta por Arquitectura, Dados, Segurança, QA e Dono do Produto. A promoção para pré-produção depende dessas evidências; a produção depende de decisão formal de Go/No-Go.
Validação da secção A.31 e prontidão para importação
Verificação
Fonte normativa
Estado
Acção para importação
Precedência
A.31 substitui A.5 e A.16–A.30 para implementação.
Aprovado documentalmente
Transpor exclusivamente os artefactos e regras de A.31.
Índice automático
Índice de níveis 1–4 entre as quebras de página.
Restaurado; actualização solicitada
Actualizar campos no ficheiro final antes da distribuição.
Caminhos
manifest/project.yaml; checksums.sha256; database/sql/; imports/schemas/projects.schema.json; codex/prompts/00-master.md.
Aprovado documentalmente
Criar a árvore física exactamente com os caminhos normativos.
SQL e rollback
001_extensions.sql cria extensões e set_updated_at() antes dos triggers; rollback 
sem CASCADE e sem remoção de extensões.
Aprovado documentalmente
Executar lint, migration dry-run e rollback dry-run em development/test.
Backlog
backlog/backlog.csv, TECH-001–TECH-036, E1–E9 e AUTO-01–AUTO-12.
Aprovado documentalmente
Materializar o CSV, validar dependências e importar na ferramenta de gestão.
Prompts Codex
00-master.md e 01-schema-postgres.md a 11-gis.md.
Aprovado documentalmente
Criar os ficheiros, confirmar comandos do repositório e executar apenas em branch própria.
Rastreabilidade
RF → TECH → ficheiro → teste → pacote AUTO.
Aprovado documentalmente
Gerar traceability.csv e reconciliar todos os IDs antes do primeiro PR.
Repositório
Artefactos físicos, versões e checksums.
Pendente
Criar ficheiros, calcular SHA-256, validar formatos e abrir PR.
Development/Test
Lint, ERD, contract tests, migração, rollback, segurança e UAT.
Pendente condicionado
Executar a checklist A.31.5 e anexar evidências.
Staging
Testes integrados e aprovações.
Pendente
Promover apenas após aceite de Arquitectura, Dados, Segurança, QA e Produto.
Produção
Decisão formal Go/No-Go.
Não aprovada
Bloquear deploy até aprovação executiva e técnica.
Sequência de materialização:
 1) criar a árvore normativa; 2) copiar exclusivamente os blocos de A.31; 3) validar SQL, YAML, JSON, CSV, OpenAPI, AsyncAPI e Mermaid; 4) calcular e registar SHA-256; 5) confirmar a rastreabilidade RF–TECH–ficheiro–teste–AUTO; 6) executar as migrações e a reversão em ambiente de desenvolvimento e teste; 7) executar testes de contrato, segurança, acessibilidade e aceitação pelo utilizador; 8) abrir o pedido de integração com evidências; 9) obter as aprovações; 10) promover para o ambiente de pré-produção. Nenhum artefacto histórico de A.5 ou A.16–A.30 deve ser importado ou executado.
​
​
​
​
​
Documento Base para o Upgrade do Portal de Investimentos da Tempo
1
Sumário executivo
1
Versão executiva para aprovação
1
Relatório final de inconsistências corrigidas
2
Checklist de qualidade da versão final
3
Relatório histórico de validação técnica do Anexo A
3
Validação da secção A.31 e prontidão para importação
4
1. Enquadramento e finalidade
12
2. Objectivos estratégicos
12
3. Princípios orientadores
12
3.1. Aproveitamento estratégico do conteúdo do portal InvestMoz
13
3.2. Jornada de descoberta e conversão
14
3.3. Rede de fornecedores e conteúdo local
14
3.4. Conteúdos de confiança e prova de investimento
14
3.5. Benchmark internacional e implicações para o InvestMoz
15
4. Módulos funcionais prioritários
15
4.1. Balcão único digital orientado por eventos
15
4.2. Módulo de clusters económicos
16
4.2.1. Requisitos funcionais do módulo de clusters
16
4.2.2. Matriz de priorização dos clusters para o portal
17
4.2.3. MVP do módulo de clusters
19
4.2.4. Indicadores dos clusters
20
4.2.5. Modelo de governação dos clusters
20
4.2.6. Roteiro de implementação do módulo de clusters
21
4.3. Módulo de Corredores de Desenvolvimento
22
4.3.1. Arquitectura funcional dos corredores
22
4.3.2. Requisitos funcionais dos Corredores de Desenvolvimento
22
4.3.3. Inteligência artificial para monitoria e aconselhamento
24
4.3.4. Matriz dos corredores prioritários
25
4.3.5. Indicadores e modelo de governação
25
4.3.6. Roteiro dos Corredores de Desenvolvimento
26
4.3.7. Zonas Económicas Especiais, Zonas Francas Industriais e parques industriais
27
4.3.7.1. Requisitos funcionais para ZEE e ZFI
28
4.3.7.2. Auditoria legal e referências dos RF-ZON
34
4.3.7.4. Lacunas e riscos jurídicos
37
4.3.7.3. Matriz de responsabilidades para ZEE, ZFI e parques industriais
41
4.3.7.5. Coerência transversal e condições de implementação
43
4.4. Módulo Experiência Integrada do Investidor
45
4.4.1. Arquitectura da jornada única
45
4.4.2. Requisitos funcionais da Experiência Integrada do Investidor
45
4.4.3. Indicadores da jornada única
47
4.4.4. MVP integrado da Experiência do Investidor
47
4.4.5. Implementação faseada
48
4.5. Consolidação final do modelo de clusters, corredores e experiência do investidor
48
4.5.1. Navegação integrada e perguntas de decisão
49
4.5.2. Matriz consolidada dos clusters recomendados
49
4.5.3. Página padrão, índice de prontidão e ciclo do cluster
50
4.5.4. Critérios Go/No-Go consolidados e rastreabilidade
50
4.5.5. Modelo físico integrado, backlog único e plano de execução
52
4.6. Formação Técnica, Competências e Investimento em Educação
53
4.6.1. Requisitos funcionais
53
4.6.2. Matriz inicial de necessidades de competências
55
4.6.3. MVP de competências e investimento em educação
55
4.6.4. Indicadores
56
4.6.5. Roadmap de implementação
57
4.6.6. Matriz completa de competências e oportunidades educativas
57
4.6.7. Testes de aceitação dos requisitos RF-EDU
61
4.6.8. Plano de execução consolidado do submódulo
62
4.7. Baseline final para implementação do MVP
64
4.7.1. Alterações finais e secções afectadas
64
4.7.2. Escopo fechado do MVP
64
4.7.3. Checklist final Go/No-Go
65
4.7.4. Plano de arranque do MVP — primeiros 30 dias
65
4.8. Transição do portal existente para a arquitectura alvo
66
4.8.1. Matriz de transição entre legado e arquitectura alvo
66
4.8.2. Estratégia de upgrade MySQL → PostgreSQL/PostGIS
67
4.8.3. Fase Zero — melhorias imediatas na versão existente
68
4.8.4. Matriz de rastreabilidade do legado para o MVP
69
4.8.5. Matriz completa de transição tecnológica e funcional
70
4.8.6. Critérios detalhados de entrega da Fase Zero
72
4.8.7. Plano de migração MySQL para PostgreSQL/PostGIS
73
5. Mercado de negócios existentes
75
5.1. Modalidades de manifestação de interesse
75
5.2. Requisitos funcionais
76
5.2.1. Formulário de oferta de negócio ou captação de investimento
76
5.2.2. Formulário de procura de negócio ou oportunidade de investimento
77
5.2.3. Matriz detalhada de campos e validações
77
5.3. Estados, notificações e regras de aprovação
80
5.4. Fluxo de correspondência entre investidores e negócios
82
5.5. Acompanhamento pós-investimento e gestão de constrangimentos
83
5.6. Requisitos funcionais para desenvolvimento
83
5.7. Requisitos legais, confidencialidade e diligência
85
5.8. Requisitos funcionais para investimentos agrícolas e fundiários
86
5.9. Campos e critérios de validação para investimentos mineiros
87
5.9.1. Documentos obrigatórios e controlos dos campos MIN
88
5.10. Módulo de monetização, facturação e controlo de comissões
90
5.10.1. Especificação detalhada dos requisitos RF-MON
91
5.10.2. Fluxo de facturação e comissões
93
6. Carteira de investimentos do PII 2026–2030
94
6.1. Matriz inicial de projectos âncora para promoção
94
6.2. Registo geográfico consolidado dos projectos
96
6.3. Inserção de novos projectos públicos e privados por localização
99
6.4. Validação institucional, coordenadas e mapas
99
6.5. Requisitos funcionais de georreferenciação
100
6.6. Fichas editoriais dos 15 projectos âncora
101
6.7. Modelo de ficha e catálogo
104
6.8. Campos para importação da matriz PII
104
6.9. Estratégia de promoção e angariação
105
6.10. Plano de campanhas e captação de investidores
105
6.11. Governação e calendário comercial
107
6.12. Fluxo de captação e encaminhamento
108
6.13. Requisitos funcionais específicos
108
7. Jornada digital do investidor
110
8. CRM, automação e inteligência artificial
110
9. Estratégia de conversão e funil de captação no CRM
110
9.1. Estratégia de conversão de visitantes em investidores
110
9.2. Perfis de investidores e campanhas segmentadas
111
9.3. Pontuação e qualificação do investidor
112
9.4. Funil de captação no CRM
113
9.5. Automações e notificações
114
9.6. Indicadores de aquisição, conversão e investimento
114
9.7. Requisitos funcionais do CRM de captação
115
9.8. Especificação detalhada dos requisitos funcionais do CRM
116
9.9. Matriz de campanhas segmentadas e orçamento indicativo
118
9.10. Modelo de dados do investidor, lead e oportunidade
120
9.11. Regras de conversão, cardinalidade e integridade
123
9.12. Diagrama das entidades e relações do CRM
123
9.13. Histórias de utilizador e backlog do CRM
124
9.14. Backlog priorizado e releases
125
9.15. Plano de implementação do CRM por fases
126
9.16. Modelo técnico de tabelas do CRM
127
9.17. Modelo técnico de APIs do CRM
129
9.18. Especificação OpenAPI 3.1 do CRM
130
9.19. Roadmap executivo do CRM: custos, riscos e dependências
133
10. Integrações e entidades de referência
136
11. Conformidade legal, regulatória e editorial
136
12. Requisitos não funcionais
136
13. Indicadores de sucesso
137
14. Roteiro de implementação
137
15. Próximas decisões
138
Anexo A — Anexo Técnico — Pacote de Automação do Upgrade
139
A.1 Finalidade, princípios e limites da automação
139
A.2 Arquitectura alvo unificada
139
A.2.1 Dependências e fluxo
139
A.3 Modelo de dados unificado
140
A.3.1 Regras transversais
140
A.4 Mapa de relações ponta-a-ponta
140
A.5 Scripts-base
141
A.5.1 Extensões PostgreSQL — modelo inicial — adaptar e rever
141
A.5.2 DDL inicial — modelo inicial — adaptar e rever
141
A.5.3 Migration Laravel — modelo inicial — adaptar e rever
141
A.5.4 Migração MySQL→PostgreSQL por lotes — modelo inicial — adaptar e rever
141
A.5.5 docker-compose mínimo — modelo inicial — adaptar e rever
141
A.5.6 Variáveis .env — modelo inicial — adaptar e rever
142
A.6 Backend Laravel
142
A.6.1 Estrutura de pastas sugerida
142
A.7 Frontend React/TypeScript
142
A.8 Contratos API e eventos
143
A.8.1 Eventos de domínio
143
A.9 Automação com Codex
143
A.9.1 Workflow em 10 passos
143
A.9.2 Prompt-base reutilizável
144
A.9.3 Matriz de autonomia
144
A.10 Estratégia de migração e importação
144
A.10.1 Cabeçalhos mínimos de importação
144
A.11 Testes e qualidade
145
A.11.1 Definition of Ready
145
A.11.2 Definition of Done
145
A.12 CI/CD e ambientes
145
A.13 Plano de execução importável
145
A.14 Checklist para iniciar Codex
146
A.15 Artefactos finais esperados
146
A.16 Pacote de ficheiros pronto para importação
147
Convenções de intercâmbio e controlo
148
manifest/project.yaml — modelo inicial — adaptar e rever
148
A.17 Modelo físico de dados detalhado
148
Cardinalidades e comportamento de eliminação
152
docs/erd.mmd — Mermaid ER importável
152
A.18 Ficheiros de importação canónicos
153
imports/schemas/projects.json — JSON Schema resumido
153
A.19 Backlog técnico importável
153
Cabeçalho exacto e linha de exemplo — backlog/backlog.csv
158
A.20 Matriz de rastreabilidade técnica
158
A.21 Biblioteca de prompts do Codex
159
Prompt mestre
159
A.22 Ordem de execução e importação
159
A.23 Checklist de entrega do pacote
160
A.24 Estrutura exacta do pacote de importação
160
A.25 Modelo físico executável — núcleo
161
A.26 Modelo físico executável — identidade, CRM, jornada, pós-investimento e educação
161
A.28 Backlog técnico CSV
161
A.30 Modelos CSV/JSON/YAML prontos para importação
162
Como materializar os ficheiros
162
A.31. Pacote técnico normativo aprovado
162
A.31.1. Precedência e caminhos normativos
162
A.31.2. SQL normativo e rollback
162
A.31.3. Backlog normativo
163
A.31.4. Prompts Codex normativos
163
A.31.5. Checklist de validação com evidências
163
A.31.6. Estado de aprovação
164
​
​
​
​
​
1. Enquadramento e finalidade
A evolução do portal deve ser orientada por métricas de produto e experiências controladas. O painel deverá medir aquisição, activação, pesquisa, comparação, pedidos de dossier, qualificação, reuniões, diligência, propostas, investimento confirmado, tempo por etapa, abandono de formulários, pesquisa sem resultados, satisfação e utilização pós-investimento. Alterações de jornada, conteúdo, formulário ou campanha devem possuir hipótese, indicador, período de teste, segmento, resultado e decisão. Nenhum teste pode reduzir transparência, consentimento, segurança ou igualdade de tratamento.
Antes da construção dos novos módulos, deverá ser concluída a Fase Zero definida nas secções 4.8.3 e 4.8.6, que concentra as melhorias imediatas da versão existente e os respectivos critérios de entrega. Esta etapa não depende de integrações institucionais ainda não confirmadas.
O presente documento estabelece a base para o upgrade do Portal de Investimentos da Tempo, transformando-o numa plataforma digital integrada de informação, orientação, captação e acompanhamento do investidor. A solução deverá combinar conteúdos fiáveis, jornadas digitais simples, gestão de relacionamento, automação assistida por inteligência artificial e integração progressiva com entidades públicas e privadas, sem apresentar como oficiais serviços ou ligações ainda não formalmente validados.
A implementação deverá partir de um diagnóstico técnico e funcional da versão actual do portal, identificando componentes reutilizáveis, dívida técnica, limitações de conteúdo, integrações existentes, qualidade dos dados, desempenho, segurança, acessibilidade e cobertura dos fluxos. Esse diagnóstico deverá produzir uma matriz 
Conservar, Melhorar, Substituir ou Descontinuar
, evitando a reconstrução de funcionalidades estáveis e preservando os investimentos já realizados.
2. Objectivos estratégicos
Centralizar informação sobre oportunidades, sectores, legislação, incentivos, procedimentos e entidades relevantes.
Orientar o investidor desde a manifestação de interesse até à instalação, operação e expansão do investimento.
Reduzir incerteza, burocracia informacional e tempo de resposta.
Disponibilizar à Tempo instrumentos de CRM, monitoria, análise de procura e gestão de oportunidades.
Preparar a plataforma para integrações transaccionais, mediante acordos institucionais, segurança e validação jurídica.
3. Princípios orientadores
Foco no investidor:
 linguagem clara, percursos simples e informação segmentada por perfil, sector e fase do investimento.
Conformidade por desenho:
 conteúdos e fluxos sujeitos a validação jurídica, institucional e editorial.
Digital primeiro:
 formulários, notificações, agendamentos, acompanhamento e autosserviço acessíveis em computador e dispositivo móvel.
Interoperabilidade:
 arquitectura preparada para APIs, autenticação segura e intercâmbio controlado de dados.
Transparência:
 indicação da fonte, data de actualização, entidade responsável e carácter orientador de cada informação.
3.1. Aproveitamento estratégico do conteúdo do portal InvestMoz
O upgrade deverá preservar, avaliar e aprofundar os cinco eixos informativos já apresentados no portal InvestMoz — “Porquê investir em Moçambique”, “Actividades económicas”, “Oportunidades de negócios”, “Áreas de investimento” e “Reguladores” — convertendo-os progressivamente de páginas predominantemente informativas numa jornada orientada à decisão e à conversão. Antes de substituir qualquer componente, a equipa deverá confirmar o seu uso, qualidade, dependências e possibilidade de reutilização. Cada conteúdo deverá conduzir o visitante da compreensão do mercado para a selecção de uma oportunidade, consulta de requisitos, manifestação de interesse e acompanhamento no CRM.
Eixo do portal
Conteúdo enriquecido
Mecanismos para atrair investimento
Chamada para acção
Porquê investir em Moçambique
Proposta de valor do país organizada por acesso a mercados, localização regional, recursos, corredores logísticos, base produtiva, capital humano, energia, zonas económicas, estabilidade institucional e oportunidades de transformação. Cada argumento deve ter fonte, data e contexto.
Páginas comparáveis por sector e região; dados visuais; histórias de investimento; perguntas frequentes; conteúdos em português e inglês; dossiers por perfil de investidor.
Explorar sectores; comparar regiões; descarregar dossier; solicitar reunião.
Actividades económicas
Perfis sectoriais com dimensão do mercado, cadeias de valor, procura, oferta, exportações, importações, infra-estruturas, competências, lacunas, riscos, projectos, empresas e instituições relevantes.
Mapa de cadeias de valor; filtros por actividade e localização; identificação de fornecedores, compradores e projectos complementares; alertas sectoriais.
Seleccionar actividade; ver oportunidades; registar perfil sectorial; propor projecto.
Oportunidades de negócios
Catálogo de projectos públicos, privados, PPP, concessões, fornecimento, empresas à venda, procura de capital, activos e parcerias, com maturidade, valor, localização, modalidade, promotor e documentação.
Pesquisa, comparação, favoritos, recomendação, correspondência com perfil, manifestações de interesse, reuniões e sala segura.
Manifestar interesse; solicitar dossier; apresentar capacidade; agendar reunião.
Áreas de investimento
Leitura territorial por província, distrito, corredor, ZEE, parque industrial, zona turística e bacia, combinando projectos, recursos, infra-estruturas, serviços, incentivos, riscos e contactos.
Mapa interactivo autorizado; páginas territoriais; agrupamento de oportunidades; campanhas regionais; comparação entre locais; associação de novos projectos públicos e privados.
Escolher local; ver projectos; propor investimento no território; contactar o ponto focal.
Reguladores
Directório por sector e processo, com competências, serviços, licenças, formulários, requisitos, prazos indicativos, taxas 
validadas, contactos e ligações oficiais.
Roteiro regulatório personalizado; checklist por projecto; encaminhamento para entidade competente; 
alertas de alteração; histórico da fonte.
Consultar requisitos; gerar checklist; pedir orientação; iniciar contacto oficial.
3.2. Jornada de descoberta e conversão
Descobrir:
 o utilizador conhece as razões para investir e escolhe sector, actividade, território ou tipo de oportunidade.
Explorar:
 consulta perfil económico, cadeia de valor, infra-estruturas, projectos, reguladores, riscos e documentos.
Comparar:
 coloca lado a lado projectos, províncias, modalidades, valores, maturidade e requisitos.
Preparar:
 recebe checklist, dossier, documentos, entidades e questões necessárias para avançar.
Manifestar interesse:
 selecciona investir, financiar, comprar, fornecer, operar, estabelecer parceria ou apresentar novo projecto.
Qualificar:
 o portal recolhe perfil, capacidade, experiência, horizonte, localização e origem do interesse.
Encaminhar:
 a Tempo revê o pedido, obtém autorizações e liga o investidor ao promotor ou regulador competente.
Acompanhar:
 o CRM mantém tarefas, reuniões, respostas, pendências, proposta, negociação e resultado.
3.3. Rede de fornecedores e conteúdo local
A plataforma deve manter um directório verificado de fornecedores locais, prestadores de serviços, operadores logísticos, consultores, instituições financeiras, centros de formação e parceiros tecnológicos. Cada projecto poderá publicar necessidades de aquisição e competências, enquanto fornecedores poderão apresentar capacidade, certificações, cobertura territorial e referências. O sistema deverá recomendar ligações entre investidores e fornecedores, medir contratos locais, emprego, formação e transferência de tecnologia e impedir que a recomendação seja apresentada como certificação ou garantia da Tempo.
3.4. Conteúdos de confiança e prova de investimento
Cada página deve mostrar fonte, data de actualização, proprietário do conteúdo, idioma e estado de validação.
Dados económicos, incentivos, licenças, taxas e prazos devem distinguir valor oficial, estimativa, referência histórica e informação pendente.
Perfis sectoriais devem conter oportunidades imediatas, projectos em preparação, lacunas de mercado, fornecedores procurados e compradores potenciais.
Casos de investimento devem apresentar problema, solução, capital mobilizado, emprego, conteúdo local e lições, apenas com autorização.
O portal deve publicar agendas de concursos, fóruns, missões, feiras e janelas de financiamento associadas às oportunidades.
Conteúdo editorial da Revista Tempo deve ser relacionado a sectores e projectos, conduzindo o leitor para a ficha de oportunidade correspondente.
Boletins personalizados devem permitir subscrição por actividade, local, valor, modalidade e fase de investimento.
O portal deve apresentar avisos claros sobre riscos, diligência necessária e papel de facilitação da Tempo.
3.5. Benchmark internacional e implicações para o InvestMoz
A análise de plataformas de promoção de investimento indica quatro modelos complementares. A Invest India e a India Investment Grid combinam inteligência sectorial, projectos pesquisáveis, manifestação de interesse, ligação a promotores, avaliação de localização e acompanhamento do investidor. A Invest Saudi integra promoção, oportunidades, registo do investidor, serviços electrónicos, incentivos e assistência antes, durante e depois da instalação. O Rwanda Development Board articula balcão único, registo do investimento, licenciamento, avaliação ambiental, procedimentos empresariais e acompanhamento pós-investimento com resolução de constrangimentos. A Estónia demonstra o valor da identidade digital, assinatura electrónica, constituição remota de empresas e acesso integrado a serviços públicos. Para alcançar um nível comparável, o InvestMoz deve combinar promoção, transacção assistida, identidade digital, interoperabilidade, acompanhamento pós-investimento e inteligência de mercado numa única experiência.
4. Módulos funcionais prioritários
Módulo
Função principal
Resultado esperado
Portal de oportunidades
Divulgar projectos, sectores, localização, dimensão e contactos.
Maior visibilidade e captação de investidores.
Jornada do investidor
Apresentar requisitos, documentos, etapas, prazos e entidades por tipo de investimento.
Orientação consistente e redução de dúvidas.
CRM do investidor
Registar contactos, interesses, interacções, tarefas, documentos e estado de cada oportunidade.
Seguimento integral e responsabilização.
Assistente de IA
Responder, classificar pedidos, recomendar conteúdos e apoiar o encaminhamento.
Atendimento mais rápido, sem substituir decisão oficial.
Agenda e helpdesk
Gerir pedidos, reuniões, tickets, prioridades e níveis de serviço.
Suporte mensurável e rastreável.
Centro legal e documental
Disponibilizar legislação, guias, formulários, fontes e histórico de actualizações.
Informação fiável e auditável.
Painel de monitoria
Apresentar procura, conversão, tempos de resposta, sectores e origem dos investidores.
Decisão baseada em dados.
Inteligência de mercado e conteúdo
Integrar as áreas “Porquê investir”, actividades económicas, áreas de investimento e reguladores com perfis sectoriais, territoriais e regulatórios administráveis.
Conteúdo actualizado que conduz directamente à descoberta, qualificação e conversão de investidores.
Mercado de negócios existentes
Publicar intenções de venda, procura de compradores, captação de investimento e procura de participação em empresas em funcionamento.
Aproximação estruturada entre proprietários, compradores e investidores.
Carteira PII 2026–2030
Publicar, promover e gerir projectos da matriz estatal de investimentos, com campanhas e mecanismos de captação de investidores.
Transformação da carteira pública em oportunidades estruturadas, pesquisáveis e acompanhadas.
4.1. Balcão único digital orientado por eventos
O portal deve disponibilizar um balcão único digital que apresente ao investidor um plano personalizado de instalação, com procedimentos, documentos, entidades, dependências, custos validados, prazos indicativos e estado de cada pedido. O investidor deve preencher 
os dados comuns uma única vez, autorizar a sua reutilização e acompanhar o processo num painel consolidado. A arquitectura deve adoptar APIs, webhooks e eventos de domínio para receber alterações dos sistemas das entidades competentes, evitando sincronizações manuais e pedidos repetidos de informação.
Decisão tecnológica:
 a arquitectura alvo manterá React no frontend e Laravel no backend, após actualização das versões, dependências, segurança, modularidade, desempenho e cobertura de testes. O PostgreSQL/PostGIS será a base de dados definitiva da nova versão, devido aos requisitos de corredores, polígonos, áreas de influência, proximidade, intersecções, inteligência territorial e relações geoespaciais. O MySQL permanecerá temporariamente como fonte legada durante a migração e não receberá novos domínios funcionais. A transição deverá ser incremental, reconciliável e reversível, com ensaios, critérios de corte, rollback, validação de integridade e desactivação formal das dependências antigas.
As integrações com APIEX, Autoridade Tributária, Banco de Moçambique, Registo Comercial e outras entidades deverão ser tratadas como hipóteses de integração até à confirmação formal de disponibilidade, proprietário, ambiente, autenticação, contrato, campos, estados, SLA, base legal e suporte. O MVP deverá manter alternativas assistidas e registo manual reconciliável para qualquer serviço cuja integração não esteja contratual e tecnicamente habilitada.
4.2. Módulo de clusters económicos
O módulo de clusters deverá organizar oportunidades, projectos, empresas, fornecedores, compradores, financiadores, competências, infra-estruturas, reguladores e territórios em ecossistemas económicos coerentes. A sua finalidade é orientar o investidor para os elos da cadeia de valor e os locais onde o investimento apresenta maior complementaridade, procura, capacidade instalada e impacto potencial. O cluster não substitui a ficha individual do projecto: funciona como camada transversal de inteligência, coordenação, promoção e monitoria.
A coexistência temporária entre o MySQL legado e o PostgreSQL/PostGIS deverá seguir a camada de compatibilidade, as regras de precedência, os controlos de reconciliação, o corte e o rollback definidos nas secções 4.8.2 e 4.8.7. Fora desse plano, nenhum módulo poderá escrever ou reconciliar directamente dados nas duas bases.
4.2.1. Requisitos funcionais do módulo de clusters
ID
Requisito funcional consolidado
Critério de aceitação
Prioridade
RF-CLU-001
Administrar clusters, subclusters, cadeias de valor, taxonomias e versões.
Cada cluster possui código, visão, âmbito territorial, sectores, elos, estado, responsável, fonte, validade e histórico; alterações são aprovadas e auditadas.
MVP
RF-CLU-002
Relacionar o cluster com projectos, oportunidades, actores e territórios.
As relações com projectos, negócios, empresas âncora, PME, fornecedores, compradores, financiadores, reguladores e instituições indicam papel, prioridade, período e estado, sem duplicar os registos de origem e com navegação nos dois sentidos.
MVP
RF-CLU-003
Representar a cadeia de valor e identificar lacunas de investimento.
O cluster apresenta fornecimento, produção, transformação, logística, comercialização, serviços e mercados; cada lacuna possui localização, capacidade necessária, justificação, estado e chamada para acção.
MVP
RF-CLU-004
Disponibilizar inteligência territorial e comparação multicritério.
Mapas autorizados mostram projectos, recursos, infra-estruturas, actores e riscos por unidade territorial; comparações usam critérios, período, fonte e limitações uniformes e não constituem garantia.
MVP para visualização; Fase 2 para comparação
RF-CLU-005
Gerir necessidades de financiamento e correspondência com financiadores.
A necessidade contém elo, fase, instrumento, valor, moeda, beneficiário, finalidade e elegibilidade; o CRM regista correspondências explicáveis e sujeitas a revisão humana.
MVP para cadastro; Fase 2 para correspondência
RF-CLU-006
Gerir programas, iniciativas, constrangimentos e planos de acção.
Cada registo possui objectivo ou problema, território, responsável, parceiros, orçamento, prazo, indicador, dependências, risco, escalonamento, estado e decisão necessária.
Fase 2
RF-CLU-007
Publicar páginas e dossiers de cluster a partir de dados validados.
A página reúne visão, cadeia, mapa, projectos, lacunas, actores, financiamento, reguladores, riscos, indicadores e chamada para acção, preservando fontes, versões e níveis de divulgação.
MVP
RF-CLU-008
Captar, qualificar e acompanhar manifestações de interesse por cluster.
O investidor informa cluster, elo, território, papel, capacidade, instrumento e horizonte; o CRM cria o lead com origem, responsável, pontuação, estado e próxima acção.
MVP
RF-CLU-009
Gerir campanhas, missões, eventos e conteúdos por cluster.
Cada campanha relaciona público, mercado-alvo, mensagem, activos, orçamento, leads, reuniões, propostas, atribuição e valor do pipeline.
MVP
RF-CLU-010
Medir prontidão, desempenho, qualidade dos dados e impacto.
Os painéis distinguem dados confirmados, estimados e pendentes e apresentam fórmula, meta, tendência, fonte, responsável, data de actualização e registos de origem.
MVP
RF-CLU-011
Controlar governação, decisões, aprovações e conflitos de interesse.
Reuniões, decisões, documentos, versões, participantes, impedimentos e aprovações ficam ligados ao cluster; ninguém valida isoladamente a informação que submeteu.
MVP
RF-CLU-012
Disponibilizar APIs, eventos e exportação controlada dos dados de cluster.
As integrações aplicam autenticação, escopos, confidencialidade, versionamento, idempotência, auditoria e autorização da entidade proprietária.
Fase 3
4.2.2. Matriz de priorização dos clusters para o portal
A priorização deve ser validada 
pelo
 MPD, tutelas, sector privado
 e
 financiadores 
com
 dados actuais. 
Cada critério recebe uma nota inteira de 0 a 5, em que 0 significa ausência de evidência e 5 representa desempenho muito forte. A pontuação final é calculada por: 
Pontuação = soma de ((nota do critério ÷ 5) × peso do critério)
. O resultado varia de 0 a 100. O risco de execução utiliza escala invertida: 5 corresponde a risco baixo e 0 a risco 
crítico. A pontuação orienta a decisão, mas não substitui validação institucional, disponibilidade de dados e critérios mínimos de prontidão.
Código
Critério
Peso
Evidência para atribuição da nota
C1
Alinhamento com o PII e prioridades nacionais
20%
Projectos âncora, política sectorial, plano nacional, compromisso institucional e contribuição para objectivos públicos.
C2
Procura de investidores e mercado
15%
Leads, pedidos, compradores, financiadores, tendências, missões, consultas e procura comprovável.
C3
Impacto económico e social
15%
Emprego, exportações, substituição de importações, receitas, produtividade, inclusão e desenvolvimento territorial.
C4
Maturidade e qualidade da carteira
15%
Número de projectos, documentação, promotores, licenças, viabilidade, localização, estrutura financeira e prontidão.
C5
Infra-estruturas e condições territoriais
10%
Energia, água, transportes, telecomunicações, instalações, logística, mão-de-obra e acesso a mercados.
C6
Conteúdo local e encadeamentos
10%
Fornecedores, PME, competências, formação, processamento local, transferência de tecnologia e compras nacionais.
C7
Capacidade institucional e de execução
10%
Entidade coordenadora, tutelas, equipa, orçamento, dados, governação, prazos e histórico de execução.
C8
Risco de execução, em escala invertida
5%
Nota 5 para risco baixo; considerar risco regulatório, ambiental, social, financeiro, fundiário, técnico e de mercado.
Total
100%
Todos os critérios devem ter fonte, data, avaliador, comentário e nível de confiança.
Faixas de decisão:
 80–100, prioridade muito alta; 65–79, prioridade alta; 50–64, prioridade média; abaixo de 50, manter em preparação. A entrada no MVP exige ainda: coordenador nomeado, dados mínimos validados, pelo menos três oportunidades publicáveis, cadeia de valor definida, fontes identificadas e formulário de captação configurado.
Cluster
Notas C1–C8
Pontuação
Classificação
Decisão proposta
Agro-indústria e segurança alimentar
5; 5; 5; 4; 4; 5; 4; 3
91
Muito alta
MVP — cluster completo.
Energia e industrialização
5; 5; 5; 4; 4; 4; 4; 3
89
Muito alta
MVP — cluster completo.
Logística, corredores e exportação
5; 5; 5; 4; 4; 4; 4; 2
88
Muito alta
MVP — cluster completo.
Turismo costeiro e economia azul
4; 4; 4; 4; 3; 4; 4; 3
77
Alta
Fase 2, após validação de mapas e carteira.
Têxtil, vestuário e algodão
4; 3; 5; 3; 3; 5; 3; 3
74
Alta
Fase 2, integrado ao cluster agro-industrial.
Mineração e transformação mineral
4; 4; 4; 3; 3; 5; 3; 2
73
Alta
MVP limitado: informação pública validada e captação; diligência avançada na Fase 2.
Tecnologia e serviços digitais
4; 4; 4; 3; 3; 4; 3; 3
72
Alta
Fase 2; função transversal desde o MVP.
Financiamento do investimento
Não aplicável como ranking autónomo.
Transversal
Habilitador
MVP — catálogo de instrumentos e ligação às necessidades dos demais clusters.
A 
matriz é uma linha de base para validação, não uma decisão final. A pontuação
 deve ser recalculada semestralmente 
e sempre que ocorrer
 alteração material em projectos, 
procura, 
financiamento, infra-estruturas, legislação, 
capacidade institucional
 ou risco. 
O sistema deve conservar notas por critério, evidências, avaliadores, nível de confiança, deliberação, data e versão anterior. Diferenças superiores a 10 pontos entre avaliadores exigem sessão de calibração.
4.2.3. MVP do módulo de clusters
Bloco do MVP validado
Escopo obrigatório
Dependências
Critério de go-live
Clusters iniciais
Agro-indústria, energia, logística e mineração em modo limitado; financiamento como camada transversal.
Coordenador, entidade de tutela, carteira mínima, fontes e autorização de publicação.
Três clusters completos e mineração com dados públicos validados; nenhum cluster sem responsável.
Cadastro e cadeia de valor
Clusters, subclusters, elos, lacunas, territórios, actores e relações com projectos.
Taxonomia, regras de versão, dados mestres e responsáveis por domínio.
100% dos registos obrigatórios completos e relações sem duplicação.
Páginas públicas e dossiers
Visão, cadeia, mapa autorizado, projectos, lacunas, actores, financiamento, reguladores, riscos e chamada para acção.
Conteúdo, mapas, traduções, revisão editorial e institucional.
Página aprovada, fonte e data visíveis, ligações funcionais e ausência de dados reservados.
Pesquisa e navegação
Filtros por cluster, cadeia, elo, território, projecto, modalidade, instrumento e fase.
Índice de pesquisa, classificação de acesso e taxonomias.
Resultados relevantes, sem exposição de campos protegidos, e navegação bidireccional testada.
Captação e CRM
Manifestação de interesse, criação do lead, atribuição, qualificação, SLA e próxima acção.
CRM, consentimentos, campanhas, perfis e regras de distribuição.
Lead criado sem duplicação; origem, cluster, responsável e tarefa futura obrigatórios.
Financiamento
Cadastro de necessidades e instrumentos; filtros e encaminhamento manual assistido.
Catálogo financeiro, financiadores, autorização de contacto e equipa de validação.
Necessidades completas e encaminhamento sujeito a revisão humana.
Painel
Prontidão, carteira, qualidade, captação, conversão, pipeline e actualização de dados.
Definições, fontes, CRM e modelo analítico.
Indicadores reconciliados, com data, definição e registos de origem.
Administração e governação
Perfis, aprovação, fontes, versões, decisões, conflitos, auditoria e suspensão.
Identidade, matriz de responsabilidades e políticas.
Segregação de funções testada; nenhuma publicação sem aprovação.
Fora do MVP:
 comparação multicritério com cenários guardados; correspondência automatizada avançada; gestão financeira integral de programas; portal de fornecedores com certificação; resolução institucional de constrangimentos; APIs externas; modelos preditivos; e diligência mineira avançada. 
Go/No-Go global:
 o MVP só poderá entrar em produção quando segurança, privacidade, acessibilidade, desempenho, recuperação, qualidade dos dados, formação, suporte, termos de uso e validação institucional estiverem aprovados e não existirem defeitos críticos.
4.2.4. Indicadores dos clusters
Dimensão
Indicadores mínimos
Periodicidade
Prontidão
Percentagem de clusters com cadeia, actores, mapa, projectos, lacunas, reguladores e fontes validados; índice médio de prontidão das oportunidades.
Mensal
Carteira
Número e valor indicativo de projectos por cluster, elo, território, fase e modalidade; proporção de projectos públicos e privados.
Mensal
Captação
Visitantes, dossiers, leads, investidores qualificados, reuniões, manifestações, diligências e propostas por cluster.
Semanal e mensal
Conversão
Taxas visitante–contacto, contacto–qualificado, qualificado–oportunidade, oportunidade–proposta e proposta–investimento confirmado.
Mensal e trimestral
Financiamento
Necessidades publicadas, janelas compatíveis, concept notes, consórcios, propostas, valor bruto e ponderado do pipeline e valor confirmado.
Mensal
Conteúdo local
Fornecedores registados e validados, correspondências, contratos locais autorizados, emprego, formação e transferência de tecnologia.
Trimestral
Constrangimentos
Casos abertos, resolvidos, vencidos, tempo médio, entidade envolvida e impacto no investimento.
Mensal
Qualidade dos dados
Completude, actualidade, fontes válidas, pendências e tempo de validação por cluster.
Semanal
Impacto
Investimento mobilizado autorizado, emprego, exportações, substituição de importações, produção local e expansão territorial.
Trimestral e anual
Cada indicador deve possuir definição, fórmula, unidade, fonte, responsável, meta, periodicidade, nível de validação e restrição de divulgação. O valor do pipeline não deve ser apresentado como investimento realizado.
Os gráficos, metas percentuais, séries históricas, taxas fiscais, exemplos de endpoints e demais valores herdados da documentação anterior deverão ser classificados como 
dados confirmados
, 
referências históricas
, 
exemplos ilustrativos
 ou 
informação pendente de validação
. Apenas dados confirmados pela fonte competente poderão alimentar linhas de base, indicadores do MVP, simuladores ou conteúdos publicados no portal.
4.2.5. Modelo de governação dos clusters
Órgão ou função
Responsabilidades
Cadência
Comité Estratégico de Clusters
Aprovar clusters prioritários, metas, orçamento, políticas, escalonamentos e entrada ou saída de clusters.
Trimestral
Conselho público-privado do cluster
Validar visão, constrangimentos, projectos, lacunas, prioridades e plano de acção; representar empresas, Estado, academia e financiadores.
Bimestral ou trimestral
Coordenador do cluster
Gerir carteira, reuniões, decisões, dados, campanhas, constrangimentos, indicadores e plano de acção.
Contínua; reporte mensal
Entidade de tutela/regulador
Validar informação oficial, licenças, políticas, requisitos, mapas e restrições de divulgação.
Por publicação e revisão
Tempo — Produto e Conteúdo
Administrar o portal, estruturar informação, promover oportunidades, captar leads e assegurar qualidade editorial.
Contínua
Tempo — CRM e Relações com Investidores
Qualificar contactos, encaminhar interesses, acompanhar reuniões, pipeline, SLA e pós-investimento.
Semanal e mensal
Secretariado de dados
Manter taxonomias, fontes, versões, qualidade, indicadores, mapas e histórico de alterações.
Semanal
Jurídico, Conformidade e Finanças
Validar termos, confidencialidade, conflitos, modelo comercial, comissões, riscos e divulgação de dados.
Por decisão e revisão trimestral
Regras de governação:
 decisões devem registar proposta, participantes, conflito de interesse, evidência, responsável, prazo e resultado; nenhum actor deve validar sozinho informação que submeteu; fontes oficiais prevalecem para requisitos e licenças; dados empresariais reservados dependem de autorização; mudanças materiais exigem nova versão e, quando aplicável, suspensão temporária da página ou indicador.
4.2.6. Roteiro de implementação do módulo de clusters
Fase
Duração indicativa
Entregáveis
Dependências críticas
Critério de passagem
0. Mobilização e validação
4 semanas
Governação, taxonomia, fórmula de priorização, clusters candidatos, responsáveis, fontes, riscos e backlog.
Patrocínio, MPD/tutelas, sector privado, acesso a dados e equipa do produto.
Critérios e pesos aprovados; coordenadores nomeados; dados e riscos inventariados.
1. Dados e desenho do MVP
6 semanas
Modelo de dados, cadeia de valor, protótipos, regras de publicação, integrações CRM, mapas e conteúdos dos clusters iniciais.
Arquitectura, GIS, conteúdo, CRM, segurança, jurídico e entidades de validação.
Protótipo aceite; três clusters completos; mineração com escopo limitado aprovado; dados mínimos acima de 90%.
2. Construção do MVP
10–12 semanas
Cadastro, relações, páginas, pesquisa, formulários, CRM, financiamento, painel, administração e auditoria.
Ambientes, identidade, APIs internas, catálogos, equipa de desenvolvimento e QA.
RF-CLU do MVP aceites; testes funcionais, autorização e integração aprovados; zero defeitos críticos.
3. Piloto e lançamento controlado
6–8 semanas
Migração, formação, piloto com investidores e promotores, correcções, conteúdos bilingues, suporte e lançamento.
Utilizadores-chave, campanhas, pontos focais, helpdesk e plano de comunicação.
Qualidade, adopção e SLA mínimos atingidos; aprovação para lançamento pelo Comité Estratégico.
4. Expansão funcional
10–12 semanas
Turismo, têxtil e tecnologia; comparação multicritério, fornecedores, correspondência, programas e constrangimentos.
Dados validados, governação madura, financiamento e capacidade operacional.
RF-CLU de Fase 2 aceites; benefícios do MVP demonstrados; orçamento e responsáveis aprovados.
5. Ecossistema e integração
12–16 semanas
APIs externas, eventos, parceiros, modelos preditivos supervisionados, automação avançada e interoperabilidade institucional.
Acordos de dados, OpenAPI, segurança, sistemas parceiros e capacidade de monitoria.
Contract tests, segurança, recuperação, privacidade e continuidade aprovados; RF-CLU-012 aceite.
6. Operação e melhoria contínua
Contínua
Repriorização semestral, optimização de conteúdo e campanhas, qualidade dos dados, novos clusters, indicadores e backlog evolutivo.
Comité activo, orçamento operacional, equipa de dados e feedback dos investidores.
Revisão trimestral de desempenho e decisão anual sobre expansão, fusão ou suspensão de clusters.
Responsabilidades executivas:
 o Dono do Produto gere o backlog; o Coordenador do Cluster responde por dados, carteira e resultados; o Secretariado de Dados assegura qualidade e versões; Tecnologia entrega plataforma e integrações; CRM gere captação e SLA; Jurídico e Conformidade validam riscos e divulgação; o Comité Estratégico aprova a passagem entre fases.
4.3. Módulo de Corredores de Desenvolvimento
O módulo de Corredores de Desenvolvimento deverá estruturar o território como uma rede integrada de infra-estruturas, projectos âncora, clusters económicos, cidades e plataformas logísticas, projectos complementares, fornecedores, compradores, financiadores e instituições. A unidade principal será o corredor, que agrega uma área de influência e liga explicitamente 
território → corredor → projecto âncora → cluster → cadeia de valor → projecto complementar → investidor
. A inteligência artificial deverá monitorar dados, detectar alterações, antecipar riscos e propor acções, mantendo explicação, fonte, nível de confiança e validação humana obrigatória.
4.3.1. Arquitectura funcional dos corredores
Componente
Função no corredor
Relações obrigatórias
Corredor de desenvolvimento
Unidade territorial e económica para planear, promover e monitorar investimentos integrados.
Área de influência, territórios, coordenador, visão, metas, riscos, indicadores e versão.
Projecto âncora
Infra-estrutura ou investimento estruturante que activa procura e reduz constrangimentos.
Corredor, clusters beneficiados, capacidade, localização, estado, dependências e projectos complementares.
Cluster económico
Ecossistema produtivo que aproveita a infra-estrutura e os mercados do corredor.
Cadeia de valor, elos, actores, lacunas, fornecedores, compradores e necessidades de financiamento.
Projecto complementar
Investimento público ou privado necessário para completar capacidade, serviços ou cadeia de valor.
Projecto âncora, cluster, localização, promotor, modalidade, valor, fase e prontidão.
Nó territorial
Porto, terminal, cidade, ZEE, parque, bacia, fronteira, aeroporto ou plataforma logística.
Infra-estruturas, serviços, capacidade, área de influência, riscos e oportunidades.
Actor
Promotor, investidor, fornecedor, comprador, financiador, regulador, universidade ou parceiro.
Papel, cobertura, autorização, contactos, projectos e responsabilidades.
Programa habilitador
Política, formação, financiamento, digitalização, ambiente, conteúdo local ou assistência técnica.
Corredor, clusters, beneficiários, orçamento, prazo, responsável e indicadores.
4.3.2. Requisitos funcionais dos Corredores de Desenvolvimento
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-COR-001
Administrar corredores, áreas de influência, nós territoriais, versões e estados.
Cada corredor possui código, visão, coordenador, territórios, geometria, nós, fontes, validade, estado e histórico aprovado.
MVP
RF-COR-002
Relacionar corredores com projectos âncora.
Cada projecto âncora indica função, capacidade, território, dependências, clusters beneficiados e fase; um projecto pode servir vários corredores com relação justificada.
MVP
RF-COR-003
Relacionar corredores com clusters e cadeias de valor.
A relação identifica elos suportados, mercados, recursos, infra-estruturas, lacunas, actores e prioridade, sem duplicar o cadastro do cluster.
MVP
RF-COR-004
Gerir projectos complementares públicos e privados.
O sistema permite propor, validar, publicar e acompanhar novos projectos ligados ao corredor, projecto âncora, cluster, elo e território.
MVP
RF-COR-005
Mapear infra-estruturas, capacidade e constrangimentos.
Energia, água, transportes, telecomunicações, armazenagem, fronteiras e serviços apresentam localização, capacidade, utilização, fonte e estado.
MVP
RF-COR-006
Gerir dependências e sequência de investimentos.
O corredor identifica predecessores, bloqueios, caminho crítico, marcos, responsáveis e data necessária; alteração material recalcula impactos.
Fase 2
RF-COR-007
Publicar página e dossier do corredor.
A página apresenta mapa autorizado, projectos âncora, clusters, oportunidades, infra-estruturas, constrangimentos, investimentos complementares, indicadores e chamada para acção.
MVP
RF-COR-008
Captar interesse e propostas por corredor.
O investidor selecciona corredor, cluster, projecto, papel, instrumento, capacidade e horizonte; o CRM cria lead, responsável e próxima acção.
MVP
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-COR-009
Comparar corredores e cenários territoriais.
A comparação aplica critérios, pesos, fontes e período uniformes e distingue capacidade instalada, planeada e condicionada.
Fase 2
RF-COR-010
Gerir planos de acção, programas e decisões.
Cada acção possui objectivo, responsável, parceiros, orçamento, prazo, indicador, dependências, risco, estado e decisão necessária.
Fase 2
RF-COR-011
Monitorar execução e impacto do corredor.
O painel mostra projectos, investimentos, progresso, emprego, exportações, conteúdo local, capacidade, constrangimentos e qualidade dos dados.
MVP
RF-COR-012
Gerir governação e coordenação interinstitucional.
Reuniões, decisões, compromissos, prazos, conflitos e escalonamentos ficam registados; ninguém valida isoladamente a informação que submeteu.
MVP
RF-COR-013
Integrar corredores com clusters, CRM, GIS, financiamento e campanhas.
Os módulos partilham IDs, estados, fontes e histórico; a integração é idempotente e não cria relações duplicadas.
MVP interno
RF-COR-014
Gerir riscos territoriais, ambientais, sociais, regulatórios, 
financeiros e de mercado.
Cada risco possui probabilidade, impacto, exposição, proprietário, mitigação, contingência, prazo e evidência actualizada.
MVP
RF-COR-015
Disponibilizar APIs e eventos dos corredores.
Integrações aplicam autenticação, escopos, confidencialidade, versionamento, idempotência, auditoria e autorização da fonte.
Fase 3
RF-COR-016
Aplicar inteligência artificial supervisionada ao corredor.
A IA usa dados autorizados, apresenta fonte, explicação e confiança, não altera decisões nem publica recomendações sem revisão humana e mantém auditoria.
MVP assistivo; Fases 2–3 avançadas
4.3.3. Inteligência artificial para monitoria e aconselhamento
Capacidade de IA
Função
Saída
Controlo obrigatório
Monitor de dados
Verificar actualidade, completude, consistência e divergência entre fontes.
Alertas, campos em falta, conflitos, validade e pedido de actualização.
Fonte autorizada, regra de precedência e confirmação do responsável pelos dados.
Monitor de execução
Comparar marcos, orçamento, progresso, dependências e SLA.
Atrasos, caminho crítico, impacto em clusters e acções prioritárias.
Gestor confirma causa, impacto e plano de recuperação.
Radar de risco
Detectar sinais de risco regulatório, territorial, ambiental, social, financeiro e de mercado.
Nível de risco, factores, tendência e mitigação sugerida.
Nenhum bloqueio ou classificação final sem avaliação especializada.
Conselheiro de priorização
Aplicar critérios aprovados a corredores, projectos e lacunas.
Pontuação explicada, cenários e sensibilidade aos pesos.
Pesos versionados; decisão pertence ao Comité.
Recomendador de investimento
Relacionar perfil do investidor com corredor, cluster, projecto e instrumento.
Lista ordenada, razões de compatibilidade e condições eliminatórias.
Revisão humana antes do encaminhamento; sem garantia de retorno.
Conselheiro de projectos complementares
Identificar lacunas de capacidade e oportunidades derivadas dos projectos âncora.
Projectos sugeridos, localização, elo, capacidade e dependências.
Sugestão marcada como não oficial até validação técnica e institucional.
Assistente de governação
Resumir reuniões, compromissos, decisões, pendências e prazos.
Acta preliminar, tarefas, responsáveis e escalonamentos.
Aprovação do secretário ou coordenador antes de registo oficial.
Previsão de impacto
Simular emprego, tráfego, procura, exportações e utilização de infra-estrutura.
Cenários, intervalo, pressupostos, confiança e limitações.
Resultados não substituem estudo de viabilidade; versão e modelo registados.
Princípios de IA responsável:
 dados mínimos e autorizados; finalidade definida; explicabilidade; avaliação de qualidade e enviesamento; supervisão humana; separação entre facto, previsão e recomendação; registo do modelo e versão; possibilidade de contestação; segurança; monitoria de desempenho; e suspensão automática quando a qualidade dos dados, a confiança ou o comportamento do modelo ficarem abaixo dos limites aprovados.
4.3.4. Matriz dos corredores prioritários
Corredor prioritário
Projectos âncora
Clusters associados
Projectos complementares e foco
Prioridade
Corredor de Nacala e Norte
A03 Corredor de Nacala; A04 Crusse Jamali; A05 Namialo–Metoro; componentes de A01.
Logística, energia, agro-indústria, mineração, turismo e indústria.
Terminais, armazenagem, processamento, parques, água, energia, formação, fornecedores e conectividade.
MVP — muito alta.
Corredor da Beira e Centro
A06 Cadeia do Arroz; A07 Parque Têxtil; componentes ferroviários, portuários e industriais.
Agro-indústria, têxtil, logística, energia e serviços.
Regadio, silos, frio, processamento, fiação, logística, certificação, formação e financiamento.
MVP — muito alta.
Corredor Zambeze–Macuse
A08 ZEE de Mocuba; A09 Cidadela de Mocuba; A10 Mphanda Nkuwa; A11 Macuse–Moatize; A12 Resiliência Costeira.
Energia, logística, mineração, agro-indústria, serviços urbanos, clima e indústria.
Transmissão, porto, terminais, parques, água, serviços urbanos, mitigação social e ambiental e fornecedores.
MVP — muito alta.
Corredor Maputo–Limpopo
A14 ZEE de Agronegócio do Limpopo; A15 Regadio da Bacia do Rio Maputo; componentes de A01.
Agro-indústria, água, logística, indústria, comércio e serviços.
Irrigação, processamento, armazenagem, energia, embalagem, transporte, mercados e serviços financeiros.
MVP — alta.
Corredor Turístico Inhambane–Bazaruto
A13 Região Integrada de Turismo de Vilanculos.
Turismo, economia azul, aviação, serviços, conservação e tecnologia.
Alojamento, marinas, mobilidade, formação, água, energia, experiências e serviços digitais.
Fase 2 — alta.
Corredor Industrial Nacional Norte–Sul
A01 MozParks; A02 Linha Ferroviária Norte–Sul.
Indústria, logística, energia, tecnologia e cadeias provinciais.
Parques, ramais, utilities, centros logísticos, fornecedores, competências e digitalização.
Fase 2 — estruturante.
A priorização dos corredores deverá usar a fórmula da secção 4.2.2, acrescida de quatro critérios específicos: conectividade regional, capacidade habilitadora dos projectos âncora, concentração de clusters complementares e dependências críticas. A IA pode recalcular cenários e sensibilidade, mas a classificação oficial exige validação do Comité Estratégico de Corredores e das entidades de tutela.
4.3.5. Indicadores e modelo de governação
Dimensão
Indicadores mínimos
Monitoria e aconselhamento da IA
Infra-estrutura
Capacidade instalada, utilizada, planeada, disponibilidade, interrupções e projectos atrasados.
Detectar saturação, gargalos e sequência recomendada de expansão.
Carteira
Projectos âncora e complementares por fase, valor, território, cluster e prontidão.
Identificar lacunas, duplicações, dependências e projectos prioritários.
Captação
Leads, investidores qualificados, reuniões, propostas, diligências e investimento confirmado.
Recomendar campanhas, mercados e contas prioritárias com explicação.
Execução
Progresso, marcos, orçamento, SLA, riscos, decisões e caminho crítico.
Alertar desvios, prever atraso e sugerir plano de recuperação.
Desenvolvimento
Emprego, conteúdo local, produção, exportações, investimento privado induzido e cobertura territorial.
Comparar cenários e assinalar resultados abaixo da trajectória.
Qualidade dos dados
Completude, actualidade, validade, divergências e tempo de correcção.
Priorizar actualizações e suspender recomendações de baixa confiança.
Órgão ou função
Responsabilidades
Cadência
Comité Estratégico de Corredores
Aprovar corredores, prioridades, investimentos âncora, metas, orçamento, riscos, decisões e passagem entre fases.
Trimestral.
Unidade de Coordenação do Corredor
Integrar projectos, clusters, dados, entidades, campanhas, constrangimentos, indicadores e plano de acção.
Contínua; reporte mensal.
Conselho territorial público-privado
Validar necessidades, projectos complementares, conteúdo local, impactos e prioridades territoriais.
Bimestral ou trimestral.
Tutelas e reguladores
Validar informação oficial, licenças, mapas, políticas, capacidade, restrições e decisões sectoriais.
Por publicação, alteração e revisão.
Tempo — Produto, Dados e CRM
Administrar o módulo, qualidade dos dados, campanhas, investidores, SLA, painéis e relatórios.
Semanal e mensal.
Comité de IA e Dados
Aprovar fontes, modelos, métricas, limites, testes, incidentes, alterações e suspensão de IA.
Mensal e por incidente.
Jurídico, Conformidade, Ambiente e Social
Validar riscos, confidencialidade, tratamento de dados, divulgação, impactos e conflitos.
Por decisão e revisão trimestral.
4.3.6. Roteiro dos Corredores de Desenvolvimento
Fase
Duração
Entregáveis
IA aplicada
Critério de passagem
0. Mobilização e governação
4–6 semanas
Comité, coordenadores, taxonomia, corredores candidatos, fontes, regras e backlog.
Inventário de dados e detecção preliminar de lacunas.
Órgãos nomeados; fontes, critérios e corredores aprovados.
1. Modelação territorial
6–8 semanas
Áreas de influência, nós, projectos âncora, clusters, relações, mapas e dados mestres.
Validação de consistência, divergências e dados em falta.
Três corredores com dados mínimos acima de 90% e mapas autorizados.
2. MVP funcional
10–12 semanas
Cadastro, páginas, pesquisa, CRM, projectos complementares, riscos, indicadores e governação.
Alertas de qualidade, risco, atraso e recomendação assistida de oportunidades.
RF-COR do MVP aceites; segurança e integrações aprovadas; zero defeitos críticos.
3. Piloto controlado
6–8 semanas
Piloto nos corredores de Nacala, Beira/Centro e Zambeze–Macuse; formação, campanhas e suporte.
Monitoria de uso, conversão, SLA, qualidade e sugestões de melhoria.
Metas de adopção, qualidade e resposta atingidas; aprovação para lançamento.
4. Expansão e optimização
10–14 semanas
Maputo–Limpopo, turismo e corredor industrial; comparação, 
dependências e planos de acção.
Previsão de atrasos, cenários, sensibilidade e projectos 
complementares sugeridos.
Modelos validados; benefícios do MVP demonstrados; 
responsáveis e orçamento aprovados.
5. Integração institucional
12–16 semanas
APIs, eventos, sistemas parceiros, dados de infra-estrutura, licenças e financiamento.
Monitoria contínua de eventos, anomalias e alterações externas.
Contract tests, privacidade, segurança, recuperação e continuidade aprovados.
6. Operação inteligente
Contínua
Revisão trimestral, novos corredores, melhoria dos modelos, auditoria e backlog evolutivo.
Conselheiro do corredor com métricas de precisão, confiança e impacto.
Revisão anual decide expansão, fusão, suspensão ou reorientação de corredores.
Go/No-Go:
 cada fase exige qualidade de dados, segurança, privacidade, acessibilidade, desempenho, validação institucional, responsáveis nomeados, formação, suporte e ausência de riscos críticos sem mitigação. A IA só progride para automação avançada quando atingir métricas aprovadas de precisão, explicabilidade, estabilidade, utilidade e ausência de impacto indevido, mantendo sempre a decisão final humana.
4.3.7. Zonas Económicas Especiais, Zonas Francas Industriais e parques industriais
O portal deverá tratar as Zonas Económicas Especiais (ZEE), as Zonas Francas Industriais (ZFI) e os parques industriais como polos de desenvolvimento distintos, mas interoperáveis, nos termos da 
Lei n.º 8/2023, de 9 de Junho
. Para esta secção, a correspondência legal confirmada é: artigos 1–3 — objecto, âmbito e definições; artigo 5 — objectivos do investimento; artigos 6–13 — garantias, direitos, deveres e responsabilidade social; artigos 14–18 — operações e liberdade de investir; artigo 19 — incentivos fiscais; artigo 20 — polos de desenvolvimento; artigo 21 — princípios procedimentais; artigo 22 — regimes de investimento; artigo 23 — dever de fundamentação, audiência prévia e decisão; artigos 24–27 — acompanhamento, reclamações e garantias; e artigos 28–31 — regulamentação, disposições transitórias, revogação e entrada em vigor. Cada zona ou parque deverá possuir cadastro próprio, delimitação geográfica, base legal validada, entidade gestora, vocação económica, infra-estruturas, serviços, lotes, operadores, projectos, incentivos aplicáveis, obrigações, riscos e indicadores. A Lei n.º 3/93, de 24 de Junho, foi revogada e não constitui fundamento vigente.
Categoria
Natureza e finalidade
Elementos distintivos no portal
Zona Económica Especial (ZEE)
Área territorial delimitada, sujeita a regime especial aprovado, destinada a promover investimento, diversificação económica, exportações, emprego, infra-estruturas e desenvolvimento regional; pode integrar actividades industriais, logísticas, comerciais, tecnológicas, turísticas ou de serviços.
Diploma de criação, perímetro, entidade gestora, sectores admitidos, regime aplicável, subzonas, projectos âncora, serviços, incentivos validados, obrigações, indicadores territoriais e ligação a corredores e clusters.
Zona Franca Industrial (ZFI)
Área ou unidade industrial autorizada, orientada predominantemente para produção, transformação, montagem ou actividades conexas sob regime aduaneiro e fiscal específico, normalmente associado a exportação e controlo de entradas, saídas e mercadorias.
Autorização e validade, perímetro ou instalação, operador, actividades elegíveis, obrigações de exportação quando aplicáveis, controlo aduaneiro, movimentos de mercadorias, licenças, origem/destino, benefícios validados, conformidade e auditoria.
Parque industrial
Empreendimento infra-estruturado que concentra actividades industriais e serviços partilhados; não beneficia automaticamente de um regime económico, fiscal ou aduaneiro especial.
Proprietário ou gestor, lotes, ocupação, preços ou condições, utilities, acessos, serviços comuns, licenciamento ordinário, empresas instaladas, capacidade e disponibilidade; qualquer estatuto ZEE/ZFI deve ser registado separadamente e comprovado.
4.3.7.1. Requisitos funcionais para ZEE e ZFI
ID
Requisito funcional
Critério de aceitação revisto
Prioridade
RF-ZON-001
Administrar o cadastro mestre de ZEE, ZFI e parques industriais.
Dado um registo novo ou alterado, o sistema só permite a sua aprovação quando categoria, código único, denominação, estado, diploma ou título habilitante, entidade competente, operador/gestor, datas de criação, emissão, validade e revisão, fonte oficial, proprietário do dado e versão estiverem preenchidos. Para ZEE/ZFI, distingue OZEE/OZFI de EZEE/EZFI e conserva certificado, condições, averbamentos, suspensão, renovação ou revogação. Um parque industrial só é marcado como ZEE/ZFI mediante prova autónoma do respectivo estatuto. Toda alteração gera histórico imutável com autor, data, motivo e aprovador.
MVP
RF-ZON-002
Gerir delimitação geográfica, subzonas, lotes e instalações.
O PostGIS aceita apenas geometrias não vazias, válidas, no sistema de referência aprovado e acompanhadas de fonte, data e entidade validadora. O perímetro oficial não pode ser publicado sem diploma/planta autorizada; conflitos, sobreposições e alterações de área são bloqueados ou encaminhados para validação. O mapa distingue ZEE, ZFI, parque, subzona, lote, instalação e área sob controlo aduaneiro e mantém versões anteriores consultáveis.
MVP
RF-ZON-003
Registar o regime jurídico, fiscal, aduaneiro, cambial, laboral, migratório e administrativo aplicável.
Cada regra ou benefício indica diploma, artigo, categoria e sujeito abrangido, condição de acesso, autoridade competente, início e fim de vigência, estado de validação e data da última revisão. O sistema impede cumulação não autorizada, cálculo automático sem regra validada e apresentação de benefício como adquirido antes do certificado, despacho ou reconhecimento competente. Conteúdo expirado, revogado, contraditório ou não confirmado é retirado da publicação e gerado alerta ao Centro Legal.
MVP
RF-ZON-004
Gerir actividades autorizadas, condicionadas e proibidas.
Para cada ZEE/ZFI, o sistema relaciona actividade, produto, serviço, licença sectorial, restrição e fundamento legal. Para ZFI, valida natureza industrial e a percentagem mínima de produção destinada à exportação definida no regime vigente, controla o limite autorizado de vendas no mercado interno e bloqueia actividades legalmente proibidas. Excepções só 
entram em vigor com decisão competente, pareceres e validade registados.
MVP
RF-ZON-005
Publicar ficha territorial e dossier de investimento.
A ficha bilingue só é publicada após aprovação institucional e editorial e apresenta mapa oficial, estatuto, operador/gestor, actividades, lotes, infra-estruturas, controlo aduaneiro quando aplicável, procedimentos, certificados, benefícios validados, obrigações, riscos, contactos e fontes. O sistema mostra data de actualização, aviso de elegibilidade caso a caso e separa informação oficial, histórica, estimada e pendente.
MVP
RF-ZON-006
Pesquisar, filtrar e comparar ZEE, ZFI e parques industriais.
A pesquisa filtra por categoria, localização, actividade, disponibilidade, infra-estruturas, acessos, operador, estatuto e validade. A comparação separa condições físicas de regimes legais, usa a mesma data de referência, assinala dados ausentes e nunca atribui benefícios de uma ZEE/ZFI a um parque industrial sem título próprio. Resultados respeitam permissões e não expõem dados reservados.
MVP; comparação avançada na Fase 2
RF-ZON-007
Gerir lotes, instalações, capacidade e ocupação.
Cada unidade contém identificador, geometria, área, uso permitido, disponibilidade, capacidade, utilities, acessos, titularidade/DUAT quando aplicável, condição de atribuição, preço autorizado, ocupante e contrato acessível apenas a perfis autorizados. Reservas concorrentes são impedidas; mudanças de ocupação exigem aprovação e histórico; a transmissão de estabelecimento ou posição sujeita a autorização não produz efeito no portal sem o respectivo averbamento.
Fase 2
RF-ZON-008
Receber manifestação de interesse e pedido de certificação/licenciamento.
O requerente escolhe ZEE/ZFI/parque, qualidade de operador ou empresa, actividade, localização, investimento, emprego, mercados e necessidades. O sistema aplica a checklist correspondente, aceita submissão em português ou inglês, valida documentos obrigatórios, emite protocolo e cria no CRM um processo sem duplicação, com responsável, prazo legal parametrizado, estado e próxima acção. O portal identifica submissões incompletas e não inicia contagem de prazo de decisão antes da confirmação de conformidade.
MVP assistido; transaccional na Fase 2
RF-ZON-009
Orquestrar análise, pareceres, decisão, certificação e instalação.
O fluxo configura competência decisória, articulação interinstitucional, documentos, pareceres, prazos, condições, notificação e reconsideração. Distingue criação da zona, licenciamento do operador, certificação da empresa e licenças sectoriais. Nenhuma decisão, certificado ou aprovação tácita é gerada pelo portal sem base legal parametrizada, confirmação da entidade competente, assinatura/validação autorizada e segregação entre submissor, analista e decisor.
Fase 2
RF-ZON-010
Controlar certificados, licenças, autorizações, obrigações e validade.
O painel associa certificado de OZEE/OZFI/EZEE/EZFI, licenças ambientais e sectoriais, NUIT, INSS, vistorias, condições da autorização e prazos de implementação ao respectivo titular. Gera alertas, regista cumprimento, interrupção, alteração, transmissão, renovação, suspensão e revogação e preserva documentos e trilho de auditoria. O estado público muda automaticamente para “pendente de validação” quando vence uma evidência crítica.
Fase 2
RF-ZON-011
Suportar o controlo aduaneiro e operacional específico das ZFI.
O sistema regista certificado dos sistemas de segurança, portarias autorizadas, instalações aduaneiras, credenciais, DU e documentos de suporte, entradas, saídas, trânsito, transferências internas, inventário, produção, refugos, perdas e vendas ao mercado interno. Mantém rastreabilidade por mercadoria, código pautal, quantidade, valor, origem, destino e declaração; alerta divergências e conserva documentos pelo prazo legal parametrizado. Nenhuma saída é marcada como autorizada sem referência à autorização aduaneira; no MVP, o registo é assistido e não substitui o sistema das Alfândegas.
Fase 2; integração na Fase 3
RF-ZON-012
Relacionar zonas com corredores, clusters, projectos, empresas e fornecedores locais.
As relações usam identificadores mestres, indicam papel, período, fonte e estado e permitem navegação bidireccional sem duplicar entidades. O sistema distingue fornecimento local, exportação para ZEE/ZFI e operações no mercado interno e exige validação antes de usar essas relações em indicadores, benefícios ou campanhas.
MVP
RF-ZON-013
Gerir infra-estruturas, utilities, segurança, ambiente e constrangimentos.
Energia, água, saneamento, telecomunicações, acessos, logística, combate a incêndio, armazenagem especial, instalações aduaneiras e serviços comuns registam capacidade instalada, utilizada e planeada, estado, fonte e responsável. Para ZEE, a publicação de actividades considera avaliação/licença ambiental; para ZFI, a entrada em operação depende também da certificação dos sistemas de segurança e das vistorias aplicáveis. Incidentes e incumprimentos geram acção, prazo e escalonamento.
MVP
RF-ZON-014
Monitorar investimento, implementação, ocupação, emprego, produção, exportações, mercado interno e conteúdo local.
Cada indicador tem definição, fórmula, unidade, período, fonte, responsável, estado de validação e restrição de divulgação. O painel separa autorizado, realizado, pipeline e estimativa; para ZFI, calcula a proporção exportada e vendida no mercado interno com base em produção anual validada; para benefícios, conserva evidência de pressupostos, declarações, fiscalizações e auditorias. Divergências bloqueiam consolidação oficial até reconciliação.
MVP
RF-ZON-015
Aplicar governação, segurança, privacidade, fiscalização e auditoria.
Perfis separados submetem, analisam, validam, decidem, publicam, inspeccionam e auditam. Acesso a dados pessoais, comerciais, fiscais, 
laborais e aduaneiros observa finalidade, minimização, autorização e retenção. Inspecções registam órgão, fundamento, autorização/dispensa aplicável, notificação, participantes, constatações e medidas. O sistema conserva logs invioláveis e impede que o mesmo utilizador aprove informação própria ou altere evidência encerrada.
MVP
RF-ZON-016
Disponibilizar APIs e eventos controlados.
Integrações com APIEX/entidade sucessora competente, Autoridade Tributária/Alfândegas, Banco de Moçambique, ambiente, trabalho, migração, registo comercial, INSS, governos locais e operadores aplicam acordo formal, base legal, autenticação forte, escopos, minimização, versionamento, idempotência, cifragem, auditoria, reconciliação, SLA, gestão de erros e testes de contrato. Na indisponibilidade de integração, o sistema activa fluxo manual assistido sem simular decisão oficial.
Fase 3
4.3.7.2. Auditoria legal e referências dos RF-ZON
RF
Diplomas e artigos aplicáveis
Resultado da auditoria
Condição jurídica de aceitação
RF-ZON-001
Lei n.º 3/93, art. 1, alíneas x) e z), e art. 21; Decreto n.º 43/2009, art. 1, alíneas b), c), h), q), t) e u), arts. 36–41 e 53–57; Decreto n.º 75/2007, arts. 2–3.
Conforme com ressalva.
 A distinção entre zona, operador e empresa está alinhada. “Parque industrial” não possui, nesta compilação, um regime geral equivalente ao de ZEE/ZFI.
Exigir título habilitante, certificado e entidade emissora; não inferir estatuto especial a partir da localização ou denominação do parque.
RF-ZON-002
Lei n.º 3/93, art. 1, alíneas x) e z); Decreto n.º 43/2009, arts. 20, 22, 36 n.º 2 al. c), 38, 40 n.º 1 al. b), 53 n.º 2 al. b) e 61; Decreto n.º 76/2007, arts. 1–2.
Conforme.
 A delimitação geográfica e a planta topográfica são elementos jurídicos essenciais.
Publicar apenas perímetros, alterações e áreas de expansão suportados por diploma, planta ou decisão competente; tratar DUAT e licença especial segundo a legislação fundiária aplicável.
RF-ZON-003
Lei n.º 3/93, arts. 13–20; Decreto n.º 43/2009, arts. 24–35 e 63–68; Lei n.º 4/2009, arts. 3–12, 45–50; Decreto n.º 56/2009, arts. 4–11 e 14–15; Decreto n.º 75/99.
Conforme, mas de alto risco de desactualização.
 Os benefícios dependem de condições, certificado, reconhecimento e legislação fiscal vigente.
Versionar diploma, artigo, beneficiário, condição, vigência e acto de reconhecimento; bloquear simulação ou promessa automática; validar não cumulação e eventual suspensão/extinção.
RF-ZON-004
Decreto n.º 43/2009, arts. 21 e 59; Lei n.º 3/93, art. 3 n.º 2; Decreto n.º 43/2009, art. 59 n.os 3–4 e arts. 61–62.
Conforme.
 Para ZFI, a referência legal auditada exige actividade industrial, pelo menos 70% da produção anual para exportação e proíbe actividades específicas.
Parametrizar percentagens e proibições por versão legal; controlar excepções formalmente autorizadas e distinguir empresa instalada dentro e fora de uma ZFI.
RF-ZON-005
Lei n.º 3/93, arts. 2–3, 6–7 e 16; Decreto n.º 75/2007, art. 3, alíneas f)–g); Decreto n.º 
43/2009, arts. 24–35 e 63–68; Lei n.º 4/2009, arts. 45–48.
Conforme como função informativa.
 O dossier não pode equivaler a certificado, 
despacho, parecer ou garantia de benefício.
Mostrar fonte, data, estatuto jurídico, limitações e contacto oficial; sujeitar incentivos, taxas, 
prazos e procedimentos a revisão jurídica antes da publicação.
RF-ZON-006
Lei n.º 3/93, arts. 2–4 e 16; Decreto n.º 43/2009, arts. 20–25, 53–68; Lei n.º 4/2009, arts. 4 e 45–48.
Conforme com controlo de representação.
 A comparação é admissível, mas não pode misturar regimes, beneficiários ou períodos.
Comparar na mesma data de referência; separar características físicas, elegibilidade e benefícios reconhecidos; incluir aviso de não substituição de análise oficial.
RF-ZON-007
Decreto n.º 43/2009, art. 22, arts. 
37 n.os 3–5, 40, 46, 52, 56 e 61; Lei n.º 3/93, art. 23.
Parcialmente conforme.
 A gestão digital de lotes deve respeitar DUAT, contratos, autorização de transmissão e competências do operador/autoridade.
Não apresentar reserva como concessão de terra ou autorização; exigir averbamento/decisão para transmissões sujeitas a autorização; restringir contratos e dados fundiários.
RF-ZON-008
Decreto n.º 43/2009, arts. 8–9, 36, 40, 47, 53 e 56; art. 70; Lei n.º 3/93, art. 21.
Conforme em modo assistido.
 A submissão electrónica é admitida quando contém os elementos necessários; a comunicação vinculativa exige forma escrita e representantes autorizados.
Separar manifestação comercial de requerimento oficial; usar formulários aprovados; emitir protocolo verificável; não iniciar prazo legal antes da confirmação de completude pela entidade competente.
RF-ZON-009
Decreto n.º 43/2009, arts. 10–14, 20, 36–41, 53–58 e 71; Lei n.º 3/93, arts. 21 e 25.
Conforme com bloqueio de automação decisória.
 Competências, prazos e deferimento tácito só podem ser aplicados na forma legal vigente.
Parametrizar competência e prazo por acto; exigir assinatura/validação oficial; impedir decisão automática, certificado sintético ou deferimento presumido sem confirmação jurídica.
RF-ZON-010
Decreto n.º 43/2009, arts. 14–19, 37, 41, 48, 55, 57–58 e 62; Lei n.º 4/2009, arts. 49–50.
Conforme.
 O acompanhamento de vigência, implementação, renovação, suspensão e revogação é legalmente relevante.
Registar autoridade, notificação, fundamento, efeito e recurso; não alterar estado jurídico público apenas por expiração técnica sem validação competente.
RF-ZON-011
Decreto n.º 43/2009, arts. 53–55, 59–60 e 65–68; Diploma Ministerial n.º 14/2002, arts. 2–26, especialmente arts. 3–4, 6–10, 12–23.
Conforme e necessário.
 A lei exige sistemas de segurança, controlo aduaneiro, DU, inventário, registos, autorizações e conservação mínima de cinco anos.
Alfândegas mantém a decisão e o controlo; nenhuma entrada/saída é validada só pelo portal; garantir rastreabilidade, acesso autorizado e retenção legal.
RF-ZON-012
Decreto n.º 43/2009, arts. 27 e 67; Decreto n.º 75/2007, art. 3, alíneas c)–g), l)–p); Lei n.º 3/93, art. 7.
Conforme.
 A integração territorial e económica é compatível com promoção e monitoria, mas a qualificação aduaneira do fornecimento local requer validação.
Não classificar automaticamente uma operação como exportação; exigir destino, actividade licenciada e evidência da operação.
RF-ZON-013
Lei n.º 3/93, arts. 7 e 26; Decreto n.º 43/2009, arts. 21–23, 36, 53–55 e 58; Diploma Ministerial n.º 14/2002, arts. 2, 5 e 10.
Conforme.
 Infra-estruturas, avaliação/licença ambiental, segurança e vistoria são condições materiais e jurídicas.
Bloquear “operacional” quando falte licença ambiental, vistoria ou certificado de segurança exigível; conservar a entidade emissora e a evidência.
RF-ZON-014
Lei n.º 3/93, art. 7; Decreto n.º 43/2009, arts. 5, 14–16, 59, 65 e 
73; Lei n.º 4/2009, arts. 2 n.º 3, 8, 12 e 49–50; Diploma Ministerial n.º 14/2002, art. 11.
Conforme.
 A monitoria deve distinguir compromisso, autorização, realização, 
produção, exportação e venda interna.
Usar dados reconciliados e validados; não publicar dados fiscais, aduaneiros ou 
empresariais reservados; conservar fórmula, fonte e período.
RF-ZON-015
Decreto n.º 43/2009, arts. 5, 50, 60, 70–71; Lei n.º 4/2009, art. 8; Decreto n.º 56/2009, art. 15; Diploma Ministerial n.º 14/2002, arts. 3–4 e 7–9.
Conforme, com lacuna normativa digital.
 A compilação sustenta fiscalização, auditoria, acesso a registos e responsabilidade, mas não define integralmente privacidade e cibersegurança da plataforma.
Adoptar base legal, classificação, acesso mínimo, retenção, resposta a incidentes e segregação compatíveis com a legislação geral vigente e acordos de partilha.
RF-ZON-016
Decreto n.º 43/2009, arts. 4–5, 47 n.º 3 e 70; Diploma Ministerial n.º 14/2002, arts. 3–4, 7–11 e 26; Decreto n.º 75/2007, arts. 3 e 9.
Conforme apenas de forma condicionada.
 Os diplomas preveem articulação e troca de informação, não uma autorização geral para interoperabilidade automática.
Exigir acordo institucional, finalidade, campos, base legal, segurança, SLA, auditoria e proprietário; manter fluxo manual quando a integração não estiver formalmente autorizada.
4.3.7.4. Lacunas e riscos jurídicos
ID
Lacuna ou risco jurídico revisto
Impacto
Tratamento obrigatório
Responsável
RJ-ZON-01
O Decreto n.º 43/2009 foi revogado pelo Decreto n.º 8/2024; competências, prazos e procedimentos antigos não podem ser reutilizados.
Crítico — fluxo inválido, decisão por entidade errada ou prazo juridicamente incorrecto.
Eliminar referências operacionais ao Decreto n.º 43/2009; parametrizar a Lei n.º 8/2023 e o Decreto n.º 8/2024; exigir parecer para qualquer regra especial.
Jurídico e Conformidade; APIEX, I.P.; Produto.
RJ-ZON-02
O Decreto n.º 8/2024 não regula especificamente ZEE, ZFI e ZETI.
Crítico — lacuna na definição de competências, certificação, licenciamento e tramitação especial.
Identificar o regime especial vigente, diplomas específicos e actos de delegação antes de automatizar; manter fluxo assistido e bloqueio de decisão.
Jurídico; APIEX, I.P.; Autoridade Tributária; tutela sectorial.
RJ-ZON-03
O artigo 20 reconhece polos de desenvolvimento, mas não contém sozinho todo o regime operacional de cada ZEE, ZFI ou parque.
Alto — falsa conclusão de que a Lei n.º 8/2023 resolve licenciamento e benefícios especiais.
Usar o artigo 20 como fundamento enquadrador; vincular cada regra operacional ao diploma especial e à entidade competente.
Jurídico; Centro Legal; Produto.
RJ-ZON-04
Parques industriais não beneficiam automaticamente de regime fiscal, aduaneiro ou de investimento especial.
Alto — informação enganosa e benefício indevido.
Manter categoria neutra; exigir título próprio; mapear legislação industrial, fundiária, urbanística, ambiental e municipal.
Jurídico; Indústria; governos locais; gestor do parque.
RJ-ZON-05
Regime de mero registo e regime de autorização podem ser confundidos ou aplicados ao sujeito errado.
Crítico — tramitação inadequada e decisão inválida.
Aplicar critérios do artigo 22 e do Decreto n.º 8/2024; registar valor, natureza, terra, concessão e sector antes da classificação; 
permitir revisão humana.
APIEX, I.P.; Jurídico; Produto.
RJ-ZON-06
O portal pode omitir fundamentação, audiência prévia ou notificação exigidas pelo artigo 23.
Crítico — afectação do direito de participação e contestação.
Modelar motivo, evidência, audiência, resposta, decisão e notificação; bloquear encerramento sem prova; não simular actos oficiais.
Entidade decisora; Jurídico; Arquitectura.
RJ-ZON-07
Benefícios, percentagens, prazos e valores podem decorrer de legislação fiscal e aduaneira própria ou posterior.
Crítico — passivo fiscal, aduaneiro e reputacional.
Não codificar valores estáticos; usar regras versionadas, acto de reconhecimento, data e validação da Autoridade Tributária/Alfândegas.
Autoridade Tributária/Alfândegas; Jurídico; Produto.
RJ-ZON-08
O portal pode aparentar emitir autorização, certificado, licença, registo ou reconhecimento de benefício.
Crítico — usurpação de competência e invalidade.
Distinguir pré-preenchimento, protocolo, mero registo, autorização e acto oficial; exigir assinatura e validação da autoridade.
Jurídico; Arquitectura; entidade competente.
RJ-ZON-09
Dados fiscais, aduaneiros, pessoais, laborais e comerciais podem estar sujeitos a reserva.
Alto — violação de sigilo, privacidade ou segredo comercial.
Definir base legal, finalidade, minimização, classificação, perfis, retenção, acesso e acordo de partilha; realizar avaliação de impacto.
Jurídico; Segurança; proprietários dos dados.
RJ-ZON-10
Delimitação, lote e disponibilidade podem colidir com DUAT, cadastro, servidões, reassentamento ou direitos de terceiros.
Alto — litígio fundiário e bloqueio do investimento.
Exigir validação cadastral/fundiária, histórico de geometria, consulta aplicável e aviso de que publicação não constitui concessão.
Terras/Cadastro; governo local; operador; Jurídico.
RJ-ZON-11
Licença ambiental, vistoria e certificado de segurança podem ser tratados como dispensáveis ou equivalentes.
Crítico — operação irregular e risco ambiental ou de segurança.
Modelar precedências e dependências; bloquear estado operacional sem evidência válida da entidade competente.
Ambiente; Alfândegas; Trabalho; Bombeiros; operador.
RJ-ZON-12
Regras históricas sobre mão-de-obra estrangeira e regimes laborais especiais podem estar superadas.
Alto — contratação irregular e sanções.
Validar legislação laboral e migratória vigente; não publicar quotas, prazos ou isenções sem confirmação oficial.
Trabalho; Migração; Jurídico.
RJ-ZON-13
Integrações e notificações digitais podem não produzir força probatória ou efeitos legais.
Alto — perda de prazo, prova insuficiente ou estado divergente.
Definir canal oficial, assinatura, carimbo temporal, recibo, indisponibilidade, reconciliação e acordo institucional.
Jurídico; Arquitectura; entidades integradas.
RJ-ZON-14
A RACI pode confundir coordenação da APIEX, I.P. com competência decisória ou competência especial de ZEE/ZFI.
Alto — aprovação por entidade não habilitada.
Registar, por procedimento, órgão instrutor, decisor, delegação, diploma e substituto; rever a matriz quando houver alteração institucional.
Jurídico; APIEX, I.P.; patrocinador.
RJ-ZON-15
Falta de texto legal consolidado e de controlo das relações altera/revoga/regulamenta.
Alto — divergência entre portal e fonte oficial.
Manter repositório legal oficial, vigência, versão e revisão a dois níveis; criar alerta de mudança normativa e retirada controlada.
Centro Legal; Jurídico; Gestão de Conteúdo.
Conclusão da auditoria:
 os RF-ZON-001 a RF-ZON-016 são funcionalmente compatíveis com a compilação legal analisada, desde que sejam implementados como mecanismos de cadastro, facilitação, rastreabilidade, monitoria e integração condicionada. Não deverão substituir competências públicas, actos administrativos, controlo aduaneiro, reconhecimento fiscal, licenciamento ambiental, decisão fundiária ou parecer jurídico. A aprovação jurídica da secção permanece condicionada à confirmação da legislação actualmente vigente, dos diplomas específicos de cada zona e da entidade sucessora competente.
4.3.7.3. Matriz de responsabilidades para ZEE, ZFI e parques industriais
Actividade/decisão
R — Executa
A — Responde/aprova
C — Consultado
I — Informado
Definir política e criar polo de desenvolvimento, ZEE, ZFI ou parque com estatuto especial
Órgão central responsável pela promoção do investimento e ministério de tutela, nos termos da regulamentação aplicável
Conselho de Ministros ou outra entidade expressamente competente no diploma específico
Finanças, indústria, Autoridade Tributária/Alfândegas, ambiente, ordenamento, governos locais e sectores abrangidos
Promotor, operador, comunidades, investidores e Tempo
Receber e instruir projecto sujeito a mero registo
APIEX, I.P., ou entidade competente definida no Decreto n.º 8/2024
Entidade competente para o registo, segundo valor, natureza e localização do projecto
Tutelas sectoriais e autoridades responsáveis por licenças ou pareceres
Investidor e Tempo
Receber e instruir projecto sujeito a autorização
APIEX, I.P., como coordenadora do processo geral, sem prejuízo do regime especial
Entidade decisória competente segundo a Lei n.º 8/2023, artigo 22, e o Decreto n.º 8/2024
Finanças, tutela sectorial, ambiente, terras, Banco de Moçambique e governos locais
Investidor, operador e Tempo
Licenciar/certificar operador ou empresa de ZEE/ZFI
Entidade pública competente definida na legislação especial vigente
Órgão expressamente habilitado pelo regime especial e diploma da zona
APIEX, I.P., Autoridade Tributária/Alfândegas, ambiente, trabalho, migração, INSS, município e tutela sectorial
Investidor, operador e Tempo
Validar perímetro, uso 
da terra, lote e ordenamento
Autoridades de terras, cadastro, 
ordenamento e governo local
Entidade fundiária/territorial 
legalmente competente
Entidade de investimento, 
ambiente, operador e comunidade conforme o procedimento aplicável
Investidor e Tempo
Reconhecer e fiscalizar incentivos fiscais e aduaneiros
Autoridade Tributária e Alfândegas
Órgão fiscal ou aduaneiro competente
Finanças, APIEX, I.P., beneficiário, auditoria e entidade do regime especial
Operador e Tempo, apenas quanto à informação autorizada
Certificar segurança e controlar mercadorias de ZFI
Operador/empresa da ZFI e Alfândegas
Autoridade aduaneira competente
Entidade do regime especial, polícia, bombeiros, ambiente e governo local
Transportadores, investidores e Tempo
Licenciamento ambiental, laboral, migratório e sectorial
Entidade sectorial competente
Autoridade emissora da licença ou autorização
APIEX, I.P., operador, empresa, governos locais e demais entidades do procedimento
Investidor e Tempo
Gerir ZEE/ZFI e cumprir obrigações operacionais
Operador e empresas certificadas/licenciadas
Operador pela gestão; autoridade competente pela supervisão pública
Alfândegas, governos locais, utilities, ambiente, trabalho, polícia, bombeiros e comunidades
Investidores e Tempo
Gerir parque industrial sem estatuto especial
Proprietário ou gestor do parque
Proprietário/gestor, sem prejuízo das aprovações públicas aplicáveis
Indústria, terras, ambiente, governo local, utilities, empresas e comunidades
Investidores e Tempo
Fundamentar, realizar audiência prévia e decidir
Órgão instrutor e entidade decisória
Entidade competente pelo registo ou autorização
Investidor e órgãos que emitiram pareceres
Partes legalmente interessadas; Tempo quando autorizado
Validar e publicar informação no portal
Tempo — Produto, Conteúdo e Dados
Dono do Produto pela publicação; entidade pública pelo conteúdo oficial
Jurídico e Conformidade, APIEX, I.P., Autoridade Tributária, operador, tutelas e proprietário do dado
CRM, investidores e utilizadores
Captar e acompanhar investidores
Tempo — CRM e Relações com Investidores
Dono do Produto/Responsável Comercial da Tempo
APIEX, I.P., operador, promotor, tutela e Jurídico
Investidor e pontos focais
Monitorar implementação, desempenho e cumprimento
Investidor, operador, APIEX, I.P. e autoridades sectoriais segundo a matéria
Órgão legalmente competente pelo indicador ou obrigação
INE, Banco de Moçambique, Autoridade Tributária, governos locais, ambiente, trabalho e Tempo
Comité Executivo e público, apenas com dados autorizados
4.3.7.5. Coerência transversal e condições de implementação
Base normativa principal e hierarquia de aplicação:
 a auditoria jurídica dos RF-ZON tem como fundamento principal a 
Lei n.º 8/2023, de 9 de Junho
. A estrutura de artigos foi confirmada pelo texto publicado: artigos 1–3, disposições gerais; artigos 4–5, política de investimento; artigos 6–13, garantias, direitos e deveres; artigos 14–20, operações de investimento, incentivos e polos de desenvolvimento; artigos 21–23, procedimentos; artigos 24–27, acompanhamento, reclamações e garantias; artigos 28–31, disposições finais. O 
Decreto n.º 8/2024, de 7 de Março
 regulamenta o processo geral de investimento privado e revogou o Decreto n.º 43/2009 e o Decreto n.º 20/2021, mas não regula especificamente ZEE, ZFI e ZETI. Por isso, a componente especial desta secção deve ser completada por legislação especial vigente e diplomas próprios de cada zona. A Lei n.º 3/93 e o Decreto n.º 43/2009 permanecem apenas como referências históricas e não podem fundamentar competências, prazos ou decisões actuais.
Módulo/artefacto relacionado
Regra de coerência
Evidência exigida
Corredores e clusters
ZEE, ZFI e parques usam os mesmos IDs mestres de território, projecto, empresa, infra-estrutura e actor; a ligação nó territorial → zona/parque → projecto → cluster não duplica cadastros.
Relações bidireccionais, fonte, período, papel e testes de unicidade.
GIS/PostgreSQL/PostGIS
Perímetros oficiais, áreas aduaneiras, lotes e instalações aplicam as mesmas regras de SRID, validade, versionamento, autorização e qualidade definidas para corredores.
Validação geométrica, reconciliação e aprovação do proprietário do dado.
Balcão único e jornada do investidor
A mesma identidade e os mesmos dados comuns alimentam manifestação de interesse, pedido de certificação, licenças e acompanhamento; cada acto continua sob competência da entidade pública.
Checklist legal versionada, protocolo, estados, prazos e trilho de decisão.
CRM
Interesses, candidaturas, reuniões, pendências e pós-investimento criam um único processo por investidor–zona–projecto e não confundem lead comercial com pedido administrativo.
Chave de deduplicação, origem, responsável, SLA, próxima acção e consentimento.
Centro legal e conteúdo
Diplomas, artigos, benefícios, formulários, prazos e autoridades têm fonte, vigência, versão, estado e revisão jurídica; referências históricas não são publicadas como direito vigente.
Registo de validação, alerta de mudança e retirada controlada.
Monitoria e indicadores
Investimento autorizado, realizado e pipeline permanecem separados; produção, exportação, vendas internas, emprego, benefícios e ocupação usam definições harmonizadas.
Fórmula, unidade, período, origem, nível de confiança e reconciliação.
Segurança, privacidade e auditoria
Dados aduaneiros, fiscais, laborais, pessoais e comerciais recebem classificação, controlo de acesso, retenção e segregação de funções compatíveis com os módulos transversais.
Matriz de acesso, logs, testes de autorização, incidente e recuperação.
MVP e roteiro
O MVP publica cadastro, fichas, pesquisa, dados validados, captação/CRM, GIS, indicadores e governação; licenciamento transaccional, controlo aduaneiro detalhado e integrações externas permanecem condicionados às Fases 2–3.
Rastreabilidade RF-ZON → entidade → ecrã/API → teste → fase e decisão Go/No-Go.
Integração e governação:
 ZEE, ZFI e parques industriais deverão integrar o GIS, o catálogo de oportunidades, os corredores, os clusters, o CRM, o balcão único, o centro legal, os painéis e o pós-investimento. A entidade gestora responde pelos dados operacionais; as autoridades competentes validam o estatuto, incentivos, requisitos aduaneiros, fiscais, ambientais e laborais; a Tempo administra a experiência digital, a qualidade editorial e a captação. A entrada no MVP exige pelo menos uma ZEE e uma ZFI com perímetro e base legal validados, gestor nomeado, dados mínimos completos, ficha bilingue aprovada, formulário ligado ao CRM, fontes visíveis e ausência de benefícios não confirmados. Parques industriais sem estatuto especial deverão permanecer identificados como parques, sem inferência automática de benefícios de ZEE ou ZFI.
4.4. Módulo Experiência Integrada do Investidor
O módulo Experiência Integrada do Investidor deverá unificar promoção, inteligência de mercado, transacção assistida, identidade digital, interoperabilidade, balcão único, acompanhamento pós-investimento e serviços de suporte numa única conta, um único perfil e uma única jornada. O investidor deverá reutilizar dados e documentos autorizados, acompanhar todos os processos num painel consolidado e receber recomendações, alertas e orientação contextual, sem que a plataforma substitua decisões oficiais, diligência independente ou validação humana.
4.4.1. Arquitectura da jornada única
Etapa da jornada
Capacidades integradas
Resultado para o investidor
Descobrir e explorar
Conteúdo, mapas, sectores, clusters, corredores, projectos, negócios, reguladores e inteligência de mercado.
Lista de oportunidades e territórios relevantes, com fontes, riscos e critérios de comparação.
Registar e verificar
Conta única, identidade digital, organização, representantes, consentimentos e nível de garantia.
Perfil reutilizável e acesso proporcional ao risco de cada serviço.
Preparar e manifestar interesse
Favoritos, dossier, checklist, formulário pré-preenchido, documentos e agendamento.
Submissão sem repetição desnecessária de dados e protocolo rastreável.
Qualificar e transaccionar
CRM, correspondência, sala segura, diligência, tarefas, reuniões e aprovações.
Processo assistido, com estado, responsável, próximos passos e confidencialidade.
Instalar e interoperar
Balcão único, procedimentos, entidades, APIs, eventos, pagamentos e assinatura quando formalmente habilitados.
Visão consolidada de pedidos, dependências, prazos, documentos e decisões.
Operar, resolver e expandir
Pós-investimento, constrangimentos, SLA, conteúdo local, fornecedores, reinvestimento e expansão.
Suporte contínuo ligado ao investimento original e às instituições competentes.
Aprender e recomendar
Indicadores, feedback, IA supervisionada, alertas e personalização.
Orientação explicável e melhoria contínua da jornada.
4.4.2. Requisitos funcionais da Experiência Integrada do Investidor
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-EII-001
Disponibilizar conta única e identidade digital progressiva.
O utilizador cria uma conta, confirma contactos, activa autenticação multifactor quando exigido e recebe nível de garantia compatível com os documentos e verificações concluídos.
MVP
RF-EII-002
Gerir perfil único de pessoa, organização e representação.
Uma pessoa pode representar várias organizações mediante poderes válidos; alterações de identidade, função ou mandato ficam versionadas e afectam imediatamente as permissões.
MVP
RF-EII-003
Reutilizar dados e documentos com consentimento e finalidade definidos.
O investidor escolhe os dados reutilizáveis; o sistema mostra origem, finalidade, destinatário, validade e versão e impede reutilização além da autorização concedida.
MVP
RF-EII-004
Orquestrar uma jornada única desde a descoberta ao pós-investimento.
Todos os passos, estados, responsáveis, tarefas, documentos, decisões e interacções conservam um identificador de jornada e ligação ao CRM, projecto, cluster, corredor e organização aplicáveis.
MVP
RF-EII-005
Disponibilizar painel único do investidor.
O painel reúne perfil, oportunidades guardadas, manifestações, processos, tarefas, reuniões, documentos, notificações, constrangimentos, investimentos e recomendações, respeitando as permissões.
MVP
RF-EII-006
Disponibilizar caixa única de tarefas, mensagens e notificações.
Cada item apresenta prioridade, prazo, responsável, origem, estado, acção necessária e histórico; respostas e falhas de entrega ficam auditadas.
MVP
RF-EII-007
Integrar favoritos, comparação, dossiers e manifestação de interesse.
O investidor guarda e compara oportunidades, solicita dossier e inicia formulário pré-preenchido sem perder o contexto de sector, território, cluster, corredor ou campanha.
MVP
RF-EII-008
Disponibilizar cofre documental do investidor.
Documentos possuem categoria, proprietário, versão, validade, classificação, permissões, registo de acesso e reutilização controlada; ficheiros são verificados antes de uso.
MVP
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-EII-009
Integrar o balcão único e serviços institucionais.
Pedidos externos mostram entidade, protocolo, dependências, estado, prazo, custo validado e última sincronização; falhas de integração geram aviso e tarefa manual.
MVP para acompanhamento; Fase 2 para submissão integrada
RF-EII-010
Gerir transacção assistida e sala segura.
Correspondências, autorizações, confidencialidade, diligência, reuniões e documentos reservados seguem perfis, segregação de funções e trilha de auditoria.
MVP assistido; Fase 2 avançada
RF-EII-011
Iniciar e manter o acompanhamento pós-investimento.
A confirmação da instalação ou do compromisso cria um plano pós-investimento ligado ao registo original, com investimento, contactos, obrigações, marcos, indicadores e responsável.
MVP
RF-EII-012
Gerir constrangimentos, pedidos de apoio e escalonamentos.
Cada caso possui categoria, prioridade, impacto, entidade, responsável, SLA, evidências, decisão, solução e satisfação; casos vencidos são escalonados.
MVP
RF-EII-013
Identificar reinvestimento, 
expansão e fornecedores locais.
O sistema relaciona necessidades do investidor com oportunidades, 
financiamento, fornecedores e competências e exige revisão humana antes do encaminhamento.
MVP assistivo; Fase 2 automatizada
RF-EII-014
Personalizar conteúdos e recomendações com IA supervisionada.
A recomendação mostra critérios, fontes, confiança e limitações, permite contestação e nunca toma decisão oficial ou autoriza contacto sem validação aplicável.
MVP assistivo
RF-EII-015
Garantir continuidade entre canais e idiomas.
O contexto é preservado entre portal, correio electrónico, helpdesk e atendimento humano; conteúdos e estados críticos permanecem coerentes em português e inglês.
MVP
RF-EII-016
Disponibilizar APIs, eventos e exportação controlada da jornada.
Integrações usam IDs comuns, autenticação, escopos, consentimento, versionamento, idempotência, auditoria e retorno de erros sem expor dados protegidos.
MVP interno; Fase 3 externa
4.4.3. Indicadores da jornada única
Dimensão
Indicador e fórmula
Periodicidade
Identidade e activação
Taxa de activação = contas activadas ÷ contas criadas; tempo mediano de activação; percentagem por nível de garantia.
Semanal e mensal
Perfil único
Completude do perfil; percentagem de organizações com representante válido; duplicados por mil perfis.
Semanal
Reutilização
Taxa de reutilização = submissões que reutilizaram dados autorizados ÷ submissões elegíveis; campos evitados e consentimentos revogados.
Mensal
Activação da jornada
Utilizadores que guardam, comparam, solicitam dossier ou manifestam interesse ÷ visitantes identificados.
Semanal e mensal
Conclusão
Taxa de conclusão por etapa; abandono de formulários; tempo entre descoberta, submissão, qualificação, diligência, instalação e pós-investimento.
Semanal e mensal
Painel do investidor
Utilizadores activos, frequência, tarefas concluídas no prazo, documentos consultados e notificações accionadas.
Mensal
Interoperabilidade
Pedidos sincronizados, taxa de sucesso, latência, eventos duplicados, reconciliações e intervenções manuais.
Diária e mensal
Pós-investimento
Investimentos acompanhados; constrangimentos abertos, resolvidos e vencidos; tempo médio de resolução; satisfação; reinvestimentos identificados e confirmados.
Mensal e trimestral
Experiência
Satisfação por etapa, esforço percebido, reclamações, reaberturas e recomendação do serviço.
Mensal e trimestral
IA e confiança
Aceitação das recomendações, precisão validada, correcções humanas, contestação, resultados de baixa confiança e incidentes.
Mensal
Cada indicador deverá possuir definição, população, fórmula, unidade, fonte, responsável, meta, linha de base, periodicidade, segmentação, regra de reconciliação e restrição de divulgação. Resultados da IA devem ser medidos separadamente de decisões humanas e não podem ser apresentados como decisões oficiais.
4.4.4. MVP integrado da Experiência do Investidor
Bloco do MVP
Escopo obrigatório
Critério de go-live
Identidade digital
Conta única, verificação de correio electrónico e telefone, MFA baseado em risco, pessoa, organização, representantes, consentimentos e níveis de garantia.
Fluxos de recuperação, revogação, alteração de representante e controlo de acesso testados; nenhum acesso indevido crítico.
Perfil e dados comuns
Perfil único com contactos, sectores, territórios, capacidade, preferências, documentos e consentimento para reutilização.
Dados reutilizados sem duplicação e com origem, versão, finalidade e autorização visíveis.
Painel do investidor
Resumo da jornada, oportunidades guardadas, manifestações, processos, tarefas, reuniões, documentos, notificações, constrangimentos e recomendações.
Todos os registos reconciliam com CRM e sistemas de origem; estados e prazos são consistentes.
Promoção e inteligência
Pesquisa, favoritos, comparação, dossiers e recomendações assistivas ligadas a sectores, territórios, clusters e corredores.
Contexto preservado até à manifestação de interesse; recomendações explicadas e sujeitas a revisão.
Transacção assistida
Lead, qualificação, tarefas, reuniões, autorizações, documentos controlados e estados essenciais da diligência.
Segregação de funções, confidencialidade, SLA e auditoria aprovados.
Acompanhamento institucional
Registo manual ou sincronizado de protocolos, estados, dependências e última actualização dos procedimentos prioritários.
Falhas de integração não ocultam o estado e geram tarefa de reconciliação.
Pós-investimento
Plano de acompanhamento, contactos, marcos, obrigações, casos de constrangimento, SLA, escalonamento, solução, satisfação e oportunidades de expansão.
Cada investimento confirmado possui responsável; casos críticos geram alerta e escalonamento; histórico permanece ligado ao CRM.
IA supervisionada
Assistente de orientação, recomendação de conteúdo e oportunidades, resumo de pendências e alertas de atraso ou dados em falta.
Fontes, explicação, confiança, contestação e revisão humana disponíveis; automações decisórias permanecem desactivadas.
Fora do MVP:
 identidade digital de elevada garantia baseada em integração estatal, assinatura electrónica qualificada, pagamentos públicos integrados, submissão transaccional a todas as entidades, sala segura avançada, 
correspondência
 autónomo, previsão vinculativa e resolução automática de constrangimentos. 
Go/No-Go global:
 o MVP exige testes ponta-a-ponta da conta à fase pós-investimento, privacidade e consentimento, segurança, acessibilidade, recuperação, desempenho, qualidade dos dados, reconciliação CRM, formação, suporte, responsáveis institucionais, métricas mínimas de adopção e ausência de defeitos críticos.
4.4.5. Implementação faseada
Fase
Entregáveis
Critério de passagem
0. Desenho e governação
Mapa da jornada, modelo de identidade, consentimentos, perfil comum, estados, RACI, dados e indicadores.
Arquitectura, riscos, responsáveis e backlog aprovados.
1. Construção do MVP
Identidade digital básica, perfil único, painel, favoritos, CRM, documentos, acompanhamento institucional e pós-investimento.
RF-EII do MVP aceites e testes ponta-a-ponta aprovados.
2. Piloto controlado
Piloto com investidores novos e instalados, helpdesk, formação, métricas e correcções.
Metas de activação, conclusão, SLA, satisfação e qualidade atingidas.
3. Integração institucional
Submissões, eventos, pagamentos e assinatura nos serviços formalmente habilitados.
Acordos, contract tests, privacidade, segurança e continuidade aprovados.
4. Experiência inteligente
Personalização avançada, previsão, aconselhamento pós-investimento e optimização contínua.
Modelos validados, monitorados e aprovados pelo Comité de IA e Dados.
4.5. Consolidação final do modelo de clusters, corredores e experiência do investidor
Com base nas lições do programa de competitividade do Rwanda, o InvestMoz deverá tratar cada cluster como um programa económico coordenado e não apenas como uma categoria de conteúdo. A página, os dados, o CRM, os mapas, as campanhas, a governação e a inteligência artificial devem ligar projectos âncora, corredores, cadeias de valor, empresas, infra-estruturas, financiamento, competências, fornecedores, compradores, mercados e políticas públicas. Esta secção consolida os elementos necessários para transformar o desenho funcional existente num plano executável, evitando duplicações entre clusters, corredores e experiência integrada do investidor.
4.5.1. Navegação integrada e perguntas de decisão
Forma de navegação
Entidades e filtros
Decisão apoiada
Por oportunidade individual
Projecto, negócio existente, procura de capital, aquisição, concessão, fornecimento, parceria e activo.
Seleccionar uma oportunidade concreta, avaliar prontidão, consultar requisitos e manifestar interesse.
Por território
Província, distrito, corredor, ZEE, parque industrial, bacia agrícola, zona turística e nó logístico.
Comparar onde investir segundo infra-estruturas, recursos, mercado, incentivos, riscos e capacidade institucional.
Por cluster económico
Cadeia de valor, elo, empresa âncora, fornecedor, comprador, financiador, regulador, competência e projecto complementar.
Identificar em que parte da cadeia investir, quais lacunas existem e que actores devem participar.
Em qualquer percurso, o portal deverá responder de forma consistente: onde investir; em que elo da cadeia de valor; que infra-estruturas existem; que fornecedores, compradores e financiadores estão disponíveis; que projectos complementares são necessários; que incentivos, licenças, riscos e constrangimentos existem; quem coordena; e qual é a próxima acção do investidor.
4.5.2. Matriz consolidada dos clusters recomendados
Cluster
Projectos âncora e oportunidades
Lacunas a evidenciar
Pontuação / entrada
Agro-indústria e segurança alimentar
A06, A14 e A15; arroz, regadio, processamento, armazenamento, logística e comercialização.
Irrigação, sementes, mecanização, frio, silos, embalagem, certificação, financiamento e compradores.
91 — MVP completo.
Energia e industrialização
A01, A05, A08 e A10; parques, transmissão, 
geração e grandes consumidores.
Subestações, geração complementar, manutenção, equipamentos, utilities, 
competências e contratos de compra.
89 — MVP completo.
Logística, corredores e exportação
A02, A03 e A11; Nacala, Macuse–Moatize, Norte–Sul, portos, terminais e armazenagem.
Última milha, intermodalidade, terminais, plataformas logísticas, digitalização, fronteiras e carga contratual.
88 — MVP completo.
Turismo costeiro e economia azul
A04 e A13; Crusse Jamali, Vilanculos, Bazaruto, hotelaria, marinas e aviação.
Alojamento, formação, mobilidade, água, energia, serviços digitais, conservação e experiências locais.
77 — Fase 2.
Têxtil, vestuário e algodão
A07; algodão, fiação, tecelagem, confecção, marcas e exportação.
Qualidade, equipamento, formação, certificação, logística, compradores, design e marcas.
74 — Fase 2.
Mineração e transformação mineral
Exploração, processamento, laboratórios, certificação, logística, equipamentos e reabilitação.
Conhecimento geológico, processamento local, energia, financiamento, tecnologia, competências, origem responsável e mercado.
73 — MVP limitado; diligência avançada na Fase 2.
Tecnologia e serviços digitais
Fintech, govtech, centros de dados, incubação, formação e serviços empresariais.
Capital de risco, competências, conectividade, investigação, clientes, propriedade intelectual e internacionalização.
72 — transversal no MVP; expansão na Fase 2.
Financiamento do investimento
Bancos, DFI, fundos climáticos, garantias, venture capital, crédito sectorial e assistência técnica.
Colateral, preparação de projectos, planos de negócio, instrumentos por fase, garantias e blended finance.
Habilitador transversal do MVP.
4.5.3. Página padrão, índice de prontidão e ciclo do cluster
Bloco da página
Conteúdo obrigatório
Controlo
Visão e mercado
Visão, objectivos, procura, oferta, compradores, mercados e proposta de valor.
Fonte, período, responsável e estado de validação.
Território e infra-estruturas
Mapa, corredores, nós, energia, água, transportes, telecomunicações e instalações.
Geometrias e capacidades autorizadas; limitações visíveis.
Cadeia de valor
Elos, empresas âncora, projectos públicos e privados, lacunas e projectos complementares.
IDs únicos, navegação nos dois sentidos e ausência de duplicação.
Ecossistema
Fornecedores, compradores, financiadores, instituições, reguladores, universidades e centros de formação.
Papel, cobertura, verificação e contacto autorizado.
Financiamento e licenciamento
Necessidades, instrumentos, incentivos, licenças, prazos, custos validados e entidades.
Informação oficial separada de estimativas.
Riscos e execução
Constrangimentos, riscos, mitigação, dependências, plano de acção, orçamento e indicadores.
Responsável, prazo, versão e escalonamento.
Conversão
Dossier, chamada para acção, formulário, reunião, evento, fornecedor ou proposta de projecto.
Origem preservada no CRM e consentimento válido.
O ciclo de gestão do cluster deverá seguir dez passos: compreender o mercado; consultar empresas, compradores e financiadores; identificar constrangimentos; seleccionar prioridades; definir visão e metas; estruturar projectos complementares; atribuir responsáveis e orçamento; apoiar empresas e fornecedores; promover 
internacionalmente; medir resultados e corrigir a estratégia. O índice de prontidão do cluster deve medir carteira, infra-estruturas, licenciamento, capacidade institucional, fornecedores, competências, financiamento, mercados, riscos e coordenação.
4.5.4. Critérios Go/No-Go consolidados e rastreabilidade
Domínio
Go
No-Go
Aprovador
Governação
Patrocinador, coordenador, RACI, tutelas, pontos focais e orçamento operacional aprovados.
Ausência de mandato, responsável ou segregação de funções.
Comité Estratégico.
Dados
Completude mínima de 90%, fontes, versões, qualidade, geometrias e responsáveis definidos.
Dados críticos órfãos, contraditórios ou sem autorização.
Secretariado de Dados e tutelas.
Carteira
Pelo menos três oportunidades publicáveis por cluster do MVP e relações com corredor, âncora, elo e território.
Projectos sem promotor, localização, prontidão ou autorização.
Coordenador do cluster/corredor.
Experiência
Conta, perfil, painel, formulário, CRM, SLA, documentos e pós-investimento testados ponta-a-ponta.
Perda de contexto, duplicação ou ausência de responsável e próxima acção.
Dono do Produto.
Segurança e conformidade
Privacidade, consentimento, autenticação, permissões, auditoria, retenção, acessibilidade e recuperação aprovadas.
Defeito crítico, exposição indevida ou base legal não validada.
Segurança, Jurídico e Conformidade.
IA
Fontes autorizadas, explicação, confiança, revisão humana, contestação, métricas e suspensão operacional.
Modelo sem dados adequados, baixa confiança, enviesamento material ou decisão automática indevida.
Comité de IA e Dados.
Operação
Formação, helpdesk, suporte, monitoria, contingência, comunicação e indicadores disponíveis.
Equipa sem capacidade, SLA indefinido ou ausência de suporte.
Direcção da Tempo.
Capacidade
Requisitos
Dados / APIs
Teste de aceitação
Fase
Navegação por oportunidade, território e cluster
RF-CLU-001–004; RF-COR-001–005; RF-EII-007.
clusters, corredores, locais, projectos, relações e pesquisa.
Utilizador percorre os três caminhos e chega à mesma oportunidade sem inconsistência.
MVP.
Âncora, cadeia e projecto complementar
RF-CLU-002–003; RF-COR-002–004.
IDs mestres e tabelas associativas para corredor, âncora, cluster, elo e complemento.
Oportunidade preserva os sete elos até ao CRM e não cria relações órfãs.
MVP.
Inteligência territorial
RF-CLU-004; RF-COR-001, 005 e 009; RF-GEO-001–010.
GIS, camadas, fontes, geometrias, capacidade e autorização.
Mapa e comparação reproduzem dados validados e ocultam informação restrita.
MVP visual; Fase 2 comparativa.
Correspondência e captação
RF-CLU-005 e 008; RF-COR-008; RF-CRM-003–008; RF-EII-004–007.
investidores, interesses, leads, oportunidades, campanhas e consentimentos.
Lead recebe origem, relações, responsável, pontuação e próxima acção.
MVP assistido.
Programas e governação
RF-CLU-006 e 011; RF-COR-010 e 012.
programas, acções, decisões, orçamento, riscos, responsáveis e auditoria.
Alteração material exige nova versão, aprovação e histórico.
Governação no MVP; programas na Fase 2.
Experiência única e pós-investimento
RF-EII-001–016.
identidade, perfil, jornada, painel, documentos, casos, SLA e integrações.
Teste ponta-a-ponta desde a conta até à resolução de um constrangimento pós-investimento.
MVP.
IA supervisionada
RF-COR-016; RF-EII-014; requisitos de IA do documento.
fontes, modelos, versões, recomendações, feedback, confiança e incidentes.
Recomendação é explicável, contestável, auditável e não executa decisão oficial.
MVP assistivo; Fases 2–3 avançadas.
4.5.5. Modelo físico integrado, backlog único e plano de execução
Domínio físico
Tabelas essenciais
Relações e controlos
Território e GIS
geo_locations, geo_geometries, geo_layers, geo_sources, geo_authorizations.
Hierarquia territorial, ponto/linha/polígono, versão, precisão, fonte e nível de divulgação.
Corredores
dev_corridors, corridor_locations, corridor_nodes, corridor_infrastructures, corridor_risks.
Área de influência, nós, capacidade, riscos, coordenador, estado e histórico.
Clusters e cadeias
economic_clusters, cluster_value_chains, value_chain_links, cluster_actors, cluster_gaps.
Subclusters, elos, actores, lacunas, prioridade, fonte, validade e versão.
Projectos
projects, project_roles, project_locations, project_clusters, anchor_relations, complementary_relations.
Tipo âncora/complementar, prontidão, promotor, território, corredor, cluster, elo e dependências.
Programas e execução
programs, initiatives, action_items, dependencies, decisions, risk_register, indicator_results.
Responsável, parceiros, orçamento, prazo, meta, estado, evidência e escalonamento.
Investidor e jornada
crm_investors, crm_contacts, investor_profiles, investor_journeys, journey_steps, investor_documents, investor_cases.
Identidade, organização, consentimentos, painel, CRM, pós-investimento e auditoria.
IA e monitoria
ai_models, ai_model_versions, ai_recommendations, ai_feedback, ai_incidents, data_quality_alerts.
Fonte, finalidade, confiança, explicação, revisão, decisão humana, suspensão e histórico.
Épico
Entregáveis
Responsável
Estimativa
E1 — Governação e dados mestres
Taxonomias, RACI, fontes, catálogos, regras de validação e migração piloto.
Dono do Produto e Líder de Dados.
4–6 semanas.
E2 — Território, corredores e clusters
Modelo físico, GIS, corredores, clusters, cadeias, relações e projectos complementares.
Arquitecto de Dados e Líder GIS.
8–10 semanas.
E3 — Conteúdo e navegação
Páginas, pesquisa, filtros, mapas, dossiers e publicação bilingue.
Produto, Conteúdo e Frontend.
6–8 semanas.
E4 — Identidade e experiência do investidor
Conta, perfil, consentimentos, painel, documentos, tarefas e notificações.
Segurança, Backend e UX.
8–10 semanas.
E5 — CRM e transacção assistida
Leads, qualificação, oportunidades, reuniões, sala assistida, SLA e campanhas.
Gestor CRM e Líder Backend.
8–10 semanas.
E6 — Pós-investimento
Planos, constrangimentos, escalonamentos, satisfação, reinvestimento e fornecedores.
Relações com Investidores.
5–7 semanas.
E7 — Analítica e IA assistiva
Indicadores, qualidade dos dados, alertas, recomendação explicável e monitoria.
Líder BI e Comité de IA e Dados.
6–8 semanas.
E8 — Integrações e operação
OpenAPI, eventos, reconciliação, segurança, desempenho, formação e suporte.
Arquitecto de Integrações e DevOps.
8–12 semanas.
E9 — Formação técnica e investimento em educação
Taxonomia de competências, matriz de procura/oferta, oportunidades educativas, mapa, captação, painel, indicadores e IA assistiva.
Produto, Tutelas de Educação/Trabalho, Líder de Dados e Relações com Investidores.
8–12 semanas.
Fase integrada
Responsáveis
Entregáveis
Critério de passagem
0. Mobilização
Patrocinador, Produto, MPD/tutelas, Jurídico e Dados.
Mandato, governação, RACI, escopo, orçamento, fontes, riscos e backlog.
Órgãos nomeados, dados autorizados e arquitectura aprovada.
1. Fundação técnica e de dados
Arquitectura, Dados, GIS, Segurança e Integrações.
Modelo físico, migração piloto, identidade, APIs internas, catálogos e ambientes.
Qualidade mínima de 90%, segurança e testes de integração aprovados.
2. MVP integrado
Produto, Desenvolvimento, CRM, Conteúdo, QA e BI.
Três clusters, três corredores, carteira âncora/complementar, páginas, pesquisa, conta, painel, CRM, pós-investimento e indicadores.
Testes ponta-a-ponta, RF do MVP aceites e zero defeitos críticos.
3. Piloto controlado
Gestores sectoriais, Relações com Investidores, Helpdesk e Marketing.
Piloto com investidores, promotores e entidades; campanhas, formação, métricas e correcções.
Metas de activação, qualidade, SLA, conversão e satisfação atingidas.
4. Expansão e interoperabilidade
Integrações, Parceiros, Tutelas, Procurement e Operação.
Novos clusters/corredores, submissões institucionais, assinatura, pagamentos habilitados e sala segura.
Acordos, contract tests, continuidade e conformidade aprovados.
5. Operação inteligente
Produto, Dados, IA, Auditoria e Comité Estratégico.
Optimização, modelos supervisionados, novos serviços, revisão de prioridades e backlog contínuo.
Revisão trimestral e decisão anual de expansão, fusão, suspensão ou reorientação.
Conclusão executiva:
 o desenho consolidado é suficiente para avançar para arquitectura técnica detalhada e preparação do MVP, desde que o modelo físico integrado, a OpenAPI de clusters/corredores/GIS, o backlog único, o RACI institucional e o plano de dados, migração, segurança, IA e operação sejam aprovados como pré-condições. A implementação deverá evitar plataformas paralelas: portal, CRM, GIS, balcão único, clusters, corredores e experiência do investidor devem partilhar os mesmos identificadores, estados, fontes e trilha de auditoria.
4.6. Formação Técnica, Competências e Investimento em Educação
O submódulo deverá converter as lacunas de competências identificadas em projectos, clusters, corredores e territórios em oportunidades estruturadas de investimento na educação e formação profissional. O portal deverá ligar procura de trabalho e competências, oferta formativa, instituições, empregadores, financiadores, fornecedores de equipamento e investidores, preservando a responsabilidade das entidades competentes pela acreditação, certificação e validação curricular. A inteligência artificial poderá detectar lacunas, recomendar percursos e monitorar resultados, mas não poderá certificar instituições, cursos ou pessoas.
4.6.1. Requisitos funcionais
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-EDU-001
Administrar áreas de conhecimento, ocupações, competências, níveis de qualificação e certificações.
Cada item possui código, descrição, sector, nível, entidade de referência, validade, fonte e versão; sinónimos não criam duplicação.
MVP
RF-EDU-002
Mapear necessidades de competências por território, corredor, cluster, projecto âncora e fase.
Cada necessidade indica ocupação, competência, quantidade, nível, prazo, localização, empregador ou fonte, confiança e responsável; estimativas são distinguidas de compromissos.
MVP
RF-EDU-003
Cadastrar instituições e oferta formativa.
Instituição, curso, modalidade, capacidade, duração, localização, requisitos, equipamentos, docentes, custos, acreditação e estado são validados e versionados.
MVP
RF-EDU-004
Calcular lacunas entre procura e oferta formativa.
O sistema compara competências, quantidade, período, território e nível, mostra fonte e limitação e permite revisão por instituição e empregador.
MVP assistivo
RF-EDU-005
Criar oportunidades de investimento em educação.
Uma lacuna validada pode gerar projecto de centro, escola técnica, laboratório, formação móvel, plataforma digital, certificação ou parceria, com localização, beneficiários, CAPEX, OPEX, modelo de receita, promotor, parceiros, maturidade e chamada para acção.
MVP
RF-EDU-006
Relacionar oportunidades educativas com projectos, clusters e corredores.
Cada oportunidade conserva IDs de território, corredor, projecto âncora, cluster, elo, ocupações e competências e permite navegação nos dois sentidos.
MVP
RF-EDU-007
Gerir acreditação, licenciamento e validade documental.
Estado, entidade, referência, emissão, validade, condições e documentos são controlados; oferta não acreditada é identificada e não pode ser apresentada como certificada.
MVP
RF-EDU-008
Captar investidores, operadores, financiadores e fornecedores para oportunidades educativas.
O formulário recolhe papel, capacidade, experiência, instrumento, localização e horizonte; o CRM cria lead, responsável e próxima acção.
MVP
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-EDU-009
Gerir manifestações de procura de formação pelos empregadores.
Empregadores registam ocupações, quantidade, local, data, turnos, requisitos e possibilidade de estágio ou contratação; alterações ficam historizadas.
MVP
RF-EDU-010
Gerir propostas de formação por instituições e operadores.
A proposta responde a uma necessidade, informa currículo, capacidade, equipa, equipamento, calendário, custo, certificação, riscos e resultados esperados.
Fase 2
RF-EDU-011
Gerir correspondência entre empregadores, instituições, formandos, investidores e financiadores.
A recomendação apresenta critérios, condições eliminatórias, fonte e confiança e exige revisão humana antes do encaminhamento.
Fase 2
RF-EDU-012
Monitorar execução dos projectos e programas de formação.
O sistema acompanha orçamento, vagas, inscrições, frequência, conclusão, certificação, estágio, colocação, empregador, SLA, riscos e satisfação.
MVP para indicadores essenciais; Fase 2 completa
RF-EDU-013
Gerir conteúdos, campanhas, bolsas e janelas de financiamento.
Cada campanha relaciona público, área, território, curso, projecto, financiador, orçamento, inscrições, conversão e resultados.
Fase 2
RF-EDU-014
Aplicar IA supervisionada à previsão de competências e aconselhamento.
A IA apresenta dados, horizonte, pressupostos, confiança, explicação e limitações; nenhuma recomendação é certificação, admissão ou promessa de emprego.
MVP assistivo
RF-EDU-015
Disponibilizar painel de competências e investimento educativo.
O painel mostra procura, oferta, lacunas, oportunidades, financiamento, execução, colocação, qualidade e impacto com registos de origem.
MVP
RF-EDU-016
Disponibilizar APIs e exportação controlada.
Integrações aplicam IDs comuns, autenticação, escopos, consentimento, confidencialidade, versionamento, idempotência e auditoria.
MVP interno; Fase 3 externa
4.6.2. Matriz inicial de necessidades de competências
Corredor / território
Clusters e projectos âncora
Famílias de competências prioritárias
Referência detalhada
Nacala e Norte
Logística, energia, indústria, mineração e turismo; A03, A04 e A05.
Logística e portos; energia e manutenção; mineração responsável; turismo; línguas; saúde e segurança.
Consultar a matriz completa da secção 4.6.6.
Beira e Centro
Agro-indústria, têxtil, logística e energia; A06 e A07.
Agronomia e regadio; processamento e frio; têxtil; manutenção; qualidade e exportação.
Consultar a matriz completa da secção 4.6.6.
Zambeze–Macuse
Energia, logística, mineração, indústria, serviços urbanos e clima; A08–A12.
Energia e infra-estruturas; ferrovia e porto; mineração; ambiente; GIS; resiliência e gestão urbana.
Consultar a matriz completa da secção 4.6.6.
Maputo–Limpopo
Agro-indústria, água, logística e indústria; A14 e A15.
Água e regadio; agricultura de precisão; agroprocessamento; 
logística; manutenção e segurança alimentar.
Consultar a matriz completa da secção 4.6.6.
Inhambane–Bazaruto
Turismo, economia azul, aviação, conservação e serviços; A13.
Turismo e hotelaria; economia azul; segurança marítima; conservação; aviação; línguas e marketing.
Consultar a matriz completa da secção 4.6.6.
Industrial Nacional Norte–Sul
Indústria, logística, energia e tecnologia; A01 e A02.
Mecatrónica; automação; manutenção; qualidade; segurança; transportes; dados e cibersegurança.
Consultar a matriz completa da secção 4.6.6.
A matriz é uma linha de base e deve ser validada por empregadores, tutelas sectoriais, instituições de ensino, reguladores profissionais, governos locais e dados de procura. Cada necessidade deverá indicar quantidade, nível, prazo, local, modalidade, evidência e nível de confiança antes de gerar uma oportunidade publicável.
4.6.3. MVP de competências e investimento em educação
Bloco do MVP
Escopo obrigatório
Critério de go-live
Taxonomia
Áreas de conhecimento, ocupações, competências, níveis, certificações e entidades responsáveis.
Catálogo validado, sem duplicações e com versão.
Procura por competências
Necessidades dos corredores e clusters do MVP, ligadas a projectos âncora e territórios.
Pelo menos cinco necessidades validadas por corredor piloto, com fonte e prazo.
Oferta formativa
Instituições, cursos, capacidade, localização, acreditação e contacto autorizado.
Estado de acreditação visível e informação confirmada pela entidade competente.
Oportunidades educativas
Pelo menos seis oportunidades: uma por corredor prioritário, com modelo de investimento, promotor e chamada para acção.
Local, procura, beneficiários, CAPEX/OPEX indicativos, modelo de receita, parceiros, riscos e autorização completos.
Pesquisa e mapa
Filtros por corredor, cluster, projecto, área, ocupação, nível, modalidade e instituição.
Resultados preservam relações e ocultam dados reservados.
Captação no CRM
Formulários para investidor, operador educativo, empregador, financiador e fornecedor.
Lead com origem, oportunidade, papel, responsável e próxima acção.
Painel
Procura, oferta, lacunas, oportunidades, leads, financiamento e indicadores de execução.
Totais reconciliados com dados de origem e actualização visível.
IA assistiva
Detecção de lacunas, sugestão de áreas e alertas de dados em falta.
Recomendação explicável, confiança visível e validação humana obrigatória.
Fora do MVP:
 matrícula individual, gestão académica integral, emissão de certificados, pagamentos de propinas, reconhecimento automático de qualificações, recomendação vinculativa de carreira e promessa de colocação. 
Go/No-Go:
 acreditação e bases legais validadas; responsáveis nomeados; procura comprovada; pelo menos uma instituição ou operador interessado por oportunidade; segurança, privacidade, acessibilidade, CRM, suporte e qualidade dos dados aprovados; nenhum conteúdo pode sugerir certificação ou emprego garantido.
4.6.4. Indicadores
Dimensão
Indicador e fórmula
Periodicidade
Procura
Necessidades activas por ocupação, nível, território, cluster, projecto e prazo; trabalhadores requeridos.
Mensal e trimestral
Oferta
Instituições, cursos, vagas, docentes, equipamentos e acreditações válidas por local e área.
Trimestral
Lacuna
Lacuna de vagas = procura validada − capacidade formativa disponível no mesmo período, nível e território.
Trimestral
Oportunidades
Projectos educativos por fase, valor, modalidade, corredor e cluster; percentagem com promotor e financiamento.
Mensal
Captação
Leads, operadores, investidores, financiadores, reuniões, propostas e valor do pipeline educativo.
Mensal
Execução
Vagas criadas, inscrições, frequência, taxa de conclusão = concluintes ÷ inscritos, certificação e custo por formando.
Mensal e trimestral
Empregabilidade
Taxa de colocação = formandos empregados na área até ao prazo definido ÷ concluintes elegíveis; estágios e retenção.
Trimestral e semestral
Conteúdo local
Percentagem de vagas dos projectos cobertas por trabalhadores formados localmente; contratos com instituições e formadores nacionais.
Trimestral
Qualidade
Satisfação de formandos e empregadores, conclusão, desistência, reclamações, auditorias e validade dos dados.
Trimestral
IA
Precisão validada das previsões, aceitação das recomendações, correcções humanas, baixa confiança e incidentes.
Trimestral
4.6.5. Roadmap de implementação
Fase
Responsáveis
Entregáveis
Critério de passagem
0. Mobilização e validação
Produto, tutelas da educação/trabalho, tutelas sectoriais, empregadores e instituições.
Governação, taxonomia, fontes, matriz inicial, RACI, riscos e backlog.
Responsáveis nomeados; catálogos e método aprovados.
1. Dados e desenho
Dados, GIS, Educação, CRM, UX e Arquitectura.
Modelo de dados, protótipos, formulários, mapas, oferta e procura piloto.
Dados mínimos acima de 90% nos corredores piloto e estados de acreditação validados.
2. Construção do MVP
Desenvolvimento, Conteúdo, CRM, BI, Segurança e QA.
Cadastro, matriz, oportunidades, pesquisa, mapa, captação, painel e IA assistiva.
RF-EDU do MVP aceites; testes ponta-a-ponta aprovados; zero defeitos críticos.
3. Piloto
Coordenadores de corredores, instituições, empregadores, Relações com Investidores e Helpdesk.
Piloto em Nacala, Beira/Centro e Zambeze–Macuse; campanhas, reuniões e correcções.
Metas de dados, leads, resposta, satisfação e utilidade atingidas.
4. Expansão
Produto, Tutelas, Financiadores, Procurement e Operação.
Maputo–Limpopo, turismo e rede industrial; propostas formativas, bolsas e matching assistido.
Procura comprovada, operadores e financiamento mínimo confirmados.
5. Integração e operação inteligente
Integrações, IA, Dados, Auditoria e Comité Estratégico.
APIs, eventos, monitoria, previsão de competências, avaliação de impacto e melhoria contínua.
Segurança, contract tests, métricas dos modelos e governança aprovadas.
4.6.6. Matriz completa de competências e oportunidades educativas
A matriz completa detalha a linha de base da secção 
4.6.6
. Quantidades, datas e níveis definitivos devem ser preenchidos após validação dos empregadores, tutelas e instituições; 
o portal não deverá converter estimativas não confirmadas em compromissos de contratação ou procura garantida.
Corredor / projecto âncora
Cluster / elo
Ocupações e competências
Nível / modalidade
Horizonte e evidência
Oportunidade educativa
Nacala e Norte — A03
Logística; transporte; terminais; comércio exterior.
Operador ferroviário e portuário; planeador logístico; manutenção de material circulante; carga, armazenagem, alfândega, segurança e dados operacionais.
Certificação profissional, técnico médio, formação dual e reciclagem.
Curto e médio prazo; validar com operadores, terminais, transportadores e projecções de carga.
Academia logística e portuária; simuladores; centro de manutenção ferroviária.
Nacala e Norte — A04
Turismo; hotelaria; serviços; economia azul.
Hotelaria, restauração, línguas, gestão de destinos, guias, eventos, marketing digital, conservação e atendimento.
Certificação profissional, técnico médio e formação em serviço.
Médio prazo; validar com promotor, operadores turísticos e plano da ZEE.
Escola de hotelaria; centro de línguas; laboratório de experiência turística.
Nacala e Norte — A05
Energia; transmissão; construção e manutenção.
Electricista de alta tensão, técnico de subestação, linhas, protecção, SCADA, segurança, ambiente, montagem e manutenção.
Técnico médio, especialização, certificação de segurança e formação dual.
Curto e médio prazo; validar com tutela da energia, operador e empreiteiros.
Centro de energia e manutenção; laboratório de protecção e automação.
Beira e Centro — A06
Agricultura; regadio; processamento; logística alimentar.
Agronomia, irrigação, mecanização, extensão, qualidade, processamento, frio, armazenagem, segurança alimentar e gestão cooperativa.
Formação profissional, técnico médio, extensão móvel e formação de formadores.
Curto prazo e sazonal; validar com produtores, processadores, regadios e compradores.
Centro agroindustrial; escola de regadio; laboratório alimentar; unidades móveis.
Beira e Centro — A07
Algodão; têxtil; vestuário; exportação.
Classificação de fibra, fiação, tecelagem, tingimento, confecção, manutenção, qualidade, 
design, produção enxuta e comércio exterior.
Técnico médio, formação dual, certificação industrial e especialização.
Médio prazo; validar com promotor do parque, produtores, marcas e compradores.
Escola têxtil; laboratório de qualidade; academia de design e exportação.
Zambeze–Macuse — A08
Indústria; ZEE; utilities; manutenção.
Mecatrónica, electricidade, água industrial, operação de parque, manutenção, segurança, qualidade, logística e gestão de instalações.
Técnico médio, formação dual e certificações ocupacionais.
Médio prazo; validar com entidade gestora e futuros inquilinos.
Instituto técnico industrial de Mocuba; academia de gestão de parques.
Zambeze–Macuse — A09
Construção; serviços urbanos; gestão de instalações.
Obras civis, instalações eléctricas e hidráulicas, manutenção predial, segurança, sustentabilidade, gestão documental e serviços digitais.
Formação profissional, técnico médio e certificação de instalações.
Por fases de construção e operação; validar com promotor e autoridades locais.
Centro de construção e instalações; formação em facilities management.
Corredor / projecto âncora
Cluster / elo
Ocupações e competências
Nível / modalidade
Horizonte e evidência
Oportunidade educativa
Zambeze–Macuse — A10
Energia; hidroelectricidade; construção; ambiente.
Hidromecânica, electrotecnia, turbinas, barragens, transmissão, obras civis, segurança, ambiente, reassentamento e gestão de projecto.
Técnico médio, especialização superior, certificação e formação dual.
Construção e operação; validar com promotor, tutela e plano de contratação.
Instituto de energia e infra-estruturas; simulador de operação; academia HSE.
Zambeze–Macuse — A11
Ferrovia; porto; mineração; logística.
Via-férrea, sinalização, material circulante, terminal, operação portuária, logística mineral, manutenção, segurança e comércio exterior.
Certificação profissional, técnico médio e formação dual.
Por fase do corredor; validar com promotor, operadores e projecções de carga.
Academia ferroviária e portuária; centro de manutenção; simuladores.
Zambeze–Macuse — A12
Clima; conectividade; água; comunidades.
Resiliência climática, GIS, hidrologia, 
obras costeiras, monitoria ambiental, gestão comunitária, manutenção viária e dados.
Técnico médio, especialização, formação comunitária e 
formação de formadores.
Curto e médio prazo; validar com entidade 
gestora, governo provincial e comunidades.
Academia de ambiente e clima; laboratório GIS; 
centros móveis comunitários.
Maputo–Limpopo — A14
Agro-indústria; ZEE; processamento; logística.
Agricultura de precisão, irrigação, processamento, embalagem, qualidade, manutenção, armazenagem, gestão de ZEE e exportação.
Técnico médio, formação dual, extensão e certificação alimentar.
Curto e médio prazo; validar com entidade gestora, empresas e produtores.
Escola de agroprocessamento; laboratório alimentar; incubadora de agronegócio.
Maputo–Limpopo — A15
Água; regadio; agricultura; manutenção.
Gestão hídrica, operação de canais, bombagem, manutenção electromecânica, solos, extensão, GIS, segurança e gestão de associações.
Formação profissional, técnico médio e unidades móveis.
Curto prazo e contínuo; validar com tutela das águas, agricultura e beneficiários.
Centro de água e regadio; laboratório de irrigação; formação móvel.
Inhambane–Bazaruto — A13
Turismo; economia azul; aviação; conservação.
Hotelaria, restauração, guias, línguas, marina, segurança marítima, mergulho, conservação, aviação, marketing e gestão de experiências.
Certificação profissional, técnico médio, formação em serviço e línguas.
Curto e médio prazo; validar com operadores, conservação e aviação.
Escola de turismo; academia marítima; centro de línguas; laboratório digital.
Industrial Nacional — A01
Parques industriais; utilities; manufactura; tecnologia.
Mecatrónica, automação, manutenção, qualidade, produção enxuta, segurança, utilities, gestão de parques, 
dados e cibersegurança.
Técnico médio, formação dual, microcredenciais e certificações industriais.
Contínuo por parque; validar com inquilinos e planos provinciais.
Rede de academias industriais nos parques; laboratórios de automação.
Industrial Nacional — A02
Ferrovia; logística; engenharia; gestão de activos.
Via, sinalização, telecomando, energia de tracção, material circulante, planeamento, segurança, manutenção e gestão de activos.
Técnico médio, especialização e formação dual.
Longo prazo por troço; validar com estudos, operador e empreiteiros.
Academia ferroviária nacional; centros regionais de manutenção e simulação.
4.6.7. Testes de aceitação dos requisitos RF-EDU
ID
Teste positivo
Teste negativo / autorização
Resultado esperado
RF-EDU-001
Criar competência com código, nível, sector, fonte e versão.
Tentar duplicar por sinónimo ou alterar versão activa sem aprovação.
Registo único criado; duplicado bloqueado ou associado; alteração auditada.
RF-EDU-002
Registar necessidade ligada a território, corredor, cluster, âncora, ocupação, quantidade e prazo.
Submeter sem fonte, local, responsável ou distinguir estimativa de compromisso.
Necessidade válida fica disponível; registo incompleto permanece em rascunho.
RF-EDU-003
Cadastrar instituição e curso com capacidade, localização e acreditação.
Publicar curso expirado, não verificado ou sem identificar ausência de acreditação.
Estado correcto é apresentado; oferta não validada não aparece como certificada.
RF-EDU-004
Comparar procura e oferta no mesmo território, período, nível e competência.
Comparar unidades, períodos ou níveis incompatíveis sem conversão explícita.
Lacuna reproduzível, com fonte, fórmula, limitações e revisão disponível.
RF-EDU-005
Converter lacuna validada em oportunidade educativa completa.
Publicar sem promotor, localização, beneficiários, modelo financeiro, riscos ou autorização.
Oportunidade recebe ID e estado de prontidão; publicação fica bloqueada até completar requisitos.
RF-EDU-006
Navegar da oportunidade para corredor, âncora, cluster, elo e competências e regressar.
Eliminar relação usada por oportunidade activa ou criar relação duplicada.
Rastreabilidade bidireccional preservada; remoção ou duplicação bloqueada/auditada.
RF-EDU-007
Registar acreditação válida com entidade, referência e validade.
Aceder a documento restrito sem permissão ou manter oferta como válida após expiração.
Acesso negado e auditado; expiração altera estado e gera alerta.
RF-EDU-008
Submeter interesse de investidor, operador, 
financiador ou fornecedor.
Submeter sem consentimento, contacto verificável ou papel definido.
Lead único criado com origem, oportunidade, responsável e 
próxima acção; inválido é rejeitado.
ID
Teste positivo
Teste negativo / autorização
Resultado esperado
RF-EDU-009
Empregador regista procura com ocupação, quantidade, local, prazo e possibilidade de estágio.
Alterar procura confirmada sem nova versão ou publicar informação confidencial.
Histórico preservado; dados públicos limitados ao nível autorizado.
RF-EDU-010
Instituição apresenta proposta ligada a necessidade validada.
Submeter currículo, capacidade ou certificação incompatível com a necessidade.
Proposta validável é encaminhada; incompatibilidades geram pendências explicadas.
RF-EDU-011
Gerar correspondência com critérios, evidências e confiança.
Encaminhar automaticamente apesar de condição eliminatória ou sem revisão humana.
Recomendação fica explicada; encaminhamento bloqueado até validação.
RF-EDU-012
Registar vagas, inscritos, concluintes, certificados, estágios e colocação.
Informar colocação sem período, elegibilidade, empregador ou evidência.
Indicadores reconciliam com registos de origem; dados incompletos não entram no resultado confirmado.
RF-EDU-013
Criar campanha ou bolsa ligada a área, território, curso e financiador.
Ultrapassar orçamento ou comunicar elegibilidade não aprovada.
Limite e mensagem são controlados; excepção exige aprovação e fica auditada.
RF-EDU-014
IA prevê lacuna e mostra horizonte, dados, pressupostos, confiança e limites.
Apresentar recomendação como certificação, admissão ou emprego garantido.
Saída assistiva e contestável; linguagem indevida bloqueada; decisão permanece humana.
RF-EDU-015
Filtrar painel por corredor, cluster, projecto, competência e período.
Exportar dados pessoais ou restritos sem escopo.
Totais reconciliados e data visível; exportação mascarada ou negada.
RF-EDU-016
Repetir pedido de integração com a mesma chave de idempotência.
Usar token sem escopo, versão incompatível ou payload inválido.
Sem duplicação; acesso negado ou erro padronizado; correlação e auditoria preservadas.
Critério transversal de testes: cada RF-EDU deve possuir casos positivos, negativos, de autorização, auditoria, integração, recuperação de falhas e acessibilidade. A aceitação exige evidência, responsável, ambiente, dados de teste, resultado esperado, resultado observado, defeito, decisão e data.
4.6.8. Plano de execução consolidado do submódulo
Frente / pacote
Responsável
Apoio
Entregáveis
Duração
Dependências / saída
WP1 — Governação e método
Dono do Produto EDU
Tutelas da educação, trabalho e 
sectores; Jurídico.
Mandato, RACI, taxonomia, método de previsão, critérios de publicação e backlog.
3–4 semanas
Saída: método e responsáveis aprovados.
WP2 — Dados de procura
Líder de Dados
Empregadores, coordenadores de corredores e clusters.
Inventário de necessidades, fontes, quantidades, horizontes, confiança e qualidade.
4–6 semanas
Depende do WP1; saída: dados mínimos ≥90% nos pilotos.
WP3 — Oferta formativa e acreditação
Coordenador de Educação
Instituições, reguladores e governos locais.
Cadastro de instituições, cursos, capacidade, equipamentos, docentes e documentos.
4–6 semanas
Depende do WP1; saída: estados de acreditação validados.
WP4 — Modelo técnico e GIS
Arquitecto de Solução
Dados, GIS, Backend, Segurança e Integrações.
Modelo físico, APIs internas, relações com corredores/âncoras/clusters, mapas e permissões.
5–7 semanas
Depende de WP1–3; saída: arquitectura e contratos aprovados.
WP5 — Oportunidades educativas
Relações com Investidores
Finanças, instituições, promotores e financiadores.
Seis oportunidades piloto, modelos de receita, CAPEX/OPEX indicativos, riscos e dossiers.
4–6 semanas
Depende das lacunas validadas; saída: oportunidades publicáveis.
WP6 — Produto e CRM
Líder de Desenvolvimento
UX, Frontend, Backend, CRM e Conteúdo.
Pesquisa, mapa, formulários, páginas, leads, oportunidades, tarefas e painel.
8–10 semanas
Depende de WP4–5; saída: RF-EDU do MVP implementados.
WP7 — Analítica e IA assistiva
Líder BI / IA
Dados, QA, empregadores e Comité de IA.
Indicadores, detecção de lacunas, explicações, confiança, alertas e monitoria.
5–7 semanas
Depende de dados estáveis; saída: modelos e métricas aprovados.
WP8 — Testes, piloto e adopção
Líder QA e Gestor de Mudança
Helpdesk, instituições, empregadores e utilizadores-piloto.
Testes RF-EDU, formação, piloto, suporte, métricas, correcções e decisão Go-Live.
6–8 semanas
Depende de WP2–7; saída: critérios Go/No-Go cumpridos.
Marco
Janela indicativa
Entregável verificável
Critério de passagem
M1 — Mobilização
Semanas 1–4
Governação, taxonomia, fontes, RACI, matriz inicial e piloto definido.
Tutelas e empregadores aprovam método e responsáveis.
M2 — Base de dados validada
Semanas 5–10
Procura e oferta dos três corredores piloto, acreditações e qualidade.
Completude ≥90%; necessidades críticas com fonte, prazo e confiança.
M3 — Arquitectura e oportunidades
Semanas 8–14
Modelo técnico, GIS, APIs internas e seis oportunidades educativas.
Arquitectura, segurança, modelos financeiros e autorização aprovados.
M4 — MVP funcional
Semanas 13–24
Cadastro, pesquisa, mapa, CRM, painel, indicadores e IA assistiva.
RF-EDU do MVP e integrações internas aprovados; zero defeitos críticos.
M5 — Piloto controlado
Semanas 25–32
Piloto em Nacala, Beira/Centro e Zambeze–Macuse, formação e suporte.
Metas de dados, utilização, resposta, satisfação e utilidade atingidas.
M6 — Expansão
Semanas 33–44
Maputo–Limpopo, Inhambane–Bazaruto e rede industrial; propostas e matching assistido.
Procura confirmada, operadores e financiamento mínimo por oportunidade.
M7 — Operação contínua
Após semana 44
APIs externas, previsão revista, avaliação de impacto e backlog trimestral.
Segurança, contract tests, governação de IA e revisão executiva aprovados.
Go/No-Go consolidado:
 o lançamento exige taxonomia e dados validados; procura comprovada e oferta identificada; oportunidades com promotor e modelo de investimento; estados de acreditação correctos; CRM, segurança, privacidade, acessibilidade, auditoria, suporte e recuperação aprovados; responsáveis e SLA definidos; indicadores reconciliados; IA com confiança, explicação, revisão humana e mecanismo de suspensão; e nenhum defeito crítico ou comunicação que prometa certificação, admissão ou emprego.
4.7. Baseline final para implementação do MVP
4.7.1. Alterações finais e secções afectadas
Secção
Estado final
Alteração consolidada
3.1–3.5
Finalizada
Conteúdo do portal, jornada, fornecedores, confiança e benchmark internacional alinhados à conversão.
4.1
Baseline do MVP
Balcão único orientado por eventos, reutilização controlada de dados e acompanhamento de procedimentos.
4.2
Baseline do MVP
Doze RF-CLU consolidados, priorização ponderada, MVP, indicadores, governação e roadmap.
4.3
Baseline do MVP
Corredores, projectos âncora, clusters, projectos complementares, IA, indicadores e roadmap.
4.4
Baseline do MVP
Identidade digital, perfil único, painel, jornada integrada, pós-investimento e interoperabilidade.
4.5
Referência transversal
Navegação integrada, Go/No-Go, rastreabilidade, modelo físico, backlog e plano integrado.
4.6
Baseline do MVP
RF-EDU, procura e oferta de competências, oportunidades educativas, testes e plano de execução.
5–9
Detalhamento funcional
Negócios existentes, PII, localização, IA, formulários, CRM e captação.
10–15
Detalhamento técnico e executivo
Integrações, conformidade, requisitos não funcionais, indicadores, roteiro e decisões.
4.7.2. Escopo fechado do MVP
Componente
Incluído no MVP
Fica para fase posterior
Conteúdo e oportunidades
Catálogo, fichas, negócios existentes, projectos PII, clusters, corredores, dossiers e pesquisa.
Marketplace transaccional autónomo e publicação sem validação institucional.
Território e GIS
Localizações, mapas autorizados, corredores, nós, projectos e filtros.
Cenários avançados e sincronização universal com todas as fontes externas.
Experiência do investidor
Conta, perfil, consentimentos, painel, favoritos, documentos, tarefas e notificações.
Identidade estatal de elevada garantia e assinatura qualificada generalizada.
CRM
Leads, perfil, score, funil, oportunidades, actividades, SLA, campanhas e pós-investimento.
Decisões autónomas, contratação financeira e custódia de fundos.
Clusters e corredores
Três clusters completos, mineração limitada, três corredores piloto e projectos complementares.
Expansão nacional integral, comparação preditiva e automação avançada.
Competências e educação
Taxonomia, procura/oferta piloto, matriz, seis oportunidades, mapa, CRM e painel.
Gestão académica, matrículas, propinas, certificados e garantia de emprego.
IA
Pesquisa assistida, recomendação explicável, alertas, qualidade de dados e resumos.
Decisão oficial, certificação, autorização, scoring opaco e execução sem revisão humana.
Integrações
APIs internas, eventos, CRM, GIS, identidade, notificações e reconciliação prioritária.
Integração transaccional com todas as entidades sem acordo e contract tests.
4.7.3. Checklist final Go/No-Go
Domínio
Condição obrigatória
Evidência
Aprovador
Governação
Patrocinador, Dono do Produto, RACI, comités, coordenadores e pontos focais nomeados.
Mandatos, actas e matriz aprovados.
Comité Executivo.
Escopo e backlog
Épicos E1–E9, histórias Must, dependências e exclusões congelados para o release.
Baseline versionada e aceite.
Dono do Produto.
Dados e conteúdo
Fontes autorizadas, completude mínima acordada, responsáveis, versões e validação institucional.
Relatório de qualidade e aprovação editorial/institucional.
Secretariado de Dados e tutelas.
Arquitectura e integração
Modelo físico, APIs internas, eventos, identidade, GIS, CRM e reconciliação aprovados.
Arquitectura, OpenAPI e contract tests.
Arquitectura e Integrações.
Segurança e conformidade
Privacidade, consentimento, MFA, privilégios, auditoria, retenção, recuperação e acessibilidade testados.
Relatórios de segurança, privacidade e acessibilidade.
Segurança, Jurídico e Conformidade.
Qualidade
Testes funcionais, negativos, autorização, integração, desempenho, recuperação e aceitação concluídos.
Relatório QA sem defeitos críticos.
QA e Negócio.
IA
Dados, finalidade, métricas, explicação, confiança, revisão humana, contestação e suspensão aprovadas.
Ficha do modelo e relatório de validação.
Comité de IA e Dados.
Operação
Formação, helpdesk, SLAs, monitoria, contingência, comunicação e suporte disponíveis.
Plano operacional e simulação de incidente.
Direcção da Tempo.
Piloto
Utilizadores, projectos, clusters, corredores e oportunidades educativas do piloto confirmados.
Plano de piloto, métricas e termo de adesão.
Comité Executivo.
4.7.4. Plano de arranque do MVP — primeiros 30 dias
Período
Acção
Responsável
Resultado verificável
Dias 1–5
Confirmar patrocinador, Dono do Produto, coordenadores, comités, RACI e canais de decisão.
Direcção da Tempo.
Mandatos e calendário de governação aprovados.
Dias 1–10
Congelar o escopo do MVP e priorizar histórias Must dos épicos E1–E9.
Dono do Produto.
Backlog baseline com dependências e critérios de aceite.
Dias 5–15
Inventariar fontes, proprietários, qualidade, restrições e migração dos dados prioritários.
Líder de Dados.
Catálogo de dados e relatório de lacunas.
Dias 5–20
Aprovar arquitectura de solução, modelo físico, ambientes, segurança, GIS, CRM e APIs internas.
Arquitecto de Solução.
Pacote de arquitectura e decisão técnica.
Dias 10–20
Confirmar clusters, corredores, projectos, oportunidades educativas e utilizadores do piloto.
Produto e Relações com Investidores.
Carteira piloto validada e responsáveis nomeados.
Dias 15–25
Preparar protótipos da pesquisa, página de oportunidade, painel e formulários principais.
UX e Produto.
Protótipos testados com utilizadores-chave.
Dias 20–30
Executar planeamento de release, testes, formação, comunicação, suporte e monitoria.
PMO, QA e Operação.
Plano integrado aprovado e decisão de início da construção.
Pendências externas antes da construção:
 nomeação formal dos órgãos e pontos focais; validação jurídica e institucional; confirmação da carteira e dos dados geográficos; escolha dos corredores, clusters e oportunidades educativas do piloto; aprovação do orçamento; contratação ou alocação da equipa; acordos de integração e dados; definição das metas de adopção, qualidade, SLA e conversão; e validação das linhas de base dos indicadores. Estas pendências devem permanecer no registo de decisões até existir evidência formal.
4.8. Transição do portal existente para a arquitectura alvo
A transição deverá preservar o serviço, reutilizar componentes válidos e executar o upgrade tecnológico sem ruptura. A arquitectura alvo adopta React, Laravel e PostgreSQL/PostGIS; o MySQL será inventariado, saneado, migrado e descontinuado por domínio após reconciliação e aceite. A decisão por componente seguirá quatro categorias: Conservar, Melhorar, Substituir ou Descontinuar.
4.8.1. Matriz de transição entre legado e arquitectura alvo
Componente existente
Decisão
Transformação para a arquitectura alvo
Responsável
Critério de aceite
Frontend React
Melhorar
Actualizar versão e dependências; adoptar TypeScript, componentes acessíveis, internacionalização, testes e integração por APIs versionadas.
Líder Frontend e UX.
Páginas críticas sem regressão; acessibilidade, desempenho, PT/EN e testes aprovados.
Backend Laravel
Melhorar
Actualizar Laravel/PHP; modularizar domínios; implementar OpenAPI, filas, eventos, auditoria, autorização e adaptadores de migração.
Líder Backend e Arquitecto.
APIs v1 validadas; testes automatizados; segurança e observabilidade aprovadas.
Base MySQL
Substituir
Mapear schemas, qualidade e dependências; migrar para PostgreSQL/PostGIS 
por domínio; manter replicação ou ETL temporário; desactivar após reconciliação.
Arquitecto de Dados e DBA.
Contagens, chaves, relações, histórico, amostras e consultas 
reconciliados; rollback testado.
Conteúdos “Porquê investir”
Melhorar
Preservar estrutura útil; acrescentar fontes, data, idioma, indicadores e chamadas para acção.
Produto e Conteúdo.
Conteúdo validado, bilingue e ligado a sectores, territórios e CRM.
Actividades económicas
Melhorar
Converter cards genéricos em perfis sectoriais, clusters, cadeias de valor, lacunas e oportunidades.
Conteúdo e Coordenadores de Cluster.
Pesquisa e filtros funcionam; fontes e relações estão completas.
Oportunidades de negócios
Melhorar
Normalizar fichas, maturidade, localização, modalidade, documentos, prontidão e manifestação de interesse.
Produto, CRM e Dados.
Fichas activas migradas sem duplicação e com responsável/estado.
Áreas de investimento
Substituir parcialmente
Evoluir páginas estáticas para PostgreSQL/PostGIS, mapas, corredores, ZEE, parques, bacias e comparação territorial.
GIS e Dados.
Geometrias, fontes, permissões e pesquisa espacial validadas.
Reguladores e links
Melhorar
Manter directório e links válidos; acrescentar serviços, requisitos, fontes, validade e roteiro regulatório.
Jurídico e Conteúdo.
Links, responsáveis e datas verificados; nenhuma integração apresentada como oficial sem acordo.
Formulários existentes
Melhorar
Normalizar campos, consentimentos, validação, rascunho, comprovativo, CRM e acessibilidade.
UX, Backend e CRM.
Testes positivos, negativos, duplicação, segurança e acessibilidade aprovados.
Área reservada / autenticação
Substituir parcialmente
Implementar identidade progressiva, MFA baseado em risco, perfis, organizações e painel único.
Segurança e Backend.
Recuperação, revogação, permissões e auditoria sem falhas críticas.
Indicadores e gráficos ilustrativos
Descontinuar como dados oficiais
Preservar apenas como referência documental; criar linhas de base a partir de dados reais e definições aprovadas.
BI e Secretariado de Dados.
Indicadores mostram fonte, fórmula, período e estado de validação.
Endpoints conceptuais
Descontinuar como contratos
Converter em hipóteses; substituir por OpenAPI confirmada com cada entidade ou por fluxo assistido.
Integrações e Jurídico.
Contrato, autenticação, SLA, ambiente e contract tests aprovados.
4.8.2. Estratégia de upgrade MySQL → PostgreSQL/PostGIS
Etapa
Actividades
Controlo
Critério de passagem
1. Inventário
Versões, tabelas, volumes, índices, rotinas, relatórios, dados órfãos, duplicados e consumidores.
Catálogo de dados, proprietário e criticidade.
100% dos objectos críticos classificados.
2. Desenho alvo
Modelo PostgreSQL/PostGIS, chaves, tipos, geometrias, histórico, auditoria e particionamento quando necessário.
Revisão de arquitectura e segurança.
Modelo físico e mapeamento origem-destino aprovados.
3. Prova de conceito
Migrar amostra representativa; testar mapas, corredores, proximidade, pesquisa e CRM.
Comparação funcional, desempenho e integridade.
Consultas críticas e espaciais atingem metas aprovadas.
4. Migração piloto
ETL/CDC temporário, saneamento, IDs, documentos e reconciliação de um domínio piloto.
Contagens, hashes, amostras e relatório de divergências.
Divergências críticas resolvidas e rollback testado.
5. Migração faseada
Conteúdo, oportunidades, CRM, geografia, clusters/corredores e módulos restantes por ondas.
Janela de corte, dupla leitura controlada e monitoria.
Aceite funcional e técnico por onda.
6. Corte e estabilização
Congelar escrita no MySQL, migrar delta final, validar, activar PostgreSQL e monitorar.
Plano de rollback e equipa de resposta.
Operação estável e indicadores reconciliados.
7. Desactivação
Arquivar, reter conforme política, revogar acessos e remover dependências do MySQL.
Aprovação de Dados, Segurança e Negócio.
Nenhum consumidor activo; evidência de arquivo e encerramento.
4.8.3. Fase Zero — melhorias imediatas na versão existente
Pacote
Melhoria imediata
Responsável
Prazo indicativo
Critério de entrega
Z0-01
Corrigir pesquisa e exemplos para termos de investimento; medir pesquisa sem resultados.
Frontend, Conteúdo e Produto.
1–2 semanas
Consultas prioritárias devolvem resultados relevantes; exemplos de cidadania removidos.
Z0-02
Rever cards sectoriais, eliminar textos repetidos e acrescentar localização, oportunidade, entidade e chamada para acção.
Conteúdo e Tutelas.
2–3 semanas
100% dos cards activos revistos, com fonte e aprovação.
Z0-03
Adicionar selector PT/EN visível e traduzir páginas, formulários, erros e botões prioritários.
UX, Frontend e Tradução.
2–4 semanas
Jornadas críticas completas nos dois idiomas, sem mistura de mensagens.
Z0-04
Criar secção “Como começar” com passos, documentos, entidades e apoio.
Produto, Jurídico e Conteúdo.
1–2 semanas
Conteúdo validado e acessível a partir da página inicial.
Z0-05
Organizar Centro de Recursos Legais por sector, processo, entidade, data e validade.
Jurídico e Conteúdo.
2–4 semanas
Documentos prioritários verificados; fonte e data visíveis; links funcionais.
Z0-06
Melhorar formulários: rascunho, obrigatoriedade, mensagens, consentimento, comprovativo e detecção de duplicados.
UX, Laravel, CRM e QA.
3–5 semanas
Testes positivos, negativos, duplicação, acessibilidade e segurança aprovados.
Z0-07
Adicionar manifestação de interesse, pedido de reunião e apoio especializado com encaminhamento para CRM.
CRM, Backend e Relações com Investidores.
2–4 semanas
Lead criado com origem, responsável, SLA e próxima acção.
Z0-08
Aplicar acessibilidade e desempenho às páginas críticas.
Frontend, UX e QA.
2–4 semanas
Navegação por teclado, contraste, rótulos, textos alternativos, mobile e 
metas de desempenho aprovados.
Z0-09
Instrumentar analítica mínima da jornada e linha de base real.
BI, Produto e Dados.
2–3 semanas
Eventos de pesquisa, cards, dossiers, formulários e contactos reconciliados.
Z0-10
Executar auditoria tecnológica React/Laravel/MySQL e preparar migração PostgreSQL/PostGIS.
Arquitectura, Segurança e Dados.
3–5 semanas
Relatório de versões, dívida técnica, matriz de migração e PoC aprovados.
Critérios globais de conclusão da Fase Zero:
 nenhuma regressão nas páginas existentes; pesquisa, formulários, PT/EN, acessibilidade e chamadas para acção aprovados; conteúdos legais e sectoriais validados; eventos analíticos activos; leads encaminhados ao CRM; vulnerabilidades críticas resolvidas; plano PostgreSQL/PostGIS e matriz de transição aprovados; manual de operação actualizado; e aceite formal do Dono do Produto, Conteúdo, Segurança, Jurídico e Operação. A Fase Zero deverá durar aproximadamente quatro a seis semanas, com execução paralela dos pacotes e sem depender de APIs governamentais ainda não confirmadas.
4.8.4. Matriz de rastreabilidade do legado para o MVP
Activo legado
Requisito futuro / épico
Decisão
Teste de regressão ou migração
Fase
Página inicial, menus e cinco eixos
Jornada e conteúdo; E3.
Melhorar e preservar URLs prioritários.
Navegação, SEO, links, PT/EN, responsividade e chamadas para acção.
Fase Zero e MVP.
Cards sectoriais e páginas informativas
Clusters, territórios e oportunidades; E2–E3.
Transformar.
Conteúdo, fonte, filtros, relações e ausência de duplicação.
Fase Zero e MVP.
Formulários e contactos
CRM e experiência; E4–E5.
Melhorar e migrar.
Validação, consentimento, duplicados, comprovativo e criação de lead.
Fase Zero.
Utilizadores e permissões
Identidade e painel; E4.
Substituir parcialmente.
Mapeamento de identidade, reset, MFA, perfis, organizações e auditoria.
MVP.
Tabelas MySQL de conteúdo e oportunidades
Modelo PostgreSQL; E1–E2.
Migrar e descontinuar.
Contagens, chaves, histórico, textos, moedas, datas e estados reconciliados.
MVP por ondas.
Dados de localização
PostGIS e GIS; E2.
Transformar.
Normalização territorial, geometria, sistema de referência, precisão e fonte.
MVP.
Documentos e links legais
Centro legal; E3.
Conservar e validar.
Integridade, versão, validade, 
proprietário, acesso e ligação.
Fase Zero.
Métricas e gráficos ilustrativos
Analítica; E7.
Descontinuar como baseline.
Substituição por dados reais, fórmula, período e reconciliação.
Fase Zero/MVP.
Integrações ou links institucionais
Interoperabilidade; E8.
Conservar links; validar APIs.
Disponibilidade, contrato, segurança, SLA e alternativa manual.
MVP e fases posteriores.
Conteúdo de competências/formação
Investimento em educação; E9.
Enriquecer.
Relação com corredor, cluster, projecto âncora, procura e oferta.
MVP.
4.8.5. Matriz completa de transição tecnológica e funcional
Activo / domínio
Estado actual
Decisão alvo
Transformação e dados
Dependências / risco
Teste e onda
Frontend React
Portal público e componentes existentes.
Melhorar e reutilizar.
Actualizar versão e bibliotecas; adoptar TypeScript, design system, PT/EN, acessibilidade, telemetria e cobertura de testes.
Inventário de componentes, compatibilidade de pacotes, SEO e URLs; risco de regressão visual.
Regressão, acessibilidade, desempenho e responsive; Fase Zero e Onda 1.
Backend Laravel
Regras e endpoints ligados ao MySQL.
Melhorar e modularizar.
Actualizar PHP/Laravel; separar domínios; OpenAPI; eventos; filas; auditoria; adaptadores para legado.
Dependências não suportadas, lógica em controladores e jobs; risco de quebra de contratos.
Testes unitários, integração, autorização e contract tests; Ondas 1–3.
MySQL
Fonte transaccional do portal existente.
Substituir.
Mapear e sanear; migrar schemas e dados para PostgreSQL/PostGIS; manter apenas leitura/sincronização temporária.
Dados órfãos, codificação, collation, tipos, chaves, SQL específico e indisponibilidade.
Reconciliação integral, desempenho, cutover e rollback; Ondas 1–4.
Conteúdo institucional
Páginas informativas dos cinco eixos.
Conservar e melhorar.
Preservar URLs e conteúdos válidos; acrescentar fonte, data, idioma, entidade e CTA.
Validação editorial e institucional; risco de informação desactualizada.
Links, SEO, PT/EN, fonte e aprovação; Fase Zero.
Cards sectoriais
Textos genéricos e pouco transaccionais.
Transformar.
Ligar a sectores, clusters, territórios, oportunidades e CRM.
Taxonomias e conteúdo validado; risco de duplicação.
Pesquisa, filtro, CTA e ausência de repetição; Fase Zero/Onda 2.
Pesquisa
Pesquisa limitada e exemplos descontextualizados.
Substituir parcialmente.
Indexação por conteúdo, sector, território, cluster, corredor, requisito e oportunidade.
Qualidade de metadados e motor de índice; risco de resultados irrelevantes.
Consultas de referência, pesquisa sem resultado e tempo de resposta; Fase Zero/Onda 2.
Formulários
Captação básica e validações limitadas.
Melhorar e migrar.
Rascunho, validação, consentimento, comprovativo, deduplicação, CRM e acessibilidade.
Mapeamento de campos, dados pessoais e anexos; risco de perda de submissões.
Casos positivos/negativos, duplicados, segurança e migração; Fase Zero/Onda 2.
Utilizadores e permissões
Autenticação e perfis do legado.
Substituir parcialmente.
Identidade progressiva, organizações, representantes, MFA, perfis e consentimentos.
Mapeamento de contas e reset seguro; risco de bloqueio ou privilégio excessivo.
Login, recuperação, revogação, MFA e autorização; Onda 2.
Activo / domínio
Estado actual
Decisão alvo
Transformação e dados
Dependências / risco
Teste e onda
Oportunidades e projectos
Fichas e conteúdos heterogéneos.
Transformar.
Modelo único com maturidade, localização, financiamento, prontidão, documentos, clusters e corredores.
Promotores, IDs e validação; risco de duplicação e dados não confirmados.
Completude, relações, histórico e publicação; Onda 2.
GIS e localização
Campos territoriais sem inteligência espacial completa.
Substituir por PostGIS.
Pontos, linhas, polígonos, áreas de influência, proximidade, intersecção, camadas e fontes.
Geometrias oficiais, SRID, precisão e autorização; risco de mapa incorrecto.
Validação geométrica, consultas espaciais e permissões; PoC e Onda 2.
CRM
Captação e acompanhamento parcamente integrados.
Melhorar e consolidar.
Lead, investidor, oportunidade, actividades, SLA, campanhas, pós-investimento e IDs comuns.
Deduplicação e migração de histórico; risco de perda de contexto.
Funil, tarefas, origem, histórico e reconciliação; Onda 3.
Documentos
Anexos e links dispersos.
Conservar, classificar e migrar.
Metadados, versão, validade, proprietário, classificação, antivírus e object storage.
Ficheiros ausentes, nomes, permissões e retenção; risco de exposição.
Hash, acesso, download, validade e auditoria; Onda 2–3.
Centro legal
Documentos e links úteis, ainda pouco estruturados.
Melhorar.
Catálogo por entidade, sector, processo, validade e estado de confirmação.
Jurídico e tutelas; risco de conteúdo desactualizado.
Fonte, validade, links e disclaimer; Fase Zero.
Clusters e corredores
Não existem como entidades completas no legado.
Criar.
PostgreSQL/PostGIS, relações com âncoras, cadeias, lacunas, actores e projectos complementares.
Dados e governação; risco de taxonomias inconsistentes.
IDs, relações bidireccionais e mapas; Onda 3.
Painel do investidor
Área reservada limitada ou inexistente.
Criar.
Perfil, favoritos, processos, documentos, tarefas, notificações e pós-investimento.
Identidade, CRM e integração; risco de estados divergentes.
Jornada ponta-a-ponta e reconciliação; Onda 3.
Indicadores
Dados e gráficos parcialmente ilustrativos.
Substituir baseline.
Dicionário, fórmula, fonte, período, estado de validação e camada analítica real.
Instrumentação e qualidade; risco de apresentar estimativa como resultado.
Reconciliação e rastreio à origem; Fase Zero/Onda 3.
Integrações institucionais
Links e endpoints conceptuais.
Validar antes de criar.
OpenAPI confirmada, autenticação, SLA, eventos e alternativa manual reconciliável.
Acordos externos; risco de dependência não controlada.
Contract tests e fallback; Fase 2/3.
IA assistiva
Não operacional ou pontual.
Criar de forma supervisionada.
Pesquisa, classificação, recomendação, qualidade e alertas com explicação e confiança.
Dados, métricas e governação; risco de recomendação indevida.
Precisão, contestação, suspensão e auditoria; Onda 4.
DevOps e observabilidade
Práticas a confirmar no legado.
Melhorar.
CI/CD, ambientes, secrets, logs, métricas, tracing, backups e resposta a incidentes.
Infra-estrutura e equipa; risco de cutover sem visibilidade.
Restore, rollback, alertas e SLO; desde a Fase Zero.
4.8.6. Critérios detalhados de entrega da Fase Zero
Domínio
Critério de entrega
Evidência obrigatória
Bloqueio de aceite
Aprovador
Pesquisa
Consultas prioritárias relevantes; sugestões de investimento; medição de zero resultados e cliques.
Roteiro de testes, métricas antes/depois e lista de termos aprovados.
Resultados de cidadania, links quebrados ou ausência de telemetria.
Produto e Conteúdo.
Cards e páginas
Sector, localização, oportunidade, entidade, fonte, data e CTA em todos os conteúdos activos.
Checklist editorial e aprovação institucional.
Texto genérico, repetido ou dado sem fonte.
Conteúdo e Tutelas.
PT/EN
Alternador visível; páginas, botões, formulários, erros e comprovativos coerentes.
Matriz de cobertura e teste de mudança de idioma.
Jornada crítica incompleta ou mistura de idiomas.
Produto e Comunicação.
Como começar
Passos, documentos, entidades, requisitos, apoio e disclaimers publicados.
Aprovação Jurídica e teste com utilizadores.
Orientação apresentada como decisão oficial ou processo desactualizado.
Jurídico e Produto.
Centro legal
Documentos prioritários classificados por entidade, sector, processo, data e validade.
Inventário, links verificados e proprietário definido.
Documento expirado apresentado como vigente.
Jurídico.
Formulários
Rascunho, validação, mensagens claras, consentimento, comprovativo, anexos e deduplicação.
Testes positivos, negativos, autorização, segurança e acessibilidade.
Perda de dados, submissão duplicada ou consentimento inválido.
QA, Segurança e CRM.
CRM e CTA
Manifestação, reunião e apoio criam lead com origem, responsável, SLA e próxima acção.
Teste ponta-a-ponta e relatório de reconciliação.
Lead órfão, duplicado ou sem tarefa futura.
Relações com Investidores.
Acessibilidade
Teclado, foco, contraste, rótulos, mensagens, textos alternativos e mobile aprovados.
Relatório de acessibilidade e correcção de problemas críticos.
Bloqueio de tarefa essencial ou erro sem explicação.
UX e QA.
Desempenho
Metas aprovadas para carregamento, pesquisa, formulários, disponibilidade e erros.
Relatório de testes em desktop e mobile.
Regressão material face à linha de base.
Arquitectura e Operação.
Segurança
Dependências actualizadas, secrets protegidos, logs, backup, restore e vulnerabilidades críticas resolvidas.
Relatório de segurança, restore testado e plano de incidente.
Vulnerabilidade crítica ou backup não recuperável.
Segurança.
Analítica
Eventos de pesquisa, conteúdo, CTA, formulário e CRM definidos e reconciliados.
Dicionário de eventos e painel de linha de base.
Eventos duplicados, sem consentimento ou sem origem.
BI e Dados.
Upgrade tecnológico
Inventário React/Laravel/MySQL, modelo alvo PostgreSQL/PostGIS, PoC, mapa de migração e rollback.
Relatório técnico e decisão de arquitectura.
Objectos críticos não inventariados ou PoC espacial reprovada.
Comité de Arquitectura.
Operação
Manual, runbook, helpdesk, responsáveis, SLA, formação e comunicação disponíveis.
Simulação operacional e termo de aceite.
Incidente sem proprietário ou ausência de suporte.
Direcção da Tempo.
Regra de aceite global:
 a Fase Zero será considerada entregue apenas quando todos os critérios obrigatórios estiverem aprovados, a lista de defeitos críticos estiver vazia, os riscos residuais tiverem proprietário e prazo, a versão existente permanecer estável, a linha de base analítica estiver activa e o Comité de Arquitectura tiver aprovado a migração para PostgreSQL/PostGIS. Entregas condicionais devem indicar excepção, impacto, mitigação, aprovador e data de regularização.
4.8.7. Plano de migração MySQL para PostgreSQL/PostGIS
Fase / onda
Actividades e artefactos
Responsável
Reconciliação e teste
Critério de corte / rollback
0. Preparação
Congelar convenções; inventariar schemas, rotinas, relatórios, volumes, integrações, dados sensíveis e dependências; definir ambientes e RACI.
Arquitecto de Dados e DBA.
Catálogo cobre todos os objectos críticos e consumidores.
Não avançar sem proprietário, criticidade e estratégia por objecto.
1. Modelo alvo
Desenhar schemas PostgreSQL; extensões PostGIS; chaves UUID/IDs; tipos; histórico; auditoria; índices; retenção e particionamento.
Arquitectura de Dados, GIS e Segurança.
Revisão de modelo, dicionário e mapeamento coluna a coluna.
Rollback documental para revisão; não construir sem aprovação.
2. Ferramentas de migração
Criar scripts versionados de extract-transform-load, saneamento, validação, reexecução idempotente e relatório de erros.
Engenharia de Dados.
Execução repetida não duplica; erros são isolados e rastreáveis.
Ferramenta deve permitir recomeçar por lote e preservar origem.
3. PoC
Migrar amostra de conteúdo, oportunidade, localização e relações; testar consultas espaciais, API e pesquisa.
Dados, GIS, Backend e QA.
Contagens, chaves, textos, datas, moedas, geometrias, desempenho e resultados funcionais.
Se integridade ou desempenho falhar, ajustar modelo antes da onda piloto.
4. Onda piloto
Migrar domínio de baixo risco com escrita no legado e sincronização controlada para PostgreSQL.
DBA, Backend e Dono do Domínio.
Reconciliação diária, amostragem funcional, logs e divergências.
Rollback para MySQL se divergência crítica, perda de evento ou SLO violado.
5. Onda 1 — conteúdo e referência
Taxonomias, sectores, reguladores, documentos, idiomas e páginas.
Dados e Conteúdo.
Contagens, links, versões, traduções e permissões.
Corte após aceite editorial e técnico; MySQL fica somente leitura desse domínio.
6. Onda 2 — oportunidades e GIS
Projectos, negócios, localizações, geometrias, ficheiros e pesquisa.
Dados, GIS e Produto.
Relações, mapas, consultas espaciais, anexos e pesquisa.
Rollback se geometria inválida, oportunidade órfã ou pesquisa crítica falhar.
7. Onda 3 — identidade e CRM
Utilizadores, organizações, consentimentos, leads, oportunidades, actividades, tarefas e histórico.
Segurança, CRM e DBA.
Deduplicação, permissões, funil, SLA, histórico e auditoria.
Janela controlada; rollback se identidade, autorização ou histórico divergir.
8. Onda 4 — clusters, corredores e IA
Criar entidades novas, relações espaciais, indicadores, 
recomendações e monitoria.
Produto, Dados, GIS e IA.
Integridade dos sete elos, desempenho espacial, 
explicação e confiança.
Não existe rollback para estrutura nova; desactivar funcionalidades e 
restaurar última versão estável.
9. Cutover final
Congelar escrita no MySQL, migrar delta, reconciliar, actualizar ligações, activar PostgreSQL e monitorar intensivamente.
Gestor de Release e Comité Go-Live.
Contagem final, checksums, transacções, filas, APIs, relatórios e smoke tests.
Rollback dentro da janela se ocorrer perda de dados, erro crítico ou quebra de SLO.
10. Estabilização
Monitorar erros, latência, locks, índices, queries, capacidade, filas e feedback; corrigir e optimizar.
DBA, DevOps e Equipas de Produto.
Relatório diário e reconciliação até estabilidade.
Encerrar quando SLO e taxa de erros permanecerem dentro da meta pelo período aprovado.
11. Desactivação do MySQL
Arquivar, cifrar, aplicar retenção, revogar acessos, remover jobs e dependências e actualizar documentação.
Dados, Segurança e Operação.
Inventário de consumidores vazio e restore do arquivo testado.
Desactivar apenas com aceite formal de Negócio, Dados, Segurança e Auditoria.
Controlos obrigatórios da migração:
 repositório versionado para DDL e scripts; dados de teste anonimizados; migrações reexecutáveis; chaves de correlação; registo de erros; checksums por lote; contagens e somatórios de controlo; validação de encoding e timezone; conversão documentada de tipos; validação de foreign keys; análise de queries; backup antes de cada corte; ensaio de restore; monitoria de replicação/ETL; freeze calendar; plano de comunicação; equipa de war room; e decisão formal de Go/No-Go. O sucesso exige ausência de perda de dados, reconciliação dos registos críticos, desempenho dentro das metas, operação estável e desactivação comprovada das dependências MySQL.
5. Mercado de negócios existentes
Cada oportunidade deve possuir um índice de prontidão composto por identidade e legitimidade, localização, documentação, licenciamento, viabilidade, estrutura financeira, impacto, riscos, promotor, procura de mercado e autorização de publicação. O resultado deve indicar dados completos, pendências, responsável e próxima revisão, sem funcionar como garantia de retorno ou certificação da Tempo. Investidores poderão filtrar oportunidades por nível de prontidão, enquanto promotores receberão uma lista de acções para melhorar a qualidade do projecto.
O portal deverá incluir uma área dedicada à aproximação entre proprietários de negócios em funcionamento, potenciais compradores e investidores. Esta área permitirá manifestar interesse em vender total ou parcialmente uma empresa, procurar capital ou parceria estratégica, adquirir um negócio existente ou investir numa participação empresarial. A Tempo funcionará como facilitadora do contacto e do processo de qualificação, sem garantir a concretização da transacção nem substituir a necessária avaliação jurídica, financeira, fiscal ou comercial.
5.1. Modalidades de manifestação de interesse
Venda de negócio:
 intenção de vender a totalidade da empresa, activos específicos ou uma participação societária.
Captação de investimento:
 procura de capital, parceiro estratégico, financiamento ou conhecimento técnico para expansão, modernização ou recuperação do negócio.
Compra de negócio:
 interesse em adquirir uma empresa existente, unidade produtiva, activos ou participação societária.
Investimento em negócio existente:
 interesse em aportar capital numa empresa em funcionamento, com ou sem participação na gestão.
5.2. Requisitos funcionais
Disponibilizar formulários separados para oferta de negócio e procura de compra ou investimento, com campos obrigatórios, condicionais e opcionais claramente identificados.
Validar formato, completude, coerência, duplicação e autorização de tratamento antes da submissão.
Permitir gravação como rascunho, actualização, suspensão, renovação e encerramento pelo utilizador ou por gestor autorizado.
Permitir 
níveis de divulgação pública, parcialmente anónima e reservada, definidos campo a campo
.
Disponibilizar pesquisa por sector, província, tipo de operação, dimensão, maturidade, valor indicativo e estado.
Permitir guardar oportunidades, pedir esclarecimentos e submeter manifestação de interesse.
Integrar cada registo no CRM, conservando responsável, estado, actividades, documentos, consentimentos e histórico.
Notificar as partes sobre recepção, validação, pedido de informação, correspondência, autorização de contacto e encerramento.
5.2.1. Formulário de oferta de negócio ou captação de investimento
Grupo
Campos
Regra
Identificação do proponente
Tipo de pessoa; nome ou denominação social; NUIT; país; endereço; representante; cargo; telefone; correio electrónico.
Obrigatório e reservado; identidade e poderes de representação sujeitos a verificação.
Identificação do negócio
Nome comercial; forma jurídica; NUIT da empresa; ano de constituição; sector e subsector; província, distrito e localização; sítio electrónico.
Nome e NUIT podem permanecer anónimos na publicação.
Local do investimento
País; região; província; distrito; posto administrativo; localidade; município ou cidade; corredor, zona económica, parque industrial ou bacia; endereço ou referência; coordenadas geográficas, quando disponíveis; âmbito nacional ou multiterritorial, quando aplicável.
Obrigatório. A localização deve identificar com precisão onde o investimento será realizado; projectos que abranjam vários locais devem indicar todos os territórios e distinguir a localização principal das áreas complementares.
Perfil operacional
Descrição; produtos ou serviços; mercados; activos principais; licenças; número de trabalhadores; fase e situação operacional.
Descrição pública sem segredos comerciais.
Desempenho indicativo
Intervalo de receitas; rentabilidade; endividamento; necessidades de fundo; moeda; período de referência.
Opcional na fase pública; documentos comprovativos apenas em área reservada.
Operação pretendida
Venda total; venda parcial; entrada de capital; financiamento; parceria estratégica; activos; percentagem disponível; valor pretendido; moeda; flexibilidade; prazo.
Modalidade e intervalo de valor obrigatórios.
Fundamentação
Motivo da operação; uso previsto dos fundos; vantagens competitivas; riscos materiais; apoio esperado do parceiro.
Motivo pode ser reservado; riscos materiais não devem ser omitidos na diligência.
Preferências de contraparte
Perfil do comprador ou investidor; experiência sectorial; capacidade financeira; origem geográfica; envolvimento na gestão; horizonte.
Usado na correspondência, sem critérios discriminatórios ilícitos.
Documentos
Certidão ou registo comercial; estatutos; poderes do representante; licenças; demonstrações financeiras; situação fiscal; activos; passivos e litígios relevantes.
Submissão faseada; acesso restrito, registo de consulta e validade definida.
Divulgação e consentimentos
Nível de anonimato; campos publicáveis; autorização de contacto; consentimento para tratamento e correspondência; aceitação dos termos; declaração de veracidade.
Obrigatório, específico e registado por data e versão.
5.2.2. Formulário de procura de negócio ou oportunidade de investimento
Grupo
Campos
Regra
Identificação do interessado
Tipo de pessoa; nome ou denominação social; NUIT ou identificação equivalente; país; endereço; representante; telefone; correio electrónico.
Obrigatório e reservado; sujeito a verificação.
Perfil do investidor
Investidor individual, empresa, fundo ou instituição; sectores de experiência; portefólio; origem dos fundos; capacidade indicativa.
Informação financeira detalhada apenas na qualificação.
Objectivo
Compra total; participação minoritária ou maioritária; injecção de capital; financiamento; parceria estratégica; aquisição de activos.
Deve admitir selecção múltipla e ordem de preferência.
Critérios do negócio
Sector e subsector; localização; fase; dimensão; antiguidade; receitas indicativas; rentabilidade; número de trabalhadores; activos ou licenças essenciais.
Usados para pesquisa e pontuação de correspondência.
Parâmetros financeiros
Valor mínimo e máximo; moeda; percentagem pretendida; instrumentos admitidos; prazo; necessidade de controlo; retorno e horizonte indicativos.
Valores não constituem compromisso vinculativo.
Participação e sinergias
Nível de intervenção na gestão; competências oferecidas; mercados, tecnologia ou rede comercial; condições essenciais e exclusões.
Condições eliminatórias devem ser claramente assinaladas.
Comprovação
Identificação; poderes do representante; perfil institucional; prova de capacidade financeira; declaração de origem lícita dos fundos.
Solicitada progressivamente, antes da revelação de dados reservados.
Consentimentos
Autorização de contacto; tratamento de dados; correspondência automatizada; confidencialidade; termos de uso; declaração de veracidade.
Obrigatório, específico, revogável quando aplicável e auditável.
5.2.3. Matriz detalhada de campos e validações
ID
Formulário
Campo e tipo
Obrigatoriedade
Validações
Visibilidade
OF-01
Oferta
Tipo de proponente — lista
Obrigatório
Pessoa singular ou colectiva; determina campos condicionais.
Reservado
OF-02
Oferta
Nome ou denominação social — texto
Obrigatório
2–150 caracteres; sem símbolos inválidos; comparação de duplicados.
Reservado até autorização
OF-03
Oferta
NUIT — texto numérico
Obrigatório para entidade registada em Moçambique
Formato válido; unicidade por entidade; documento comprovativo.
Altamente restrito
OF-04
Oferta
Representante e cargo — texto
Condicional
Obrigatório para pessoa colectiva; poderes de representação válidos.
Reservado
OF-05
Oferta
Telefone e correio electrónico — contacto
Obrigatório
Formato internacional; correio electrónico confirmado; telefone verificado.
Reservado
OF-06
Oferta
Nome comercial do negócio — texto
Obrigatório
2–150 caracteres; pesquisa de duplicados; coerência com registo.
Configurável
OF-07
Oferta
Forma jurídica — lista
Obrigatório
Valor de catálogo; opção “outra” exige descrição.
Limitado
OF-08
Oferta
Sector e subsector — lista hierárquica
Obrigatório
Subsector compatível com sector; catálogo administrável.
Público
OF-09A
Oferta
Local exacto do investimento — listas hierárquicas, texto e coordenadas
Obrigatório
País, região, província, distrito e localidade coerentes; pelo menos um território; coordenadas em formato válido; “nacional” ou “multiterritorial” exige lista das áreas abrangidas; 
localização principal obrigatória.
Público até ao nível autorizado; coordenadas exactas podem ser limitadas por segurança ou confidencialidade.
OF-10
Oferta
Descrição do negócio — texto longo
Obrigatório
100–2 000 caracteres; sem contactos, dados pessoais ou alegações proibidas.
Público após aprovação
OF-11
Oferta
Ano de constituição — ano
Obrigatório
Não superior ao ano corrente; coerente com documentação.
Limitado
OF-12
Oferta
Situação operacional — lista
Obrigatório
Em operação, suspenso, pré-operacional ou em recuperação; motivo condicionado.
Público
OF-13
Oferta
Número de trabalhadores — inteiro/faixa
Opcional
Valor não negativo; intervalo coerente.
Limitado
OF-14
Oferta
Receitas, rentabilidade e dívida — moeda/faixa
Condicional na qualificação
Moeda e período obrigatórios; mínimo não superior ao máximo; comprovativos.
Confidencial
OF-15
Oferta
Modalidade da operação — selecção múltipla
Obrigatório
Pelo menos uma opção; campos financeiros activados pela modalidade.
Público
OF-16
Oferta
Percentagem ou activos disponíveis — número/texto
Condicional
Percentagem entre 0,01 e 100; descrição de activos quando aplicável.
Limitado
OF-17
Oferta
Valor pretendido — moeda/faixa
Obrigatório salvo justificação
Valor positivo; moeda obrigatória; mínimo não superior ao máximo.
Configurável
OF-18
Oferta
Motivo e uso dos fundos — texto
Condicional
50–1 000 caracteres; uso dos fundos obrigatório em captação.
Confidencial
OF-19
Oferta
Riscos materiais e litígios — texto/declaração
Obrigatório na diligência
Resposta sim/não; “sim” exige detalhe e documento.
Altamente restrito
OF-20
Oferta
Documentos — ficheiro
Faseado
PDF/JPG/PNG; tamanho e antivírus; validade; versão; entidade emissora.
Por permissão
PR-01
Procura
Tipo e identidade do interessado — lista/texto
Obrigatório
Regras equivalentes a OF-01 a OF-05; verificação de identidade.
Reservado
PR-02
Procura
Perfil do investidor — lista
Obrigatório
Individual, empresa, fundo ou instituição; opção “outra” exige descrição.
Limitado
PR-03
Procura
Objectivo da operação — selecção múltipla
Obrigatório
Pelo menos uma modalidade; permite ordenar preferências.
Limitado
PR-04
Procura
Sectores e localizações pretendidos — selecção múltipla
Obrigatório
Pelo menos um sector; hierarquias coerentes; admite “todo o país”.
Limitado
PR-05
Procura
Fase, dimensão e antiguidade — listas/faixas
Opcional
Limites inferiores não superiores aos superiores.
Limitado
PR-06
Procura
Montante disponível — moeda/faixa
Obrigatório
Valor positivo; moeda obrigatória; mínimo não superior ao máximo.
Confidencial
PR-07
Procura
Participação pretendida — percentagem/lista
Condicional
Entre 0,01 e 100; minoritária, maioritária ou controlo coerente.
Confidencial
PR-08
Procura
Horizonte e prazo — número/data
Obrigatório
Data futura; horizonte em meses ou anos; prazo razoável.
Limitado
PR-09
Procura
Capacidade financeira — declaração/ficheiro
Obrigatório antes do contacto
Documento válido, origem identificada e aprovação manual.
Altamente restrito
PR-10
Procura
Origem lícita dos fundos — declaração
Obrigatório na qualificação
Aceitação expressa; informação adicional conforme risco.
Altamente restrito
PR-11
Procura
Competências e sinergias — texto
Opcional
Até 1 000 caracteres; sem contactos públicos.
Limitado
PR-12
Procura
Condições eliminatórias — selecção/texto
Opcional
Critérios estruturados; usados antes da pontuação.
Reservado
CM-01
Ambos
Nível de divulgação — lista
Obrigatório
Público, parcialmente anónimo ou reservado; prevalece a opção mais restritiva.
Regra de acesso
CM-02
Ambos
Consentimentos e declarações — caixas
Obrigatório
Sem pré-selecção; versão, data, utilizador e origem registados.
Auditoria
CM-03
Ambos
Estado e responsável — sistema
Automático
Alteração apenas por transição autorizada; histórico imutável.
Conforme perfil
CM-04
Ambos
Data de expiração — data
Automático/configurável
Superior à publicação; alerta prévio; renovação sujeita a confirmação.
Limitado
5.3. Estados, notificações e regras de aprovação
Estado
Entrada e acções permitidas
Aprovação e transição
Notificações
Rascunho
Criado pelo proponente; editar, anexar ou eliminar.
Sem aprovação; passa a Submetido quando campos obrigatórios e consentimentos forem válidos.
Confirmação de gravação e lembrete de rascunho inactivo.
Submetido
Registo fechado para edição substantiva; gera protocolo.
Automática se validações técnicas passarem; encaminha para Em validação.
Recibo ao proponente e tarefa ao analista.
Em validação
Verificação de identidade, representação, duplicados, conteúdo e documentação.
Analista pode pedir correcção; aprovação do gestor leva a Pré-qualificado ou Publicado; risco elevado exige Jurídico/Conformidade.
Início da análise; pedido de correcção; alertas de prazo ao responsável.
Pendente de correcção
Proponente altera apenas campos indicados e volta a submeter.
Regressa a Em validação; expira se não houver resposta no prazo configurado.
Lista de pendências; lembretes; aviso de expiração.
Pré-qualificado
Dados mínimos e legitimidade confirmados; elegível para correspondência.
Aprovação do gestor; publicação depende do nível de divulgação e revisão editorial.
Resultado ao proponente e tarefa de publicação/correspondência.
Publicado
Perfil disponível segundo a classificação de acesso; pode receber interesses.
Gestor editorial ou de negócio; alterações materiais regressam a Em validação.
Confirmação, ligação do anúncio, alertas de interesse e de expiração.
Correspondência identificada
Sistema calcula compatibilidade e apresenta justificação ao gestor.
Revisão humana obrigatória; só passa a Interesse convidado após aprovação.
Tarefa ao gestor; nenhuma notificação externa antes da aprovação.
Interesse convidado
Perfil anónimo/limitado apresentado à contraparte.
Contraparte aceita, recusa ou pede esclarecimento; aceitação leva a Interesse recebido.
Convite com prazo; lembrete; resultado ao gestor.
Interesse recebido
Regista condições preliminares e documentos de capacidade.
Analista valida completude; gestor aprova envio ao titular da oportunidade.
Recibo ao interessado e tarefa ao analista.
Aguardando autorização bilateral
Cada parte autoriza o contacto e aceita confidencialidade.
Duas aprovações independentes; sem ambas não há revelação de identidade.
Pedido individual a cada parte; lembretes; aviso de recusa ou expiração sem revelar fundamento confidencial.
Contacto autorizado
Libertação dos contactos e abertura do espaço seguro.
Automática após autorizações válidas e, quando aplicável, acordo de confidencialidade assinado.
Confirmação às partes e ao gestor; instruções de acesso.
Em diligência
Partilha controlada de documentos, tarefas, perguntas e reuniões.
Gestor controla acessos; documentos altamente restritos exigem autorização do proprietário.
Novo documento, pedido, resposta, acesso anómalo e prazo.
Em negociação
Registo de marcos e condições não vinculativas.
Alteração pelo gestor com confirmação das partes; não implica aprovação da Tempo.
Mudança de estado, próximos marcos e prazos.
Concluído
Regista desfecho, data e indicadores autorizados.
Encerramento pelo gestor com confirmação das partes; campos sensíveis dependem de consentimento.
Encerramento, avaliação do serviço e política de retenção.
Rejeitado
Registo não cumpre requisitos, apresenta risco não mitigado ou informação insuficiente.
Decisão fundamentada por gestor; matéria legal ou fraude exige parecer de Conformidade/Jurídico.
Decisão e via de reclamação, sem expor controlos internos sensíveis.
Suspenso
Oculta temporariamente o registo e bloqueia novas correspondências.
Gestor; casos de segurança, fraude ou ordem legal exigem Conformidade/Jurídico.
Aviso às partes afectadas conforme necessidade e registo interno imediato.
Expirado
Oportunidade ultrapassou a validade sem renovação.
Automática; renovação regressa a Em validação se houver alteração material.
Avisos prévios e confirmação de expiração.
Cancelado
Retirado pelo proponente antes do encerramento.
Automática se não houver diligência activa; caso contrário requer gestor.
Confirmação ao proponente, gestor e contrapartes activas.
Regras transversais:
 nenhuma pessoa pode submeter e aprovar o mesmo registo; aprovações devem guardar utilizador, função, data, decisão, fundamento e versão analisada; alterações a identidade, modalidade, valor, titularidade, documentos críticos ou nível de divulgação anulam a aprovação anterior; decisões de risco elevado exigem dupla aprovação; notificações devem usar modelos versionados, respeitar preferências e confidencialidade, ocultar dados sensíveis e manter registo de envio, entrega, falha e leitura quando disponível; falhas devem gerar nova tentativa e tarefa manual.
5.
4
. Fluxo de correspondência entre investidores e negócios
Registo e consentimento:
 o utilizador cria o perfil, escolhe a modalidade e aceita os termos aplicáveis.
Validação inicial:
 o sistema verifica campos, duplicações e coerência; a Tempo confirma identidade, representação e informação mínima.
Classificação:
 a oportunidade recebe sector, localização, modalidade, dimensão, intervalo financeiro, maturidade, confidencialidade e palavras-chave.
Pré-qualificação:
 o gestor avalia elegibilidade, documentação, riscos, origem indicativa dos fundos e condições eliminatórias.
Correspondência:
 o sistema compara critérios obrigatórios e preferenciais e atribui uma pontuação explicável; não há contacto automático.
Revisão humana:
 o gestor confirma pertinência, conflitos de interesse e nível de informação que pode ser revelado.
Manifestação de interesse:
 a contraparte recebe um perfil anónimo ou limitado e apresenta interesse, capacidade e condições preliminares.
Autorização bilateral:
 ambas as partes autorizam a aproximação; quando necessário, assinam acordo de confidencialidade.
Sala segura de informação:
 documentos são disponibilizados por níveis, com permissões, validade, marcação, registo de acesso e proibição de descarga quando aplicável.
Diligência e negociação:
 as partes recorrem a assessoria jurídica, financeira, fiscal e técnica independente; a Tempo acompanha tarefas e marcos sem decidir pela transacção.
Encerramento:
 regista-se resultado, motivo, data, valor apenas se autorizado, satisfação das partes e obrigações de retenção ou eliminação.
Critérios mínimos de correspondência:
 modalidade compatível, sector, localização, intervalo financeiro, percentagem ou activo pretendido, prazo, fase do negócio, capacidade comprovável e condições eliminatórias. A pontuação e a recomendação devem ser auditáveis, explicadas ao gestor e sujeitas a correcção. 
As transições aplicáveis seguem a matriz da secção 5.3.
5.5. Acompanhamento pós-investimento e gestão de constrangimentos
O serviço pós-investimento deve iniciar após a confirmação da instalação ou do compromisso de capital e permanecer ligado ao registo original no CRM. O investidor poderá comunicar constrangimentos relacionados com licenças, terra, energia, água, logística, fiscalidade, trabalho, importação, exportação ou interacção com entidades públicas. Cada caso terá categoria, prioridade, responsável, entidade envolvida, prazo, escalonamento, solução, satisfação e impacto no investimento. O serviço deve também identificar oportunidades de reinvestimento, expansão, fornecedores locais e novos projectos.
5.6. Requisitos funcionais para desenvolvimento
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-MN-001
Registar utilizadores singulares e colectivos com verificação de contactos.
Conta só é activada após confirmação do correio electrónico ou telefone; tentativas e falhas ficam registadas.
MVP
RF-MN-002
Gerir perfis, representantes, funções e organizações.
Uma organização pode ter vários utilizadores; cada acção identifica o utilizador e a função.
MVP
RF-MN-003
Criar, guardar, editar e submeter ofertas e procuras.
Rascunho persiste; submissão bloqueia campos essenciais e gera número de protocolo.
MVP
RF-MN-004
Aplicar campos condicionais por tipo de pessoa, modalidade e fase.
Campos aparecem e tornam-se obrigatórios conforme regras da matriz, sem perda de dados válidos.
MVP
RF-MN-005
Validar formatos, intervalos, dependências, duplicados e consentimentos.
O sistema impede submissão inválida e apresenta mensagem associada ao campo e orientação de correcção.
MVP
RF-MN-006
Carregar e gerir documentos por categoria e versão.
Ficheiros permitidos passam por antivírus, recebem metadados, validade e controlo de acesso.
MVP
RF-MN-007
Configurar visibilidade por registo e por campo.
Utilizador não autorizado nunca recebe o valor protegido na interface, exportação, pesquisa ou API.
MVP
RF-MN-008
Executar validação e aprovação por perfis.
Transições respeitam a matriz de estados, segregação de funções e aprovações obrigatórias.
MVP
RF-MN-009
Publicar, suspender, renovar, expirar e retirar oportunidades.
Apenas registos aprovados são publicados; todas as alterações mantêm histórico e motivo.
MVP
RF-MN-010
Pesquisar e filtrar oportunidades.
Pesquisa combina modalidade, sector, localização, valor, dimensão, fase e data; não revela campos restritos.
MVP
RF-MN-011
Guardar pesquisas e oportunidades favoritas.
Utilizador pode criar, editar e eliminar preferências e receber alertas autorizados.
Fase 2
RF-MN-012
Calcular correspondência entre oferta e procura.
Condições eliminatórias são avaliadas primeiro; pontuação guarda pesos, critérios, versão e explicação.
MVP
RF-MN-013
Permitir revisão humana da correspondência.
Nenhum convite externo é enviado sem aprovação do gestor; decisão e fundamento ficam auditáveis.
MVP
RF-MN-014
Registar manifestação de interesse e condições preliminares.
Interessado submete mensagem estruturada e documentos exigidos; recebe protocolo.
MVP
RF-MN-015
Obter autorização bilateral antes da revelação de identidade.
Contactos permanecem ocultos até às duas autorizações válidas e ao acordo de confidencialidade quando exigido.
MVP
RF-MN-016
Gerar, assinar e versionar acordo de confidencialidade.
O sistema associa o acordo às partes e oportunidade, regista assinatura e impede acesso antecipado.
Fase 2
RF-MN-017
Disponibilizar sala segura de informação.
Proprietário concede acesso por pasta/documento e prazo; visualizações, tentativas e downloads ficam registados.
Fase 2
RF-MN-018
Gerir perguntas, reuniões, tarefas e marcos de diligência.
Cada item tem responsável, prazo, estado, comentários, anexos e lembretes.
Fase 2
RF-MN-019
Enviar notificações transaccionais multicanal.
Evento gera modelo correcto; envio respeita idioma e preferência e regista entrega, falha e nova tentativa.
MVP
RF-MN-020
Integrar oportunidades, contactos e actividades no CRM.
Não são criados duplicados; estado, responsável e histórico mantêm sincronização controlada.
MVP
RF-MN-021
Registar consentimentos e pedidos de exercício de direitos.
Versão, finalidade, data e origem são conservadas; revogação bloqueia tratamento não obrigatório.
MVP
RF-MN-022
Aplicar retenção, anonimização e eliminação.
Rotina identifica registos vencidos, exige aprovação quando aplicável e produz comprovativo de execução.
Fase 2
RF-MN-023
Manter trilho de auditoria imutável.
Criação, consulta sensível, alteração, aprovação, exportação e partilha registam autor, data, objecto e resultado.
MVP
RF-MN-024
Gerir denúncias, reclamações, conflitos e recursos.
Caso recebe protocolo, prioridade, responsável, prazo, decisão e comunicação ao requerente.
Fase 2
RF-MN-025
Produzir painéis e relatórios operacionais.
Indicadores filtram período, sector, localização, modalidade, estado, conversão e tempo de tratamento; exportação respeita permissões.
MVP
RF-MN-026
Administrar catálogos, regras, pesos, prazos e modelos.
Alterações são versionadas, aprovadas e aplicadas apenas a partir da data definida.
MVP
RF-MN-027
Expor serviços de integração por API segura.
API usa autenticação, autorização, limites, logs, idempotência e tratamento normalizado de erros.
Fase 3
RF-MN-028
Permitir localização em português e inglês.
Rótulos, mensagens, modelos e conteúdos administráveis surgem no idioma seleccionado com fallback definido.
MVP
A plataforma deve suportar identidade digital verificada, autenticação multifactor, representação de organizações, assinatura electrónica de manifestações de interesse, acordos de confidencialidade, autorizações bilaterais, propostas e actas. Cada assinatura deve guardar signatário, qualidade de representação, data, versão, evidência, integridade e estado de validação. A solução deve admitir provedores nacionais ou internacionais legalmente reconhecidos e manter alternativa assistida quando a assinatura electrónica não for juridicamente admissível.
5.
7
. Requisitos legais, confidencialidade e diligência
Papel da Tempo:
 os termos de uso devem definir se a Tempo actua apenas como publicadora e facilitadora ou se presta serviços adicionais. O portal não deve receber fundos, custodiar valores, executar ordens ou apresentar recomendações como consultoria financeira sem enquadramento e autorização aplicáveis.
Identidade e legitimidade:
 verificar identidade, existência jurídica, poderes de representação, titularidade ou autorização para alienar o negócio, activos ou participações.
Prevenção de fraude e branqueamento de capitais:
 adoptar abordagem baseada no risco, identificar beneficiário efectivo e origem dos fundos quando aplicável, realizar diligência reforçada em casos de maior risco e encaminhar situações suspeitas segundo aconselhamento jurídico e obrigações legais aplicáveis. O desenho deve considerar a Lei n.º 14/2023, alterada pela Lei n.º 3/2024, e o respectivo regulamento, sem presumir que todas as obrigações de entidades financeiras se aplicam automaticamente à Tempo.
Protecção de dados:
 observar a Constituição e a Lei n.º 3/2017, de Transacções Electrónicas, incluindo finalidade determinada, minimização, exactidão, segurança, acesso limitado e proibição de transferência indevida. A futura lei geral de protecção de dados, ainda sujeita ao processo legislativo à data desta revisão, deve ser acompanhada e incorporada quando entrar em vigor.
Consentimento e transparência:
 apresentar aviso de privacidade por camadas, identificar responsável pelo tratamento, finalidades, destinatários, prazo de conservação, canais para acesso e correcção, transferências, correspondência automatizada e consequências de não fornecer dados.
Confidencialidade:
 classificar informação como pública, limitada, confidencial ou altamente restrita; aplicar acesso por função e necessidade; usar acordo de 
confidencialidade antes da revelação de identidade ou documentação sensível; registar visualizações, partilhas, downloads e revogações.
Segurança e incidentes:
 encriptar dados em trânsito e repouso, usar autenticação multifactor para áreas reservadas, efectuar cópias de segurança, testes e gestão de vulnerabilidades, e manter procedimento de resposta, contenção, investigação e comunicação de incidentes.
Publicidade responsável:
 proibir informação falsa, garantias de retorno, omissão de riscos relevantes, uso não autorizado de marcas e ofertas contrárias à lei. Todos os valores devem ser indicativos e acompanhados de data e moeda.
Diligência independente:
 a publicação ou validação inicial não equivale a certificação. Antes da transacção, devem ser verificados aspectos societários, fiscais, laborais, cambiais, ambientais, licenças, activos, passivos, litígios, garantias e restrições à transmissão.
Retenção e eliminação:
 definir uma tabela por categoria documental, fundamento e estado do processo; no termo do prazo, eliminar ou anonimizar, salvo obrigação legal, litígio ou consentimento válido para conservação adicional.
Conflitos e reclamações:
 declarar conflitos de interesse, separar funções incompatíveis, disponibilizar canal de denúncia e recurso e conservar decisões de publicação, recusa, suspensão e partilha.
Validação jurídica:
 submeter termos de uso, política de privacidade, acordo de confidencialidade, formulários, critérios de qualificação e modelo de intervenção da Tempo a parecer jurídico moçambicano antes da entrada em produção.
5.
8
. Requisitos funcionais para investimentos agrícolas e fundiários
O portal deve tratar oportunidades agrícolas e fundiárias como investimentos em exploração, empresas, activos, benfeitorias, infra-estruturas, participações ou direitos legalmente admissíveis. A publicação não deve apresentar a terra como propriedade privada livremente alienável. Toda operação relacionada com uso e aproveitamento da terra, titularidade, transmissão de benfeitorias ou mudança de controlo fica sujeita a verificação documental e parecer jurídico moçambicano.
ID
Requisito funcional
Critério de aceitação
Prioridade
RF-AGR-001
Classificar a oportunidade agrícola ou fundiária por natureza: exploração agrícola, agro-indústria, pecuária, silvicultura, irrigação, armazenagem, participação empresarial, activos e benfeitorias, parceria ou financiamento.
A submissão exige pelo menos uma natureza; a opção seleccionada activa os campos, documentos e fluxo correspondentes; designações não admissíveis ficam bloqueadas.
MVP
RF-AGR-002
Registar localização e extensão da área.
Província, distrito, posto, localidade, área em hectares e localização principal são obrigatórios; coordenadas ou polígono são validados e só publicados após autorização.
MVP
RF-AGR-003
Registar situação de uso e aproveitamento da terra.
O proponente informa referência, titular, finalidade, área, prazo, estado, entidade emissora, ónus e documento de suporte; divergência impede publicação.
MVP
RF-AGR-004
Descrever a exploração e a cadeia de valor.
O registo contém culturas ou espécies, sistema produtivo, calendário, capacidade, produtividade histórica ou prevista, processamento, armazenagem, logística e mercados; estimativas são identificadas como tal.
MVP
RF-AGR-005
Registar disponibilidade e direito de uso da água.
Fonte, volume, sazonalidade, infra-estrutura, autorização e entidade competente são exigidos quando o projecto depende de irrigação; falta de licença aplicável gera pendência.
MVP
RF-AGR-006
Inventariar activos e benfeitorias abrangidos.
Máquinas, edifícios, sistemas de irrigação, armazéns, plantações permanentes, animais e outros activos possuem descrição, quantidade, estado, titularidade e valor indicativo separado do direito fundiário.
MVP
RF-AGR-007
Registar situação ambiental e social.
Categoria, licença ou parecer, plano de gestão, comunidades abrangidas, reassentamento quando aplicável, reclamações e obrigações são declarados; risco elevado exige validação jurídica/ambiental.
MVP
RF-AGR-008
Validar legitimidade e disponibilidade para a operação.
Identidade, poderes, titularidade dos activos, autorizações, ónus, litígios e consentimentos são verificados antes da correspondência ou diligência.
MVP
RF-AGR-009
Permitir pesquisa e correspondência agrícola.
O utilizador filtra por cultura, cadeia, área, localização, irrigação, fase, natureza da operação, valor e certificação; o matching explica critérios e exige revisão humana.
Fase 2
RF-AGR-010
Gerir diligência sectorial e validade da informação.
Checklist controla documentos fundiários, fiscais, laborais, ambientais, hídricos, sanitários e operacionais; documentos expirados suspendem divulgação ou avançam para revalidação.
Fase 2
Grupo de campos
Campos mínimos
Validação
Área e localização
Área total e útil; unidade; província; distrito; posto; localidade; coordenadas; polígono; acessos.
Área positiva; geometria coerente com a hierarquia territorial; fonte e precisão registadas.
Base fundiária
Referência do direito ou processo; titular; finalidade; prazo; estado; ónus; litígios; documento.
Correspondência entre titular, área e localização; documento válido; alteração de titularidade exige nova validação.
Produção
Cultura/espécie; ciclo; área cultivada; rendimento; capacidade; tecnologia; certificações.
Período e unidade obrigatórios; histórico separado de previsão; comprovativos na diligência.
Água e energia
Fonte; autorização; capacidade; sazonalidade; irrigação; consumo e alternativas.
Projecto irrigado não avança sem fonte e situação da autorização.
Activos e preço
Benfeitorias, equipamentos, inventário, valor por componente, moeda e data-base.
Separar valor dos activos, empresa, produção futura e outros direitos; não atribuir preço de venda à terra.
Ambiente e comunidade
Licenças, plano de gestão, áreas sensíveis, comunidades, compromissos e reclamações.
Risco material exige documento, plano e aprovação competente antes da publicação.
5.
9
. Campos e critérios de validação para investimentos mineiros
ID
Campo
Obrigatoriedade e validação
Visibilidade
MIN-01
Tipo de oportunidade: venda de participação, entrada de capital, financiamento, parceria, cessão autorizada de activos ou direitos, operação ou fornecimento.
Obrigatório; a modalidade determina documentos e aprovações; qualquer cessão fica condicionada à admissibilidade e autorização legal.
Público após aprovação.
MIN-02
Recurso mineral principal e secundário; classe; produto pretendido.
Obrigatório; valores de catálogo; recurso coerente com o título e estudos anexos.
Público.
MIN-03
Fase: prospecção/pesquisa, avaliação, desenvolvimento, construção, operação, expansão, suspensão, encerramento ou reabilitação.
Obrigatório; documentação e métricas condicionadas à fase.
Público.
MIN-04
Título ou licença: tipo, número, titular, entidade emissora, emissão, validade, área e estado.
Obrigatório para oportunidade associada a direito mineiro; correspondência com titular e localização; validade futura ou estado expressamente indicado; comprovativo obrigatório.
Limitado; documento restrito.
MIN-05
Localização e área: província, distrito, localidade, área, coordenadas e polígono.
Obrigatório; geometria coerente com o título; fonte, sistema de referência e precisão registados; mapa público apenas após autorização.
Por nível autorizado.
MIN-06
Titularidade, beneficiário efectivo, percentagens, parceiros e ónus.
Obrigatório na qualificação; soma das participações coerente; ónus, garantias, litígios e acordos materiais declarados.
Altamente restrito.
MIN-07
Recursos e reservas: categoria, quantidade, teor, data-base, padrão e entidade competente.
Condicional; nenhuma estimativa pode ser apresentada como reserva sem relatório técnico identificável; fonte, versão e qualificações obrigatórias.
Resumo público aprovado; relatório restrito.
MIN-08
Produção, capacidade, recuperação, vida útil e plano mineiro.
Condicional à fase; unidades e período obrigatórios; resultados históricos separados de previsões.
Configurável.
MIN-09
Infra-estruturas e consumos: energia, água, estradas, ferrovia, porto, acampamento e processamento.
Obrigatório na fase de desenvolvimento/operação; capacidade, estado, titularidade e dependências identificados.
Limitado.
MIN-10
Licenciamento ambiental, social, segurança, conteúdo local e plano de reabilitação/encerramento.
Obrigatório conforme fase; documento, entidade, validade, obrigações, garantias e passivos; pendência crítica bloqueia publicação ou diligência.
Resumo público; detalhes restritos.
MIN-11
Investimento realizado, necessidade de capital, custos operacionais, receitas e preço de referência.
Moeda, período, fonte e pressupostos obrigatórios; informação histórica separada da previsão; comprovativos restritos.
Configurável/confidencial.
MIN-12
Autorização para transacção ou mudança de controlo.
Quando aplicável, deve existir parecer e autorização da entidade competente antes da conclusão; ausência mantém estado “condicionado”.
Estado público; documento restrito.
5.
9
.1. Documentos obrigatórios e controlos dos campos MIN
ID
Documentos mínimos
Validação e bloqueio
Responsável
MIN-01
Manifestação do titular; mandato ou procuração; deliberação societária quando aplicável; termo da modalidade pretendida.
Identidade e poderes devem coincidir com o titular; modalidade sem base legal ou autorização aplicável fica bloqueada.
Analista, Jurídico e entidade reguladora quando exigido.
MIN-02
Licença/título; relatório geológico ou memória técnica; catálogo do recurso.
Designação do recurso deve coincidir com o título e estudos; recurso não comprovado não pode ser publicitado.
Especialista mineiro e gestor de conteúdo.
MIN-03
Programa de trabalhos; estudo de viabilidade; plano de mina; relatório operacional ou plano de encerramento, conforme fase.
A fase declarada determina os campos e documentos; inconsistência mantém o registo em correcção.
Gestor sectorial e especialista técnico.
MIN-04
Cópia certificada do título/licença; despacho; comprovativo de taxas; certidão de validade ou consulta oficial.
Número, titular, área, datas e estado devem coincidir; título expirado, suspenso ou contestado bloqueia publicação como oportunidade activa.
Jurídico, Conformidade e regulador competente.
MIN-05
Planta, KML/GeoJSON/Shapefile ou levantamento; memória descritiva; documento oficial da área.
Polígono deve corresponder à área titulada, sem sobreposição não explicada; sistema de referência, precisão e fonte obrigatórios.
Especialista GIS e entidade titular da informação.
MIN-06
Certidão comercial, estatutos, registo de accionistas, declaração de beneficiário efectivo, contratos de garantia e certidão de ónus/litígios.
Participações devem totalizar valor coerente; divergência de titularidade, ónus omitido ou beneficiário não verificado impede diligência.
Jurídico e Conformidade.
MIN-07
Relatório técnico de recursos/reservas, declaração da pessoa competente, anexos laboratoriais e versão aprovada.
Categoria, quantidade, teor, data-base e padrão devem constar do relatório; alegação sem responsável técnico é rejeitada.
Especialista mineiro independente e gestor sectorial.
MIN-08
Plano mineiro, relatórios de produção, balanço metalúrgico, plano de processamento e cronograma.
Unidades e períodos coerentes; histórico separado de previsão; variações materiais exigem explicação e nova versão.
Especialista técnico e Finanças.
MIN-09
Contratos ou autorizações de água e energia; plantas de infra-estrutura; acordos logísticos; inventário de activos.
Capacidade, titularidade, disponibilidade e dependências críticas devem ser comprovadas; ausência relevante é assinalada como risco.
Engenharia, promotor e entidades fornecedoras.
MIN-10
Licença ambiental; EIA/ESIA; plano de gestão; plano de saúde e segurança; plano de conteúdo local; plano e garantia de reabilitação/encerramento.
Documento, validade e obrigações monitorados; licença expirada, passivo crítico ou garantia inexistente bloqueia avanço conforme fase.
Ambiente, Jurídico, Segurança e regulador.
MIN-11
Demonstrações financeiras, orçamento, CAPEX/OPEX, modelo financeiro, contratos de venda ou premissas de preço.
Moeda, período, fonte, taxa de câmbio e pressupostos obrigatórios; informação auditada identificada; previsões nunca tratadas como resultados.
Finanças, auditor independente quando aplicável.
MIN-12
Parecer jurídico; pedido e autorização de cessão/mudança de controlo; aprovações societárias e regulatórias.
Sem autorização formal, a operação permanece “condicionada” e não pode ser encerrada como concluída.
Jurídico, regulador e órgão societário competente.
Todos os documentos mineiros devem possuir categoria, entidade emissora, número, versão, data de emissão, validade, titular, estado de verificação, nível de confidencialidade e hash ou identificador de integridade. O sistema deve verificar formato e antivírus, impedir substituição silenciosa, conservar versões e gerar alertas antes da expiração.
ID
Requisito
Critério de aceitação
RF-MIN-001
Aplicar formulário e checklist específicos por fase mineira.
Campos e documentos mudam conforme fase e modalidade sem eliminar dados históricos.
RF-MIN-002
Validar título, titular, área e validade.
Inconsistência entre título, titular ou polígono impede aprovação e gera pendência auditável.
RF-MIN-003
Controlar declarações de recursos e reservas.
Publicação exige categoria, data, padrão, fonte e responsável técnico; alegação sem suporte é bloqueada.
RF-MIN-004
Gerir documentos ambientais, sociais e de encerramento.
Validade e obrigações são monitoradas; expiração ou passivo crítico suspende o registo.
RF-MIN-005
Controlar cessão, mudança de controlo e aprovações.
A oportunidade mostra estado condicionado até à aprovação competente; conclusão exige evidência formal.
RF-MIN-006
Pesquisar e corresponder oportunidades mineiras.
Filtros incluem recurso, fase, título, localização, valor, modalidade e infra-estrutura; recomendação é explicável e revista por gestor.
5.
10
. Módulo de monetização, facturação e controlo de comissões
Os serviços devem ser organizados em níveis progressivos. O nível público disponibiliza informação, pesquisa, alertas e manifestação de interesse. O nível registado permite favoritos, comparação, dossiers e acompanhamento. O nível verificado habilita correspondência, reuniões e acesso condicionado a informação. O nível assistido oferece avaliação de localização, preparação de projecto, roteiro regulatório e coordenação institucional mediante contrato. O nível pós-investimento assegura resolução de constrangimentos, expansão e ligações empresariais. Cada nível deve definir elegibilidade, preço quando aplicável, prazo, responsável, entregáveis e limites de responsabilidade.
O módulo deve monetizar serviços claramente contratados sem transformar a Tempo em custodiante de fundos de investimento ou intermediária financeira não autorizada. Preços, comissões, factos geradores, impostos, responsabilidades, exclusões e condições de pagamento devem constar de contrato aprovado por Jurídico e Finanças. A plataforma deve separar receita editorial/publicitária, subscrição, serviço profissional, taxa fixa e comissão de sucesso.
Modelo
Facto gerador
Base de cálculo
Controlo
Publicação premium
Aprovação e activação do anúncio ou ficha destacada.
Preço fixo por período, pacote, sector ou alcance.
Ordem comercial, período, entrega e renovação.
Subscrição
Activação do plano.
Mensalidade ou anuidade por utilizador, organização ou funcionalidades.
Plano, ciclo, renovação, suspensão e consumo.
Serviços profissionais
Aceitação de proposta e entrega de marco.
Preço fixo, horas, fase ou entregável.
Contrato, timesheet quando aplicável, aceite e factura.
Evento, missão ou roadshow
Inscrição, patrocínio ou participação confirmada.
Preço por participante, pacote ou patrocínio.
Lista, benefício contratado, presença e reconciliação.
Taxa de encaminhamento
Encaminhamento aceite pelas partes, se juridicamente admissível.
Valor fixo por oportunidade ou marco.
Consentimento bilateral, prova do evento e não duplicação.
Comissão de sucesso
Evento contratual verificável: assinatura, desembolso, pagamento ou outro marco aprovado.
Percentagem, escalão ou valor fixo sobre base elegível definida no contrato.
Confirmação independente, dupla aprovação, factura, recebimento, estorno e auditoria.
Publicidade e patrocínio
Campanha ou espaço activado.
Preço por período, formato, pacote ou entrega.
Ordem de inserção, prova de publicação e relatório.
Prioridade consolidada:
 RF-MON-001 a RF-MON-007, RF-MON-010 e RF-MON-011 integram o MVP; RF-MON-008, RF-MON-009 e RF-MON-012 integram a Fase 2. A especificação detalhada da secção 5.
10
.1 constitui a referência normativa para regras, entradas, saídas e critérios de aceitação.
5.
10
.1. Especificação detalhada dos requisitos RF-MON
ID
Regras de negócio e actores
Entradas e saídas
Critérios de aceitação testáveis
RF-MON-001
Produto, serviço, plano, preço, imposto e validade são administrados por Comercial; Finanças aprova preço e fiscalidade; Jurídico aprova termos. Versões activas não podem ser alteradas retroactivamente.
Entrada: código, descrição, unidade, moeda, preço, imposto, vigência, elegibilidade. Saída: item comercial versionado e disponível para proposta.
Não permite sobreposição incoerente de vigência; proposta antiga conserva a versão usada; alteração exige aprovação; item inactivo não entra em nova proposta.
RF-MON-002
A proposta relaciona cliente, oportunidade, projecto ou campanha. Descontos acima do limite exigem aprovação. Aceitação cria contrato e calendário facturável.
Entrada: cliente, itens, quantidades, preço, desconto, imposto, validade, termos e anexos. Saída: proposta/contrato numerado e obrigações.
Total recalcula automaticamente; versão enviada torna-se imutável; aceite exige evidência; expirada não pode ser aceite sem renovação; contrato mantém ligação à oportunidade.
RF-MON-003
A regra de comissão define pagador, beneficiário, base elegível, taxa, escalão, limites, facto gerador, exclusões e vigência. Jurídico e Finanças aprovam.
Entrada: contrato, serviço, projecto, base, percentagem/fixo, moeda, datas e condições. Saída: regra activa e versionada.
Impede regra sem contrato ou facto gerador; detecta regras concorrentes; soma de percentagens respeita máximo; alteração não recalcula eventos anteriores sem processo formal.
RF-MON-004
O cálculo usa a regra vigente na data do facto gerador e conserva todos os componentes. 
Conversão cambial usa fonte e data aprovadas.
Entrada: valor-base, moeda, regra, taxa cambial, imposto, exclusões. Saída: memória de cálculo, 
comissão bruta, impostos e valor líquido.
Mesmo input e versão produzem o mesmo resultado; mínimo/máximo aplicados; arredondamento configurado; 
recálculo cria nova versão; diferença é explicada.
RF-MON-005
Gestor confirma o evento; Finanças valida cálculo; aprovador independente decide em conflito. O criador não pode aprovar.
Entrada: evidência, cálculo, contrato, comentários. Saída: comissão aprovada, rejeitada ou pendente.
Sem duas aprovações válidas não fica facturável; rejeição exige motivo; alteração material reinicia aprovação; todas as decisões ficam auditadas.
RF-MON-006
Factura é emitida apenas a partir de contrato ou comissão aprovada. Notas de crédito referenciam documento original. Numeração segue série autorizada.
Entrada: cliente fiscal, linhas, imposto, moeda, emissão, vencimento e referência. Saída: factura, nota de crédito ou documento de cobrança.
Número único; totais reconciliam; documento emitido não é apagado; correcção usa nota apropriada; PDF e dados estruturados coincidem.
ID
Regras de negócio e actores
Entradas e saídas
Critérios de aceitação testáveis
RF-MON-007
Tesouraria regista ou importa recebimentos; sistema propõe correspondência; utilizador autorizado confirma a alocação.
Entrada: referência, pagador, conta, data-valor, montante, moeda e comprovativo. Saída: alocação, saldo, diferença e estado.
Admite pagamentos parciais e múltiplas facturas; impede alocação superior ao disponível; duplicado gera alerta; conciliação conserva utilizador e data.
RF-MON-008
Estorno, cancelamento, reembolso e disputa exigem motivo, evidência e aprovação. A comissão vinculada é recalculada, suspensa ou recuperada conforme contrato.
Entrada: transacção original, tipo de reversão, valor, motivo e anexos. Saída: nota de crédito, saldo revisto, comissão ajustada e caso de disputa.
Não admite reversão sem documento original; valor não excede saldo elegível; dupla aprovação para valores acima do limite; histórico permanece intacto.
RF-MON-009
Finanças configura a regra de reconhecimento e de partilha por serviço, período, marco ou recebimento. Alterações são versionadas.
Entrada: contrato, calendário, obrigação, montante, centro de custo, projecto e beneficiário. Saída: plano de reconhecimento e lançamentos exportáveis.
Soma reconhecida não excede receita contratada ajustada; períodos fechados não mudam sem lançamento correctivo; totais reconciliam por cliente e contrato.
RF-MON-010
CRM origina oportunidade e contrato; facturação actualiza estados financeiros; contabilidade recebe documentos e pagamentos por API idempotente.
Entrada: oportunidade ganha, contrato, factura, pagamento e códigos contabilísticos. Saída: IDs cruzados, estados sincronizados e relatório de reconciliação.
Reenvio não duplica; falha entra em fila de repetição; divergência cria pendência; cada registo guarda sistema de origem e correlation-id.
RF-MON-011
Separação mínima entre criação, aprovação, emissão, recebimento, conciliação e estorno. Perfis e limites são aprovados pela Direcção.
Entrada: utilizador, função, acção, valor e objecto. Saída: autorização ou bloqueio e evento de auditoria.
Utilizador não aprova o próprio registo; acessos indevidos são bloqueados; exportações ficam registadas; auditoria inclui antes/depois e fundamento.
RF-MON-012
Painéis distinguem previsto, apurado, aprovado, facturado, recebido, vencido, estornado e disputado. Acesso varia por função.
Entrada: contratos, comissões, facturas, pagamentos, estornos e dimensões. Saída: indicadores, listas reconciliáveis e exportações protegidas.
Filtros por período, cliente, projecto, campanha, serviço e responsável; total abre os registos fonte; data de actualização visível; exportação respeita mascaramento.
5.
10
.2. Fluxo de facturação e comissões
Configuração comercial:
 Comercial propõe produto, preço e regra de comissão; Finanças valida impostos, limites e base; Jurídico valida admissibilidade e termos; aprovação activa uma versão.
Proposta:
 o gestor selecciona cliente, oportunidade e itens; o sistema calcula subtotal, desconto, imposto e total; desvios são encaminhados para aprovação.
Contratação:
 a aceitação ou assinatura fixa versão, partes, serviço, preço, factos geradores, calendário, comissão, moeda e condições de estorno.
Execução do serviço:
 entregas, publicação, evento, encaminhamento ou marco são registados com evidência e aceite pelo cliente quando aplicável.
Apuramento da comissão:
 o sistema identifica o facto gerador, selecciona a regra vigente, calcula base elegível, taxa, limites, câmbio, imposto e valores bruto/líquido.
Validação e aprovação:
 gestor confirma o evento; Finanças verifica cálculo e documentação; aprovador independente decide conflitos ou excepções.
Facturação:
 obrigação aprovada gera factura ou calendário; a emissão atribui série e número, fixa o documento e envia-o pelos canais autorizados.
Cobrança:
 o sistema acompanha vencimento, envia lembretes, regista promessa de pagamento e escala atraso conforme política.
Recebimento:
 Tesouraria importa ou regista o pagamento; o sistema sugere correspondência; utilizador autorizado aloca e concilia.
Liquidação da comissão:
 conforme contrato, a comissão passa a recebida ou pagável somente após o evento financeiro definido; pagamentos parciais geram liquidação proporcional quando previsto.
Estorno ou disputa:
 cancelamento, reembolso, inadimplência ou revisão abre caso; nota de crédito e ajuste da comissão referenciam o registo original.
Reconhecimento e contabilização:
 receita e comissão são classificadas por serviço, projecto, campanha, período e centro de custo; integração contabilística recebe lançamentos idempotentes.
Fecho e auditoria:
 Finanças reconcilia contratos, facturas, recebimentos, comissões e contabilidade; divergências permanecem abertas até resolução; o período só fecha após aprovação.
 
Ponto de controlo
Não pode avançar sem
Excepção
Proposta → Contrato
Cliente validado, itens activos, preço/imposto aprovados e aceite válido.
Excepção comercial documentada e aprovada dentro do limite.
Contrato → Comissão apurada
Regra vigente, facto gerador comprovado e base elegível.
Revisão manual por Jurídico e Finanças.
Comissão apurada → Facturável
Validação do gestor e aprovação de Finanças.
Conflito exige aprovador independente.
Factura → Paga
Recebimento identificado, alocado e conciliado.
Diferença autorizada permanece registada.
Comissão facturada → Recebida/pagável
Evento financeiro definido no contrato e ausência de bloqueio ou disputa.
Liquidação parcial apenas se contratualmente prevista.
Período → Fechado
Reconciliação sem divergências materiais e aprovação de Finanças.
Ajuste posterior somente por lançamento correctivo auditado.
Objecto
Estados mínimos
Dados e validações essenciais
Proposta/contrato
Rascunho, em aprovação, enviado, aceite, rejeitado, expirado, cancelado.
Cliente, serviço, projecto/oportunidade, versão, moeda, preço, desconto autorizado, imposto, validade, assinatura e anexos.
Comissão
Prevista, apurada, em validação, aprovada, facturável, facturada, recebida, parcialmente recebida, estornada, disputada, cancelada.
Regra e versão, facto gerador, evidência, base elegível, taxa, limites, moeda, conversão, imposto, aprovadores e vínculo contratual.
Factura
Rascunho, emitida, enviada, parcialmente paga, paga, vencida, anulada, creditada, em disputa.
Número único, cliente, NUIT, endereço, linhas, imposto, total, moeda, emissão, vencimento, contrato e saldo.
Pagamento
Pendente, identificado, alocado, parcialmente alocado, conciliado, devolvido, contestado.
Referência, pagador, conta, data-valor, moeda, montante, comprovativo, factura e utilizador da conciliação.
Indicadores mínimos:
 receita contratada, facturada, recebida e vencida; prazo médio de cobrança; taxa de cobrança; comissão prevista, aprovada, facturada, recebida e estornada; margem por serviço; receita por campanha, projecto e sector; descontos; disputas; divergências de reconciliação; concentração por cliente. 
Salvaguardas:
 a Tempo não deve receber nem movimentar capital destinado ao investimento por este módulo; a base tributável, documentação fiscal, retenções, câmbio, reconhecimento de receita e admissibilidade de comissões devem ser validados por Finanças, Fiscalidade e Jurídico antes da produção.
6. Carteira de investimentos do PII 2026–2030
O mecanismo de selecção de localização deve combinar mapas autorizados com dados de energia, água, transportes, telecomunicações, mão-de-obra, fornecedores, mercados, incentivos, riscos climáticos, restrições ambientais e disponibilidade de terrenos ou instalações. O investidor deve poder comparar locais, guardar cenários e solicitar uma avaliação assistida. Cada indicador territorial deve apresentar fonte, data, cobertura, precisão e estado de validação.
Com base no relatório 
Programa Integrado de Investimento (PII) 2026–2030
, preparado pelo Ministério da Planificação e Desenvolvimento, o portal deverá incorporar uma carteira pública estruturada de projectos âncora e complementares. O PII organiza 15 projectos âncora, distribuídos pelas regiões Nacional, Norte, Centro e Sul, com foco em indústria, logística, energia, agro-indústria, turismo, infra-estruturas institucionais e resiliência. A função da Tempo deverá ser transformar essa carteira em oportunidades digitais pesquisáveis, promover projectos junto de investidores e parceiros, captar manifestações de interesse, qualificar potenciais investidores e encaminhar os contactos às entidades competentes, sempre mediante validação da versão oficial, autorização de publicação e identificação do ponto focal institucional.
6.1. Matriz inicial de projectos âncora para promoção
ID
Projecto âncora
Região
Local do investimento
Sector / natureza
Potencial de promoção no portal
A01
MozParks – 20 Parques Industriais
Nacional
Âmbito nacional: parques industriais distribuídos pelas províncias de Moçambique; localização específica de cada parque sujeita a validação institucional.
Indústria e comércio
Campanha nacional para investidores industriais, PME, operadores logísticos e empresas âncora.
A02
Linha Ferroviária Norte–Sul
Nacional
Corredor ferroviário de âmbito nacional, ligando as regiões Norte, Centro e Sul; traçado e pontos exactos dependentes dos estudos técnicos.
Transportes e logística
Promoção como projecto estruturante de integração territorial, logística e PPP.
A03
Programa de Desenvolvimento Integrado do Corredor de Nacala
Norte
Corredor de Nacala: Nampula, Cabo Delgado, Niassa, Tete e Norte da Zambézia, incluindo Nacala, Nampula, Cuamba, Palma e áreas ligadas ao corredor.
Logística, indústria, energia e agricultura
Campanhas por corredor económico, exportação, parques industriais, energia, água e formação.
A04
Crusse Jamali – Zona Económica Especial de Turismo
Norte
Crusse Jamali, zona de Nacala, província de Nampula.
Turismo e serviços
Promoção orientada a turismo sustentável, resorts, marinas, hotelaria e operadores internacionais.
A05
Linha de Transmissão Namialo–Metoro (400 kV)
Norte
Eixo Namialo–Metoro, entre as províncias de Nampula e Cabo Delgado, com ligações a Pemba e Palma.
Energia e infra-estrutura
Promoção junto de investidores em energia, EPC, manutenção, equipamentos e indústria eléctrica.
A06
Cadeia de Valor do Arroz por Projecto de Processamento
Centro
Províncias de Tete, Manica, Zambézia e Sofala, articuladas pelos corredores da Beira e de Nacala e pelas bacias de irrigação identificadas.
Agro-indústria e agricultura
Captação de investidores em processamento, irrigação, logística agrícola e substituição de importações.
A07
Parque Têxtil Integrado
Centro
Região Centro, com incidência principal em Sofala e articulação produtiva com Manica e Tete, junto ao Corredor da Beira.
Indústria transformadora
Promoção para investidores têxteis, algodão, confecção, certificação, exportação e emprego industrial.
A08
Zona Económica Especial de Mocuba
Centro
Mocuba e Munhamade, província da Zambézia, com 
ligações a Quelimane, Nacala, Caia e Milange.
Indústria, energia, logística e agro-indústria
Campanha para instalação industrial, agro-
processamento, logística, energia e serviços de suporte.
A09
Construção da Cidadela Parlamentar de Mocuba
Centro
Cidade de Mocuba, província da Zambézia.
Infra-estruturas institucionais e urbanas
Promoção voltada a construção, imobiliário, TIC, segurança, serviços urbanos e hotelaria de apoio.
A10
Mphanda Nkuwa HPP – Hidroeléctrica
Centro
Rio Zambeze, província de Tete, a jusante da Hidroeléctrica de Cahora Bassa; área exacta sujeita à documentação oficial do projecto.
Energia
Promoção junto de financiadores, investidores energéticos, equipamentos, transmissão e compradores de energia.
A11
Corredor Ferroviário e Portuário de Macuse–Moatize
Centro
Corredor entre Moatize, na província de Tete, e Macuse, no distrito de Nicoadala, província da Zambézia, incluindo Mutarara, Mopeia e Quelimane.
Ferrovia, porto e logística
Captação de parceiros para ferrovia, porto, terminais, mineração, carga geral e serviços logísticos.
A12
Programa de Conectividade e Resiliência Costeira (Compacto II)
Centro
Província da Zambézia, com incidência em zonas rurais, no rio Licungo, na Circular de Mocuba e em comunidades e ecossistemas costeiros.
Infra-estrutura, agricultura, ambiente e clima
Promoção para parceiros de conectividade rural, agricultura, resiliência climática e economia azul.
A13
Vilanculos – Região Integrada de Turismo
Sul
Corredor turístico Vilanculos–Inhassoro–Bazaruto, província de Inhambane, incluindo áreas costeiras e ilhas associadas.
Turismo e serviços
Campanha para turismo costeiro, hotelaria, marina, aviação, formação e serviços digitais turísticos.
A14
Zona Económica Especial de Agronegócio do Limpopo
Sul
Vale do Limpopo, província de Gaza: Chókwè, Xai-Xai, Guijá, Chongoene, Chibuto, Limpopo e Bilene.
Agro-indústria, irrigação e logística
Promoção para investidores em produção agrícola, processamento, armazenagem, crédito e equipamentos.
A15
Regadio na Bacia Hidrográfica do Rio Maputo
Sul
Bacia Hidrográfica do Rio Maputo, província de Maputo, com incidência nos distritos de Boane, Moamba e Namaacha e ligação às bacias do Maputo e Incomáti.
Agricultura irrigada, água e energia
Captação de operadores agrícolas, tecnologia de irrigação, energia, infra-estrutura hídrica e gestão digital.
6.2. Registo geográfico consolidado dos projectos
ID
Projecto
Local consolidado
Latitude / longitude
Mapa
Entidade de validação
Estado
A01
MozParks – 20 Parques Industriais
Âmbito nacional; cada parque deve possuir registo individual por província, distrito, localidade e parcela.
A confirmar por parque
Um mapa nacional e um mapa por parque, após autorização.
MPD, entidade de tutela e MozParks/promotor de cada parque.
Pendente de desagregação e validação.
A02
Linha Ferroviária Norte–Sul
Corredor nacional entre Norte, Centro e Sul; estações, troços e áreas de implantação dependem dos estudos.
Traçado geográfico a confirmar
Mapa linear apenas com traçado oficial aprovado.
MPD, entidade de tutela dos transportes e promotor técnico.
Pendente de estudos e autorização cartográfica.
A03
Corredor de Nacala
Nampula, Cabo Delgado, Niassa, Tete e Norte da Zambézia; Nacala, Nampula, Cuamba, Palma e áreas ligadas ao corredor.
Múltiplas coordenadas
Mapa do corredor e camadas por projecto complementar.
MPD, tutelas sectoriais, governos provinciais e promotores.
Localização geral identificada; pontos exactos pendentes.
A04
ZEE de Turismo de Crusse Jamali
Crusse Jamali, zona de Nacala, província de Nampula.
A confirmar
Polígono da ZEE e acessos, mediante autorização.
MPD, tutela do turismo, governo provincial e promotor da ZEE.
Pendente de coordenadas oficiais.
A05
Linha Namialo–Metoro 400 kV
Eixo Namialo–Metoro, Nampula–Cabo Delgado, com ligações a Pemba e Palma.
Traçado e subestações a confirmar
Mapa linear e pontos de subestações autorizados.
MPD, tutela da energia, EDM/promotor técnico e governos provinciais.
Pendente de ficheiro geoespacial oficial.
A06
Cadeia de Valor do Arroz
Tete, Manica, Zambézia e Sofala; corredores da Beira e Nacala e 
bacias de irrigação associadas.
Múltiplas coordenadas
Mapa por unidade produtiva, processamento, regadio e logística.
MPD, tutela da agricultura, governos provinciais e promotores privados.
Localização regional validável; sítios exactos pendentes.
A07
Parque Têxtil Integrado
Região Centro, com incidência principal em Sofala e articulação com Manica e Tete.
A confirmar
Mapa do parque e cadeia de fornecimento, quando autorizado.
MPD, tutela da indústria, governo provincial e promotor.
Local principal por confirmar.
A08
ZEE de Mocuba
Mocuba e Munhamade, Zambézia, com ligações a Quelimane, Nacala, Caia e Milange.
A confirmar
Polígono da ZEE, lotes e infra-estruturas autorizadas.
MPD, entidade gestora da ZEE, governo provincial e tutela sectorial.
Pendente de coordenadas e limites oficiais.
A09
Cidadela Parlamentar de Mocuba
Cidade de Mocuba, província da Zambézia.
A confirmar
Mapa geral sem detalhes sensíveis de segurança.
MPD, Assembleia da República/promotor e autoridades locais.
Localidade identificada; implantação exacta restrita até autorização.
A10
Mphanda Nkuwa HPP
Rio Zambeze, província de Tete, a jusante da Hidroeléctrica de Cahora Bassa.
A confirmar por fonte oficial
Mapa da área do projecto e transmissão conforme informação pública autorizada.
MPD, tutela da energia e entidade promotora do projecto.
Localização geral identificada; coordenadas sujeitas a validação.
A11
Corredor Macuse–Moatize
Moatize–Mutarara–Mopeia–Nicoadala–Macuse, entre Tete e Zambézia, incluindo ligações a Quelimane.
Traçado e terminais a confirmar
Mapa linear do corredor, porto e terminais autorizados.
MPD, tutela dos transportes, governos provinciais e promotor.
Traçado geral identificado; ficheiro oficial pendente.
A12
Conectividade e Resiliência Costeira
Zambézia; zonas rurais, rio Licungo, Circular de Mocuba e comunidades e ecossistemas costeiros.
Múltiplas coordenadas
Mapa por componente, sem expor comunidades ou activos sensíveis.
MPD, entidade gestora do Compacto II, governo provincial e promotores.
Áreas gerais identificadas; componentes pendentes de validação.
A13
Região Integrada de Turismo de Vilanculos
Vilanculos–Inhassoro–Bazaruto, província de Inhambane, incluindo áreas 
costeiras e ilhas autorizadas.
A confirmar
Mapa turístico e de activos, respeitando zonas protegidas e restrições.
MPD, tutela do turismo, administração de conservação, governo provincial e promotor.
Corredor identificado; polígonos pendentes.
A14
ZEE de Agronegócio do Limpopo
Chókwè, Xai-Xai, Guijá, Chongoene, Chibuto, Limpopo e Bilene, província de Gaza.
Múltiplas coordenadas
Mapa da ZEE, perímetros agrícolas, logística e componentes autorizadas.
MPD, tutela da agricultura, entidade gestora da ZEE e governo provincial.
Distritos identificados; limites e pontos pendentes.
A15
Regadio da Bacia do Rio Maputo
Boane, Moamba e Namaacha, província de Maputo, nas bacias do Maputo e Incomáti.
Múltiplas coordenadas
Mapa de barragens, canais, perímetros e componentes autorizadas.
MPD, tutela das águas/agricultura, ARA competente e governos locais.
Distritos identificados; coordenadas técnicas pendentes.
6.3. Inserção de novos projectos públicos e privados por localização
Campo
Regra
Validação
Natureza do projecto
Público, privado, PPP, concessão, comunitário, cooperação ou iniciativa mista.
Obrigatório; determina entidade aprovadora, documentos e fluxo.
Local associado
Seleccionar um local já registado ou criar nova localização hierárquica.
Obrigatório; validar país, província, distrito, posto, localidade e localização principal.
Relação territorial
Dentro do projecto âncora, complementar, fornecedor, infra-estrutura de suporte, cadeia de valor ou oportunidade independente.
Obrigatório quando associado a um dos 15 projectos.
Proponente e entidade responsável
Nome, natureza jurídica, NUIT, representante, tutela ou regulador e ponto focal.
Verificação de identidade, legitimidade e poderes de representação.
Coordenadas e geometria
Latitude, longitude; opcionalmente linha, perímetro ou múltiplos pontos.
Formato válido; ponto dentro da unidade territorial indicada; fonte e precisão registadas.
Documentos territoriais
DUAT ou referência fundiária, autorização, licença, planta, estudo, parecer ambiental e documento de localização, conforme aplicável.
Acesso restrito; validade, entidade emissora e correspondência com o local.
Autorização de mapa
Indicar se pode publicar ponto, área aproximada, polígono, traçado ou apenas distrito/província.
Aprovação expressa da entidade responsável e avaliação de segurança/confidencialidade.
Estado territorial
Rascunho, submetido, em validação, pendente de correcção, validado, autorizado para mapa, publicado, suspenso ou expirado.
Transições auditáveis e segregação entre submissão e aprovação.
6.4. Validação institucional, coordenadas e mapas
Preparação:
 a Tempo consolida nome, código, descrição, local, fonte, coordenadas propostas, mapa preliminar e entidade responsável.
Verificação documental:
 o analista compara a localização com o relatório oficial, estudos, plantas, licenças ou ficheiros geoespaciais.
Envio para validação:
 o sistema remete uma ficha de validação ao MPD, tutela sectorial, promotor e, quando necessário, governo provincial, município, distrito ou autoridade da área protegida.
Correcção:
 divergências regressam ao gestor com comentários, versão e prazo; nenhuma coordenada contestada é publicada.
Aprovação territorial:
 a entidade confirma nome oficial, hierarquia administrativa, ponto ou perímetro, fonte, precisão e data de validade.
Aprovação de divulgação:
 a entidade define o nível publicável: província, distrito, localidade, ponto aproximado, ponto exacto, traçado ou polígono.
Publicação:
 somente registos “Validados” e “Autorizados para mapa” podem apresentar coordenadas ou mapas ao público.
Revisão:
 alterações de traçado, parcela, entidade, risco, estudo ou autorização suspendem o mapa até nova validação.
Controlo
Evidência mínima
Aprovador
Registo obrigatório
Nome e código do projecto
Documento oficial ou comunicação formal.
MPD e entidade promotora.
Fonte, versão, data e responsável.
Hierarquia territorial
Designação administrativa oficial e documento de suporte.
Entidade de tutela e autoridade territorial competente.
Província, distrito, posto, localidade e código territorial.
Coordenadas
Ficheiro geoespacial, planta, levantamento ou comunicação oficial.
Promotor técnico e autoridade competente.
Latitude, longitude, sistema de referência, precisão e fonte.
Traçado ou polígono
Shapefile, GeoJSON, KML, planta ou desenho aprovado.
Promotor e tutela sectorial.
Versão, área/extensão, data e restrições.
Publicação do mapa
Autorização expressa de divulgação.
Entidade proprietária da informação e Jurídico/Conformidade.
Nível publicável, prazo, condições e revogação.
Revisão periódica
Confirmação ou nova versão.
Ponto focal institucional.
Data da revisão, resultado e próxima revisão.
A Tempo deverá manter um cadastro de pontos focais e pedidos de validação, com protocolo, entidade, destinatário, data de envio, prazo, resposta, anexos, decisão e validade. Até à recepção de evidência formal, as localizações desta versão permanecem classificadas como preliminares e não devem ser apresentadas como coordenadas oficiais.
6.5. Requisitos funcionais de georreferenciação
ID
Requisito
Critério de aceitação
RF-GEO-001
Manter cadastro único de locais de investimento.
Cada local possui identificador, hierarquia territorial, nome oficial, fonte, estado e histórico.
RF-GEO-002
Permitir vários projectos públicos ou privados no mesmo local.
Um local pode relacionar múltiplos projectos sem duplicação; cada relação indica natureza, papel e período.
RF-GEO-003
Permitir várias localizações por projecto.
O projecto define uma localização principal e zero ou mais locais complementares, troços ou áreas.
RF-GEO-004
Capturar coordenadas e geometrias.
O sistema aceita ponto, linha e polígono, valida formato, sistema de referência, extensão territorial e ficheiro.
RF-GEO-005
Apresentar mapa apenas quando autorizado.
O mapa público só é renderizado se a localização estiver validada, a autorização vigente e o nível de detalhe permitido.
RF-GEO-006
Aplicar níveis de precisão e confidencialidade.
O sistema pode publicar província, distrito, ponto aproximado, ponto exacto, traçado ou polígono sem expor dados mais restritos.
RF-GEO-007
Gerir pedidos de validação institucional.
Pedido possui protocolo, entidade, ponto focal, prazo, anexos, comentários, decisão e validade.
RF-GEO-008
Suspender mapas desactualizados ou revogados.
Nova versão, expiração ou revogação remove o mapa público e cria tarefa de revalidação.
RF-GEO-009
Pesquisar projectos por mapa e localização.
O utilizador filtra por província, distrito, raio, corredor, ZEE, parque, bacia, sector e natureza pública ou privada.
RF-GEO-010
Importar e exportar dados geográficos autorizados.
O sistema suporta formatos geográficos definidos, gera relatório de erros e preserva fonte, versão e permissões.
6.
6
. Fichas editoriais dos 15 projectos âncora
ID e projecto
Proposta de valor para publicação
Dados-chave
Investidores e parceiros prioritários
Chamada para acção
A01 — MozParks: 20 Parques Industriais
Plataforma nacional de industrialização descentralizada para instalar empresas, desenvolver fornecedores locais e integrar cadeias de valor em todas as províncias.
Âmbito nacional; indústria e comércio; investimento âncora indicado de USD 100 milhões; horizonte 2026–2030; potencial superior a 200 mil empregos directos e indirectos, sujeito a validação oficial.
Fabricantes, operadores de parques, empresas âncora, fundos industriais, logística, energia, água, tecnologia e PME fornecedoras.
Solicitar o dossier nacional, seleccionar uma província ou manifestar interesse em instalar, operar, financiar ou fornecer serviços.
A02 — Linha Ferroviária Norte–Sul
Ligação ferroviária contínua entre Norte, Centro e Sul para reduzir custos logísticos, integrar mercados e reforçar Moçambique como plataforma regional.
Extensão estimada de 3 808 km; custo ainda dependente de estudos; horizonte 2026–2030; projecto estruturante de transportes e logística.
Operadores ferroviários, fundos de infra-estrutura, construtoras, fornecedores de material circulante, portos, mineração, agricultura e PPP.
Registar interesse em estudos, estruturação, financiamento, construção, operação ou fornecimento tecnológico.
A03 — Corredor de Nacala
Programa integrado que combina porto, ferrovia, indústria, agricultura, energia, água e serviços para transformar o Norte num corredor produtivo e exportador.
Nampula, Cabo Delgado, Niassa, Tete e Norte da Zambézia; custo global indicado de USD 2,43 mil milhões; cerca de 48 projectos complementares identificados.
Logística, portos, ferrovias, parques industriais, energia, água, agronegócio, formação, comércio regional e parceiros multilaterais.
Escolher um subprojecto, solicitar informação técnica ou propor financiamento, operação, construção ou parceria.
A04 — ZEE de Turismo de Crusse Jamali
Destino turístico integrado de alta gama na costa de 
Nampula, articulando resorts, marina, residência, conectividade e serviços sustentáveis.
Nacala, Nampula; projecto âncora privado indicado em 
USD 99,2 milhões; rede complementar de porto, aeroporto, estrada, energia, água, formação e telecomunicações.
Grupos hoteleiros, promotores 
imobiliários, operadores turísticos, aviação, marinas, fundos de turismo, utilities e tecnologia.
Solicitar o dossier turístico, agendar apresentação ou 
propor desenvolvimento, operação, financiamento ou serviço complementar.
A05 — Linha Namialo–Metoro 400 kV
Infra-estrutura energética para estabilizar o fornecimento ao Norte e suportar indústria, gás, mineração, cidades e novos investimentos.
Nampula–Cabo Delgado; custo âncora indicado de USD 550 milhões; inclui transmissão, subestações e interligações; horizonte 2026–2030.
Produtores e transmissores de energia, EPC, fabricantes de equipamento, fundos climáticos, manutenção, automação e formação técnica.
Manifestar interesse em financiamento, EPC, equipamentos, operação, manutenção ou componentes complementares.
A06 — Cadeia de Valor do Arroz
Programa de produção irrigada, processamento e logística para reduzir importações, aumentar produtividade e criar emprego rural no Centro.
Tete, Manica, Zambézia e Sofala; projecto âncora privado indicado em USD 36,71 milhões; complementares de irrigação, ferrovia, estrada, porto, energia e água.
Produtores, processadores, armazenagem, irrigação, maquinaria, logística, retalho alimentar, bancos e fundos de impacto.
Solicitar oportunidades por elo da cadeia ou propor capital, tecnologia, compra de produção, processamento ou logística.
A07 — Parque Têxtil Integrado
Reindustrialização da fileira do algodão, da produção à fiação, tecelagem, confecção, certificação e exportação.
Zona Centro, com foco em Sofala, Manica e Tete; investimento âncora indicado em USD 42 milhões; integração com Porto e Corredor da Beira.
Fabricantes têxteis, marcas, fundos industriais, algodoeiras, equipamentos, logística, certificação, formação e compradores internacionais.
Manifestar interesse em instalar unidade, participar na cadeia, financiar, fornecer equipamento ou estabelecer contrato de compra.
A08 — Zona Económica Especial de Mocuba
Ecossistema industrial e agro-logístico para transformar a Zambézia num pólo de processamento, inovação, energia e exportação.
Mocuba e Munhamade; projecto âncora indicado em USD 37,4 milhões; complementares de porto, ferrovia, estrada, energia, água, formação e plataforma digital.
Agro-indústria, silvicultura, pecuária, logística, parques industriais, utilities, tecnologia, certificação e fundos regionais.
Seleccionar lote, cadeia de valor ou activo complementar e solicitar reunião com a entidade promotora.
A09 — Cidadela Parlamentar de Mocuba
Complexo institucional e urbano destinado a reforçar a descentralização, serviços públicos, actividade económica e 
desenvolvimento urbano da Zambézia.
Mocuba; investimento âncora indicado em USD 120 milhões; componentes residenciais, administrativas, 
viárias, hoteleiras, segurança e TIC.
Construção, imobiliário, gestão de instalações, hotelaria, segurança, TIC, energia eficiente 
e serviços urbanos.
Registar capacidade e interesse em construção, fornecimento, tecnologia, operação de serviços ou 
parceria autorizada.
A10 — Mphanda Nkuwa HPP
Central hidroeléctrica de grande escala para ampliar energia limpa, reforçar a industrialização e consolidar exportações eléctricas regionais.
Tete, rio Zambeze; 1 500 MW; custo âncora indicado de USD 4,5 mil milhões; associado a transmissão, expansão de rede e electrificação.
Investidores energéticos, financiadores, EPC, turbinas, transmissão, compradores de energia, fundos climáticos e seguradoras.
Solicitar informação pública validada ou manifestar interesse em financiamento, fornecimento, construção ou serviços especializados.
A11 — Corredor Macuse–Moatize
Corredor ferroviário e porto de águas profundas para ligar Tete à costa, diversificar rotas e aumentar a capacidade exportadora.
Tete–Zambézia; custo âncora indicado de USD 1,524 mil milhões; inclui porto, ferrovia, terminais, controlo, oficinas e mitigação social e ambiental.
Portos, ferrovias, mineração, carga geral, combustíveis, fundos de infra-estrutura, engenharia, tecnologia e operadores logísticos.
Manifestar interesse em estruturação, financiamento, construção, operação, carga contratual ou serviços complementares.
A12 — Conectividade e Resiliência Costeira
Programa integrado para melhorar conectividade rural, investimento agrícola e resiliência de comunidades e ecossistemas costeiros da Zambézia.
Zambézia; Compacto II com componentes de transportes rurais, reforma e investimento agrícola e meios de vida costeiros; valores sujeitos a harmonização oficial.
Fundos climáticos, cooperação, agricultura, estradas, economia azul, conservação, tecnologia de monitoria e fundos de impacto.
Solicitar oportunidades de parceria, assistência técnica, co-financiamento, fornecimento ou inovação climática.
A13 — Região Integrada de Turismo de Vilanculos
Destino turístico costeiro integrado que combina hotelaria, acessibilidade, energia, água, formação, economia azul e serviços digitais.
Vilanculos–Inhassoro–Bazaruto; projecto âncora indicado em USD 20 milhões; 12 projectos complementares; horizonte 2026–2030.
Hotelaria, resorts, aviação, marinas, operadores turísticos, fundos imobiliários, utilities, formação e tecnologia.
Solicitar dossier, agendar apresentação ou propor investimento em alojamento, mobilidade, serviços, infra-estrutura ou formação.
A14 — ZEE de Agronegócio do Limpopo
Ecossistema agro-industrial integrado para ligar irrigação, produção, processamento, armazenamento, energia, crédito e mercados.
Gaza; Chókwè, Xai-Xai, Guijá, Chongoene, Chibuto, Limpopo e Bilene; custo âncora indicado de USD 354 milhões.
Produtores, processadores, irrigação, armazenagem, logística, energia, maquinaria, bancos, fundos agrícolas e compradores.
Seleccionar componente, cultura ou serviço e manifestar interesse em capital, operação, fornecimento, crédito ou compra.
A15 — Regadio da Bacia do Rio Maputo
Programa hídrico e agrícola para aumentar segurança 
de água, irrigação moderna, produtividade, processamento e resiliência climática.
Boane, Moamba e Namaacha; custo âncora indicado de 
USD 480 milhões; barragens, canais, drenagem, energia, estradas, formação e SCADA.
Operadores agrícolas, irrigação, 
engenharia hídrica, energia, tecnologia, fundos climáticos, logística, processamento e formação.
Propor financiamento, tecnologia, 
operação agrícola, fornecimento, assistência técnica ou parceria num componente validado.
Nota editorial: custos, metas, maturidade, entidades responsáveis e disponibilidade para investimento devem ser confirmados com o MPD e a entidade de tutela antes da publicação. A ficha pública deve distinguir claramente informação oficial, estimativa, oportunidade complementar e chamada exploratória ao mercado.
6.
7
. Modelo de ficha e catálogo
Código oficial, designação, descrição executiva e entidade promotora.
Local do investimento:
 país, região, província, distrito, posto administrativo, localidade, município ou cidade, corredor, zona económica, parque industrial ou bacia, endereço ou referência e coordenadas geográficas, quando disponíveis. Projectos nacionais ou multiterritoriais devem listar cada área abrangida e indicar a localização principal.
Objectivo, problema público ou económico e resultados esperados.
Fase de preparação: conceito, estudo, estruturação, concurso, execução ou expansão.
Valor estimado, moeda, componente pública, montante por mobilizar e horizonte.
Modalidade pretendida: investimento directo, parceria público-privada, concessão, financiamento, participação, assistência técnica ou outra.
Activos, infra-estruturas, estudos, licenças, terra, garantias ou contrapartidas disponíveis.
Indicadores de impacto: emprego, produção, exportações, substituição de importações, receitas, cobertura territorial e sustentabilidade.
Riscos, dependências, requisitos legais, ambientais, sociais e institucionais.
Documentos públicos, data de actualização, ponto focal e canal oficial de contacto.
6.
8
. Campos para importação da matriz PII
ID do projecto âncora e ID do projecto complementar.
Tipo: âncora, complementar público, complementar privado, PPP, regulatório, formação, energia, logística, água, digital ou ambiental.
Relação com o projecto âncora: alimenta, é alimentado, integra a cadeia, suporta ou viabiliza.
Localização normalizada:
 país, âmbito nacional ou regional, província, distrito, posto administrativo, localidade, município ou cidade, corredor, zona económica, parque industrial ou bacia, endereço ou referência, latitude, longitude e localização principal. Registos multiterritoriais devem admitir múltiplas localizações relacionadas.
Custo estimado em USD e MZN, taxa de câmbio usada, fonte e observação quando o valor carece de estudo.
Horizonte, fase de maturidade, existência de estudos, licenças, salvaguardas ambientais e sociais.
Modalidade recomendada de financiamento: concessional, PPP, investimento privado, blended finance, fundo climático, garantia ou assistência técnica.
Impactos esperados: emprego, exportações, produção, energia, conectividade, substituição de importações, receitas e resiliência.
Entidade promotora, ministério de tutela, ponto focal, parceiros potenciais e nível de autorização para divulgação.
Prioridade de campanha: alta, média ou baixa, em função de maturidade, atractividade privada e disponibilidade de informação.
6.
9
. Estratégia de promoção e angariação
Criar páginas de campanha por sector, corredor económico, província e perfil de investidor.
Produzir fichas resumidas, dossiers sectoriais, apresentações, conteúdos editoriais e versões em português e inglês.
Disponibilizar pesquisa, filtros, comparação, favoritos, alertas e recomendação de projectos.
Implementar chamadas para acção: “Manifestar interesse”, “Solicitar dossier”, “Agendar reunião” e “Propor financiamento ou parceria”.
Promover oportunidades através da Revista Tempo, boletins, redes sociais, eventos, missões empresariais, webinars e parceiros institucionais.
Criar listas segmentadas de investidores por sector, geografia, dimensão, instrumento e histórico de interesse.
Executar campanhas no CRM com responsável, público-alvo, conteúdo, calendário, orçamento, origem do contacto e métricas de conversão.
Preparar salas virtuais de apresentação e rondas de reuniões entre investidores qualificados e entidades promotoras.
6.
10
. Plano de campanhas e captação de investidores
Campanha
Projectos e público
Activos e canais
Sequência de captação
Indicadores e cadência
Moçambique: Razões para Investir
Todos os sectores; investidores em fase de descoberta, consultores, câmaras de comércio, diplomacia económ
ica e diáspora.
Página institucional, dossier do país, perfis sectoriais, infografias, artigos, boletim, webinar e apresentações a mercados-alvo.
Atrair audiência → capturar sector e país de interesse → recomendar área e projecto → oferecer dossier → qualific
ar → agendar reunião.
Visitantes internacionais, downloads, subscrições, perfis criados, reuniões e oportunidades; campanha permanente.
Industrializar Moçambique
A01, A07 e A08; fabricantes, operadores de parques, marcas, fundos industriais, PME e fornecedores.
Landing page, dossier sectorial, fichas provinciais, artigos na Revista Tempo, LinkedIn, correio directo, webinar e fórum industrial.
Conteúdo de autoridade → descarga de dossier → formulário de perfil → qualificação → reunião sectorial → encaminhamento.
Leads, dossiers solicitados, investidores qualificados, reuniões e propostas; campanha permanente com activações 
trimestrais.
Corredores Logísticos e Exportação
A02, A03 e A11; portos, ferrovias, fundos de infra-estrutura, operadores logísticos, mineração e exportadores.
Mapa de corredores, dossier técnico, vídeo executivo, briefing fechado, missões empresariais e reuniões individuais.
Mapear 50 contas-alvo → abordagem personalizada → briefing técnico → recolha de capacidade → sessão com promotor → seguimento no CRM.
Contas activadas, briefings, reuniões, manifestações e valor indicativo; ciclos semestrais por corredor.
Energia para Crescimento
A05 e A10; produtores, EPC, fornecedores, financiadores climáticos, utilities e compradores industriais.
Dossier energético, fichas técnicas, webinar, roundtable, newsletter especializada e contacto com associações e bancos.
Segmentar por capital, EPC, equipamento e compra de energia → convite → qualificação → sala informativa → encaminhamento.
Participantes qualificados, pedidos técnicos, consórcios formados e propostas; campanhas bimestrais e dois fóruns anuais.
Agro-indústria e Segurança Alimentar
A06, A14 e A15; produtores, processadores, irrigação, armazenagem, retalho, bancos e agtech.
Fichas por cadeia, calculadora indicativa, histórias de mercado, rádio e meios sectoriais, feiras, visitas de campo e webinar.
Identificar cadeia e localização → captar interesse → validar capacidade → formar grupos por elo → visitas → propostas.
Leads por cadeia, visitas, compradores âncora, cartas de interesse e propostas; activações por campanha agrícola e feira.
Turismo Costeiro e Serviços
A04 e A13; hotelaria, resorts, aviação, marinas, 
operadores, fundos imobiliários e tecnologia.
Microssítio visual, brochura, roteiro de activos, 
imprensa de viagens, feiras, roadshow, webinar e visitas ao destino.
Pré-lançamento visual → captação em feiras → 
qualificação → apresentação do destino → visita → encaminhamento e acompanhamento.
Alcance internacional, pedidos de 
dossier, visitas, operadores interessados e propostas; duas ondas anuais antes das épocas de feiras.
Resiliência, Clima e Impacto
A12 e componentes ambientais de A03, A06, A14 e A15; fundos climáticos, cooperação, impacto, ONG e tecnologia.
Concept notes, matriz de impacto, dados ESG, webinar técnico, submissões a fundos, mesas de parceiros e conteúdos de transparência.
Mapear janelas de financiamento → adaptar concept note → identificar consórcio → validar elegibilidade → submissão → seguimento.
Janelas identificadas, concept notes, consórcios, submissões e financiamento; revisão mensal do pipeline.
Serviços Urbanos e Institucionais
A09 e componentes urbanas; construção, imobiliário, gestão de instalações, TIC, segurança e hotelaria.
Ficha de componentes, convite à manifestação de capacidade, briefing técnico e reuniões com fornecedores qualificados.
Publicar informação autorizada → receber capacidade → validar experiência → shortlist → encaminhar à entidade competente.
Empresas qualificadas, reuniões, propostas e tempo de resposta; campanhas associadas ao calendário institucional.
6.
11
. Governação e calendário comercial
Período
Actividades principais
Responsáveis
Entregáveis
Meses 1–2
Validar carteira, autorizações, pontos focais, campos, custos e prioridade; configurar CRM, formulários e modelos.
Dono do produto, MPD/tutelas, Jurídico, Conteúdo, Tecnologia e CRM.
Backlog aprovado, 15 fichas validadas, base de investidores e plano editorial.
Meses 3–4
Lançar catálogo, campanhas Industrializar Moçambique e Agro-indústria; activar newsletters, conteúdos e webinars.
Marketing, Conteúdo, Gestores sectoriais e CRM.
Landing pages, dossiers, automações, primeira lista de leads e relatórios semanais.
Meses 5–6
Activar Energia e Corredores; realizar briefings fechados e reuniões com contas prioritárias.
Gestores sectoriais, Relações institucionais e entidades promotoras.
Contas qualificadas, reuniões, pedidos de informação e encaminhamentos.
Meses 7–8
Lançar Turismo e Resiliência; desenvolver roadshows, visitas e concept notes.
Marketing internacional, Conteúdo, Clima/ESG e promotores.
Roadshow, visitas, consórcios e pipeline de financiamento.
Meses 9–10
Optimizar campanhas, reactivar leads, publicar resultados autorizados e preparar segunda onda.
CRM, Dados, Marketing e Gestão.
Relatório de conversão, conteúdos de prova, listas resegmentadas e campanhas corrigidas.
Meses 11–12
Realizar fórum anual de investimento, consolidar propostas e aprovar plano do ciclo seguinte.
Direcção da Tempo, parceiros públicos e privados.
Fórum, carteira de propostas, relatório anual e plano de 12 meses seguinte.
Gestão comercial:
 cada lead deve possuir origem, campanha, projecto, sector, país, perfil, capacidade indicativa, interesse, responsável, próxima acção, prazo e estado. O contacto inicial deve ocorrer dentro do nível de serviço aprovado; leads sem resposta entram em cadência de nutrição; leads qualificados seguem para reunião e validação institucional; nenhuma promessa, condição financeira ou acesso reservado pode ser comunicado sem autorização. A Direcção deve rever mensalmente o pipeline e trimestralmente o desempenho das campanhas.
6.
12
. Fluxo de captação e encaminhamento
Importar ou registar o projecto, preservando o código e a fonte oficial.
Validar conteúdo, autorização de publicação, estado de preparação e ponto focal.
Publicar a ficha e associá-la a sectores, territórios, campanhas e perfis de investidor.
Captar interesse por formulário estruturado, evento, contacto directo ou parceiro.
Registar automaticamente o contacto, projecto, campanha e origem no CRM.
Qualificar identidade, capacidade, estratégia, prazo, instrumento e requisitos do potencial investidor.
Atribuir pontuação de adequação e submeter o encaminhamento à revisão humana.
Obter autorização para partilha e enviar o interesse à entidade promotora competente.
Agendar reunião, controlar pedidos de informação e acompanhar os marcos acordados.
Registar o resultado: em análise, diligência, proposta, negociação, mobilizado, não concretizado ou suspenso.
6.
13
. Requisitos funcionais específicos
ID
Requisito
Critério de aceitação
RF-PII-001
Importar projectos por folha estruturada ou API.
O sistema valida campos, identifica duplicados, gera relatório de erros e preserva código e fonte.
RF-PII-002
Gerir versões e validação institucional.
Cada publicação identifica versão, data, entidade promotora, aprovador e histórico de alterações.
RF-PII-003
Publicar catálogo pesquisável e comparável.
O utilizador filtra por sector, território, valor, fase e modalidade e compara projectos seleccionados.
RF-PII-004
Gerar páginas e fichas promocionais.
Conteúdo aprovado pode ser publicado na Web e exportado nos idiomas disponíveis sem dados reservados.
RF-PII-005
Registar manifestações de interesse por projecto.
A submissão gera protocolo, associa projecto e campanha e cria contacto ou oportunidade no CRM.
RF-PII-006
Qualificar e pontuar potenciais investidores.
A pontuação considera capacidade, experiência, prazo, modalidade e adequação, mantendo explicação e revisão humana.
RF-PII-007
Gerir campanhas de angariação.
Cada campanha possui público, canais, conteúdo, calendário, orçamento, responsável e métricas.
RF-PII-008
Encaminhar interesses às entidades promotoras.
A partilha depende de aprovação, consentimento e registo de destinatário, data, informação enviada e resposta.
RF-PII-009
Acompanhar o funil de mobilização.
O painel apresenta contactos, qualificados, reuniões, propostas, negociações, investimento indicativo e mobilizado.
RF-PII-010
Gerir actualização e expiração de projectos.
Projectos sem confirmação no prazo são sinalizados, ocultados ou submetidos a nova validação.
RF-PII-011
Classificar automaticamente projectos por carteira promocional.
O sistema atribui sector, região, campanha recomendada, tipo de investidor e prioridade, permitindo revisão manual antes da publicação.
RF-PII-012
Produzir dossier promocional por projecto, sector e região.
O dossier agrega descrição, localização, custo, modalidade, impactos, riscos, contactos oficiais e documentos públicos aprovados.
RF-PII-013
Gerir autorização institucional de publicação e encaminhamento.
Nenhum projecto fica público nem é encaminhado sem registo da entidade promotora, ponto focal, versão autorizada, data e âmbito da autorização.
RF-PII-014
Monitorar funil por campanha, projecto e entidade promotora.
O painel mostra visualizações, pedidos de dossier, reuniões, investidores qualificados, propostas, encaminhamentos, respostas e valor indicativo mobilizado.
RF-PII-015
Registar e publicar o local exacto de realização do investimento.
O sistema exige localização principal, valida a hierarquia territorial, permite múltiplas áreas para projectos nacionais ou multiterritoriais, suporta coordenadas e mapa quando autorizados e disponibiliza pesquisa por região, província, distrito, cidade, corredor, zona económica, parque industrial ou bacia.
RF-PII-016
Gerir perfis “Porquê investir em Moçambique”.
O editor administra argumentos, dados, fontes, datas, regiões, sectores, idiomas e chamadas para acção, sem publicar conteúdo não aprovado.
RF-PII-017
Gerir actividades económicas e cadeias de valor.
Cada actividade relaciona sectores, produtos, mercados, infra-estruturas, projectos, empresas, riscos, reguladores, territórios e oportunidades.
RF-PII-018
Gerir áreas de investimento territoriais.
Cada área apresenta localização, projectos, actividades, infra-estruturas, serviços, incentivos validados, riscos, mapas autorizados e ponto focal.
RF-PII-019
Manter directório de reguladores e roteiros por processo.
O utilizador selecciona actividade e projecto e recebe entidades, licenças, documentos, sequência, canais oficiais e prazos validados.
RF-PII-020
Converter navegação em perfil e oportunidade no CRM.
Com consentimento, dossiers, favoritos, alertas, eventos, comparações e manifestações de interesse registam origem, tema, projecto, localização, campanha e próxima acção.
7. Jornada digital do investidor
Identificar o perfil, o sector, a localização e a dimensão do investimento.
Consultar oportunidades, requisitos legais, incentivos e riscos aplicáveis.
Explorar por actividade económica, área de investimento, província, corredor ou regulador e comparar alternativas antes de manifestar interesse.
Quando aplicável, escolher entre vender um negócio, captar investimento, comprar uma empresa existente ou investir numa participação empresarial.
Criar conta e registar a manifestação de interesse.
Receber uma lista personalizada de documentos, etapas e entidades.
Solicitar esclarecimento, reunião ou apoio de facilitação.
Submeter informação ou pedidos, quando existir integração oficialmente autorizada.
Acompanhar o estado, responder a pendências e receber notificações.
Avaliar o serviço e manter o relacionamento após a instalação do investimento.
8. CRM, automação e inteligência artificial
O CRM deve manter um registo único do investidor, organização, contactos, interesses, documentos, actividades, consentimentos e histórico de atendimento.
Os fluxos devem incluir responsáveis, prazos, alertas, escalonamento, níveis de serviço e trilho de auditoria.
A IA pode apoiar pesquisa, triagem, tradução, recomendação, resumo e detecção de pedidos incompletos.
Respostas com impacto jurídico, fiscal, cambial ou administrativo devem citar a fonte e ser apresentadas como orientação sujeita a confirmação oficial.
Decisões, aprovações e rejeições devem permanecer sob responsabilidade humana ou da entidade competente.
O sistema deve permitir revisão, correcção, monitoria de qualidade e suspensão de respostas automatizadas inadequadas.
9. Estratégia de conversão e funil de captação no CRM
A estratégia deverá converter visitantes anónimos em contactos identificados, 
contactos em investidores qualificados e estes em reuniões
, propostas e investimentos concretizados. A conversão deve ser progressiva: solicitar apenas a informação 
necessária em cada etapa, oferecer conteúdo proporcional ao compromisso do utilizador e manter um responsável e uma próxima acção para cada oportunidade no CRM.
9.1. Estratégia de conversão de visitantes em investidores
Etapa
Objectivo
Oferta ao utilizador
Dados captados
Acção automática
Atrair
Gerar tráfego qualificado por sector, país e território.
Artigos, perfis sectoriais, fichas territoriais, campanhas, eventos e páginas “Porquê investir”.
Origem, campanha, página, país aproximado, idioma e comportamento agregado.
Segmentar audiência e recomendar conteúdo relacionado, respeitando consentimento.
Envolver
Aumentar interesse e recorrência.
Comparação de projectos, mapas autorizados, calculadoras indicativas, vídeos, perguntas frequentes e boletins.
Sector, localização, modalidade, páginas consultadas, favoritos e temas escolhidos.
Personalizar recomendações e convite à subscrição.
Converter em contacto
Obter identificação e permissão de relacionamento.
Dossier, alerta, inscrição em webinar, pedido de informação ou contacto com a Tempo.
Nome, organização, função, país, correio electrónico, telefone opcional, interesse e consentimento.
Criar ou actualizar contacto no CRM, atribuir origem e iniciar nutrição.
Qualificar
Confirmar intenção, adequação e capacidade.
Formulário progressivo, reunião de descoberta e recomendação de oportunidades.
Perfil, experiência, capacidade indicativa, instrumento, prazo, sector, localização e decisão.
Calcular pontuação, atribuir gestor e criar tarefa dentro do nível de serviço.
Converter em oportunidade
Associar investidor a projecto ou negócio concreto.
Dossier avançado, apresentação, sessão com promotor e esclarecimentos.
Projecto, modalidade, valor indicativo, condições, participantes, obstáculos e próximos passos.
Criar oportunidade, plano de acção, reunião e previsão de fecho.
Avançar para proposta
Obter manifestação formal, carta de interesse ou proposta.
Acesso autorizado a documentos, sala segura, visitas e coordenação institucional.
Documento de interesse, montante, calendário, condições, diligência e aprovações.
Actualizar etapa, probabilidade, valor e alertar responsáveis.
Concretizar e fidelizar
Registar investimento e manter relação de longo prazo.
Apoio de instalação, acompanhamento, expansão, fornecedores e novas oportunidades.
Valor mobilizado autorizado, empregos, localização, marcos, satisfação e novas necessidades.
Encerrar como ganho, criar plano pós-investimento e campanhas de expansão.
9.2. Perfis de investidores e campanhas segmentadas
Perfil
Necessidade principal
Critérios de segmentação
Campanha e conteúdo
Conversão prioritária
Investidor estratégico empresarial
Acesso a mercado, activos, cadeia de fornecimento, integração vertical ou expansão regional.
Sector, país, receitas, presença regional, tecnologia, experiência e dimensão pretendida.
Dossiers sectoriais, oportunidades de aquisição, parques industriais, reuniões executivas e visitas.
Reunião com promotor, carta de interesse ou proposta de parceria.
Fundo de infra-estruturas ou private equity
Projectos estruturados, governação, retorno, saída, riscos e pipeline.
Ticket, mandato, sector, fase, moeda, prazo, controlo e tolerância ao risco.
Corredores, energia, parques, PPP, sala informativa e briefing fechado.
Manifestação de interesse, diligência e proposta indicativa.
Banco, instituição financeira ou DFI
Projectos financiáveis, garantias, impacto, conformidade e capacidade de reembolso.
Instrumento, prazo, moeda, concessionalidade, sector, país e critérios ambientais e sociais.
Pipeline financiável, concept notes, blended finance, mesas técnicas e dados de impacto.
Term sheet indicativo, missão de avaliação ou financiamento.
Fundo climático ou de impacto
Impacto mensurável, adicionalidade, elegibilidade, mitigação e adaptação.
Tema ESG, geografia, beneficiários, instrumento, janela e métricas.
Resiliência, energia limpa, água, agricultura, economia azul e chamadas de financiamento.
Consórcio, concept note ou candidatura.
Desenvolvedor, operador ou concessionário
Direitos de desenvolvimento, procura, viabilidade, licenças e parceiro local.
Especialidade, capacidade técnica, histórico, território e modelo contratual.
Convites de capacidade, fichas técnicas, roadshows e sessões com tutelas.
Pré-qualificação, consórcio ou proposta técnica.
Empresa fornecedora de tecnologia, EPC ou serviços
Pipeline de contratos, especificações, parceiros e calendário.
Produto, certificações, capacidade, localização, prazo e referências.
Alertas de fornecimento, briefings técnicos, catálogos de componentes e eventos B2B.
Registo de fornecedor e encaminhamento para componente.
Investidor em PME ou negócio existente
Aquisição, participação, expansão, sucessão empresarial ou parceria.
Sector, localização, valor, percentagem, intervenção na gestão e horizonte.
Mercado de negócios, perfis anónimos, correspondência e reuniões confidenciais.
Autorização bilateral, acordo de confidencialidade e diligência.
Investidor individual e diáspora
Oportunidades acessíveis, confiança, apoio local e clareza regulatória.
País de residência, capacidade, sector, localização e nível de envolvimento.
Boletins, webinars, oportunidades por província, guias e atendimento assistido.
Perfil verificado, reunião de orientação ou participação elegível.
Promotor público ou privado
Capital, parceiro, operador, comprador, 
tecnologia ou visibilidade.
Natureza, maturidade, valor, localização, 
documentação e autorização.
Preparação de ficha, campanha sectorial, 
matching e apresentação a contas-alvo.
Projecto aprovado e campanha activa no CRM.
9.3. Pontuação e qualificação do investidor
Critério
Peso de referência
Evidência
Adequação ao sector, projecto e localização
20%
Preferências, experiência e correspondência com requisitos.
Capacidade financeira indicativa
20%
Faixa declarada e comprovação progressiva.
Experiência e capacidade técnica
15%
Portefólio, projectos comparáveis, equipa e certificações.
Intenção e prontidão
15%
Prazo, decisão interna, pedido concreto, participação em reunião e resposta a tarefas.
Modalidade e instrumento compatíveis
10%
Capital, dívida, PPP, concessão, compra, operação ou fornecimento.
Conformidade e transparência
10%
Identidade, representação, beneficiário efectivo e origem lícita dos fundos, quando aplicável.
Impacto e valor estratégico
10%
Emprego, conteúdo local, tecnologia, exportação, resiliência e desenvolvimento territorial.
Faixas sugeridas:
 80–100, prioridade estratégica e contacto imediato; 60–79, qualificado para reunião; 40–59, nutrição e recolha adicional; abaixo de 40, acompanhamento automatizado ou arquivo. Condições eliminatórias — identidade não verificável, incompatibilidade legal, origem de fundos não esclarecida quando exigida, informação falsa ou conflito não mitigado — sobrepõem-se à pontuação. Nenhuma rejeição ou decisão de investimento deve ser exclusivamente automatizada.
9.4. Funil de captação no CRM
Estado
Critério de entrada
Acção e responsável
Critério de saída
Prazo de referência
Visitante identificado
Subscrição, dossier, evento, formulário ou conta.
CRM consolida contacto, origem e consentimento; Marketing acompanha.
Perfil mínimo e interesse confirmados.
Automático.
Lead novo
Contacto válido com interesse registado.
Distribuir por sector, território e campanha; Gestor recebe tarefa.
Primeiro contacto efectuado ou nutrição iniciada.
1 dia útil.
Lead em contacto
Tentativa ou resposta inicial.
Confirmar organização, função, necessidade e disponibilidade.
Reunião aceite, informação adicional ou sem resposta.
Até 5 dias úteis.
Em qualificação
Interesse real e dados mínimos disponíveis.
Aplicar perfil e pontuação; Gestor sectorial valida.
Pontuação e decisão de qualificação registadas.
Até 5 dias úteis.
Em nutrição
Interesse relevante, mas prazo, capacidade ou projecto ainda não prontos.
Enviar conteúdo e alertas segmentados; Marketing e CRM monitoram sinais.
Novo sinal de intenção, prazo expirado ou perda.
Revisão mensal.
Investidor qualificado
Pontuação mínima, identidade e adequação confirmadas.
Atribuir gestor, projecto e plano de acção.
Reunião de descoberta concluída.
Até 3 dias úteis.
Reunião realizada
Necessidade, capacidade e condições discutidas.
Registar acta, obstáculos, documentos e próxima acção.
Projecto seleccionado ou oportunidade suspensa.
2 dias úteis após reunião.
Oportunidade criada
Interesse associado a projecto, negócio ou carteira.
Definir valor indicativo, probabilidade, promotor, equipa e previsão.
Apresentação ao promotor ou acesso autorizado.
Até 5 dias úteis.
Encaminhada ao promotor
Consentimento e aprovação de partilha concluídos.
Relações institucionais controla recepção e resposta.
Resposta, reunião técnica ou pedido adicional.
Prazo institucional acordado.
Em diligência
Partes concordam em analisar documentos e condições.
Gerir sala segura, perguntas, tarefas e especialistas.
Proposta, desistência ou suspensão.
Conforme plano.
Proposta recebida
Carta de interesse, term sheet ou proposta formal.
Registar valor, instrumento, condições e validade.
Negociação, aprovação ou rejeição fundamentada.
Conforme validade.
Em negociação
Condições principais em discussão.
Actualizar marcos, decisões, riscos e previsão de fecho.
Ganho, perdido ou suspenso.
Revisão semanal.
Ganho / investimento mobilizado
Acordo ou compromisso confirmado pela entidade competente.
Registar valor autorizado, projecto, instrumento e plano pós-investimento.
Transição para acompanhamento e expansão.
Imediato.
Perdido
Desistência, rejeição, incompatibilidade ou ausência prolongada.
Registar motivo padronizado e possibilidade de reactivação.
Arquivo ou nova nutrição, quando autorizada.
Imediato.
9.5. Automações e notificações
Atribuição automática por sector, localização, idioma, campanha e carga de trabalho.
Resposta imediata com protocolo, conteúdo solicitado e expectativa de prazo.
Tarefa e escalonamento quando o primeiro contacto ou seguimento ultrapassar o nível de serviço.
Cadências segmentadas para leads novos, sem resposta, em nutrição, pós-evento e reactivação.
Alertas quando o investidor consulta repetidamente um projecto, solicita novo dossier, participa em evento ou actualiza capacidade.
Lembretes de reunião, documentos, autorizações, validade de proposta e próxima acção.
Bloqueio de partilha de dados reservados enquanto consentimentos, aprovação ou confidencialidade não estiverem concluídos.
Resumo semanal por gestor e painel mensal para Direcção, com conversão, valor, atrasos, perdas e previsões.
9.6. Indicadores de aquisição, conversão e investimento
Dimensão
Indicador
Cálculo ou definição
Periodicidade
Aquisição
Visitantes qualificados por campanha
Visitantes que consultam conteúdo sectorial, territorial, projecto ou regulador.
Semanal e mensal
Aquisição
Custo por contacto
Despesa da campanha ÷ contactos válidos gerados.
Por campanha
Envolvimento
Taxa de interacção qualificada
Visitantes com comparação, favorito, dossier, alerta ou evento ÷ visitantes.
Mensal
Conversão
Visitante para contacto
Contactos válidos ÷ visitantes.
Mensal
Conversão
Contacto para investidor qualificado
Investidores qualificados ÷ contactos trabalhados.
Mensal
Conversão
Qualificado para oportunidade
Oportunidades criadas ÷ investidores qualificados.
Mensal
Conversão
Oportunidade para proposta
Propostas recebidas ÷ oportunidades activas.
Mensal e trimestral
Resultado
Taxa de concretização
Oportunidades ganhas ÷ oportunidades encerradas.
Trimestral
Resultado
Valor indicativo do pipeline
Soma dos valores indicativos das oportunidades activas, sem confundir com investimento confirmado.
Semanal
Resultado
Valor ponderado do pipeline
Soma de valor indicativo × probabilidade aprovada por etapa.
Semanal
Resultado
Investimento mobilizado
Valor confirmado e autorizado pela entidade competente.
Mensal e anual
Eficiência
Tempo de primeira resposta
Tempo entre criação do lead e primeiro contacto válido.
Diário e mensal
Eficiência
Tempo por etapa
Dias médios e mediana em cada estado do funil.
Mensal
Eficiência
Leads sem próxima acção
Registos activos sem tarefa futura ÷ registos activos.
Diário
Qualidade
Completude do CRM
Registos com campos obrigatórios, responsável e próxima acção ÷ registos activos.
Semanal
Qualidade
Motivos de perda
Distribuição padronizada por financiamento, maturidade, prazo, risco, inadequação, ausência de resposta ou decisão institucional.
Mensal e trimestral
Relacionamento
Satisfação do investidor
Avaliação após reunião, encaminhamento e encerramento.
Por marco
9.7. Requisitos funcionais do CRM de captação
ID
Requisito
Critério de aceitação
RF-CRM-001
Consolidar contacto e organização num registo único.
Correio, telefone, domínio, NUIT ou identificação equivalente detectam duplicados e preservam histórico.
RF-CRM-002
Registar origem e atribuição multicanal.
Cada lead mantém primeira origem, última origem, campanha, conteúdo, evento e parceiro.
RF-CRM-003
Classificar perfil de investidor.
O gestor selecciona perfil principal e secundário, ticket, instrumento, sectores, localização e horizonte.
RF-CRM-004
Aplicar pontuação configurável e explicável.
O CRM mostra critérios, pesos, evidências, versão, resultado e revisão humana.
RF-CRM-005
Gerir funil, transições e critérios obrigatórios.
Nenhuma etapa avança sem campos, aprovações e actividades mínimas definidas.
RF-CRM-006
Gerir responsável, equipa e próxima acção.
Todo registo activo possui responsável e tarefa futura; ausência gera alerta.
RF-CRM-007
Automatizar cadências e níveis de serviço.
Modelos, prazos, tentativas, pausas, preferência e consentimento são configuráveis e auditáveis.
RF-CRM-008
Relacionar investidor, projecto, local, campanha e promotor.
Uma organização pode ter múltiplos interesses e oportunidades sem duplicar contactos.
RF-CRM-009
Registar valor, probabilidade e previsão.
Oportunidades activas apresentam moeda, valor indicativo, probabilidade aprovada, data prevista e fundamento.
RF-CRM-010
Produzir painéis de conversão e pipeline.
Filtros incluem período, campanha, perfil, sector, país, localização, projecto, gestor, etapa e motivo de perda.
RF-CRM-011
Proteger dados e consentimentos.
Comunicações e partilhas respeitam finalidade, preferência, permissão, confidencialidade e retenção.
RF-CRM-012
Registar encerramento e pós-investimento.
Ganho exige confirmação, valor autorizado e plano de acompanhamento; perda exige motivo e possibilidade de reactivação.
9.8. Especificação detalhada dos requisitos funcionais do CRM
Os requisitos RF-CRM-001 a RF-CRM-012 são apresentados nas tabelas seguintes com regras de negócio, critérios de aceitação verificáveis, prioridade e dependências. Para aprovação do desenvolvimento, cada requisito deverá ser convertido em histórias de utilizador e casos de teste positivos, negativos, de autorização, auditoria e recuperação de falha.
ID
Descrição e regras de negócio
Critérios de aceitação verificáveis
Prioridade / dependências
RF-CRM-001
Registo único de contacto e organização.
 Criar ou actualizar contactos e organizações provenientes do portal, campanhas, eventos, importações e registo manual. Impedir duplicação por correio electrónico normalizado, telefone, domínio, NUIT ou identificação equivalente. A fusão deve preservar origem, actividades, consentimentos e relações.
1) Ao submeter um correio já existente, o sistema actualiza ou propõe fusão, sem criar duplicado silencioso. 2) A pesquisa encontra o registo por nome, correio, telefone, NUIT ou domínio. 3) A fusão mostra campos divergentes, exige escolha do valor principal e mantém histórico. 4) Uma organização admite vários contactos e um contacto pode representar mais de uma organização com período e função.
MVP. Depende de catálogos de país, tipo de pessoa e regras de normalização.
RF-CRM-002
Origem e atribuição multicanal.
 Registar primeira origem, última origem, canal, campanha, conteúdo, evento, parceiro, parâmetros de campanha e formulário. A primeira origem é imutável; a última origem actualiza-se a cada nova interacção identificada.
1) Todo lead possui primeira origem e data. 2) Nova conversão actualiza a última origem sem apagar a primeira. 3) Registos importados exigem fonte e responsável. 4) Relatórios distinguem origem inicial, assistida e final. 5) Alteração manual exige permissão e motivo.
MVP. Depende de campanhas, formulários, eventos e integração analítica.
RF-CRM-003
Perfil do investidor.
 Classificar perfil principal e secundário, mandato, ticket, instrumentos, sectores, territórios, horizonte, nível de envolvimento, experiência, impacto esperado e restrições. A classificação pode ser sugerida pelo sistema, mas depende de confirmação humana.
1) O perfil pode ser criado progressivamente. 2) Sector, localização, instrumento e faixa financeira admitem múltiplas selecções priorizadas. 3) O gestor confirma ou corrige a sugestão e regista fundamento. 4) Alterações relevantes recalculam correspondências. 5) Campos altamente restritos obedecem a permissões.
MVP. Depende de catálogos sectoriais, territoriais, instrumentos e perfis.
RF-CRM-004
Pontuação configurável e explicável.
 Calcular adequação, capacidade, experiência, intenção, compatibilidade do instrumento, conformidade e impacto. Pesos, faixas e condições eliminatórias são versionados por campanha ou carteira. A decisão final é humana.
1) O resultado apresenta pontuação total, notas por critério, evidência, versão e data. 2) Critério sem evidência fica pendente ou recebe regra definida. 3) Condição eliminatória bloqueia avanço e gera revisão. 4) Gestor pode ajustar com justificativa e autorização. 5) Reprocessamento não altera o histórico anterior.
MVP. Depende de RF-CRM-003, motor de regras, auditoria e conformidade.
RF-CRM-005
Funil, transições e etapas obrigatórias.
 Gerir estados desde visitante identificado até ganho, perdido ou suspenso. Cada transição define campos, actividades, aprovação, motivo e notificação obrigatórios. Retrocesso mantém histórico e explica a causa.
1) Não é possível avançar sem cumprir critérios da etapa. 2) Estados encerrados exigem motivo padronizado. 3) Retrocesso exige comentário. 4) Cada transição regista autor, data, estado anterior e novo. 5) Probabilidade e previsão actualizam segundo regra configurada, sujeita a validação do gestor.
MVP. Depende de matriz de estados, perfis de acesso e auditoria.
RF-CRM-006
Responsável, equipa e próxima acção.
 Todo registo activo deve possuir responsável principal, equipa, fila e próxima acção com prazo. A atribuição considera sector, localização, idioma, campanha, promotor e carga de trabalho.
1) Lead activo sem responsável ou próxima acção aparece em alerta. 2) Redistribuição conserva histórico. 3) Ausência programada encaminha tarefas. 4) O gestor visualiza carteira por responsável e atraso. 5) Apenas utilizador autorizado encerra ou transfere a oportunidade.
MVP. Depende de utilizadores, equipas, calendários e níveis de serviço.
ID
Descrição e regras de negócio
Critérios de aceitação verificáveis
Prioridade / dependências
RF-CRM-007
Cadências e níveis de serviço.
 Configurar sequências por perfil, etapa, campanha e idioma, com modelos, canais, intervalos, tentativas, horário, pausa e escalonamento. A comunicação depende de consentimento e preferência.
1) Evento elegível inicia a cadência correcta. 2) Resposta, reunião, revogação ou mudança de estado pausa a sequência. 3) Falha gera nova tentativa dentro do limite e tarefa manual ao esgotar. 4) Atraso no nível de serviço alerta responsável e superior. 5) Todos os envios guardam modelo, versão, canal e resultado.
MVP. Depende de consentimentos, modelos, correio/SMS e calendários.
RF-CRM-008
Relações entre investidor, projecto, local, campanha e promotor.
 Um investidor pode ter vários interesses e oportunidades; uma oportunidade pode envolver vários contactos, organizações, projectos, locais, promotores e parceiros, indicando papel e período.
1) O sistema permite múltiplas relações sem duplicar o contacto. 2) Cada relação possui tipo, prioridade, data e estado. 3) A remoção lógica não apaga histórico. 4) Pesquisa e relatórios navegam em ambos os sentidos. 5) Acesso a relações confidenciais respeita permissões.
MVP. Depende do modelo de dados, projectos, locais e organizações.
RF-CRM-009
Valor, probabilidade e previsão.
 Registar moeda, valor mínimo, máximo e estimado, instrumento, probabilidade, data prevista, cenário e fundamento. Valores indicativos não são apresentados como investimento confirmado.
1) Moeda e data de referência são obrigatórias quando há valor. 2) Mínimo não excede máximo. 3) Probabilidade automática pode ser ajustada com fundamento. 4) Alterações ficam historizadas. 5) O painel separa valor bruto, ponderado, proposto e confirmado.
MVP. Depende de moedas, etapas, regras de probabilidade e auditoria.
RF-CRM-010
Painéis e relatórios.
 Apresentar aquisição, conversão, velocidade, pipeline, investimento confirmado, produtividade, qualidade dos dados, campanhas e motivos de perda. Filtros devem respeitar acesso e período.
1) Filtros incluem campanha, perfil, sector, país, local, projecto, promotor, gestor e etapa. 2) Totais reconciliam com registos fonte. 3) Exportação respeita mascaramento. 4) Indicadores exibem definição e data de actualização. 5) Utilizador pode abrir a lista que compõe cada indicador.
MVP. Depende de todos os registos transaccionais e modelo analítico.
RF-CRM-011
Protecção de dados, consentimentos e confidencialidade.
 Registar finalidade, base, versão, canal, data, preferências e revogação. Aplicar acesso por função, minimização, retenção, mascaramento e bloqueio de partilha reservada.
1) Comunicação não obrigatória cessa após revogação. 2) Acesso e exportação de dados restritos ficam auditados. 3) Partilha com promotor exige consentimento e aprovação vigentes. 4) Retenção vencida cria tarefa de eliminação ou anonimização. 5) Pedido de acesso ou correcção recebe protocolo e prazo.
MVP. Depende de módulo de consentimentos, perfis, auditoria e retenção.
RF-CRM-012
Encerramento e pós-investimento.
 Ganho exige confirmação pela entidade competente, valor autorizado, instrumento, data, projecto, localização e plano de acompanhamento. Perda exige motivo, concorrente ou alternativa quando aplicável e possibilidade de reactivação.
1) Apenas utilizador autorizado marca “ganho”. 2) Valor confirmado fica separado do indicativo. 3) Encerramento cria avaliação e plano pós-investimento. 4) Perda usa motivo de catálogo e comentário. 5) Reactivação cria nova fase sem apagar o encerramento anterior.
MVP para encerramento; Fase 2 para pós-investimento. Depende de aprovações, indicadores e tarefas.
Critério transversal: todos os requisitos devem possuir testes positivos, negativos, de autorização, auditoria e recuperação de falha. Os valores, probabilidades e classificações 
produzidos pelo CRM são instrumentos de gestão e não substituem confirmação da entidade competente.
9.9. Matriz de campanhas segmentadas e orçamento indicativo
Campanha / público
Mensagem central e chamada
Canais e activos
Orçamento indicativo
Meta e decisão
Moçambique: Razões para Investir
Empresas em descoberta, câmaras, consultores, diplomacia económica e diáspora.
“Descubra sectores, territórios e projectos que ligam Moçambique aos mercados regionais.” CTA: explorar, descarregar dossier e solicitar reunião.
Portal, SEO, Revista Tempo, LinkedIn, correio, vídeo, webinar e apresentações institucionais.
MZN 1 200 000–1 800 000/ano.
 Conteúdo 30%; media 30%; eventos digitais 15%; tecnologia/landing pages 15%; medição 10%.
Contactos válidos, subscrições, dossiers, reuniões e custo por contacto. Manter se a conversão para contacto atingir a meta aprovada.
Industrializar Moçambique
Fabricantes, operadores de parques, marcas, fundos industriais, PME e fornecedores.
“Instale, financie ou forneça para novas plataformas industriais e cadeias de valor.” CTA: seleccionar localização e apresentar capacidade.
Dossier sectorial, fichas provinciais, LinkedIn, correio dirigido, fórum, webinar e reuniões B2B.
MZN 1 500 000–2 400 000/ano.
 Conteúdo 20%; contas-alvo 20%; media 20%; fórum/roadshow 30%; CRM/medição 10%.
60 contas-alvo, 25 reuniões, 10 manifestações e 3 propostas indicativas por ciclo anual.
Corredores Logísticos e Exportação
Portos, ferrovias, fundos, operadores logísticos, mineração e exportadores.
“Participe na integração dos corredores, terminais e serviços que reduzem custos e ampliam exportações.” CTA: solicitar briefing fechado.
Account-based marketing, mapa autorizado, dossier técnico, vídeo executivo, missões e reuniões individuais.
MZN 2 000 000–3 500 000/ano.
 Pesquisa/contas 15%; activos 20%; missões 45%; reuniões 10%; CRM 10%.
50 contas activadas, 20 briefings, 12 reuniões e 4 processos de diligência. Rever após cada missão.
Energia para Crescimento
Produtores, EPC, fornecedores, financiadores climáticos, utilities e compradores.
“Energia e transmissão para industrializar, electrificar e vender ao mercado regional.” CTA: indicar papel, capacidade e projecto de interesse.
Dossier energético, roundtable, webinar técnico, associações, bancos, correio dirigido e sala informativa.
MZN 1 800 000–3 000 000/ano.
 Activos 20%; mesas técnicas 30%; media 15%; contacto directo 20%; CRM 15%.
30 investidores/fornecedores qualificados, 15 reuniões, 5 consórcios ou propostas em formação.
Agro-indústria e Segurança Alimentar
Produtores, processadores, irrigação, 
armazenagem, retalho, bancos e agtech.
“Invista da produção ao processamento e mercado, com oportunidades em irrigação, logística 
e substituição de importações.” CTA: escolher cadeia e local.
Fichas por cadeia, rádio e meios sectoriais, feiras, visitas de campo, 
webinar e parceiros financeiros.
MZN 1 600 000–2 800 000/ano.
 Conteúdo 20%; media 20%; feiras 25%; visitas 25%; CRM 10%.
80 leads por cadeia, 30 qualificados, 15 visitas e 5 cartas de interesse/propostas.
Turismo Costeiro e Serviços
Hotelaria, resorts, aviação, marinas, fundos imobiliários, operadores e tecnologia.
“Desenvolva destinos integrados em Vilanculos e Crusse Jamali.” CTA: solicitar dossier, participar em roadshow ou agendar visita.
Microssítio visual, brochura, vídeo, feiras, imprensa especializada, roadshow e visitas.
MZN 2 200 000–4 000 000/ano.
 Produção visual 20%; feiras/roadshow 45%; media 20%; visitas 10%; CRM 5%.
40 operadores contactados, 15 reuniões, 8 visitas e 3 propostas. Activar em duas ondas anuais.
Resiliência, Clima e Impacto
Fundos climáticos, cooperação, DFI, fundos de impacto, ONG e tecnologia.
“Financie projectos com impacto mensurável em água, energia, agricultura, conectividade e costa.” CTA: formar consórcio ou solicitar concept note.
Concept notes, matriz ESG, bases de financiadores, mesas técnicas, webinar e submissões.
MZN 1 400 000–2 500 000/ano.
 Pesquisa 20%; preparação técnica 35%; eventos 15%; submissões 20%; CRM 10%.
12 janelas mapeadas, 8 concept notes, 4 consórcios e 3 submissões qualificadas.
Mercado de Negócios e Diáspora
Investidores individuais, diáspora, empresários, family offices e compradores de PME.
“Encontre negócios existentes para comprar, capitalizar ou desenvolver em Moçambique.” CTA: criar perfil verificado e receber correspondências.
Portal, boletim, webinars por país, associações da diáspora, correio, eventos e atendimento assistido.
MZN 900 000–1 600 000/ano.
 Conteúdo 20%; parceiros 20%; eventos 25%; media 20%; CRM 15%.
150 perfis, 60 qualificados, 20 correspondências autorizadas e 5 diligências.
Síntese anual
Valor / meta
Regra de gestão
Orçamento mínimo agregado das oito campanhas
MZN 12 600 000
Cenário essencial, priorizando conteúdo, CRM, contacto dirigido e activações de maior conversão.
Orçamento máximo agregado das oito campanhas
MZN 21 600 000
Cenário expandido, incluindo missões, feiras, roadshows e produção audiovisual intensiva.
Reserva de contingência
Até 10% dentro do tecto aprovado
Uso sujeito a autorização, motivo e relatório de execução.
Revisão de alocação
Trimestral
Redistribuir segundo custo por contacto qualificado, avanço no funil, reuniões, propostas e valor ponderado.
Meta de topo de funil
Contactos e perfis válidos por campanha
Metas específicas permanecem na matriz; duplicados e contactos sem consentimento não contam.
Meta de conversão
Investidores qualificados, reuniões, diligências e propostas
O CRM deve demonstrar a origem, a etapa e a contribuição de cada campanha.
Meta de resultado
Investimento confirmado e autorizado
Separar sempre valor indicativo, ponderado, proposto e efectivamente mobilizado.
Os orçamentos são intervalos de planeamento, não cotações. Devem ser validados por procurement e ajustados ao número de mercados, viagens, fornecedores, produção audiovisual e compra de media. Recomenda-se uma reserva de contingência de 10% dentro do tecto aprovado e redistribuição trimestral segundo custo por contacto qualificado, avanço no funil e valor ponderado do pipeline.
9.10. Modelo de dados do investidor, lead e oportunidade
Entidade
Campos principais
Validações e segurança
Relações
Organização / investidor institucional
investor_id; type; legal_name; trade_name; registration_number; NUIT; country; address; website; profile_primary; profile_secondary; mandate; sectors; geographies; instruments; ticket_min; ticket_max; currency; horizon; management_preference; impact_priorities; risk_appetite; verification_status; risk_level; owner_user_id; created_at; updated_at.
Identificador único; nome e país obrigatórios; NUIT único quando aplicável; faixa financeira coerente; dados financeiros e beneficiário efectivo altamente restritos; alterações de verificação auditadas.
1:N contactos; N:N sectores, locais, campanhas e projectos; 1:N leads e oportunidades; N:N promotores/parceiros por papel.
Contacto do investidor
contact_id; investor_id; full_name; job_title; email; phone; preferred_language; preferred_channel; country; decision_role; verification_status; communication_status; owner_user_id.
Correio normalizado; telefone internacional; contacto principal único por organização e finalidade; preferências e bloqueios aplicados em todas as comunicações.
N:1 organização; N:N oportunidades, actividades e campanhas; 1:N consentimentos.
Lead
lead_id; contact_id; investor_id opcional; first_source; last_source; channel; campaign_id; content_id; event_id; referred_by; interest_type; sector_ids; location_ids; project_ids; declared_capacity_min/max; currency; instrument_ids; time_horizon; lead_status; score; score_version; owner_user_id; next_action_at; created_at; qualified_at; disqualified_reason.
Lead pode nascer sem organização; pelo menos um contacto ou canal identificável; primeira origem imutável; capacidade não negativa; estado e próxima acção obrigatórios enquanto activo; desqualificação exige motivo.
N:1 contacto/organização quando identificados; N:N projectos, sectores, locais e campanhas; 1:N actividades; 0..1 conversão para oportunidade principal, admitindo várias oportunidades justificadas.
Oportunidade
opportunity_id; investor_id; lead_id; name; opportunity_type; stage; stage_reason; project_ids; business_listing_id opcional; 
promoter_ids; location_ids; sector_ids; instrument_ids; amount_min; amount_max; amount_estimated; currency; probability; weighted_value; expected_close_date; source_campaign_id; owner_user_id; team_ids; next_action_at; confidentiality_level; approval_status; lost_reason; confirmed_amount; confirmed_date; created_at; closed_at.
Investidor e tipo obrigatórios; projecto ou negócio obrigatório antes da 
diligência; valor exige moeda; probabilidade entre 0 e 100; weighted_value calculado; ganho requer aprovação, montante confirmado e data; perdido exige motivo.
N:1 investidor; N:N contactos, projectos, locais, promotores, instrumentos, 
documentos e actividades; 1:N histórico de etapas, valores, aprovações e previsões.
Interesse do investidor
interest_id; investor_id; sector_id; location_id; project_id opcional; priority; role_sought; instrument_id; ticket_min/max; currency; horizon; eliminatory_condition; active_from; active_to.
Evitar duplicado exacto; prioridade obrigatória; data final posterior à inicial; condições eliminatórias reservadas.
Entidade associativa entre investidor, sector, local, projecto e instrumento; alimenta correspondência.
Actividade CRM
activity_id; entity_type; entity_id; activity_type; subject; description; channel; occurred_at; due_at; status; outcome; owner_user_id; participants; confidentiality_level.
Entidade e tipo obrigatórios; tarefas abertas exigem prazo; reunião concluída exige resultado; notas confidenciais protegidas.
Relaciona lead, contacto, organização ou oportunidade; pode gerar próxima acção e notificação.
Campanha e participação
campaign_id; name; objective; audience_profile; start_date; end_date; budget_min/max; currency; owner_user_id; status; channel_ids; project_ids; participation_id; member_status; response; attributed_value.
Período e moeda obrigatórios; orçamento não negativo; participação única por contacto e campanha; atribuição conserva primeira e última influência.
N:N contactos, investidores, leads, oportunidades, projectos, conteúdos, eventos e canais.
Consentimento
consent_id; subject_type; subject_id; purpose; lawful_basis; channel; status; policy_version; captured_at; expires_at; withdrawn_at; source; evidence.
Finalidade, versão e data obrigatórias; revogação bloqueia tratamento não necessário; histórico imutável.
1:N por contacto ou organização e finalidade; consultado por campanhas, partilhas e retenção.
9.11. Regras de conversão, cardinalidade e integridade
9.12. Diagrama das entidades e relações do CRM
O diagrama representa o modelo lógico proposto. As relações muitos-para-muitos devem ser implementadas por tabelas associativas; actividades e consentimentos usam referência controlada à entidade de origem; valores, etapas e relações críticas devem manter histórico e auditoria. A arquitectura física, índices, particionamento, nomes finais e tipos de dados serão definidos no desenho técnico.
Um visitante identificado cria contacto e lead; a organização só é criada quando houver dados suficientes ou validação manual.
Um contacto pode pertencer a várias organizações, mas cada relação deve indicar função, período e organização principal.
A qualificação não elimina o lead: cria ou associa o investidor e conserva origem, pontuação, evidências e actividades.
Um lead pode gerar várias oportunidades apenas quando há projectos, negócios ou instrumentos distintos; cada criação exige justificativa.
Uma oportunidade pode envolver vários contactos e promotores, com papel definido: decisor, influenciador, consultor, financiador, operador ou ponto focal.
Valores monetários conservam moeda original, data e fonte; conversões para relatórios usam taxa e data identificadas.
Campos multivalorados — sectores, locais, instrumentos, projectos e campanhas — devem usar tabelas associativas, não texto livre.
Todos os catálogos e regras devem ser versionados sem alterar retroactivamente registos históricos.
Eliminação funcional deve ser lógica; eliminação física ou anonimização segue a política de retenção e deixa comprovativo.
O trilho de auditoria deve registar criação, alteração, fusão, exportação, partilha, pontuação, transição, aprovação e encerramento.
9.13. Histórias de utilizador e backlog do CRM
ID
História de utilizador
Critérios de aceitação resumidos
Épico / prioridade
US-CRM-001
Como analista, quero localizar, criar e fundir contactos e organizações, para manter um registo único e completo.
Detecta duplicados por correio, telefone, domínio e NUIT; apresenta divergências; preserva origens, consentimentos, actividades e auditoria; permite relações múltiplas contacto–organização.
Dados mestres / Must
US-CRM-002
Como gestor de marketing, quero conhecer a primeira e a última origem de cada contacto, para medir a contribuição dos canais e campanhas.
Primeira origem é imutável; última origem actualiza-se; importações exigem fonte; relatórios distinguem origem inicial, assistida e final.
Atribuição / Must
US-CRM-003
Como gestor de investimento, quero construir progressivamente o perfil do investidor, para recomendar projectos adequados.
Regista perfil, ticket, sectores, locais, instrumentos, horizonte e restrições; aceita várias preferências priorizadas; alterações recalculam correspondências; dados restritos são protegidos.
Perfil / Must
US-CRM-004
Como gestor, quero uma pontuação explicável e configurável, para priorizar investidores sem depender de decisão automática opaca.
Mostra total, critérios, pesos, evidências e versão; condições eliminatórias bloqueiam avanço; ajuste exige fundamento; histórico é preservado.
Qualificação / Must
US-CRM-005
Como responsável comercial, quero controlar transições do funil, para assegurar que nenhuma oportunidade avança sem dados e aprovações.
Critérios obrigatórios por etapa; encerramento e retrocesso exigem motivo; autor e data são registados; probabilidade e previsão seguem regras aprovadas.
Funil / Must
US-CRM-006
Como supervisor, quero que todo registo activo tenha responsável e próxima acção, para evitar leads abandonados.
Alertas para registos sem responsável ou tarefa futura; redistribuição auditada; substituição por ausência; painel de atrasos e carga.
Produtividade / Must
US-CRM-007
Como gestor de campanhas, quero executar cadências segmentadas, para contactar investidores no momento e canal adequados.
Cadência inicia por evento; resposta ou revogação pausa; falhas têm limite e escalonamento; cada envio guarda modelo, versão e resultado.
Automação / Should
US-CRM-008
Como analista, quero relacionar investidores, contactos, projectos, 
locais, campanhas e promotores, para visualizar todo o contexto da oportunidade.
Relações múltiplas sem duplicação; tipo, papel, prioridade, período e 
estado; remoção lógica; pesquisa bidireccional; acesso por permissão.
Relacionamentos / Must
US-CRM-009
Como director, quero acompanhar valor, probabilidade e previsão, para gerir o pipeline sem confundir estimativas com investimento confirmado.
Valor exige moeda e data; faixas coerentes; ajustamento de probabilidade fundamentado; histórico; separação de valor bruto, ponderado, proposto e confirmado.
Pipeline / Must
US-CRM-010
Como gestor, quero painéis reconciliáveis e filtráveis, para tomar decisões baseadas nos registos fonte.
Filtros completos; totais reconciliados; indicador mostra definição e actualização; permite abrir registos; exportação respeita mascaramento.
Analítica / Must
US-CRM-011
Como encarregado de conformidade, quero controlar consentimento, acesso, retenção e partilha, para proteger dados pessoais e confidenciais.
Revogação bloqueia comunicação não obrigatória; acessos e exportações auditados; partilha exige autorização; retenção vencida gera acção; pedidos recebem protocolo.
Conformidade / Must
US-CRM-012
Como gestor de investimento, quero encerrar e acompanhar oportunidades, para distinguir resultados e apoiar expansão pós-investimento.
Ganho exige confirmação e valor autorizado; perda exige motivo; encerramento cria avaliação e plano; reactivação não apaga histórico.
Encerramento / Should
Definition of Ready:
 história ligada ao RF-CRM; actor e valor definidos; regras e dados identificados; protótipo ou fluxo aprovado; dependências, permissões, eventos e critérios de aceitação compreendidos; ausência de bloqueio jurídico ou institucional. 
Definition of Done:
 código revisto; migração e API documentadas; testes unitários, integração, autorização e aceitação aprovados; auditoria e métricas activas; documentação publicada; sem defeitos críticos; demonstração aceite pelo dono do produto.
9.14. Backlog priorizado e releases
Ordem
Épico e histórias
Release
Entregável
Dependências
1
Fundação, segurança e catálogos: US-CRM-001, US-CRM-011.
R1 — Fundação
Organizações, contactos, utilizadores, equipas, consentimentos, perfis de acesso, auditoria e catálogos.
Arquitectura, identidade, política de dados e modelo técnico.
2
Captação e atribuição: US-CRM-002, parte de US-CRM-006.
R1 — Fundação
Formulários, origens, campanhas, importação, deduplicação, filas e atribuição inicial.
Integração com portal, correio e campanhas.
3
Perfil e relacionamentos: US-CRM-003, US-CRM-008.
R2 — Operação comercial
Perfil do investidor, interesses, sectores, locais, instrumentos, projectos e promotores.
Catálogos validados e dados de projectos.
4
Funil e produtividade: US-CRM-005, conclusão de US-CRM-006.
R2 — Operação comercial
Etapas, critérios, actividades, tarefas, SLA, responsável, equipa e próxima acção.
Regras de negócio e matriz de aprovação.
5
Qualificação e pipeline: US-CRM-004, US-CRM-009.
R3 — Qualificação
Pontuação, condições eliminatórias, valores, probabilidades, previsões e histórico.
Perfil, funil, conformidade e motor de regras.
6
Automação e comunicação: US-CRM-007.
R3 — Qualificação
Cadências, modelos, preferências, notificações, tentativas e escalonamentos.
Consentimentos, serviço de mensagens e eventos.
7
Analítica e gestão: US-CRM-010.
R4 — Gestão
Painéis, filtros, indicadores, reconciliação, exportação e relatórios.
Dados transaccionais estáveis e modelo analítico.
8
Encerramento e pós-investimento: US-CRM-012.
R4 — Gestão
Ganho, perda, reactivação, investimento confirmado, satisfação e plano pós-investimento.
Aprovações, indicadores e integrações institucionais.
9
Integrações avançadas e API externa.
R5 — Ecossistema
Webhooks, sincronização, API de parceiros, georreferenciação e sala segura.
Acordos institucionais, segurança e testes de carga.
9.15. Plano de implementação do CRM por fases
Fase
Duração indicativa
Actividades e entregáveis
Equipa principal
Critério de passagem
0. Mobilização e desenho
3–4 semanas
Governação; processos-alvo; backlog; arquitectura; segurança; modelo de dados; protótipos; plano de migração, testes e adopção.
Patrocinador, dono do produto, negócio, arquitectura, UX, segurança, jurídico e dados.
Backlog, arquitectura, riscos e protótipos aprovados; dados e integrações inventariados.
1. Fundação e captação
6–8 semanas
Contactos, organizações, duplicados, consentimentos, utilizadores, equipas, campanhas, origens, formulários, importação e auditoria.
Backend, frontend, QA, dados, DevOps e segurança.
US-CRM-001, 002 e 011 aceites; migração piloto reconciliada; sem falhas críticas.
2. Operação comercial
6–8 semanas
Perfis, interesses, relacionamentos, funil, actividades, responsáveis, tarefas, SLA e notificações básicas.
Produto, desenvolvimento, CRM, QA e utilizadores-chave.
US-CRM-003, 005, 006 e 008 aceites; equipa piloto opera casos reais.
3. Qualificação e automação
5–7 semanas
Pontuação, condições eliminatórias, valores, probabilidades, previsões, cadências e modelos multicanal.
Negócio, dados, desenvolvimento, conformidade e marketing.
US-CRM-004, 007 e 009 aceites; regras explicáveis, mensagens autorizadas e SLA medidos.
4. Analítica e encerramento
4–6 semanas
Painéis, indicadores, filtros, exportações, motivos de perda, ganho, 
investimento confirmado e pós-investimento.
BI, dados, desenvolvimento, gestão e QA.
US-CRM-010 e 012 aceites; indicadores 
reconciliados; relatório de gestão aprovado.
5. Integrações e escala
6–10 semanas
APIs de parceiros, webhooks, geodados, portal, correio, calendários, sala segura, desempenho e recuperação.
Arquitectura, integrações, segurança, DevOps e parceiros.
Contratos de API aprovados; testes de segurança, carga, recuperação e continuidade concluídos.
6. Operação assistida e optimização
8–12 semanas
Formação, suporte, monitoria, limpeza de dados, optimização de funil, campanhas, adopção e backlog evolutivo.
Produto, suporte, dados, marketing e gestores.
Metas de adopção e qualidade atingidas; operação transferida; backlog trimestral aprovado.
Governação:
 comité mensal de direcção; revisão quinzenal do produto; demonstração no fim de cada sprint; decisão formal de passagem entre fases. 
Riscos prioritários:
 dados duplicados, regras não aprovadas, baixa adopção, integração instável, mensagens sem consentimento, valores confundidos com investimento confirmado e dependência de entidades externas. Cada risco deve possuir responsável, probabilidade, impacto, mitigação, contingência e data de revisão.
9.16. Modelo técnico de tabelas do CRM
Tabela
Chave e campos essenciais
Restrições e índices
Relações
crm_investors
id UUID PK; type; legal_name; trade_name; registration_number; nuit; country_code; website; verification_status; risk_level; owner_user_id; created_at; updated_at; deleted_at.
UNIQUE(country_code, nuit) quando preenchido; índice em legal_name, verification_status e owner_user_id; soft delete.
1:N contacts, leads, opportunities, interests e consents.
crm_contacts
id UUID PK; full_name; email_normalized; phone_e164; preferred_language; preferred_channel; verification_status; owner_user_id; timestamps.
Índices únicos condicionais em email_normalized e phone_e164; pesquisa por full_name; dados pessoais cifrados conforme classificação.
N:N investors via crm_investor_contacts; 1:N leads, activities e consents.
crm_investor_contacts
investor_id FK; contact_id FK; role; is_primary; valid_from; valid_to.
PK composta; um contacto principal activo por investidor e finalidade; CHECK valid_to ≥ valid_from.
Resolve N:N investidor–contacto.
crm_leads
id UUID PK; contact_id FK; investor_id FK nullable; first_source_id; last_source_id; campaign_id; status; score; score_version; owner_user_id; next_action_at; 
qualified_at; disqualified_reason; timestamps.
CHECK score 0–100; estado activo exige owner e next_action_at; índices em status, owner, campaign, created_at e next_action_at.
N:N projects, sectors e locations; 0:N opportunities; 1:N activities e score_history.
crm_opportunities
id UUID PK; investor_id FK; lead_id FK nullable; name; type; stage; approval_status; amount_min/max/estimated; currency_code; probability; weighted_value; expected_close_date; owner_user_id; confidentiality_level; lost_reason; confirmed_amount; confirmed_date; timestamps.
CHECK 0≤probability≤100; min≤max; weighted_value calculado; ganho exige confirmed_amount, confirmed_date e approval_status=approved; índices em stage, owner, expected_close_date e campaign.
N:N contacts, projects, locations, promoters, instruments e team members; 1:N stage_history, value_history, activities e approvals.
crm_interests
id UUID PK; investor_id FK; sector_id FK; location_id FK; project_id FK nullable; instrument_id FK; priority; ticket_min/max; currency_code; horizon_months; eliminatory_condition; active_from/to.
UNIQUE por combinação activa relevante; min≤max; active_to≥active_from; índice para matching.
Liga investidor a preferências de sector, local, projecto e instrumento.
crm_activities
id UUID PK; entity_type; entity_id; activity_type; subject; description; channel; occurred_at; due_at; status; outcome; owner_user_id; confidentiality_level.
Índice(entity_type, entity_id); tarefa aberta exige due_at; reunião concluída exige outcome; conteúdo reservado cifrado.
Referência controlada a investor, contact, lead ou opportunity.
crm_campaigns
id UUID PK; name; objective; audience_profile; start_date; end_date; budget_min/max; currency_code; status; owner_user_id.
CHECK end_date≥start_date e orçamento não negativo; índices em status e período.
N:N contacts via crm_campaign_members; 1:N leads e opportunities atribuídas.
crm_campaign_members
id UUID PK; campaign_id FK; contact_id FK; member_status; response; first_touch_at; last_touch_at; attributed_value.
UNIQUE(campaign_id, contact_id); histórico de estado; attributed_value não negativo.
Resolve N:N campanha–contacto.
crm_consents
id UUID PK; subject_type; subject_id; purpose; lawful_basis; channel; status; policy_version; captured_at; expires_at; withdrawn_at; source; evidence_hash.
Índice(subject_type, subject_id, purpose); revogado é imutável; datas coerentes; evidência protegida.
Associado a contacto ou investidor por finalidade.
crm_stage_history
id UUID PK; opportunity_id FK; from_stage; to_stage; reason; probability; changed_by; changed_at.
Somente append; índice em opportunity_id e changed_at.
Histórico imutável da oportunidade.
crm_audit_log
id UUID PK; actor_id; action; entity_type; entity_id; before_hash; after_hash; occurred_at; ip_hash; correlation_id.
Append-only; retenção definida; índices em entidade, actor, data e correlation_id.
Audita operações críticas de todas as entidades.
As relações N:N devem usar tabelas associativas dedicadas: crm_lead_projects, crm_lead_sectors, crm_lead_locations, crm_opportunity_contacts, crm_opportunity_projects, crm_opportunity_locations, crm_opportunity_promoters, crm_opportunity_instruments e crm_opportunity_team. 
Cada tabela deve incluir papel, prioridade, estado, valid_from, valid_to, created_by e timestamps quando aplicável. Recomenda-se PostgreSQL com UUID, controlo de concorrência por version/updated_at, transacções, migrações versionadas, encriptação de campos sensíveis, índices parciais para registos activos e políticas de acesso por função e entidade.
9.17. Modelo técnico de APIs do CRM
Domínio
Endpoints principais
Operação e regras
Investidores
POST /api/v1/investors
GET /api/v1/investors/{id}
PATCH /api/v1/investors/{id}
GET /api/v1/investors?query=&profile=&status=
Criar, consultar, actualizar e pesquisar; criação suporta idempotency-key; dados restritos são mascarados por escopo.
Contactos
POST /api/v1/contacts
GET /api/v1/contacts/{id}
POST /api/v1/contacts/merge
POST /api/v1/investors/{id}/contacts
Deduplicação, fusão, verificação e associação a organizações; merge exige permissão e motivo.
Leads
POST /api/v1/leads
GET /api/v1/leads/{id}
PATCH /api/v1/leads/{id}
POST /api/v1/leads/{id}/qualify
POST /api/v1/leads/{id}/disqualify
Captar, atribuir, qualificar e desqualificar; qualificação valida perfil, score, responsável e consentimentos.
Oportunidades
POST /api/v1/opportunities
GET /api/v1/opportunities/{id}
PATCH /api/v1/opportunities/{id}
POST /api/v1/opportunities/{id}/transition
POST /api/v1/opportunities/{id}/close-won
POST /api/v1/opportunities/{id}/close-lost
Transições usam comando explícito, version para concorrência e critérios obrigatórios; ganho e perda exigem campos específicos.
Relacionamentos
POST /api/v1/opportunities/{id}/projects
POST /api/v1/opportunities/{id}/contacts
POST /api/v1/opportunities/{id}/locations
POST /api/v1/opportunities/{id}/promoters
DELETE correspondente
Associações idempotentes; cada relação informa papel, prioridade, vigência e confidencialidade; eliminação é lógica quando há histórico.
Actividades
POST /api/v1/activities
GET /api/v1/activities?entity_type=&entity_id=
PATCH /api/v1/activities/{id}
POST /api/v1/activities/{id}/complete
Chamadas, mensagens, reuniões, notas e tarefas; conclusão exige resultado quando configurado.
Campanhas
POST /api/v1/campaigns
GET /api/v1/campaigns/{id}/members
POST /api/v1/campaigns/{id}/members
GET /api/v1/campaigns/{id}/performance
Gerir membros, respostas, atribuição e desempenho; comunicação verifica consentimento antes do envio.
Consentimentos
POST /api/v1/consents
GET /api/v1/consents?subject_type=&subject_id=
POST /api/v1/consents/{id}/withdraw
Registo append-only por finalidade e versão; revogação produz evento e bloqueia tratamentos dependentes.
Painéis
GET /api/v1/analytics/funnel
GET /api/v1/analytics/pipeline
GET /api/v1/analytics/campaigns
GET /api/v1/analytics/data-quality
Filtros por período, campanha, sector, país, local, projecto, gestor e etapa; resultados incluem updated_at e definição.
Importação
POST /api/v1/import-jobs
GET /api/v1/import-jobs/{id}
GET /api/v1/import-jobs/{id}/errors
Processamento assíncrono; validação, deduplicação, relatório por linha, reconciliação e reexecução segura.
Eventos de domínio:
 a lista normativa, o payload, a assinatura, a idempotência, as novas tentativas e a fila de falhas são 
definidas
 na secção 9.18, “Especificação OpenAPI 3.1 do CRM”. A implementação desta secção deve consumir o mesmo catálogo versionado, sem manter uma lista paralela.
Eventos e webhooks:
 contact.created, contact.merged, lead.created, lead.assigned, lead.qualified, lead.disqualified, opportunity.created, opportunity.stage_changed, opportunity.won, opportunity.lost, consent.captured, consent.withdrawn, campaign.response_recorded e sla.breached. O payload deve conter event_id, event_type, occurred_at, entity_id, tenant/context, version e correlation_id; entrega assinada, repetível e idempotente; nova tentativa com backoff; dead-letter queue; segurança e subscrições por parceiro.
9.18. Especificação OpenAPI 3.1 do CRM
A API deverá ser publicada em OpenAPI 3.1.0, com JSON Schema 2020-12, versão semântica, documentação em português e inglês e ficheiro contratual validado no pipeline de integração contínua. O contrato abaixo consolida a versão inicial 
v1
; a implementação física deverá gerar um ficheiro YAML completo, validado e versionado no repositório técnico.
Componente OpenAPI
Especificação v1
openapi
3.1.0
info
title: InvestMoz CRM API; version: 1.0.0; description: captação, qualificação e acompanhamento de investidores e oportunidades.
servers
Produção: https://api.investemoz.tempo.co.mz/api/v1; Homologação: https://staging-api.investemoz.tempo.co.mz/api/v1.
securitySchemes
OAuth 2.0 Authorization Code com PKCE para utilizadores; Client Credentials para integrações; OpenID Connect para identidade.
Escopos
crm.read, crm.write, crm.admin, investors.read, investors.write, leads.read, leads.write, opportunities.read, opportunities.write, campaigns.manage, consents.manage, analytics.read, integrations.manage.
Formatos
application/json; application/problem+json para erros; datas ISO 8601; UUID; moedas ISO 4217; países ISO 3166-1 alpha-2.
Controlo
Idempotency-Key em POST críticos; ETag/If-Match ou version em actualizações; X-Correlation-Id; paginação por cursor; rate limiting.
Compatibilidade
Alterações não disruptivas dentro de v1; alterações incompatíveis exigem nova versão principal e período de transição.
Tag / operação
Método e caminho
Entrada principal
Resposta
Investors — listar/criar
GET/POST /investors
Filtros query, profile, status, country, cursor; InvestorCreate no POST.
200 PagedInvestors; 201 Investor; 409 duplicado; 422 regra de negócio.
Investors — consultar/actualizar
GET/PATCH /investors/{investorId}
UUID; InvestorUpdate; If-Match.
200 Investor; 404; 412 versão desactualizada.
Contacts — criar/consultar
POST /contacts; GET /contacts/{contactId}
ContactCreate; UUID.
201/200 Contact; 409 duplicado.
Contacts — fundir
POST /contacts/merge
master_contact_id, duplicate_contact_ids, field_resolution, reason.
200 MergeResult; 403; 409.
Investor contacts
POST /investors/{investorId}/contacts
contact_id, role, is_primary, valid_from/to.
201 InvestorContactRelation.
Leads — listar/criar
GET/POST /leads
Filtros status, owner, campaign, project, cursor; LeadCreate.
200 PagedLeads; 201 Lead.
Leads — consultar/actualizar
GET/PATCH /leads/{leadId}
UUID; LeadUpdate; If-Match.
200 Lead; 404; 412.
Leads — qualificar
POST /leads/{leadId}/qualify
score_version, evidence, decision, assignee, next_action.
200 QualificationResult; 422 critérios incompletos.
Leads — desqualificar
POST /leads/{leadId}/disqualify
reason_code, detail, reactivation_allowed.
200 Lead; 422.
Opportunities — listar/criar
GET/POST /opportunities
Filtros stage, owner, project, investor, close_date; OpportunityCreate.
200 PagedOpportunities; 201 Opportunity.
Opportunities — consultar/actualizar
GET/PATCH /opportunities/{opportunityId}
UUID; OpportunityUpdate; If-Match.
200 Opportunity; 404; 412.
Transição de etapa
POST /opportunities/{opportunityId}/transition
from_stage, to_stage, reason, version, approvals, next_action.
200 Opportunity; 409/412/422.
Encerrar ganho/perda
POST /opportunities/{id}/close-won; /close-lost
WonRequest ou LostRequest.
200 Opportunity; 403/422.
Relações da oportunidade
POST/DELETE /opportunities/{id}/{projects|contacts|locations|promoters|instruments}/{relationId}
RelationCreate com role, priority, valid_from/to.
201 Relation; 204; 409.
Activities
GET/POST /activities; PATCH /activities/{id}; POST /activities/{id}/complete
ActivityCreate/Update/Complete.
200/201 Activity; 422.
Campaigns
POST /campaigns; GET/POST /campaigns/{id}/members; GET /campaigns/{id}/performance
CampaignCreate, CampaignMemberCreate, filtros.
200/201; CampaignPerformance.
Consents
GET/POST /consents; POST /consents/{id}/withdraw
ConsentCreate; withdrawal reason.
200/201 Consent; 409.
Analytics
GET /analytics/{funnel|pipeline|campaigns|data-quality}
from, to, campaign, sector, country, location, project, owner.
200 AnalyticsResponse com definition e updated_at.
Import jobs
POST /import-jobs; GET /import-jobs/{id}; GET /import-jobs/{id}/errors
multipart ou storage_reference, mapping, mode.
202 ImportJob; 200 status/erros.
Schema
Campos obrigatórios e validações
InvestorCreate
type, legal_name, country_code, owner_user_id; profile e preferências opcionais; ticket.minimum/maximum ≥ 0; ISO currency; additionalProperties=false.
ContactCreate
full_name e pelo menos email ou phone; email format; phone em E.164; preferred_language; additionalProperties=false.
LeadCreate
contact_id ou canal identificável; first_source; interest_type; pelo menos sector, localização ou projecto; consent_reference quando aplicável.
Lead
id, status, score 0–100, score_version, owner_user_id e next_action_at quando activo; timestamps e version.
OpportunityCreate
investor_id, name, opportunity_type, stage, owner_user_id; projecto ou negócio obrigatório antes da diligência; probability 0–100.
MoneyRange
minimum, maximum, estimated, currency; minimum ≤ maximum; valores não negativos; estimated dentro da faixa quando ambos existirem.
TransitionRequest
from_stage, to_stage, reason, version; approvals e next_action condicionais à etapa.
WonRequest
confirmed_amount, currency, confirmed_date, confirmation_reference, approval_status=approved, post_investment_plan.
ConsentCreate
subject_type, subject_id, purpose, lawful_basis, channel, policy_version, captured_at, source, evidence.
Problem
type URI, title, status, detail, instance, correlation_id e errors[] com field e code.
PagedResponse
items[], next_cursor, has_more e total apenas quando autorizado e tecnicamente viável.
Extracto contratual OpenAPI 3.1:
openapi: 3.1.0
info:
  title: InvestMoz CRM API
  version: 1.0.0
servers:
  - url: https://api.investemoz.tempo.co.mz/api/v1
security:
  - oauth2: [crm.read]
paths:
  /investors:
    post:
      operationId: createInvestor
      security: [{ oauth2: [investors.write] }]
      requestBody:
        required: true
        content:
          application/json:
            schema: { $ref: '#/components/schemas/InvestorCreate' }
      responses:
        '201': { description: Created }
        '409': { $ref: '#/components/responses/Conflict' }
        '422': { $ref: '#/components/responses/BusinessRuleViolation' }
components:
  securitySchemes:
    oauth2:
      type: oauth2
      flows:
        authorizationCode:
          authorizationUrl: https://identity.tempo.co.mz/oauth2/authorize
          tokenUrl: https://identity.tempo.co.mz/oauth2/token
          scopes:
            investors.write: Criar e actualizar investidores
  schemas:
    InvestorCreate:
      type: object
      additionalProperties: false
      required: [type, legal_name, country_code, owner_user_id]
Eventos e webhooks:
 contact.created, contact.merged, lead.created, lead.assigned, lead.qualified, lead.disqualified, opportunity.created, opportunity.stage_changed, opportunity.won, opportunity.lost, consent.captured, consent.withdrawn, campaign.response_recorded e sla.breached. Cada evento deve conter event_id, event_type, occurred_at, entity_id, version e correlation_id; a entrega deve ser assinada, idempotente, repetida com backoff e encaminhada para fila de falhas após esgotar tentativas.
Critérios de aceitação da especificação:
 validação automática sem erros; cobertura de todos os endpoints v1; exemplos válidos para pedidos, respostas e erros; autenticação e escopos documentados; contract tests entre consumidor e fornecedor; verificação de compatibilidade retroactiva; protecção de dados nos exemplos; documentação gerada em ambiente de homologação; aprovação por Arquitectura, Segurança, Produto e Integrações.
9.19. Roadmap executivo do CRM: custos, riscos e dependências
O 
roteiro
 adopta um horizonte indicativo de 12 a 14 meses, equipa multidisciplinar e implementação incremental. Os valores são estimativas de planeamento em meticais, não incluem IVA, aquisição de hardware, viagens internacionais nem compra de media das campanhas e devem ser confirmados após solicitação de propostas, arquitectura final e inventário de integrações.
Fase / período
Entregáveis executivos
Custo indicativo
Dependências críticas
Decisão de passagem
0. Mobilização e desenho
Meses 1–2
Governação, processos, backlog, protótipos, arquitectura, modelo de dados, OpenAPI inicial, segurança, migração e plano de adopção.
MZN 1 800 000–2 800 000
Patrocinador; dono do produto; acesso a dados; decisões jurídicas; disponibilidade de utilizadores-chave.
Âmbito, arquitectura, backlog, riscos e orçamento-base aprovados.
1. Fundação e captação
Meses 2–4
Identidade, equipas, permissões, investidores, contactos, duplicados, 
consentimentos, campanhas, origens, formulários, importação e auditoria.
MZN 4 500 000–6 500 000
Ambientes, identidade, política de dados, catálogos e 
integração com o portal.
Histórias Must da fundação aceites; migração piloto reconciliada; 
segurança sem falhas críticas.
2. Operação comercial
Meses 4–6
Perfis, interesses, projectos, locais, promotores, funil, actividades, tarefas, responsável, SLA e notificações básicas.
MZN 4 000 000–6 000 000
Catálogos sectoriais e territoriais; processos aprovados; equipa piloto; dados de projectos.
Casos reais processados de ponta a ponta; responsáveis e próximas acções completos.
3. Qualificação e automação
Meses 6–8
Pontuação explicável, condições eliminatórias, pipeline financeiro, previsões, cadências, modelos e escalonamentos.
MZN 3 500 000–5 500 000
Regras de negócio, consentimentos, serviços de correio/SMS e revisão de conformidade.
Pontuação auditável; comunicações autorizadas; SLA e transições aprovados.
4. Analítica e encerramento
Meses 8–9
Painéis, indicadores, reconciliação, exportações, ganho, perda, investimento confirmado e pós-investimento.
MZN 2 800 000–4 200 000
Dados transaccionais estáveis; definições de indicadores; BI e aprovação financeira.
Indicadores reconciliados; relatório executivo aceite; valor confirmado separado do indicativo.
5. Integrações e escala
Meses 9–11
OpenAPI 3.1 completa, portal de APIs, webhooks, integrações institucionais, geodados, sala segura, carga, segurança e recuperação.
MZN 5 000 000–8 000 000
Acordos com parceiros, sistemas externos, credenciais, dados geográficos e requisitos de segurança.
Contract tests, carga, segurança, continuidade e integrações prioritárias aprovados.
6. Operação assistida e optimização
Meses 11–14
Formação, migração final, suporte, limpeza, adopção, medição, optimização de campanhas/funil e transferência operacional.
MZN 2 500 000–4 000 000
Disponibilidade dos utilizadores, suporte interno, dados finais e plano de mudança.
Metas de adopção e qualidade cumpridas; operação entregue; backlog trimestral aprovado.
Componente
Intervalo indicativo
Observação
Implementação total — fases 0 a 6
MZN 24 100 000–37 000 000
Desenvolvimento, configuração, testes, migração, integração, formação e operação assistida.
Contingência
10%–15%
Aplicar ao orçamento aprovado conforme incerteza de integrações, dados e requisitos externos.
Operação anual após estabilização
MZN 5 000 000–8 000 000/ano
Infra-estrutura cloud, suporte, segurança, monitoria, licenças técnicas e manutenção evolutiva; exclui campanhas.
Campanhas anuais
MZN 12 600 000–21 600 000/ano
Orçamento já definido na matriz de campanhas; gerir separadamente do custo tecnológico.
Cenário executivo recomendado
MZN 30 000 000–34 000 000
Base para contratação faseada, sujeita a propostas técnicas e comerciais.
Risco
Probabilidade / impacto
Resposta e mitigação
Responsável
Atraso na validação institucional e jurídica
Alta / Alta
Calendário de decisões; pontos focais; prazos; versões preliminares; 
nenhuma publicação ou integração sem autorização.
Patrocinador e Jurídico.
Dados incompletos, duplicados ou inconsistentes
Alta / Alta
Perfil de dados; regras de qualidade; deduplicação; migração piloto; reconciliação e responsáveis por domínio.
Líder de Dados.
Expansão não controlada do âmbito
Alta / Alta
Backlog priorizado; comité de mudança; orçamento por fase; critérios de go/no-go e controlo de benefícios.
Dono do Produto.
Baixa adopção pela equipa
Média / Alta
Co-desenho, piloto, formação por função, superutilizadores, suporte e indicadores de utilização.
Gestor de Mudança.
Integrações externas indisponíveis ou instáveis
Alta / Média
Contratos de API; mocks; filas; idempotência; retries; reconciliação; implementação faseada e alternativa manual.
Arquitecto de Integrações.
Incidente de segurança ou exposição de dados
Média / Muito alta
Zero trust, MFA, cifragem, segregação, testes, monitoria, resposta a incidentes e minimização.
Segurança e Conformidade.
Automação ou pontuação inadequada
Média / Alta
Explicabilidade, versão, evidência, revisão humana, testes de viés e monitoria de falsos positivos/negativos.
Produto, Dados e Conformidade.
Custos superiores ao previsto
Média / Alta
Contratação faseada, limites de consumo, FinOps, contingência, medição de valor e revisão trimestral.
Patrocinador e Finanças.
Dependência excessiva de fornecedor
Média / Média
OpenAPI, padrões abertos, código e documentação entregues, portabilidade, propriedade de dados e plano de saída.
Arquitectura e Procurement.
Valor do pipeline confundido com investimento realizado
Média / Alta
Estados, campos e painéis separados; confirmação institucional; auditoria e mensagens claras.
Gestor CRM e Finanças.
Dependências decisivas:
 patrocínio executivo e orçamento; acordo sobre o papel da Tempo; validação jurídica; disponibilidade de dados e pontos focais; 
serviços de identidade, correio electrónico e SMS
; ambientes cloud; equipa interna; contratos com fornecedores e parceiros; autorização para mapas e integrações; definições reconciliadas de indicadores. 
Marcos executivos:
 M2, desenho aprovado; M4, fundação operacional; M6, piloto comercial; M8, qualificação automatizada; M9, painéis executivos; M11, integrações prioritárias; M14, transferência para operação.
10. Integrações e entidades de referência
O portal deverá estar preparado para integração progressiva com a APIEX, Autoridade Tributária, Banco de Moçambique, BAU, ministérios, institutos públicos, municípios e outros intervenientes relevantes. Cada integração deverá ter finalidade, base legal, proprietário dos dados, campos partilhados, autenticação, níveis de serviço, tratamento de erros e responsabilidades formalmente definidos. Endpoints, formulários e serviços descritos durante a análise serão considerados conceptuais até confirmação pela entidade competente.
11. Conformidade legal, regulatória e editorial
Manter matriz de conformidade com diploma, matéria, obrigação, processo afectado, controlo, evidência, responsável e periodicidade de revisão.
Acompanhar a legislação aplicável ao investimento, sociedades comerciais, transmissão de participações e activos, licenciamento, fiscalidade, trabalho, ambiente, concorrência, terras, regime cambial, transacções electrónicas e prevenção do branqueamento de capitais.
Confirmar na fonte oficial a vigência e as alterações de cada diploma; registar versão, data de publicação, entrada em vigor, data de revisão e responsável.
Submeter incentivos, taxas, limiares, isenções, prazos, restrições sectoriais e procedimentos a validação jurídica e institucional antes da publicação.
Definir termos de uso, política de privacidade, política de publicação, política de retenção, acordo de confidencialidade, regras de reclamação e avisos de não aconselhamento.
Distinguir claramente informação pública, orientação editorial, resultado automatizado, validação da Tempo e decisão de autoridade competente.
Realizar avaliação jurídica e de risco antes de novas integrações, transferências de dados, uso de inteligência artificial ou alteração do papel da Tempo no processo transaccional.
Estabelecer comité de governação com funções editorial, jurídica, tecnológica, segurança, negócio e relacionamento institucional, mantendo registo de aprovações e excepções.
12. Requisitos não funcionais
Segurança:
 autenticação robusta, controlo por perfis, encriptação, cópias de segurança, registos de auditoria e testes regulares.
Disponibilidade:
 monitoria contínua, recuperação de falhas e definição de níveis de serviço.
Desempenho:
 páginas optimizadas para ligações de baixa largura de banda e dispositivos móveis.
Acessibilidade:
 navegação por teclado, contraste adequado, textos alternativos e estrutura compatível com tecnologias de apoio.
Multilinguismo:
 português e inglês na primeira fase; francês e mandarim mediante procura e capacidade editorial.
Escalabilidade:
 arquitectura modular, APIs documentadas e separação entre conteúdo, serviços, dados e integrações.
Observabilidade:
 métricas, alertas, gestão de incidentes e relatórios operacionais.
13. Indicadores de sucesso
Número de oportunidades publicadas e actualizadas.
Taxa de conversão de visitante em manifestação de interesse.
Conversão por eixo de conteúdo: visitantes de “Porquê investir”, actividades económicas, oportunidades, áreas de investimento e reguladores que descarregam dossier, subscrevem alertas, comparam projectos ou manifestam interesse.
Percentagem de perfis sectoriais, territoriais e regulatórios com fonte, responsável, estado de validação e revisão dentro do prazo.
Número de negócios existentes publicados, manifestações de interesse qualificadas e correspondências realizadas entre vendedores, compradores e investidores.
Número de projectos do PII publicados e actualizados; investidores captados e qualificados; reuniões realizadas; propostas recebidas; valor indicativo e valor efectivamente mobilizado.
Número de projectos âncora e complementares importados do relatório PII, classificados por região, sector, campanha, maturidade e entidade promotora.
Tempo médio de primeira resposta e de resolução.
Percentagem de processos concluídos sem assistência adicional.
Nível de satisfação do investidor.
Percentagem de conteúdos revistos dentro do prazo.
Número de integrações activas e respectivas taxas de sucesso.
Incidentes de segurança, privacidade e informação desactualizada.
14. Roteiro de implementação
Fase 0 — Validação e governação:
 aprovar o âmbito, o papel da Tempo, o acordo com o MPD e tutelas, a política editorial, a base legal, os pontos focais e a carteira inicial.
Fase 1 — MVP comercial:
 lançar catálogo PII, fichas, mercado de negócios existentes, formulários, pesquisa, CRM, helpdesk, consentimentos, notificações e painel básico.
Fase 2 — Captação estruturada:
 executar o plano de campanhas, segmentação, dossiers, webinars, reuniões, pontuação de leads e encaminhamento institucional.
Fase 3 — Diligência segura:
 introduzir acordos de confidencialidade, sala de informação, gestão de documentos, tarefas, reclamações, retenção e auditoria avançada.
Fase 4 — Integração e inteligência:
 integrar fontes autorizadas, APIs e entidades; implementar recomendação e IA supervisionada para pesquisa, triagem e apoio editorial.
Fase 5 — Optimização:
 rever métricas, segurança, acessibilidade, desempenho, qualidade dos dados, conversão e satisfação; actualizar trimestralmente o backlog.
15. Próximas decisões
Aprovar este documento como base funcional e comercial do upgrade.
Formalizar com o MPD e entidades de tutela a autorização de publicação, actualização, encaminhamento e uso de marcas, mapas e documentos.
Validar custos, metas, maturidade, códigos, entidades promotoras e pontos focais dos 15 projectos âncora e respectivos complementares.
Nomear patrocinador, dono do produto, gestor de carteira, responsáveis sectoriais, Jurídico/Conformidade, Conteúdo, CRM e Tecnologia.
Aprovar o âmbito do MVP, orçamento, cronograma, níveis de serviço e critérios de passagem entre fases.
Converter os requisitos em histórias de utilizador, modelo de dados, arquitectura, protótipos, plano de testes e backlog priorizado.
Preparar os 15 dossiers públicos em português e inglês, mantendo versões restritas separadas.
Constituir e qualificar a base inicial de investidores por sector, geografia, instrumento e capacidade.
Aprovar o calendário anual de campanhas, fóruns, webinars, roadshows e missões empresariais.
Submeter termos de uso, política de privacidade, confidencialidade, retenção e modelo de intervenção da Tempo a parecer jurídico antes do lançamento.
Anexo A — Anexo Técnico — Pacote de Automação do Upgrade
Especificação técnica importável para orientar a implementação, migração e operação do upgrade. Para implementação do pacote técnico, A.31 é a única fonte normativa; os requisitos funcionais (RF), os épicos E1–E9 e as decisões formalmente aprovadas mantêm-se como fontes de requisitos e governação, nos termos consolidados por A.31. Todo o código gerado por agentes de programação, incluindo Codex, deve passar por revisão humana, testes, validação de segurança e aprovação antes de qualquer utilização em produção.
A.1 Finalidade, princípios e limites da automação
A finalidade é acelerar trabalho repetível e verificável sem transferir autoridade decisória para a automação. A rastreabilidade deve ligar cada alteração ao RF, épico, decisão, risco, teste e evidência de aceite correspondentes.
• Fonte de verdade: requisitos RF aprovados, backlog E1–E9, contratos OpenAPI, modelo de dados e ADRs vigentes.
• Codex pode acelerar scaffolding, migrations, testes, documentação, refactoring controlado e propostas de correcção.
• Codex não pode inventar regras de negócio, resolver ambiguidades por conta própria nem alterar o âmbito aprovado.
• É proibido deploy directo, aprovação automática, acesso irrestrito a produção, leitura de segredos ou uso de dados pessoais não anonimizados.
• Princípios: menor privilégio, revisão por pares, alterações pequenas, reversibilidade, idempotência, observabilidade, segurança por defeito e evidência reproduzível.
A.2 Arquitectura alvo unificada
A solução alvo usa React + TypeScript no frontend; Laravel modular e API-first no backend; PostgreSQL/PostGIS como sistema transaccional e geoespacial; Redis para cache, locks e filas curtas; object storage compatível com S3 para documentos; motor de pesquisa para indexação; filas/eventos para processamento assíncrono; OpenAPI como contrato; observabilidade transversal; e um serviço de IA isolado por interfaces, políticas e auditoria.
A.2.1 Dependências e fluxo
Fluxo principal: browser → gateway/API Laravel → módulos de domínio → PostgreSQL/PostGIS, Redis, object storage e motor de pesquisa. Alterações de estado relevantes gravam evento de outbox na mesma transacção; workers publicam eventos e listeners actualizam pesquisa, notificações, integrações e analítica. O serviço de IA recebe apenas dados minimizados e autorizados, devolve recomendações identificadas por modelo/versão e nunca executa decisões finais.
• O frontend depende do OpenAPI versionado, autenticação e design system; não acede directamente às bases de dados.
• Os módulos comunicam por Actions/Services e eventos estáveis, evitando dependências circulares.
• PostGIS suporta geometrias, proximidade e intersecção; o motor de pesquisa suporta texto, filtros e ranking.
• Observabilidade correlaciona pedido, job, evento e integração através de correlation_id.
A.3 Modelo de dados unificado
Convenções globais: chaves primárias UUID geradas por pgcrypto; created_at e updated_at em UTC; deleted_at para soft delete quando retenção e auditoria o permitirem; version ou lock_version para concorrência; source_system para proveniência; data_classification para classificação; correlation_id para rastreabilidade. Chaves estrangeiras devem explicitar ON DELETE/ON UPDATE. Dados históricos e de auditoria não devem ser apagados por soft delete indiscriminado.
Domínio
Entidades essenciais
Chaves e relações principais
Identidade
users, organizations, memberships, roles, permissions, consents
memberships liga user↔organization; roles/permissions por tabelas associativas; consents pertence a user/organization
Conteúdo
contents, translations, documents, sources
translations→contents; documents polimórficos ou por associação explícita; contents/documents→sources
Território/GIS
geo_locations, geo_geometries, geo_layers, geo_sources
geo_geometries→geo_locations/layers/sources; geometry com SRID controlado
Oportunidades
projects, project_locations, project_documents, project_readiness, project_financing
tabelas associativas ligam project a localização/documento; readiness e financing versionados
Clusters
economic_clusters, value_chains, value_chain_links, cluster_actors, cluster_gaps
value_chains→cluster; links conectam nós/elos; actors e gaps→cluster
Corredores
development_corridors, corridor_locations, corridor_nodes, corridor_infrastructures, anchor_projects, complementary_projects
locations/nodes/infrastructures→corridor; projectos associados por papel âncora/complementar
CRM
investors, contacts, leads, opportunities, activities, tasks, meetings, campaigns
contacts→investor; leads/opportunities→investor; actividades/tarefas/reuniões relacionam actor e oportunidade
Jornada
investor_journeys, journey_steps, submissions, notifications
journey→investor/opportunity; steps→journey; submissions/notifications→step
Pós-investimento
aftercare_plans, constraints, escalations, reinvestments
plan→investor/project; constraints→plan; escalations→constraint; reinvestments→plan
Educação
skills, occupations, training_needs, training_providers, courses, education_opportunities
necessidades ligam skill/occupation/território; courses→provider; opportunities→course/location
Governação e risco
decisions, approvals, risk_register, audit_events
approvals→decision; riscos ligam módulo/entidade; audit_events imutáveis
IA
ai_models, ai_model_versions, ai_recommendations, ai_feedback, ai_incidents
versions→model; recommendations→version; feedback/incidents→recommendation/version
Integração
integration_endpoints, webhooks, outbox_events, inbox_events, sync_runs, reconciliation_issues
webhooks→endpoint; eventos e execuções usam idempotency_key/correlation_id; issues→sync_run
A.3.1 Regras transversais
• Nomes físicos em snake_case; UUID como uuid nativo; timestamps com timezone; geometrias com tipo e SRID explícitos.
• Registos publicados mantêm histórico de versão e autor; documentos mantêm checksum, media_type, tamanho, classificação e localização no object storage.
• data_classification usa vocabulário governado; source_system distingue criação nativa, migração e integração.
A.4 Mapa de relações ponta-a-ponta
Cadeia principal: território → corredor → projecto âncora → cluster → cadeia/elo → projecto complementar → investidor → lead/oportunidade → jornada → pós-investimento. Um território pode participar em vários corredores e um corredor abrange várias localizações; usar corridor_locations. Corredores e projectos têm relação N:N por project_corridors, com role = anchor ou complementary. Clusters possuem várias cadeias; cadeias possuem vários elos. Projectos podem ligar-se a vários clusters/cadeias por project_clusters e project_value_chain_links. Um investidor pode ter vários leads e oportunidades; uma 
oportunidade pode originar uma jornada; uma jornada tem passos ordenados; um investidor/projecto pode ter vários planos de aftercare.
Módulo
Requisitos
Cobertura
Clusters
RF-CLU
clusters económicos, actores, lacunas, cadeias e elos
Corredores
RF-COR
corredores, nós, infra-estruturas, riscos e projectos âncora/complementares
Investimento
RF-EII
projectos, prontidão, financiamento, documentos e manifestação de interesse
Educação
RF-EDU
competências, ocupações, necessidades, provedores, cursos e oportunidades
CRM e jornada
RF-CRM
investidores, contactos, leads, oportunidades, actividades, jornada e aftercare
A.5 Scripts-base
Todos os blocos desta secção são modelo inicial — adaptar e rever. Devem ser executados apenas em ambientes autorizados, com backup, revisão e ensaio.
A.5.1 Extensões PostgreSQL — modelo inicial — adaptar e rever
CREATE EXTENSION IF NOT EXISTS postgis;\nCREATE EXTENSION IF NOT EXISTS pgcrypto;
A.7 Frontend React/TypeScript
O frontend deve fornecer app shell responsivo, autenticação segura, i18n PT/EN, design system versionado, acessibilidade, query/cache com invalidação explícita, formulários tipados, mapas, analytics com consentimento e error boundaries. Clientes são gerados ou validados contra OpenAPI; dados sensíveis não são persistidos em armazenamento inseguro.
Tela
Rota
Perfil
Módulos/dados principais
Página inicial
/
Público
conteúdo, destaques, pesquisa
Pesquisa
/pesquisa
Público
índice, filtros, projectos/clusters/corredores
Oportunidade
/oportunidades/:id
Público/Investidor
projecto, localização, prontidão, documentos
Cluster
/clusters/:id
Público
cadeias, actores, lacunas
Corredor
/corredores/:id
Público
nós, infra-estruturas, riscos, projectos
Mapa
/mapa
Público/Analista
camadas GIS e filtros
Centro legal
/legal
Público
termos, privacidade, consentimentos
Registo/login
/auth/*
Público
identidade e consentimento
Perfil/organização
/conta
Autenticado
user, organization, memberships
Painel do investidor
/investidor
Investidor
interesses, jornadas, tarefas
Favoritos/comparação
/investidor/favoritos
Investidor
projectos guardados e comparação
Manifestação
/oportunidades/:id/interesse
Investidor
submission e consentimento
Documentos
/documentos
Autenticado
metadados, versões, acesso
Tarefas/notificações
/tarefas
Autenticado
tasks e notifications
CRM leads
/crm/leads
Gestor CRM
leads, filtros, actividades
CRM oportunidade
/crm/oportunidades/:id
Gestor CRM
pipeline, contactos, reuniões
Pós-investimento
/aftercare
Gestor
planos, constrangimentos, escalonamentos
Competências
/competencias
Analista
skills, occupations, training_needs
Oportunidade educativa
/educacao/:id
Público/Analista
curso, provedor, localização
Administração
/admin
Administrador
utilizadores, papéis, configurações
Qualidade de dados
/admin/qualidade
Data steward
issues, reconciliação, proveniência
Governação
/governacao
Comité
decisions, approvals, risks
Monitoria de IA
/admin/ia
Responsável IA
modelos, recomendações, feedback, incidentes
A.8 Contratos API e eventos
Endpoint
Métodos
Escopos
RF
/api/v1/projects
GET, POST; /{id}: GET, PATCH
projects:read/write
RF-EII
/api/v1/clusters
GET, POST; /{id}: GET, PATCH
clusters:read/write
RF-CLU
/api/v1/corridors
GET, POST; /{id}: GET, PATCH
corridors:read/write
RF-COR
/api/v1/investors
GET, POST; /{id}: GET, PATCH
crm:read/write
RF-CRM
/api/v1/leads
GET, POST; /{id}: GET, PATCH
crm:read/write
RF-CRM
/api/v1/journeys
GET, POST; /{id}: GET, PATCH
journeys:read/write
RF-CRM
/api/v1/aftercare
GET, POST; /{id}: GET, PATCH
aftercare:read/write
RF-CRM
/api/v1/skills
GET, POST; /{id}: GET, PATCH
education:read/write
RF-EDU
/api/v1/education-opportunities
GET, POST; /{id}: GET, PATCH
education:read/write
RF-EDU
/api/v1/search
GET
search:read
RF-EII/RF-CLU/RF-COR/RF-EDU
/api/v1/maps
GET
maps:read
RF-COR/RF-EII
Erro comum: {"error":{"code":"VALIDATION_ERROR","message":"...","details":[],"correlation_id":"uuid"}}. 
Colecções usam page, per_page, total e links/cursor quando adequado. POST mutável aceita Idempotency-Key; todos os pedidos propagam Correlation-Id. GET de recursos suporta ETag/If-None-Match. Mudanças incompatíveis criam nova versão /api/v2; alterações compatíveis seguem versionamento semântico do OpenAPI.
A.8.1 Eventos de domínio
• ProjectPublished — project_id, version, published_at, actor_id, correlation_id.
• InvestorInterestRegistered — investor_id, project_id, submission_id, correlation_id.
• LeadQualified — lead_id, score/version, qualified_by, correlation_id.
• CorridorRiskChanged — corridor_id, risk_id, previous_level, new_level, correlation_id.
• ConstraintEscalated — constraint_id, escalation_id, severity, correlation_id.
• TrainingGapDetected — training_need_id, geography_id, skills, correlation_id.
• DataQualityIssueDetected — entity_type, entity_id, rule_id, severity, correlation_id.
Envelope mínimo: event_id UUID, event_type, event_version, occurred_at UTC, producer, subject_id, organization_id quando aplicável, correlation_id, causation_id e payload. 
Consumidores devem ser idempotentes e tolerantes a campos adicionais.
A.9 Automação com Codex
A.9.1 Workflow em 10 passos
• 1. Ler requisitos RF, matriz de rastreabilidade e backlog E1–E9.
• 2. Gerar plano pequeno, riscos, dependências e critérios de aceite.
• 3. Criar branch segundo a estratégia aprovada e associar ticket.
• 4. Gerar ou ajustar schema e migrations reversíveis.
• 5. Gerar/actualizar OpenAPI e exemplos sem quebrar compatibilidade.
• 6. Criar scaffolding backend, autorização, validação, auditoria e jobs necessários.
• 7. Criar telas/componentes frontend acessíveis e tipados.
• 8. Gerar testes unitários, integração, contrato, segurança e fixtures anonimizadas.
• 9. Executar lint, typecheck, testes e revisão estática/segurança; corrigir apenas no âmbito.
• 10. Abrir pull request com ficheiros, RF/épico, evidências, riscos, rollback e pontos para revisão humana.
A.9.2 Prompt-base reutilizável
Tarefa: <descrição>. Fonte de verdade: <RF e épico>. Antes de alterar, cite os RF/épicos aplicáveis, liste pressupostos, riscos e ficheiros previstos. Não invente regras de negócio nem dados. Preserve compatibilidade de API e migrações; se uma quebra for necessária, pare e peça decisão. Implemente a menor alteração completa, liste todos os ficheiros criados/alterados, gere testes relevantes e comandos reproduzíveis. Não use segredos nem dados reais. Não faça deploy. Pare perante ambiguidade, conflito de requisitos, falha de segurança ou ausência de critério de aceite. No fim, apresente evidências, limitações, rollback e itens que exigem revisão humana.
A.9.3 Matriz de autonomia
Categoria
Pode automatizar
Exige revisão/aprovação
Proibido
Código
scaffolding, DTOs, testes, documentação, refactoring local
regras de negócio, migrations, autorização, desempenho
alterar âmbito ou aprovar o próprio código
Dados
fixtures anonimizadas, validadores, relatórios
mapeamentos, retenção, reconciliação
dados reais não autorizados ou apagar evidência
Segurança
SAST e propostas de correcção
threat model, excepções e aceite de risco
ler/expor segredos ou reduzir controlos
Operação
manifestos e runbooks em branch
promoção e rollback
deploy directo ou acesso irrestrito a produção
IA
avaliações e telemetria controlada
modelo, limiares, uso e comunicação
decisão autónoma com efeito material
A.10 Estratégia de migração e importação
Executar por ondas: inventário e perfil; esquema e dados de referência; identidade/organizações; conteúdo/documentos; GIS; projectos/clusters/corredores; CRM/jornada/aftercare; educação; integrações; delta final e corte. Cada onda tem dry-run, janela, backup, rollback, reconciliação e aprovação.
• Formatos canónicos UTF-8: CSV com cabeçalho e datas ISO 8601; JSON/NDJSON para estruturas aninhadas; geometria em GeoJSON ou WKT com SRID declarado.
• Manter mapping_id origem→UUID destino, source_system, checksum, lote, estado, erro e correlation_id.
• Validar schema, obrigatoriedade, domínios, referências, duplicados, geometria e classificação; inválidos seguem para quarantine.
• Rollback remove apenas dados do lote ou restaura snapshot; reconciliação compara contagens, somas, chaves, checksums e amostras aprovadas.
A.10.1 Cabeçalhos mínimos de importação
projects.csv: source_id,code,name,status,description,geometry_wkt,srid,source_system,data_classification,updated_at\nproject_locations.csv: project_source_id,location_source_id,role,latitude,longitude,srid,source_system\nclusters.csv: source_id,code,name,status,description,location_source_id,source_system,data_classification\ncorridors.csv: source_id,code,name,status,geometry_wkt,srid,source_system,data_classification\ninvestors.csv: source_id,legal_name,country_code,organization_type,contact_email,data_classification,consent_reference,source_system\ndocuments.csv: source_id,owner_type,owner_source_id,title,media_type,object_key,checksum_sha256,version,data_classification,source_system\ntraining.csv: source_id,provider_source_id,course_code,title,skill_codes,occupation_codes,location_source_id,start_date,end_date,capacity,source_system
Ficheiros devem possuir manifest.json com versão do formato, lote, contagens, checksum de cada ficheiro, timezone, SRID, sistema de origem e contacto responsável. E-mails e identificadores pessoais só são importados com base legal, minimização e canal seguro.
A.11 Testes e qualidade
Pirâmide: muitos testes unitários; integração para base de dados, filas e storage; contract tests para OpenAPI e eventos; poucos testes end-to-end críticos. Incluir testes de migração e rollback, GIS/SRID/geometrias, autorização e segurança, acessibilidade, desempenho, recuperação, IA e UAT com evidência.
A.11.1 Definition of Ready
• RF/épico, proprietário, dados, dependências, risco, critérios de aceite e impacto de compatibilidade definidos.
• Contrato/API e desenho necessários disponíveis; fixtures anonimizadas; plano de teste e rollback identificados.
A.11.2 Definition of Done
• Código revisto; testes e scans aprovados; migrations ensaiadas; documentação, OpenAPI, observabilidade e rastreabilidade actualizadas.
• Aceite funcional e de segurança registado; rollback praticável; sem segredos, dados reais ou findings críticos abertos.
Critérios de bloqueio: teste obrigatório falhado; vulnerabilidade crítica/alta sem tratamento aprovado; perda ou reconciliação incompleta de dados; quebra de contrato não aprovada; ausência de autorização/auditoria; falha de acessibilidade crítica; rollback não viável; comportamento de IA não avaliado. A cobertura mínima é definida e aprovada pelo Comité Técnico; não se fixa percentagem neste anexo.
A.12 CI/CD e ambientes
Ambientes segregados: development, test, staging e production, com configurações e credenciais distintas. Pipeline: lint → typecheck → unit → integration/contract → migrations dry-run → SAST → dependency scan → container scan → build assinado → deploy em staging → DAST → smoke/UAT → aprovação manual → produção → smoke e monitoria. Artefactos são imutáveis e promovidos entre ambientes.
• Production exige aprovação humana, janela quando aplicável, backup, plano de rollback e segregação de funções.
• O agente não pode fazer deploy directo, aprovar gates, aceder a segredos ou contornar controlos.
• Rollback inclui versão anterior do artefacto, migrations compatíveis/forward-fix e instruções testadas.
A.13 Plano de execução importável
Pacote
Responsável
Dependências
Saída
RF/épico
Critério de aceite
AUTO-01 Repositório
Tech Lead
governação
repos, standards, CI base
E1
PR, branch rules e comandos validados
AUTO-02 Plataforma
DevOps
AUTO-01
ambientes, containers, observabilidade
E1
staging reproduzível e monitorado
AUTO-03 Dados
Data Architect
AUTO-01
modelo, catálogo, ERD
E2
schema revisto e rastreável
AUTO-04 Migração
Data Engineer
AUTO-03
pipelines, quarantine, reconciliação
E2
dry-run reconciliado e rollback testado
AUTO-05 Identidade
Backend Lead
AUTO-02/03
IAM, organizações, consentimentos
E3
Policies e auditoria aprovadas
AUTO-06 Conteúdo
Product/Backend
AUTO-03/05
conteúdo, traduções, documentos
E3
PT/EN, versões e acesso testados
AUTO-07 GIS
GIS Lead
AUTO-03/04
camadas, geometrias, mapa
RF-COR/RF-EII; E4
SRID, índices e consultas validados
AUTO-08 Projectos
Product Squad
AUTO-05/06/07
oportunidades e prontidão
RF-EII; E5
fluxos e publicação aceites
AUTO-09 Clusters/corredores
Domain Lead
AUTO-07/08
clusters, cadeias, corredores
RF-CLU/RF-COR; E6
relações ponta-a-ponta verificadas
AUTO-10 CRM/jornada
CRM Lead
AUTO-05/08
investidor, lead, oportunidade, jornada
RF-CRM; E7
pipeline e eventos testados
AUTO-11 Educação/pós-investimento
Domain Leads
AUTO-09/10
skills, formação, aftercare
RF-EDU/RF-CRM; E8
lacunas e escalonamentos aceites
AUTO-12 IA/analítica/operação
AI Lead/SRE
AUTO-01–11
serviço IA, dashboards, runbooks
E9
avaliação, aprovação e operação prontas
A.14 Checklist para iniciar Codex
• Repositório e proprietários confirmados; branch strategy e convenções de commit/PR documentadas.
• Versões de PHP, Laravel, Node, React, TypeScript, PostgreSQL/PostGIS, Redis e ferramentas fixadas.
• Acesso de menor privilégio, temporário e sem segredos em prompts, ficheiros ou logs.
• Requisitos RF e backlog E1–E9 congelados para a iteração; matriz de rastreabilidade disponível.
• OpenAPI, modelo de dados, ADRs e políticas de compatibilidade publicados.
• Fixtures anonimizadas, dados sintéticos e critérios de reconciliação aprovados.
• Standards de código, segurança, acessibilidade, i18n, observabilidade e documentação definidos.
• Comandos de lint, typecheck, testes, migrations dry-run e scans executáveis localmente.
• Proprietário e revisor humano atribuídos a cada módulo; rota de escalonamento para ambiguidades definida.
A.15 Artefactos finais esperados
• Monorepo ou repositórios coordenados com versionamento, ownership e pipelines consistentes.
• Migrations e seeders seguros; OpenAPI; ERD; catálogo de dados e dicionário de classificações.
• Componentes React/TypeScript e módulos Laravel com testes, autorização e observabilidade.
• Scripts de migração, manifests, mappings, quarantine, reconciliação e relatórios assinados.
• Testes unitários, integração, contrato, E2E, GIS, segurança, acessibilidade, desempenho, recuperação e IA.
• Deployment manifests, configuração por ambiente, runbooks, rollback, alertas e SLOs aprovados.
• ADRs e relatório de rastreabilidade RF/épico → desenho → código → teste → evidência → release.
Este anexo é uma especificação de automação e não substitui arquitectura detalhada, revisão de código, testes, aprovação jurídica, segurança ou decisão humana.
A.16 Pacote de ficheiros pronto para importação
O pacote é organizado para importação controlada, validação automática e rastreabilidade entre requisitos, código, dados e testes. Todos os artefactos abaixo são modelos iniciais a adaptar e rever no repositório real.
Caminho
Formato
Finalidade
Produtor
Consumidor
Validação
manifest/project.yaml
YAML
Manifesto, stack e ordem de execução
Arquitectura / CI
Pipeline e equipa técnica
Lint YAML; versão; SHA-256
database/001_extensions.sql
SQL
Extensões PostgreSQL/PostGIS
DBA
PostgreSQL
psql; idempotência
database/010_identity.sql
SQL
Identidade, organizações e consentimentos
Backend
PostgreSQL
DDL; PK/FK; rollback
database/020_content.sql
SQL
Conteúdo, traduções e documentos
Backend
PostgreSQL
DDL; índices GIN
database/030_geography.sql
SQL
Território e geometrias
GIS
PostGIS
SRID 4326; GIST
database/040_projects.sql
SQL
Projectos, prontidão e financiamento
Projectos
PostgreSQL
Restrições; índices
database/050_clusters.sql
SQL
Clusters e cadeias de valor
Economia
PostgreSQL
FK; unicidade
database/060_corridors.sql
SQL
Corredores e relações
GIS
PostgreSQL/PostGIS
FK; GIST
database/070_crm.sql
SQL
Investidores, contactos e CRM
CRM
PostgreSQL
RBAC; índices
database/080_journey_aftercare.sql
SQL
Jornada e pós-investimento
Aftercare
PostgreSQL
Estados; auditoria
database/090_education.sql
SQL
Competências, formação e educação
Educação
PostgreSQL
FK; pesquisa
database/100_governance_ai.sql
SQL
Decisões, riscos, auditoria e IA
Governação
PostgreSQL
Imutabilidade; JSONB
database/110_integrations.sql
SQL
Integrações, outbox/inbox e reconciliação
Integrações
PostgreSQL
Idempotência
database/seeds/*.csv
CSV UTF-8
Dados de referência
Data steward
Seeds
Cabeçalho; domínio; checksum
database/migrations/mysql_to_postgres/*.yaml
YAML
Mapeamento de migração
Migração
ETL
Schema; amostra; reconciliação
openapi/investmoz-v1.yaml
OpenAPI 3.1
Contrato REST
Backend
Frontend/integrações
OpenAPI lint
events/asyncapi.yaml
AsyncAPI
Contrato de eventos
Integrações
Produtores/consumidores
AsyncAPI lint
imports/schemas/*.json
JSON Schema
Validação de importações
Dados
Importador
JSON Schema
imports/templates/*.csv
CSV UTF-8
Modelos canónicos
Dados
Utilizadores autorizados
Cabeçalhos; encoding
backlog/backlog.csv
CSV UTF-8
Backlog técnico
PMO técnico
Planeamento
36 IDs únicos
backlog/traceability.csv
CSV UTF-8
Rastreabilidade
QA
Auditoria
RF→TECH→teste
codex/prompts/*.md
Markdown
Prompts controlados
Arquitectura
Equipa de desenvolvimento
Revisão humana
frontend/routes.json
JSON
Rotas e autorização
Frontend
Aplicação React
JSON; RBAC
frontend/screens.json
JSON
Inventário de telas
UX/Frontend
QA
Schema; acessibilidade
backend/modules.json
JSON
Módulos Laravel
Backend
CI
Schema; dependências
ci/pipeline.yaml
YAML
Build, lint, testes e segurança
DevOps
CI/CD
Lint; dry-run
docs/data-dictionary.csv
CSV UTF-8
Dicionário de dados
Data steward
Equipa/auditoria
Cobertura; tipos
docs/erd.mmd
Mermaid
ER importável
Arquitectura
Documentação
Mermaid parse
docs/runbooks/*.md
Markdown
Operação, incidente e rollback
Operações
Suporte
Revisão e simulação
Convenções de intercâmbio e controlo
Aspecto
Convenção
Codificação e CSV
UTF-8 sem BOM; separador vírgula; aspas duplas segundo RFC 4180; LF no repositório.
Datas e horas
ISO 8601; date=AAAA-MM-DD; date-time em UTC com Z.
Identificadores
UUID canónico minúsculo; external_id preservado com source_system; correlation_id UUID.
Moeda
Montante decimal; currency_code ISO 4217; numeric(20,2) na base de dados.
Território
Códigos oficiais e versionados de país/província/distrito/posto; parent_code obrigatório quando aplicável.
Nulos
Campo vazio representa null; texto literal NULL não é aceite; zero não equivale a null.
Cabeçalhos
snake_case, únicos, estáveis e sem espaços; primeira linha obrigatória.
Versão
SemVer para pacote/contratos; migrations imutáveis após publicação; compatibilidade declarada.
Integridade
SHA-256 por ficheiro no manifesto; normalização de LF antes do cálculo; divergência bloqueia importação.
A.17 Modelo físico de dados detalhado
Campos transversais, quando aplicáveis: id uuid PK; source_system varchar(50); external_id varchar(150); version_no integer ≥1; data_classification enum public/internal/confidential/restricted; correlation_id uuid; created_at e updated_at timestamptz UTC; deleted_at timestamptz para soft delete. 
Dinheiro usa numeric(20,2)+currency_code char(3) ISO 4217. JSONB é permitido apenas com schema, tamanho e chaves controlados. Conteúdo multi-idioma usa locale BCP 47 e unicidade por entidade+locale. Geometrias PostGIS usam SRID 4326, validação ST_IsValid e índice GIST. Índices B-tree servem igualdade/ordenação; GIN pesquisa/JSONB; GIST geometrias.
Domínio
Nome físico
PK
FKs
Campos obrigatórios
Restrições/índices
RF ligados
Identidade
users
id uuid
—
email, status
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-001
Identidade
organizations
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-002
Identidade
memberships
id uuid
user_id→users; organization_id→organizations
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-003
Identidade
consents
id uuid
user_id→users
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-004
Conteúdo
contents
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; GIN search_vector; CHECK version_no>0
RF-005
Conteúdo
content_translations
id uuid
content_id→contents
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; GIN search_vector; CHECK version_no>0
RF-006
Conteúdo
documents
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-007
Geografia
geo_locations
id uuid
—
code/name ou tipo/estado 
conforme domínio
UNIQUE external_id+source_system; B-tree 
FKs/estado; GIST geometry; CHECK version_no>0
RF-008
Geografia
geo_geometries
id uuid
geo_location_id→geo_locations
geometry, geometry_type
UNIQUE external_id+source_system; B-tree FKs/estado; GIST geometry; CHECK version_no>0
RF-009
Projectos/GIS
projects
id uuid
—
project_code, name, status
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-010
Projectos/GIS
project_locations
id uuid
project_id→projects; geo_location_id→geo_locations
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-011
Conteúdo
project_documents
id uuid
project_id→projects; document_id→documents
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-012
Projectos/GIS
project_readiness
id uuid
project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-013
Projectos/GIS
project_financing
id uuid
project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-014
Projectos/GIS
economic_clusters
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-015
Projectos/GIS
value_chains
id uuid
cluster_id→economic_clusters
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-016
Projectos/GIS
value_chain_links
id uuid
from_value_chain_id/to_value_chain_id→value_chains
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-017
Projectos/GIS
cluster_projects
id uuid
cluster_id→economic_clusters; project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-018
Projectos/GIS
development_corridors
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-019
Projectos/GIS
corridor_locations
id uuid
corridor_id→development_corridors; geo_location_id→geo_locations
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-020
Projectos/GIS
corridor_projects
id uuid
corridor_id→development_corridors; project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-021
Projectos/GIS
corridor_clusters
id uuid
corridor_id→development_corridors; 
cluster_id→economic_clusters
code/name ou tipo/estado 
conforme domínio
UNIQUE external_id+source_system; B-tree 
FKs/estado; CHECK version_no>0
RF-022
Projectos/GIS
anchor_project_links
id uuid
anchor_project_id/linked_project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-023
Projectos/GIS
complementary_project_links
id uuid
project_id/complementary_project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-024
CRM
investors
id uuid
—
legal_name, investor_type
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-001
CRM
contacts
id uuid
investor_id→investors
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-002
CRM
leads
id uuid
investor_id→investors; contact_id→contacts
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-003
CRM
opportunities
id uuid
lead_id→leads; project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-004
CRM
activities
id uuid
opportunity_id→opportunities
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-005
CRM
tasks
id uuid
activity_id→activities
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-006
CRM
investor_journeys
id uuid
investor_id→investors; project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-007
Jornada/Aftercare
journey_steps
id uuid
journey_id→investor_journeys
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-008
Jornada/Aftercare
submissions
id uuid
journey_step_id→journey_steps
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-009
Jornada/Aftercare
aftercare_plans
id uuid
journey_id→investor_journeys
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-010
Jornada/Aftercare
constraints
id uuid
aftercare_plan_id→aftercare_plans
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-011
Jornada/Aftercare
escalations
id uuid
constraint_id→constraints
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-012
Educação
skills
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-013
Educação
occupations
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-014
Educação
training_needs
id uuid
occupation_id→occupations; project_id→projects
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-015
Educação
training_providers
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-016
Educação
courses
id uuid
provider_id→training_providers; skill_id→skills
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-017
CRM
education_opportunities
id uuid
course_id→courses; geo_location_id→geo_locations
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-018
Governação/IA
decisions
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-019
Governação/IA
approvals
id uuid
decision_id→decisions
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-020
Governação/IA
risk_register
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-021
Governação/IA
audit_events
id uuid
—
event_type, occurred_at, payload_hash
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-022
Governação/IA
ai_models
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-023
Governação/IA
ai_recommendations
id uuid
ai_model_id→ai_models
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-024
Integrações
integration_endpoints
id uuid
—
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-001
Integrações
outbox_events
id uuid
correlation_id lógico→audit_events
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-002
Integrações
inbox_events
id uuid
endpoint_id→integration_endpoints
code/name ou tipo/estado 
conforme domínio
UNIQUE external_id+source
_system; B-tree FKs/estado; CHECK version_no>0
RF-003
Integrações
sync_runs
id uuid
endpoint_id→integration_endpoints
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-004
Integrações
reconciliation_issues
id uuid
sync_run_id→sync_runs
code/name ou tipo/estado conforme domínio
UNIQUE external_id+source_system; B-tree FKs/estado; CHECK version_no>0
RF-005
Cardinalidades e comportamento de eliminação
Relações associativas (memberships, project_locations, cluster_projects, corridor_*) são N:M e têm unicidade composta. Relações pai→filho de composição, como content→translations, journey→steps e sync_run→issues, usam CASCADE apenas quando a remoção do pai é autorizada e auditada. Referências históricas, financeiras, auditoria, decisões, aprovações e projectos usam RESTRICT. Referências opcionais operacionais podem usar SET NULL. Soft delete não deve quebrar unicidade activa; usar índices parciais WHERE deleted_at IS NULL.
A.18 Ficheiros de importação canónicos
Ficheiro
Cabeçalhos mínimos
projects.csv
project_id,project_code,name,status,sector,estimated_cost,currency_code,source_system,external_id,updated_at
geo_locations.csv
geo_location_id,location_code,name,location_type,parent_code,country_code
geo_geometries.csv
geometry_id,geo_location_id,geometry_type,wkt,srid
clusters.csv
cluster_id,cluster_code,name,sector,status
value_chain_links.csv
link_id,from_value_chain_id,to_value_chain_id,link_type
corridors.csv
corridor_id,corridor_code,name,status
project_relations.csv
relation_id,from_project_id,to_project_id,relation_type
investors.csv
investor_id,investor_code,legal_name,investor_type,country_code
leads.csv
lead_id,investor_id,project_id,stage,source,created_at
documents.csv
document_id,owner_type,owner_id,title,object_key,mime_type,checksum_sha256
training_needs.csv
training_need_id,project_id,occupation_id,skill_id,quantity,needed_by
training_providers.csv
provider_id,provider_code,name,geo_location_id,status
education_opportunities.csv
opportunity_id,course_id,geo_location_id,start_date,end_date,capacity,status
Linhas fictícias — EXEMPLO, sem dados pessoais reais: projects.csv → 11111111-1111-4111-8111-111111111111,PRJ-EXEMPLO-001,Projecto demonstrativo,planned,agro,1000000.00,MZN,example,EX-001,2026-01-15T10:00:00Z. geo_locations.csv → 22222222-2222-4222-8222-222222222222,MZ-EX-001,Local fictício,district,,MZ. Os restantes ficheiros devem seguir o mesmo princípio, com UUIDs reservados para teste e valores explicitamente marcados EXEMPLO.
Campo de controlo
Regra
quarantine
true quando a linha não pode entrar nas tabelas de destino; preservar original imutável.
duplicate_key
Chave canónica que colidiu; não fazer merge automático sem regra aprovada.
error_code
Código estável, por exemplo REQUIRED_MISSING, INVALID_UUID, FK_NOT_FOUND.
error_message
Mensagem clara, sem expor segredos nem dados sensíveis.
source_row_number
Número físico da linha, incluindo cabeçalho como linha 1.
batch_id
UUID comum ao lote e aos registos de reconciliação.
imported_at
date-time ISO 8601 UTC preenchido apenas após persistência válida.
A.19 Backlog técnico importável
id
épico
módulo
história técnica
RF relacionados
prioridade
dependências
responsável
saída
testes
estado inicial
TECH-001
E1
governance
Manifesto, governação e checksums com configuração versionada, validação automática e evidência reproduzível.
RF-001
Must
—
Equipa governance
Manifesto, governação e checksums entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-002
E1
data
Dicionário e classificação de dados com configuração versionada, validação automática e evidência reproduzível.
RF-002
Must
TECH-001
Equipa data
Dicionário e classificação de dados entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-003
E2
platform
Containers locais reproduzíveis com configuração versionada, validação automática e evidência reproduzível.
RF-003
Must
TECH-001
Equipa platform
Containers locais reproduzíveis entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-004
E2
devops
Pipeline CI com gates com configuração versionada, validação automática e evidência reproduzível.
RF-004
Must
TECH-001
Equipa devops
Pipeline CI com gates entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-005
E3
database
Extensões PostgreSQL/PostGIS com configuração versionada, validação automática e evidência reproduzível.
RF-005
Must
TECH-001
Equipa database
Extensões PostgreSQL/PostGIS entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-006
E3
identity
Migrations de identidade com configuração versionada, validação automática e evidência reproduzível.
RF-006
Must
TECH-001; TECH-003
Equipa identity
Migrations de identidade entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-007
E3
content
Migrations de conteúdo com configuração versionada, validação automática e 
evidência reproduzível.
RF-007
Must
TECH-001; TECH-003
Equipa content
Migrations de conteúdo entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-008
E3
projects
Migrations GIS/projectos com configuração versionada, validação automática e evidência reproduzível.
RF-008
Must
TECH-001; TECH-003
Equipa projects
Migrations GIS/projectos entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-009
E3
clusters
Migrations clusters/corredores com configuração versionada, validação automática e evidência reproduzível.
RF-009
Must
TECH-001; TECH-003
Equipa clusters
Migrations clusters/corredores entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-010
E3
crm
Migrations CRM com configuração versionada, validação automática e evidência reproduzível.
RF-010
Must
TECH-001; TECH-003
Equipa crm
Migrations CRM entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-011
E3
aftercare
Migrations jornada/aftercare com configuração versionada, validação automática e evidência reproduzível.
RF-011
Must
TECH-001; TECH-003
Equipa aftercare
Migrations jornada/aftercare entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-012
E3
education
Migrations educação com configuração versionada, validação automática e evidência reproduzível.
RF-012
Must
TECH-001; TECH-003
Equipa education
Migrations educação entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-013
E3
governance_ai
Migrations governação/IA com configuração versionada, validação automática e evidência reproduzível.
RF-013
Must
TECH-001; TECH-003
Equipa governance_ai
Migrations governação/IA entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-014
E3
integrations
Migrations integrações/outbox com configuração versionada, validação automática e evidência reproduzível.
RF-014
Must
TECH-001; TECH-003
Equipa integrations
Migrations integrações/outbox entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-015
E3
database
Seeds de referência com configuração versionada, validação automática e 
evidência reproduzível.
RF-015
Must
TECH-001; TECH-003
Equipa database
Seeds de referência entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-016
E4
migration
Mapeamentos MySQL→PostgreSQL com configuração versionada, validação automática e evidência reproduzível.
RF-016
Must
TECH-001; TECH-003
Equipa migration
Mapeamentos MySQL→PostgreSQL entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-017
E4
migration
Migração piloto por ondas com configuração versionada, validação automática e evidência reproduzível.
RF-017
Must
TECH-001; TECH-003
Equipa migration
Migração piloto por ondas entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-018
E4
data_quality
Reconciliação e qualidade de dados com configuração versionada, validação automática e evidência reproduzível.
RF-018
Must
TECH-001; TECH-003
Equipa data_quality
Reconciliação e qualidade de dados entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-019
E4
migration
Rollback de migração com configuração versionada, validação automática e evidência reproduzível.
RF-019
Must
TECH-001; TECH-003
Equipa migration
Rollback de migração entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-020
E5
identity
RBAC e memberships com configuração versionada, validação automática e evidência reproduzível.
RF-020
Must
TECH-001; TECH-003
Equipa identity
RBAC e memberships entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-021
E5
identity
Consentimento e auditoria com configuração versionada, validação automática e evidência reproduzível.
RF-021
Must
TECH-001; TECH-003
Equipa identity
Consentimento e auditoria entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-022
E6
content
Object storage e documentos com configuração versionada, validação automática e evidência reproduzível.
RF-022
Must
TECH-001; TECH-003
Equipa content
Object storage e documentos entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-023
E6
content
Pesquisa multi-idioma com configuração versionada, validação automática e 
evidência reproduzível.
RF-023
Must
TECH-001; TECH-003
Equipa content
Pesquisa multi-idioma entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-024
E7
gis
Mapas e camadas GIS com configuração versionada, validação automática e evidência reproduzível.
RF-024
Must
TECH-001; TECH-003
Equipa gis
Mapas e camadas GIS entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-025
E2
api
OpenAPI v1 com configuração versionada, validação automática e evidência reproduzível.
RF-001
Must
TECH-001; TECH-003
Equipa api
OpenAPI v1 entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-026
E8
events
AsyncAPI e eventos/outbox com configuração versionada, validação automática e evidência reproduzível.
RF-002
Must
TECH-001; TECH-003
Equipa events
AsyncAPI e eventos/outbox entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-027
E2
backend
Módulos backend Laravel com configuração versionada, validação automática e evidência reproduzível.
RF-003
Must
TECH-001; TECH-003
Equipa backend
Módulos backend Laravel entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-028
E6
frontend
Rotas e telas React com configuração versionada, validação automática e evidência reproduzível.
RF-004
Should
TECH-001; TECH-003
Equipa frontend
Rotas e telas React entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-029
E8
crm
CRM e funil com configuração versionada, validação automática e evidência reproduzível.
RF-005
Should
TECH-001; TECH-003
Equipa crm
CRM e funil entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-030
E8
aftercare
Jornada e pós-investimento com configuração versionada, validação automática e evidência reproduzível.
RF-006
Should
TECH-001; TECH-003
Equipa aftercare
Jornada e pós-investimento entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-031
E9
education
Educação e oportunidades com configuração versionada, validação automática e evidência reproduzível.
RF-007
Should
TECH-001; TECH-003
Equipa education
Educação e oportunidades entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-032
E9
analytics
Indicadores e analítica com configuração versionada, validação automática e evidência reproduzível.
RF-008
Should
TECH-001; TECH-003
Equipa analytics
Indicadores e analítica entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-033
E9
ai
IA governada e recomendações com configuração versionada, validação automática e evidência reproduzível.
RF-009
Should
TECH-001; TECH-003
Equipa ai
IA governada e recomendações entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-034
E9
security
Segurança e análise de dependências com configuração versionada, validação automática e evidência reproduzível.
RF-010
Should
TECH-001; TECH-003
Equipa security
Segurança e análise de dependências entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-035
E9
operations
Observabilidade e alertas com configuração versionada, validação automática e evidência reproduzível.
RF-011
Could
TECH-001; TECH-003
Equipa operations
Observabilidade e alertas entregue e documentado
Unitário; integração; lint; evidência
Backlog
TECH-036
E9
operations
Runbooks, acessibilidade e prontidão operacional com configuração versionada, validação automática e evidência reproduzível.
RF-012
Could
TECH-001; TECH-003
Equipa operations
Runbooks, acessibilidade e prontidão operacional entregue e documentado
Unitário; integração; lint; evidência
Backlog
Mapa de épicos: E1 governação/dados; E2 plataforma; E3 PostgreSQL/PostGIS; E4 migração; E5 identidade; E6 conteúdo/pesquisa; E7 GIS/projectos/clusters/corredores; E8 CRM/jornada/pós-investimento; E9 educação, IA/analítica, segurança/DevOps/operação. Os 36 itens cobrem o MVP e fases posteriores; Must precede Should e Could, salvo dependência técnica aprovada.
Cabeçalho exacto e linha de exemplo — backlog/backlog.csv
id,epico,modulo,historia_tecnica,rf_relacionados,prioridade,dependencias,responsavel,saida,testes,estado_inicial\nTECH-001,E1,governance,"Definir manifesto, governação e checksums",RF-001,Must,,"Equipa governance","Manifesto validado","lint; checksum; revisão",Backlog
A.20 Matriz de rastreabilidade técnica
TECH
RF principais
Entidade/tabela
Endpoint/evento
Tela
Teste/evidência
Pacote
TECH-001..TECH-003
RF-001..RF-002
governance / entidades do domínio
/api/v1/governance; governance.changed
Tela Manifesto, governação e checksums
T-001 unit/integration/e2e
AUTO-01
TECH-004..TECH-006
RF-003..RF-004
devops / entidades do domínio
/api/v1/devops; devops.changed
Tela Pipeline CI com gates
T-002 unit/integration/e2e
AUTO-02
TECH-007..TECH-009
RF-005..RF-006
content / entidades do domínio
/api/v1/content; content.changed
Tela Migrations de conteúdo
T-003 unit/integration/e2e
AUTO-03
TECH-010..TECH-012
RF-007..RF-008
crm / entidades do domínio
/api/v1/crm; crm.changed
Tela Migrations CRM
T-004 unit/integration/e2e
AUTO-04
TECH-013..TECH-015
RF-009..RF-010
governance_ai / entidades do domínio
/api/v1/governance_ai; governance_ai.changed
Tela Migrations governação/IA
T-005 unit/integration/e2e
AUTO-05
TECH-016..TECH-018
RF-011..RF-012
migration / entidades do domínio
/api/v1/migration; migration.changed
Tela Mapeamentos MySQL→PostgreSQL
T-006 unit/integration/e2e
AUTO-06
TECH-019..TECH-021
RF-013..RF-014
migration / entidades do domínio
/api/v1/migration; migration.changed
Tela Rollback de migração
T-007 unit/integration/e2e
AUTO-07
TECH-022..TECH-024
RF-015..RF-016
content / entidades do domínio
/api/v1/content; content.changed
Tela Object storage e documentos
T-008 unit/integration/e2e
AUTO-08
TECH-025..TECH-027
RF-017..RF-018
api / entidades do domínio
/api/v1/api; api.changed
Tela OpenAPI v1
T-009 unit/integration/e2e
AUTO-09
TECH-028..TECH-030
RF-019..RF-020
frontend / entidades do domínio
/api/v1/frontend; frontend.changed
Tela Rotas e telas React
T-010 unit/integration/e2e
AUTO-10
TECH-031..TECH-033
RF-021..RF-022
education / entidades do domínio
/api/v1/education; education.changed
Tela Educação e oportunidades
T-011 unit/integration/e2e
AUTO-11
TECH-034..TECH-036
RF-023..RF-024
security / entidades do domínio
/api/v1/security; security.changed
Tela Segurança e análise de dependências
T-012 unit/integration/e2e
AUTO-12
Cada linha agrupada é importável como intervalo inclusivo de três TECH. A evidência detalhada deve desdobrar o intervalo no CSV final, mantendo a mesma chave AUTO e ligando commit, resultado de teste, aprovação e checksum.
A.21 Biblioteca de prompts do Codex
Prompt mestre
Usar 00-plan.md como orquestrador: seleccionar os prompts especializados estritamente necessários, passar-lhes os mesmos RF/TECH e âmbito, consolidar dependências e impedir execução paralela de migrations incompatíveis. O mestre exige revisão humana entre plano, implementação, migração, segurança e PR; nunca autoriza deploy, merge ou eliminação de dados.
Actividade
Automatizável
Revisão obrigatória
Proibido
Planeamento, scaffolding, lint e testes locais
Sim, em branch isolada
Arquitectura/QA
Inventar requisitos
DDL e migração piloto
Geração e dry-run
DBA, segurança e dono do dado
Produção; apagar dados
OpenAPI/AsyncAPI e código
Geração, lint e testes
Backend/frontend/integrações
Segredos; breaking change não aprovado
PR e evidências
Preparar branch, commits e texto
Aprovação humana
Merge/deploy automático
IA e recomendações
Protótipo e testes
Governação, negócio e segurança
Decisão automática vinculativa
A.22 Ordem de execução e importação
Etapa
Comandos orientadores — modelos iniciais
Saída esperada
Stop condition
1. Validar manifesto
<yaml-linter> manifest/project.yaml; sha256sum -c manifest/checksums.sha256
Manifesto e checksums válidos
Ficheiro ausente, versão incompatível ou checksum divergente
2. Criar branch
git switch -c <branch>
Branch isolada criada
Branch protegida ou alterações locais não resolvidas
3. Subir containers
docker compose config && docker compose up -d <services>
Serviços saudáveis
Configuração inválida ou healthcheck falhado
4. Aplicar extensões
psql <connection-placeholder> -v ON_ERROR_STOP=1 -f database/001_extensions.sql
Extensões confirmadas
Ligação não autorizada ou versão incompatível
5. Migrations por domínio
php artisan migrate --pretend; psql <placeholder> -f <script>
DDL aplicado na ordem do manifesto
Erro SQL, lock, irreversibilidade não aprovada
6. Seeds
php artisan db:seed --class=<SeedClass>
Referências idempotentes
Duplicado ou domínio inválido
7. OpenAPI/AsyncAPI
<openapi-linter> openapi/investmoz-v1.yaml; <asyncapi-linter> events/asyncapi.yaml
Contratos sem erros
Breaking change não aprovado
8. Backend
composer install; php artisan test
Módulos e testes verdes
Falha de segurança, lint ou teste
9. Frontend
npm ci; npm run lint; npm test; npm run build
Build reproduzível e acessível
Erro TypeScript, teste ou acessibilidade crítico
10. Importação piloto
php artisan import:<domain> --file=<path> --dry-run
Lote piloto com batch_id
Quarantine acima do limiar aprovado
11. Reconciliação
php artisan reconcile --batch=<uuid>
Contagens, totais e hashes conciliados
Diferença não explicada
12. Testes
composer test; npm test; <contract-tests>
Unitários, integração, contrato e E2E passam
Qualquer teste obrigatório falha
13. PR
git push -u origin <branch>; criar PR sem merge
PR com RF/TECH e evidências
Revisores ou evidência em falta
14. Staging
Executar pipeline aprovado para <staging>
Smoke tests e monitoria válidos
Ambiente errado, alerta ou regressão
15. Aprovação manual
Registar aprovações técnica, negócio e segurança
Decisão formal auditável
Qualquer aprovação pendente
A.23 Checklist de entrega do pacote
#
Verificação
Estado
1
Todos os ficheiros previstos no manifesto existem nos caminhos exactos.
Pendente
2
YAML, JSON, CSV e SQL são sintacticamente válidos.
Pendente
3
DDL é reexecutável e reversível quando aplicável; efeitos não reversíveis estão justificados e aprovados.
Pendente
4
Todas as migrations têm down/rollback testado ou decisão formal documentada.
Pendente
5
OpenAPI e AsyncAPI passam lint e testes de contrato.
Pendente
6
TypeScript e PHP passam lint, análise estática e build.
Pendente
7
Testes unitários, integração, contrato, E2E e migração passam.
Pendente
8
Nenhum segredo, credencial, token, dado pessoal real ou endpoint produtivo está incluído.
Pendente
9
Checksums SHA-256 e versões coincidem com o manifesto.
Pendente
10
Rastreabilidade RF→TECH→ficheiro→teste→evidência está completa.
Pendente
11
Importações registam batch_id, quarantine, erros e reconciliação.
Pendente
12
Índices, SRID 4326, UTC, moedas e regras de nulidade foram verificados.
Pendente
13
RBAC, consentimento, classificação e auditoria foram revistos.
Pendente
14
Acessibilidade, observabilidade, alertas, backups e rollback foram ensaiados.
Pendente
15
Revisão humana e aprovações técnica, negócio, segurança e dados estão registadas.
Pendente
Os conteúdos desta secção constituem modelos históricos não normativos. A transposição para o repositório deve usar exclusivamente A.31 e requer adaptação ao código-fonte real, revisão humana, testes, controlo de versão, segurança e aprovação formal.
A.24 Estrutura exacta do pacote de importação
A estrutura abaixo é histórica e não normativa; para transposição para ficheiros de repositório prevalecem exclusivamente os caminhos definidos em A.31.1.
FICHEIRO: árvore do pacote
investmoz-upgrade/\n
├
── README.md\n
├
── manifest/\n│   └── project.yaml\n
├
── database/\n│   
├
── sql/\n│   │   
├
── 001_extensions.sql\n│   │   
├
── 010_identity.sql\n│   │   
├
── 020_content.sql\n│   │   
├
── 030_geography.sql\n│   │   
├
── 040_projects.sql\n│   │   
├
── 050_clusters.sql\n│   │   
├
── 060_corridors.sql\n│   │   
├
── 070_crm.sql\n│   │   
├
── 080_journey_aftercare.sql\n│   │   
├
── 090_education.sql\n│   │   
├
── 100_governance_ai.sql\n│   │   └── 110_integrations.sql\n│   
├
── migrations/mysql_to_postgres/\n│   │   
├
──
 mapping.yaml\n│   │   
├
──
 batches.yaml\n
│
   
│
   
└──
 reconciliation.yaml\n
│
   
└──
 seeds/\n
│
       
└──
 *.csv\n
├
──
 imports/\n
│
   
├
──
 templates/\n
│
   
│
   
└──
 *.csv\n
│
   
└──
 schemas/\n
│
       
└──
 *.json\n
├
──
 openapi/\n
│
   
└──
 investmoz-v1.yaml\n
├
──
 events/\n
│
   
└──
 asyncapi.yaml\n
├
──
 backend/\n
│
   
└──
 modules.json\n
├
──
 frontend/\n
│
   
├
──
 routes.json\n
│
   
└──
 screens.json\n
├
──
 backlog/\n
│
   
├
──
 backlog.csv\n
│
   
└──
 traceability.csv\n
├
──
 codex/prompts/\n│   
├
──
 00-master.md\n
│
   
├
──
 01-schema-postgres.md\n
│
   
├
──
 02-laravel-module.md\n
│
   
├
──
 03-openapi.md\n
│
   
├
──
 04-react-screen.md\n
│
   
├
──
 05-mysql-migration.md\n
│
   
├
──
 06-tests.md\n
│
   
├
──
 07-security-review.md\n
│
   
├
──
 08-refactor.md\n
│
   
├
──
 09-pull-request.md\n
│
   
├
──
 10-data-import.md\n
│
   
└──
 11-gis.md\n
├
──
 ci/\n
│
   
└──
 pipeline.yaml\n
└──
 docs/\n    
├
──
 data-dictionary.csv\n    
├
──
 erd.mmd\n    
└──
 runbooks/
Área
Artefactos
Finalidade
Base de dados
12 scripts SQL; migração; seeds
Esquema, carga e reconciliação
Contratos
OpenAPI, AsyncAPI e JSON Schema
Interfaces verificáveis
Aplicação
modules.json, routes.json, screens.json
Composição de backend e frontend
Entrega
backlog, traceability, prompts e pipeline
Execução controlada e rastreável
Documentação
dicionário, ERD e runbooks
Operação e governação
FICHEIRO: README.md
# InvestMoz Upgrade\n\nmodelo inicial — adaptar e rever\n\n## Pré-requisitos\n- PostgreSQL 15+ com PostGIS e pgcrypto disponíveis.\n- Cliente psql, validador JSON Schema, validador OpenAPI/AsyncAPI e utilitário SHA-256.\n- Branch de trabalho, fixtures anonimizadas e ambiente development/test.\n\n## Ordem\n1. Validar manifest/project.yaml e contratos.\n2. Executar database/sql/001_extensions.sql e depois os scripts 010–110 por ordem numérica.\n3. Validar schemas e importar CSV por lotes idempotentes.\n4. Executar reconciliação, testes e revisão de segurança.\n5. Abrir PR com evidências; não fazer deploy automático.\n\n## Comandos de validação\npsql -v ON_ERROR_STOP=1 -f database/sql/001_extensions.sql\nfor f in database/sql/*.sql; do psql -v ON_ERROR_STOP=1 -f "$f"; done\npython -m json.tool imports/schemas/projects.schema.json\nnpx @redocly/cli lint openapi/investmoz-v1.yaml\nnpx @asyncapi/cli validate events/asyncapi.yaml\nsha256sum $(find . -type f | sort)\n\n## Aviso\nNão usar segredos ou dados reais. Executar somente em development/test antes de staging.
A.25 Modelo físico executável — núcleo
modelo inicial — adaptar e rever. SQL PostgreSQL/PostGIS sem segredos nem dados reais.
 
EXTENSION IF EXISTS postgis;\nDROP EXTENSION IF EXISTS pgcrypto;\nCOMMIT;
A.26 Modelo físico executável — identidade, CRM, jornada, pós-investimento e educação
Origem
Destino
Cardinalidade
ON DELETE
Território
Corredor
N:M via corridor_locations
RESTRICT território/CASCADE associação
Corredor
Projecto
N:M
CASCADE associação
Cluster
Cadeia de valor
1:N
CASCADE
Projecto âncora
Projecto complementar
N:M dirigida
CASCADE associação
Investidor
Lead/Oportunidade
1:N / 1:N
SET NULL histórico
Jornada
Etapa/Submissão
1:N / 1:N
CASCADE
Plano pós-investimento
Constrangimento/Escalação
1:N / 1:N
CASCADE
Curso
Oportunidade de educação
1:N
CASCADE
A.28 Backlog técnico CSV
FICHEIRO: backlog/backlog.csv
A.30 Modelos CSV/JSON/YAML prontos para importação
Como materializar os ficheiros
Não copiar nem executar estes blocos históricos. Materializar exclusivamente os artefactos e caminhos normativos de A.31, validar a sintaxe, calcular SHA-256, colocar sob controlo de versão, abrir PR e executar apenas em development/test antes de staging.
As secções históricas contêm modelos não normativos; a criação física no repositório deve seguir exclusivamente A.31 e ser realizada pela equipa técnica ou pelo Codex sob revisão humana.
A.31. Pacote técnico normativo aprovado
A.31.1. Precedência e caminhos normativos
A.31 é a única fonte para implementação. 
A.31
 e 
A.31
–
A.31
 permanecem exclusivamente como histórico.
Caminhos normativos únicos: manifest/project.yaml; checksums.sha256; database/sql/001_extensions.sql, 010_identity.sql, 020_content.sql, 030_geography.sql, 040_projects.sql, 050_clusters.sql, 060_corridors.sql, 070_crm.sql, 080_journey_aftercare.sql, 090_education.sql, 100_governance_ai.sql, 110_integrations.sql; database/migrations/mysql_to_postgres/mapping.yaml, batches.yaml, reconciliation.yaml; imports/schemas/projects.schema.json; imports/templates/*.csv; openapi/investmoz-v1.yaml; events/asyncapi.yaml; backlog/backlog.csv; backlog/traceability.csv; codex/prompts/00-master.md e 01-schema-postgres.md a 11-gis.md; ci/pipeline.yaml; docs/data-dictionary.csv; docs/erd.mmd; docs/runbooks/*.md.
As variantes database/ sem sql, projects.json e 00-plan.md são não normativas.
A.31.2. SQL normativo e rollback
database/sql/001_extensions.sql — modelo inicial — adaptar e rever\nCREATE EXTENSION IF NOT EXISTS postgis;\nCREATE EXTENSION IF NOT EXISTS pgcrypto;\nCREATE OR REPLACE FUNCTION public.set_updated_at() RETURNS trigger LANGUAGE plpgsql AS $$ BEGIN NEW.updated_at = timezone('utc', now()); RETURN NEW; END; $$;\nCOMMENT ON FUNCTION public.set_updated_at() IS 'Managed by InvestMoz platform migrations; extensions are platform-managed and are not removed by application rollback.';
O ficheiro database/sql/001_extensions.sql é executado primeiro; os triggers só são criados depois da função. Os ficheiros 010–110 são migrations versionadas.
Rollback normativo: sem CASCADE e sem DROP EXTENSION. A remoção faz-se em ordem inversa apenas para triggers, índices, constraints e tabelas próprias, sempre com IF EXISTS e RESTRICT por defeito.
Controlo
Evidência normativa
Função antes dos triggers
001_extensions.sql é executado antes de qualquer trigger.
Extensões preservadas
O rollback não remove postgis nem pgcrypto.
Rollback não destrutivo
Sem CASCADE; IF EXISTS e RESTRICT por defeito.
Soft-delete/unicidade
Controlos obrigatórios das migrations.
GIS e dinheiro/moeda
GIST, SRID, validade geométrica e dinheiro/moeda são controlos obrigatórios das migrations.
A.31.3. Backlog normativo
backlog/backlog.csv desta secção é a única fonte normativa para TECH-001–TECH-036.
Regras: IDs únicos e sequenciais; épicos E1–E9; prioridade Must para manifesto/repositório, SQL/extensões, modelo físico, migração/rollback, identidade/RBAC/consentimento, conteúdo/pesquisa, GIS, projectos, CRM básico, outbox/inbox, OpenAPI, testes, segurança, acessibilidade, observabilidade e runbooks; Should/Could apenas para expansão; dependências somente em TECH anteriores; nunca AUTO como dependência; AUTO-01–AUTO-12 apenas na coluna auto_package; estado inicial Backlog.
Intervalo TECH
Grupo
001–004
Fundação
005–008
Dados/migração
009–012
Identidade/conteúdo
013–017
GIS/projectos/clusters/corredores
018–022
CRM/jornada/pós-investimento
023–025
Educação
026–029
APIs/eventos/analítica
030–036
Testes/segurança/acessibilidade/observabilidade/runbooks
Confirmação normativa: não existem ciclos; há cobertura integral de E1–E9 e AUTO-01–AUTO-12.
A.31.4. Prompts Codex normativos
A única biblioteca normativa é: 00-master.md e 01-schema-postgres.md, 02-laravel-module.md, 03-openapi.md, 04-react-screen.md, 05-mysql-migration.md, 06-tests.md, 07-security-review.md, 08-refactor.md, 09-pull-request.md, 10-data-import.md e 11-gis.md. O master selecciona somente os prompts necessários.
Todos exigem Papel, Contexto, Inputs, RF/TECH, Tarefa, Restrições, Entregáveis, Comandos obtidos do repositório, Condições de paragem e Formato.
Regras: branch própria, PR, listar ficheiros, gerar testes/evidências, preservar compatibilidade, sem segredos, sem deploy, sem apagar dados, sem alterar fora do âmbito, sem inventar regras e parar perante ambiguidade material.
As variantes 00-plan e as bibliotecas anteriores são não normativas.
A.31.5. Checklist de validação com evidências
Verificação
Evidência documental
Estado
Aprovador/execução necessária
set_updated_at antes de triggers
Ordem definida em A.31.2
Aprovado documentalmente
Nenhuma
Extensões preservadas
Rollback exclui DROP EXTENSION
Aprovado documentalmente
Nenhuma
Rollback sem CASCADE
Política de rollback em A.31.2
Aprovado documentalmente
Nenhuma
Caminhos normalizados
Lista única em A.31.1
Aprovado documentalmente
Nenhuma
checksums.sha256 presente
Caminho normativo declarado
Aprovado documentalmente
Nenhuma
Backlog único
backlog/backlog.csv
Aprovado documentalmente
Nenhuma
Dependências TECH válidas
Somente TECH anteriores; sem AUTO
Aprovado documentalmente
Nenhuma
Prompts únicos/master condicional
Biblioteca 00–11 e selecção condicional
Aprovado documentalmente
Nenhuma
SQL lint
Relatório de lint
Pendente no repositório
Execução no repositório
YAML/JSON/CSV lint
Relatórios de lint
Pendente
Execução
ERD parse
Resultado de parsing
Pendente
Execução
Contract tests
Relatório de testes
Pendente
Execução
Migration dry-run
Log de dry-run
Pendente
Execução
Rollback dry-run
Log de dry-run
Pendente
Execução
Checksums calculados
checksums.sha256 calculado
Pendente
Execução
Security review
Relatório de segurança
Pendente
Segurança
Revisão Arquitectura/Dados/Segurança/QA/Produto
Registo de revisão
Pendente
Aprovações formais
A.31.6. Estado de aprovação
Âmbito
Estado
Condição/decisão
Documento
Aprovado documentalmente
A.31 resolve os quatro bloqueios
Repositório
Pendente
criar ficheiros físicos e checksums
Development/Test
Pendente condicionado
lint, dry-runs e testes
Staging
Pendente
contract/security/UAT
Produção
Não aprovada
Go/No-Go formal
Os quatro bloqueios críticos estão corrigidos documentalmente; a transposição ao repositório está autorizável; a execução continua condicionada às evidências pendentes.
A.31 é a única fonte normativa do pacote técnico. Secções anteriores do Anexo A permanecem como histórico e não devem ser importadas nem executadas.