# SDR-0001 — Arquitetura **contratual** dos três contratos (C1 / C2 / C3) > **Atenção:** **arquitetura contratual** ≠ **arquitetura de sistemas de TI**. Este SDR trata da partição do **modelo de serviços** em três contratos. Para o **Modelo de Serviços de TI** (Eixo 1) ver [`../modelo-servicos-ti/`](../modelo-servicos-ti/) e o [glossário de eixos](./glossario-eixos.md). > > **Nomenclatura:** arquivo físico `sdr-0001-arquitetura-tres-contratos.md` (mantido para preservar links). Não usar `SRD-*.md` em paralelo neste repositório. --- ## 1. Metadados | Campo | Valor | |-------|--------| | **ID** | `sdr-0001-arquitetura-tres-contratos` | | **Título** | Arquitetura contratual dos três contratos (C1 / C2 / C3) | | **Versão** | `v0.2` | | **Data** | `2026-04-26` | | **Autor** | Equipe do repositório (documento legado consolidado) | | **Revisores** | *(pendente)* | | **Status** | `Em validação` | | **Substitui** | — | | **Substituído por** | — | | **Classificação** | `Interno` | | **Eixo** | `Arquitetura Contratual` | | **Domínio** | Arquitetura de contratos e papéis (governança / medição / operação) | | **Stakeholders** | Área de contratação de TI; agentes de documentação; consumidores listados na seção 9 | | **SDRs relacionados** | [sdr-0003-indice-fonte-unica.md](./sdr-0003-indice-fonte-unica.md), [sdr-0002-imr-unidades-e-evidencias.md](./sdr-0002-imr-unidades-e-evidencias.md), [sdr-0022-repositorio-convencoes-e-construcao.md](./sdr-0022-repositorio-convencoes-e-construcao.md) | | **SSoT (âmbito deste SDR)** | Sim — dono de *arquitetura* e *papéis* (C1 / C2 / C3) para este repositório, em consolidação junto à Proposta | --- ## 2. Controle de Revisão | Versão | Data | Autor | Mudanças | |--------|------|-------|----------| | v0.1 | *(anterior)* | — | Versão inicial (estrutura livre) | | v0.2 | 2026-04-26 | Equipe do repositório | Alinhamento ao template de 18 seções (governança SDR); preservação do conteúdo canônico e remissões | --- ## 3. Objetivo > **Atenção:** *arquitetura contratual* (Eixo 2 — partição em três contratos) **não** é *arquitetura de sistemas de TI* (Eixo 1 — desenho do serviço de operação, segurança, etc.). Ver [glossário de eixos](./glossario-eixos.md). Definir e manter, como **fonte única no âmbito “arquitetura contratual dos três contratos”**, o modelo de **papéis** e **fronteiras** entre **C1** (governança / medição), **C2** (operação) e **C3** (continuidade / segurança conforme escopo da Proposta), sem duplicar nos documentos consumidores o que ainda está sendo extraído da [Proposta](../../arquitetura-contratual/Proposta%20-%20Modelo%20de%20Central%20de%20Servi%C3%A7os%20e%20Infraestrutura%20de%20TI.md). --- ## 4. Escopo e Abstração ### 4.1 Dentro do escopo - Arquitetura lógica dos **três contratos** e **vedação** entre papéis (dois “operadores” do mesmo serviço, quando aplicável ao modelo). - O que o **C1** mede e o que **não** executa operacionalmente (em nível de princípio). - **Fronteiras** com escopo fora (ex.: telefonia, certificados pessoais — alinhado à Proposta §1.5). - Remissões normativas à Proposta enquanto o texto canônico **ainda** estiver majoritariamente na Proposta. ### 4.2 Fora do escopo - Detalhamento de **unidades**, **IMR** e evidências de medição — dono: [sdr-0002-imr-unidades-e-evidencias.md](./sdr-0002-imr-unidades-e-evidencias.md). - Regra de **fonte única entre SDRs** (mapa tópico → dono) — dono: [sdr-0003-indice-fonte-unica.md](./sdr-0003-indice-fonte-unica.md). - Especificação completa de **continuidade**, **segurança** ou **LGPD** — remeter aos SDRs de domínio correspondentes (ex.: continuidade em [sdr-0016-seguranca-c3-continuidades.md](./sdr-0016-seguranca-c3-continuidades.md)). ### 4.3 Nível de abstração **Arquitetura de referência** para contratação e documentação; não substitui cláusulas de edital ou ANS sem trâmite próprio. ### 4.4 Nomenclatura estendida (material novo) Em **TR**, **ANS**, minutas e **secções novas** de HTML, a forma preferida de identificar os três itens contratuais é **C1-GOV**, **C2-OPR** e **C3-SEC**, como **sinônimos** explícitos de **C1**, **C2** e **C3** (ver tabela e política de primeira menção em [sdr-0022-repositorio-convencoes-e-construcao.md](./sdr-0022-repositorio-convencoes-e-construcao.md) §10.1). Este **SDR-0001** permanece dono da **arquitetura** dos papéis; o **SDR-0022** é dono da **política de rótulo** em material novo. > **Eixo do C1-GOV:** o contrato de Governança é **instrumento contratual** (IMR, ANS, glosa, trava — Eixo 2) **e** **serviço prestado** (medição, ITSM, CMDB, NOC de medição, sala de medição — Eixo 1). Por isso o hub [sdr-0011](./sdr-0011-governanca-c1-medicao.md) e seus sub-SDRs (`0011a–d`) ficam classificados como `Eixo: Ambos`. A **trilateralidade** (cobrança mútua entre C1-GOV ↔ C2-OPR ↔ C3-SEC) tem texto canônico no sub-SDR [sdr-0011c](./sdr-0011c-c1-trilateralidade-cobranca-mutua.md). | Rótulo estendido | Contrato (este SDR) | |------------------|---------------------| | **C1-GOV** | C1 — governança / medição | | **C2-OPR** | C2 — operação | | **C3-SEC** | C3 — segurança da informação e continuidade cibernética no escopo do modelo | --- ## 5. Contexto e Síntese Executiva ### 5.1 Problema Sem um **âncora** clara para C1/C2/C3, documentos (Proposta, HTML, DFD/ETP, TR) podem divergir sobre papéis e limites de medição versus operação. ### 5.2 Solução proposta (resumo) Manter este SDR como **dono** do tema “arquitetura dos três contratos”; até a consolidação completa aqui, a **leitura obrigatória** complementar permanece a Proposta — [seção 2 — Estrutura dos 3 contratos](../../arquitetura-contratual/Proposta%20-%20Modelo%20de%20Central%20de%20Servi%C3%A7os%20e%20Infraestrutura%20de%20TI.md#2-estrutura-dos-3-contratos) e premissas [§1](../../arquitetura-contratual/Proposta%20-%20Modelo%20de%20Central%20de%20Servi%C3%A7os%20e%20Infraestrutura%20de%20TI.md#1-premissa-central-do-modelo). ### 5.3 Benefícios esperados Alinhamento entre agentes humanos/IA e entre artefatos do repositório sobre **quem mede**, **quem opera** e **onde** começa a continuidade. ### 5.4 Riscos se não implementado Redocumentação cíclica, ambiguidade em fiscalização e glosas, e inconsistência entre site HTML e pacote de contratação. --- ## 6. Slides Executivos - **C1** — governança e medição (o que se contrata medir; o que não é execução operacional do C2). - **C2** — operação do parque e serviços no escopo contratual. - **C3** — continuidade / resposta / camadas de proteção conforme modelo da Proposta. - **Vedação** — evitar conflito de papéis sobre o mesmo serviço sem regra explícita. --- ## 7. Restrições Globais, Não-Funcionais e Critérios de Sucesso ### 7.1 Restrições técnicas - **Não** copiar parágrafos longos deste arquivo para a [Proposta](../../arquitetura-contratual/Proposta%20-%20Modelo%20de%20Central%20de%20Servi%C3%A7os%20e%20Infraestrutura%20de%20TI.md) sem apagar o duplicado antigo, quando a consolidação ocorrer. - Alterações profundas de arquitetura devem refletir **primeiro** o dono (este SDR ou a Proposta, conforme fase da consolidação) e só então propagar. ### 7.2 Restrições de negócio / compliance Obedecer ao arcabouço de contratação pública aplicável ao órgão; este SDR é **instrumento de alinhamento**, não substituto de parecer jurídico. ### 7.3 Critérios de sucesso mensuráveis - Checklist da seção 8.4 **concluído** e texto correspondente presente **uma única vez** no conjunto Proposta + SDR (sem duplicidade canônica). - Consumidores (seção 9) **referenciam** este SDR ou a Proposta de forma consistente após revisão. --- ## 8. Design / Arquitetura ### 8.1 Visão geral O modelo organiza responsabilidades em **três frentes contratuais** (C1, C2, C3), com separação entre **medição/governança**, **execução operacional** e **continuidade/proteção**, conforme a [Proposta — §2 e §1](../../arquitetura-contratual/Proposta%20-%20Modelo%20de%20Central%20de%20Servi%C3%A7os%20e%20Infraestrutura%20de%20TI.md). ### 8.2 Componentes | Componente | Papel (resumo) | |------------|----------------| | **C1** | Contrato de governança e medição; indicadores e fiscalização da qualidade do que foi contratado em C2/C3 | | **C2** | Operação do parque e serviços de TI no escopo | | **C3** | Continuidade, resposta a incidentes de segurança e camadas de proteção (no limite do modelo da Proposta) | ### 8.3 Fluxos *(Detalhar em revisão futura: fluxo de medição → constatação → glosa/trava, remetendo a [sdr-0005-trava-e-glosa.md](./sdr-0005-trava-e-glosa.md) quando couber.)* ### 8.4 Decisões pendentes de consolidação (checklist) - [ ] Papel e **vedação** (dois “operadores” do mesmo serviço) - [ ] O que o C1 mede / não executa operacionalmente - [ ] Fronteiras com escopo fora (telefonia, certificados pessoais, etc. — Proposta §1.5) --- ## 9. Processos e Integrações ### 9.1 Processos afetados Planejamento da contratação, elaboração de TR/edital, desenho de ANS/IMR e fiscalização. ### 9.2 Integrações - Documentos: DFD, ETP, TR, ANS, IMR. - Site: `modelo-central-servicos.html` e páginas derivadas do modelo. ### 9.3 SLAs / tempos Definidos nos instrumentos de **C2/C3** e no **ANS**; não duplicar aqui os parâmetros numéricos (ver [sdr-0007-ans-parametros-sla.md](./sdr-0007-ans-parametros-sla.md) quando for o caso). --- ## 10. Dados, Modelos e Classificações ### 10.1 Entidades / glossário - **C1 / C2 / C3** — camadas contratuais do modelo. - **Vedação** — separação explícita de papéis para evitar conflito de interesse operacional. ### 10.2 Modelos de dados *N/A neste SDR* (dados de parque e localidades: ver [sdr-0004-parque-localidades-ativos.md](./sdr-0004-parque-localidades-ativos.md) e correlatos). ### 10.3 Classificações (LGPD, criticidade, etc.) Remeter a [sdr-0014-ppsi-lgpd-conformidade.md](./sdr-0014-ppsi-lgpd-conformidade.md) quando o fluxo tocar dados pessoais ou classificações de informação. --- ## 11. Controles de Exclusividade e Risco ### 11.1 Exclusividade / fonte única - Este arquivo é **dono** do tópico *arquitetura dos três contratos* no sentido do [índice](./sdr-0003-indice-fonte-unica.md): outros `sdr-*.md` devem **remeter**, não recriar o mesmo bloco normativo. - Entre SDRs, aplicam-se [REGRAS-AGENTE-E-PROMPTS.md](./REGRAS-AGENTE-E-PROMPTS.md) e o [sdr-0003](./sdr-0003-indice-fonte-unica.md). ### 11.2 Riscos e mitigação | Risco | Mitigação | |-------|-----------| | Divergência Proposta × SDR | Consolidação planejada; até lá, priorizar remissões explícitas | | Duplicação em dois SDRs | Corrigir no **dono** e trocar duplicatas por links | --- ## 12. Segurança, LGPD e Auditoria ### 12.1 Controles de segurança Remeter a continuidade e segurança em [sdr-0016-seguranca-c3-continuidades.md](./sdr-0016-seguranca-c3-continuidades.md). ### 12.2 LGPD / privacidade *Não específico deste SDR* — ver [sdr-0014-ppsi-lgpd-conformidade.md](./sdr-0014-ppsi-lgpd-conformidade.md). ### 12.3 Auditoria / evidências Evidências de aderência à arquitetura surgem na **documentação de contratação** e em **atos de fiscalização**; não prescrever formato aqui. --- ## 13. Rastreabilidade e Validação ### 13.1 Critérios de aceite globais - Leitores conseguem responder: *quem é C1, C2 e C3 neste modelo?* apenas com este SDR + remissões. - Checklist 8.4 tratado em revisão formal antes de marcar **Status: Aprovado**. ### 13.2 Validações automáticas (quando existirem) `python scripts/check_sdr_conformity.py` — estrutura e metadados. ### 13.3 Validações manuais Revisão conjunta com responsável pela Proposta e pelo pacote HTML do modelo. --- ## 14. Matriz de Implementações Dependentes e Riscos | Implementação | Depende de | Risco se atrasar | |---------------|------------|------------------| | Texto integral estável no site (`modelo-central-servicos.html`) | Consolidação Proposta ↔ SDR-0001 | Desalinhamento percebido por stakeholders | | TR/Edital | Arquitetura aprovada | Ambiguidade de escopo e papéis | --- ## 15. Histórico de Mudanças Governadas | Data | Mudança | SDR / proposta | |------|---------|----------------| | 2026-04-26 | Migração para template 18 seções; **Status** `Em validação` | sdr-0001 v0.2 | --- ## 16. Propostas Governadas (alternativas) *Nenhuma alternativa formal registrada nesta versão.* Renomeação ou fatiamento C1/C2/C3 deve passar por [SDR-CHANGE-PROPOSAL-TEMPLATE.md](./templates/SDR-CHANGE-PROPOSAL-TEMPLATE.md) quando houver impacto em consumidores. --- ## 17. Requisitos ### 17.1 Requisitos funcionais | ID | Requisito | Prioridade | Aceite quando | |----|-----------|------------|---------------| | RF-001 | Descrever **vedação** entre operadores do mesmo serviço (quando aplicável) | Alta | Texto canônico neste SDR ou remissão única à Proposta, sem contradição | | RF-002 | Explicitar o que o **C1 mede** e o que **não** executa como C2 | Alta | Checklist 8.4 concluído | | RF-003 | Delimitar **fronteiras** com escopo fora (ex.: Proposta §1.5) | Média | Checklist 8.4 concluído | ### 17.2 Rastreabilidade implementação ↔ requisito | Requisito | Arquivo / componente | Observação | |-----------|----------------------|------------| | RF-001–RF-003 | [Proposta — Modelo de Central de Serviços e Infraestrutura de TI](../../arquitetura-contratual/Proposta%20-%20Modelo%20de%20Central%20de%20Servi%C3%A7os%20e%20Infraestrutura%20de%20TI.md) §1–2 | Fonte narrativa até consolidação total no SDR | | *(site)* | `arquitetura-contratual/modelo-central-servicos.html` | Consumidor; alinhar seções ao dono após consolidação | | Rastreio agregado | [traceability.md](./traceability.md) | Incluir linhas quando houver código com comportamento dedicado a C1/C2/C3 | ### 17.3 Requisitos não-funcionais | ID | Requisito | Métrica | |----|-----------|---------| | RNF-001 | Legibilidade para agentes de IA | Estrutura 1–18 presente; links relativos válidos | --- ## 18. Checklist de Governança - [x] Metadados completos (seção 1) - [x] Status coerente com o ciclo de vida (`Em validação` = texto ainda em consolidação com a Proposta) - [x] Sem duplicar norma já dona em outro `sdr-*.md` (ver [sdr-0003](./sdr-0003-indice-fonte-unica.md)) - [ ] `traceability.md` e/ou comentários `SDR:` no código quando houver **implementação** exclusiva deste domínio *(hoje: majoritariamente documental — ver 17.2)* - [ ] Revisores e data de aprovação quando **Status: Aprovado** --- ## Ligações (navegação rápida) - [sdr-0003-indice-fonte-unica.md](./sdr-0003-indice-fonte-unica.md) - [sdr-0002-imr-unidades-e-evidencias.md](./sdr-0002-imr-unidades-e-evidencias.md) (IMR assenta na arquitetura de medição) ## Consumidores (referenciam; não donos) - Proposta, `modelo-central-servicos.html`, DFD/ETP, TR. --- ## Agentes de conformidade (Cursor) Os três agentes abaixo aplicam-se à edição e à revisão dos arquivos `SDRs/sdr-*.md` (exceto `SDRs/templates/` e normas em `SDRs/governance/`). Este bloco é **informativo**; use o script na raiz do repositório para diagnóstico estrutural. | Agente | Regra Cursor | Norma em `SDRs/governance/rules/` | |--------|----------------|-------------------------------------| | Verificador de conformidade SDR | [`sdr-conformity-checker.mdc`](../.cursor/rules/sdr-conformity-checker.mdc) | [`sdr-conformity-checker.md`](./governance/rules/sdr-conformity-checker.md) | | Detector de implementação sem vínculo SDR | [`implementation-without-sdr-detector.mdc`](../.cursor/rules/implementation-without-sdr-detector.mdc) | [`implementation-without-sdr-detector.md`](./governance/rules/implementation-without-sdr-detector.md) | | Anti-vibecoding sem SDR | [`no-vibecoding-without-sdr.mdc`](../.cursor/rules/no-vibecoding-without-sdr.mdc) | [`no-vibecoding-without-sdr.md`](./governance/rules/no-vibecoding-without-sdr.md) | **Processo:** [`governance/README.md`](./governance/README.md) · **Rastreabilidade código:** [`traceability.md`](./traceability.md) · **Checagem:** `python scripts/check_sdr_conformity.py` (na raiz do repositório).