SDR-0001 — Arquitetura **contratual** dos três contratos (C1 / C2 / C3)

Página estática gerada a partir do Markdown do repositório — o texto abaixo já vem no HTML (adequado a importação por URL em ferramentas que não executam o ver-md.html). Arquivo: sdr-0001-arquitetura-tres-contratos.md

Baixar o .md — Abrir no visualizador Markdown — Catálogo de SDRs — Início do site

Fonte: SDRs/sdr-0001-arquitetura-tres-contratos.md

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/ e o glossário de eixos.

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-0002-imr-unidades-e-evidencias.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.

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.

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

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 §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 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.

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 e premissas §1.

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 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.

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 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 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 e correlatos).

10.3 Classificações (LGPD, criticidade, etc.)

Remeter a 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: outros sdr-*.md devem remeter, não recriar o mesmo bloco normativo.
  • Entre SDRs, aplicam-se REGRAS-AGENTE-E-PROMPTS.md e o sdr-0003.

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.

12.2 LGPD / privacidade

Não específico deste SDR — ver 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 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 §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 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)
  • [ ] 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)

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 sdr-conformity-checker.md
Detector de implementação sem vínculo SDR implementation-without-sdr-detector.mdc implementation-without-sdr-detector.md
Anti-vibecoding sem SDR no-vibecoding-without-sdr.mdc no-vibecoding-without-sdr.md

Processo: governance/README.md · Rastreabilidade código: traceability.md · Checagem: python scripts/check_sdr_conformity.py (na raiz do repositório).