Jurídico

1. Primeiro princípio: quem está sendo protegido?

Os dados, a continuidade e a autonomia do Cliente devem sobreviver a qualquer relação comercial.

A Control-C não está apenas licenciando software — está delegando custódia. Este acordo codifica esse dever para que ele sobreviva a mudanças de liderança, choques de mercado e boas intenções que se desgastam.

2. Definição do modelo de parceria (ancorar a forma)

2.1 White-Label Stewardship Partnership (WLSP)

Um White-Label Stewardship Partnership (WLSP) é uma relação em que:

• O Parceiro opera uma instância auto-hospedada da Control-C.
• O Parceiro controla o relacionamento comercial com os clientes finais.
• A Control-C mantém obrigações de supervisão custodial para proteger a sobrevivência do cliente.
• Os clientes podem integrar plataformas de terceiros (por exemplo Xero) sob autoridade delegada.

Essa definição evita reinterpretações futuras (“apenas revenda”, “apenas infraestrutura”).

3. Pacto de stewardship (núcleo ético)

3.1 Dever de stewardship

O Parceiro reconhece expressamente que:

• Atua como guardião dos dados, e não como proprietário, dos dados do Cliente.
• Seu papel inclui dever de diligência, continuidade e reversibilidade.
• A otimização comercial nunca deve comprometer materialmente:
  • Integridade dos dados
  • Recuperabilidade
  • Direitos de saída do cliente

3.2 Cláusula de primazia do cliente

Em qualquer conflito entre:

• Interesses comerciais do Parceiro
• Sustentabilidade da plataforma
• Sobrevivência dos dados do cliente

Prevalece a sobrevivência do cliente.

4. Controles técnicos e operacionais (onde os ideais viram realidade)

4.1 Requisitos de hospedagem e arquitetura

Parceiros devem:

• Executar a Control-C em infraestrutura documentada e reproduzível.
• Manter backups automatizados diários de:
  • Datastores da Control-C
  • Configuração
  • Material de criptografia (quando aplicável)
• Suportar exportação em formatos abertos e documentados (no mínimo dump de Postgres e schema).

A Control-C se reserva o direito de auditar diagramas de arquitetura, não apenas o código.

4.2 Governança de funcionalidades e integridade do produto

• A Control-C define uma matriz de capacidades (funcionalidades habilitadas e desabilitadas).
• O Parceiro não pode:
  • Remover ferramentas de saída do cliente
  • Ofuscar fluxos de recuperação
  • Representar incorretamente paridade de funcionalidades com as ofertas core da Control-C
• Qualquer customização deve:
  • Ser documentada de forma declarativa
  • Ser reversível sem perda de dados do cliente

5. Garantias de sobrevivência do cliente (o coração)

5.1 Direito à continuidade

Todo cliente final deve manter a capacidade de:

• Recuperar uma cópia completa e utilizável de seus dados.
• Reconectar-se a:
  • Outro parceiro da Control-C
  • Control-C direto
  • Um ambiente autogerenciado

Sem economia de “refém”.

5.2 Salvaguardas de escrow e transição

Parceiros devem concordar com um ou mais itens:

• Escrow de código (para extensões específicas do parceiro)
• Escrow criptografado de credenciais (para segredos de propriedade do cliente)
• Um caminho de recuperação “break glass” mantido pela Control-C

Disparado automaticamente em caso de:

• Insolvência
• Término de licença
• Descumprimento material
• Indisponibilidade prolongada do serviço

Sem atrasos discricionários.

6. Mudança de negócio e disposições de fim de vida

6.1 Mudança de controle

Se o Parceiro passar por aquisição, fusão, mudança de controle majoritária, ou pivot estratégico afastando-se de serviços de dados, deve:

• Notificar a Control-C com antecedência.
• Fornecer aos clientes opções claras de continuidade, prazos e caminhos de migração.

Silêncio é descumprimento.

6.2 Saída ou falha do parceiro

Em caso de término (voluntário ou involuntário):

• O Parceiro mantém o serviço por uma janela de transição definida (por exemplo 90 dias).
• A Control-C pode intervir para ajudar na migração e assumir controle custodial temporário apenas para proteger os clientes.
• Sem preços de resgate. Sem bloqueio por “serviços profissionais”.

7. Código de ética (curto, direto e exigível)

Parceiros concordam em:

1. Nunca colocar clientes em risco conscientemente por ganho de curto prazo.
2. Comunicar falhas cedo e de forma clara.
3. Preservar a reversibilidade em todas as decisões técnicas.
4. Evitar dark patterns, venda casada forçada ou fricção de saída.
5. Tratar os dados do cliente como confiança emprestada, não como ativo.

Quebrar este código de ética é quebrar este acordo.

8. Supervisão, auditoria e “direito de cuidado”

A Control-C mantém o direito de:

• Conduzir revisões periódicas de stewardship.
• Solicitar evidências de:
  • Integridade de backups
  • Exercícios de restauração
  • Prontidão de resposta a incidentes
• Intervir somente para proteger clientes, não para competir.

9. Declaração de intenção

Esta parceria existe para garantir que empresas que dependem de sistemas digitais nunca sejam abandonadas por eles. Sucesso comercial é bem-vindo. Abandono do cliente não é.

10. O que este framework faz sem dizer

Sem declarar isso abertamente, este framework:

• Filtra parceiros de má-fé desde o início.
• Força maturidade operacional.
• Faz da Control-C o centro de gravidade ético.
• Posiciona a Control-C como infraestrutura de continuidade, não de conveniência.

11. Linhagem da plataforma, stewardship de atualizações e continuidade central

11.1 Replicação de continuidade central (não negociável)

Todas as instâncias hospedadas pelo Parceiro devem suportar replicação segura e automatizada para um Datastore Central de Continuidade gerenciado pela Control-C.

Propriedades principais:

• Somente leitura para a Control-C em operação normal.
• Criptografia em trânsito e em repouso.
• Escopo:
  • Dados do cliente
  • Metadados
  • Índices de recuperação
  • Provas de integridade (hashes, manifestos)

Esse datastore existe exclusivamente para:

• Validar recuperabilidade.
• Viabilizar cenários de sobrevivência do cliente.
• Fornecer verificação independente dos backups.

Não é análise. Não é monetização. Não é vigilância.

11.2 Replicação como condição de licença

O Parceiro reconhece que:

• A replicação central é condição da licença white-label.
• Desativar ou degradar materialmente a replicação:
  • Exige aprovação por escrito.
  • Deve ser limitada no tempo.
  • Deve incluir notificação ao cliente se prolongada.

Falha silenciosa é descumprimento material.

12. Atualização de software e integridade operacional

12.1 Compromisso de versão suportada

Parceiros devem operar apenas em releases da Control-C atualmente suportados, dentro do desvio permitido (no máximo N-2).

A Control-C define:

• Prazos de fim de suporte.
• SLAs de patches de segurança.
• Janelas obrigatórias de upgrade para correções críticas.

Rodar software obsoleto é tratado como risco de continuidade do cliente, não como preferência técnica.

12.2 Modelo de responsabilidade por atualizações (linhas claras)

12.3 Operabilidade e sinalização de saúde

Parceiros devem expor telemetria básica de saúde, incluindo:

• Disponibilidade (uptime)
• Sucesso de jobs
• Frescor dos backups
• Reporte de versão
• Status de replicação

Esses sinais podem ser via API, push ou pull, leves, mas devem existir.

13. Direito de assistência (cláusula de dever de cuidado)

13.1 Direito de remediação assistida

Se uma instância do Parceiro estiver falhando na replicação, criticamente desatualizada, não operável, ou colocando a continuidade do cliente em risco, a Control-C poderá:

• Notificar o Parceiro.
• Oferecer assistência direta.
• Exigir um plano de remediação com prazos.

Sem resolução, a Control-C poderá aplicar uma intervenção protetiva limitada estritamente a restaurar a operabilidade ou viabilizar a transição do cliente.

Não é uma cláusula de tomada de controle. É uma cláusula de dever de cuidado.

14. Continuidade da plataforma na saída do parceiro

Em caso de encerramento ou falha do Parceiro:

• O Datastore Central de Continuidade torna-se a referência autoritativa de recuperação.
• A Control-C poderá:
  • Validar o último estado “bom” conhecido.
  • Ajudar no re-homing do cliente.
  • Reconstituir ambientes quando contratualmente necessário.

Clientes não começam do zero.

15. Por que isso fecha o ciclo de stewardship

Estas cláusulas protegem três camadas simultaneamente:

1. Sobrevivência do cliente
2. Integridade da plataforma ao longo do tempo
3. Confiança do ecossistema (parceiros, reguladores, plataformas upstream como a Xero)

Continuidade não é só dados. É a continuidade do cuidado.