Status de conteúdo e capacidades
O Centro de Documentação UbID separa classificações que respondem a perguntas diferentes. Uma página pode estar editorialmente completa ao descrever capacidade planejada, ou descrever capacidade disponível enquanto sua redação ainda aguarda revisão especializada.
Status da capacidade
| Status | Significado |
|---|---|
| Disponível | Aprovada para uso geral dentro do produto, região e condições declarados |
| Disponibilidade limitada | Disponível apenas para clientes, regiões, ambientes ou implantações controladas identificados |
| Preview | Disponível para avaliação; interfaces, comportamento, suporte ou evidência podem mudar |
| Planejada | Direção aprovada, mas não apresentada como disponível atualmente |
| Conceitual | Conceito de arquitetura ou pesquisa sem compromisso de produto |
| Acesso de parceiros | Capacidade ou documentação fornecida apenas por onboarding controlado |
Uma página não deve inferir disponibilidade a partir da existência de código-fonte, protótipo, diagrama de arquitetura ou serviço interno.
Status editorial
| Status | Significado |
|---|---|
| Outline | Escopo e limites definidos; texto público completo pendente |
| Foundation | Explicação-base substancial disponível; revisão especializada e linguística pode continuar |
| Approved | A versão declarada concluiu revisão editorial, temática, de exposição e publicação |
Todas as páginas criadas até a Fase 3 permanecem em foundation até a conclusão da revisão formal.
Estado da fonte arquitetônica
Fontes institucionais podem classificar material como:
- CURRENT — capacidade evidenciada no ambiente validado na data da fonte;
- REFERENCE — regra, limite ou responsabilidade de produto arquitetônica e durável;
- TARGET — evolução pretendida, não apresentada como já implementada.
Esses estados da fonte não se convertem automaticamente em disponibilidade de produto. Responsáveis por produto, operações, segurança e comercial devem aprovar o status público da capacidade.
Nível de exposição
O modelo de governança editorial usa:
| Nível | Regra de publicação |
|---|---|
| Public | Adequada ao portal público após revisão normal |
| Public reviewed | Explicável publicamente, mas exige revisão especializada porque as afirmações envolvem segurança, privacidade, regulação, biometria, criptografia ou automação de alto impacto |
| Partner | Documentação controlada para integradores autorizados |
| Internal | Arquitetura, operações, riscos, procedimentos e evidência para pessoal autorizado |
| Restricted ou secret | Chaves, credenciais, material de recuperação, achados sensíveis, acesso privilegiado e outro material que nunca deve entrar na árvore pública de fontes |
Apenas páginas public e public-reviewed são permitidas em docs/.
Hierarquia de fontes
O conteúdo público deve ser sustentado nesta ordem:
- lei, regulação, orientação de autoridade ou padrão normativo oficial e vigente;
- documentos controlados de arquitetura e política UbID aprovados;
- evidência de implementação e operação validada;
- decisões aprovadas de produto e disponibilidade;
- material explicativo claramente identificado como não normativo.
Quando fontes entrarem em conflito, a página não deve reconciliá-las silenciosamente. O conflito deve ser encaminhado ao responsável e a afirmação pública limitada até sua resolução.
Metadados de revisão da página
Uma página madura deve conseguir identificar:
- responsável pelo conteúdo;
- revisores especializados;
- versões de fontes e data de corte da pesquisa;
- data da última revisão;
- status da capacidade quando relevante;
- jurisdições e produtos no escopo;
- limitações conhecidas;
- próxima revisão ou gatilho de mudança.
Nem todo campo precisa ser exibido publicamente, mas o registro de aprovação deve existir.
Mudança e deprecação
Mudanças materiais devem atualizar:
- conteúdo da página e registro de revisão;
- changelog da documentação;
- status da capacidade;
- orientação afetada de parceiros;
- aviso de migração ou deprecação;
- referências externas;
- traduções depois que o idioma-fonte for aprovado.
Conteúdo depreciado deve indicar substituição e data de vigência. Ele não deve desaparecer quando usuários históricos ainda precisam de informações de migração.
Segurança de publicação
A verificação do build público examina front matter, valores de exposição, arquivos referenciados, assets estáticos e padrões comuns de segredos ou endereços internos. Controles automatizados reduzem erros, mas não substituem revisão humana de segurança, privacidade, jurídico, arquitetura e produto.
O portal permanece sem indexação até o marco de publicação aprovado.
Consulte o Registro de alterações da documentação e Governança e responsabilização.