{
  "id": "dominio-e-modelo-de-dados",
  "title": "Domínio e modelo de dados",
  "description": "Mapa de navegação das entidades, regras de persistência e ciclos do SGE.",
  "type": "data-model",
  "status": "in-progress",
  "visibility": "public",
  "tags": [
    "sge/dominio",
    "sge/modelagem",
    "sge/banco-de-dados"
  ],
  "related": [
    "glossario",
    "pessoas-e-responsabilidades",
    "modelo-de-dados-nucleo",
    "modelo-de-dados-acesso",
    "modelo-de-dados-historico",
    "ciclos-de-status",
    "modelagem-de-dados",
    "fluxos-principais"
  ],
  "sourceRefs": [],
  "authors": [],
  "updated": null,
  "diagram": "dominio-modelo-diagrama",
  "body": "## Antes de olhar os dados\n\nEsta página explica como o sistema organiza as informações para que cada etapa tenha um responsável e um histórico confiável. Não é preciso conhecer banco de dados para acompanhar a ideia: a pessoa inicia uma solicitação, o aceite cria o estágio, documentos e avaliações ficam ligados a ele e mudanças importantes permanecem registradas.\n\nAs expressões técnicas aparecem porque esta também é a referência da equipe que implementa o sistema. Sempre que elas forem necessárias, consulte o [glossário](doc:glossario). Para entender quem participa de cada etapa, leia [Pessoas e responsabilidades](doc:pessoas-e-responsabilidades).\n\n## Visão do domínio\n\nEsta página é o ponto de entrada do modelo de dados. Os campos e relacionamentos detalhados ficam nos recortes especializados, evitando repetir contratos em várias notas.\n\n{{diagram:dominio-modelo-diagrama}}\n\n## Encontre a regra certa\n\n| Pergunta | Fonte canônica |\n| --- | --- |\n| Quais entidades e FKs formam o estágio? | [Modelo de dados — Núcleo](doc:modelo-de-dados-nucleo) |\n| Como a pessoa escolhe um contexto e recebe acesso? | [Modelo de dados — Acesso](doc:modelo-de-dados-acesso) |\n| Quando usar FK, dado atual, snapshot ou log? | [Modelo de dados — Histórico](doc:modelo-de-dados-historico) |\n| Quais estados existem e quem pode mudá-los? | [Ciclos de status](doc:ciclos-de-status) |\n| Como as partes se conectam visualmente? | [Modelagem de dados](doc:modelagem-de-dados) |\n| O que significa cada termo? | [Glossário](doc:glossario) |\n\n## Regras que atravessam o modelo\n\n- A pessoa possui uma conta e pode ter vários vínculos institucionais.\n- O vínculo ativo define função, campus e curso usados por Gates e Policies.\n- Solicitação, estágio, documento e avaliação possuem ciclos independentes.\n- Cadastros atuais mantêm relacionamentos por FK; fatos históricos relevantes são congelados em snapshots.\n- Cada linha de [`addresses`](doc:migration-01-addresses) pertence a no máximo um cadastro ou registro histórico; endereços idênticos de proprietários distintos têm IDs diferentes. A base já permite criar cópias históricas, mas a exclusividade ainda não é garantida pelo schema atual.\n- Alterações relevantes registram autoria e vínculo no Activity Log.\n- Templates são versionados; documentos gerados preservam a versão e os dados usados, sem armazenar permanentemente o arquivo final.\n- A jornada pactuada, os feriados e as pausas são registros próprios porque afetam a previsão de término; uma nova vigência de jornada só é criada por aditivo formalizado.\n\n> [!tip] Leitura recomendada\n> Para uma visão visual, comece em [Modelagem de dados](doc:modelagem-de-dados). Para implementar uma regra, vá ao recorte correspondente e confirme o fluxo em [Fluxos principais](doc:fluxos-principais).",
  "sections": [
    {
      "id": "antes-de-olhar-os-dados",
      "level": 2,
      "title": "Antes de olhar os dados",
      "text": "Esta página explica como o sistema organiza as informações para que cada etapa tenha um responsável e um histórico confiável. Não é preciso conhecer banco de dados para acompanhar a ideia: a pessoa inicia uma solicitação, o aceite cria o estágio, documentos e avaliações ficam ligados a ele e mudanças importantes permanecem registradas.  As expressões técnicas aparecem porque esta também é a referência da equipe que implementa o sistema. Sempre que elas forem necessárias, consulte o [glossário](doc:glossario). Para entender quem participa de cada etapa, leia [Pessoas e responsabilidades](doc:pessoas-e-responsabilidades).",
      "line": 1
    },
    {
      "id": "visao-do-dominio",
      "level": 2,
      "title": "Visão do domínio",
      "text": "Esta página é o ponto de entrada do modelo de dados. Os campos e relacionamentos detalhados ficam nos recortes especializados, evitando repetir contratos em várias notas.",
      "line": 7
    },
    {
      "id": "encontre-a-regra-certa",
      "level": 2,
      "title": "Encontre a regra certa",
      "text": "| Pergunta | Fonte canônica | | --- | --- | | Quais entidades e FKs formam o estágio? | [Modelo de dados — Núcleo](doc:modelo-de-dados-nucleo) | | Como a pessoa escolhe um contexto e recebe acesso? | [Modelo de dados — Acesso](doc:modelo-de-dados-acesso) | | Quando usar FK, dado atual, snapshot ou log? | [Modelo de dados — Histórico](doc:modelo-de-dados-historico) | | Quais estados existem e quem pode mudá-los? | [Ciclos de status](doc:ciclos-de-status) | | Como as partes se conectam visualmente? | [Modelagem de dados](doc:modelagem-de-dados) | | O que significa cada termo? | [Glossário](doc:glossario) |",
      "line": 13
    },
    {
      "id": "regras-que-atravessam-o-modelo",
      "level": 2,
      "title": "Regras que atravessam o modelo",
      "text": "- A pessoa possui uma conta e pode ter vários vínculos institucionais. - O vínculo ativo define função, campus e curso usados por Gates e Policies. - Solicitação, estágio, documento e avaliação possuem ciclos independentes. - Cadastros atuais mantêm relacionamentos por FK; fatos históricos relevantes são congelados em snapshots. - Cada linha de [`addresses`](doc:migration-01-addresses) pertence a no máximo um cadastro ou registro histórico; endereços idênticos de proprietários distintos têm IDs diferentes. A base já permite criar cópias históricas, mas a exclusividade ainda não é garantida pelo schema atual. - Alterações relevantes registram autoria e vínculo no Activity Log. - Templates são versionados; documentos gerados preservam a versão e os dados usados, sem armazenar permanentemente o arquivo final. - A jornada pactuada, os feriados e as pausas são registros próprios porque afetam a previsão de término; uma nova vigência de jornada só é criada por aditivo formalizado.  > [!tip] Leitura recomendada > Para uma visão visual, comece em [Modelagem de dados](doc:modelagem-de-dados). Para implementar uma regra, vá ao recorte correspondente e confirme o fluxo em [Fluxos principais](doc:fluxos-principais).",
      "line": 24
    }
  ],
  "sourcePath": "content/dominio-e-modelo-de-dados.md",
  "visuals": [
    {
      "id": "dominio-modelo-diagrama",
      "kind": "architecture",
      "title": "Domínio e modelo de dados",
      "description": "Áreas conceituais que conectam identidade, processo de estágio, formalização e histórico.",
      "summary": "O vínculo ativo conecta identidade e contexto à solicitação; a solicitação origina o estágio, documentos e avaliações, enquanto snapshots, Activity Log e notificações preservam o histórico.",
      "renderMode": "mermaid",
      "api": "api/diagrams/dominio-modelo-diagrama.json",
      "human": "diagrams/dominio-modelo-diagrama.html"
    }
  ],
  "apiVersion": 1
}