Contratos.
O que cada capacidade promete, por escrito e versionado.
Cada capacidade sob contrato.
Cada demanda respondida contra ele.
O AugIQ mantém um modelo escrito e versionado do que cada capacidade promete — e responde cada nova demanda contra esse modelo. Já coberta. Coberta por configuração. Ou aqui está exatamente o que seria necessário.
Ver o AugIQPodemos atender um parceiro que financia suas próprias promoções?
Documentos de estratégiaRoadmapJiraConfluenceCRMHistórico de entregas
Initial assessment
Pricing e promoção
Financiamento do parceiro
Liquidação
1 ruptura de contrato2 opções viáveis
A demanda chega toda semana. A capacidade muda a cada trimestre.
Ninguém está medindo a diferença.
Contexto.
Estratégia, roadmap, histórico de entrega e demanda de clientes em um único modelo.
Deltas.
A diferença exata entre o que está sendo pedido e o que foi prometido.
Prova.
Evidência de que a capacidade funciona, não apenas de que o trabalho foi entregue.
O AugIQ transforma demanda recebida em decisões com escopo, antes que ela vire trabalho sob medida.
Nada é construído duas vezes.
Demandas recorrentes são reconhecidas como recorrentes, entre mercados e times.
Nada chega como surpresa.
Cada pedido encontra um lugar específico em uma promessa já escrita.
Nada é assumido sem o trade-off sobre a mesa.
O que avança, o que espera e do que depende — antes da reunião, não depois.
Sensoriamento aberto. Compromisso governado.
Qualquer pessoa pode perguntar o que algo exigiria. A realidade chega primeiro a quem está mais perto dos clientes; obrigá-los a preencher um formulário é como as organizações permanecem ignorantes.
Comprometer o trimestre é outro ato. Alocar recursos, mudar uma promessa ao cliente ou mover a direção arquitetural continua explícito, com responsável e auditável.
01
Perguntar
Open
02
Levantar um sinal
Open
03
Redigir uma demanda
Open
04
Patrocinar
Sponsored
05
Marcar como pronta para decisão
Sponsored
06
Comprometer recursos
Restricted
07
Mudar o contrato
Restricted
Cada resposta carrega suas fontes, premissas, nível de confiança e a versão do contrato usada no raciocínio. É possível discordar e ver precisamente onde discordar.
O AugIQ prepara o julgamento. Não substitui a autoridade.
Quatro números, definidos antes de começar.
Não temos uma década de benchmarks. Temos um placar que estamos dispostos a publicar antecipadamente — a parte que a maioria das firmas evita.
- 01Parcela da demanda recebida atendida sem novo desenvolvimento de produto.
- 02Tempo entre sinal e decisão.
- 03Demandas duplicadas identificadas antes de serem construídas duas vezes.
- 04Tempo para integrar um novo parceiro ou mercado, comparando o primeiro ao seguinte.
Medidos desde o primeiro trabalho, publicados favoreçam-nos ou não.
Uma capacidade, mostrada como deve ser.
Um contrato para a capacidade de pricing e promoção: o que promete, as situações que atende, o padrão que sustenta e a linha onde termina. Depois, uma demanda que cai exatamente nessa linha e o delta resultante — em regras, modelo operacional, produto, dados e pessoas.
Capability contract · v1.4
Pricing & promotion
Plataformas Comerciais
Latência de decisão · 4 dias
Promise
Suportar promoções financiadas por fabricantes entre parceiros, com regras explícitas de elegibilidade, aprovação e liquidação.
Boundary
Termina quando o parceiro exige uma lógica de financiamento que não pode ser expressa pelo conjunto governado de regras.
Demand on the boundary
Atender um parceiro que financia suas promoções com janelas de liquidação específicas por mercado.
Regras · adicionar hierarquia de financiadorModelo operacional · definir responsável pela liquidaçãoProduto · estender configuraçãoDados · evidenciar origem dos recursosPessoas · aprovar rota de exceção
Quatro dessas cinco dimensões não têm relação com software. Por isso, a versão entregue apenas como funcionalidade nunca se sustentaria.
Ver o exemplo completoO que o AugIQ faz com uma demanda.
01 / Product surface
Conectar.
Estratégia, roadmap, entrega e sinais de clientes em um modelo de capacidades.
02 / Product surface
Testar.
Executar qualquer demanda contra o que a capacidade promete hoje.
03 / Product surface
Decidir.
Opções, dependências, trade-offs e o que muda se houver compromisso.
04 / Product surface
Provar.
Cenários que demonstram que a capacidade se sustenta em condições reais.
O modelo não se constrói sozinho.
A Cinquelli arquiteta o sistema de capacidades: o que a organização deve ser capaz de prometer, como as capacidades se estruturam e o que precisa convergir para cada uma se sustentar. O AugIQ o mantém verdadeiro enquanto novas demandas chegam.
A maioria dos trabalhos começa com uma capacidade — normalmente aquela da qual todo o resto passou a depender.
O métodoO Padrão de Contrato de Capacidade
Uma especificação aberta para registrar o que uma capacidade promete. Gratuita, citável e utilizável sem nós.
As definições dos campos. As regras para versionar uma promessa. Como escrever uma situação para que possa ser testada, não discutida. Três contratos completos de diferentes tipos de capacidade. E os erros que tornam um contrato inútil — inclusive os que já cometemos.
Organizações já fazem uma versão ruim disso em registros de decisão arquitetural, critérios de aceitação e na cabeça de duas pessoas seniores. O padrão lhe dá forma.
Ler o padrãoTraga uma decisão que está prestes a tomar.
Algo que seu time está perto de assumir — um parceiro, um mercado, um grande cliente, uma mudança regulatória. Colocaremos sob contrato a capacidade sobre a qual ela recai e mostraremos o que realmente seria necessário.
Ver o AugIQO modelo que se mantém honesto.
Todo modelo de capacidades que sua organização construiu era preciso no dia em que ficou pronto. O do AugIQ é mantido pelo fluxo de demanda real: cada pergunta feita contra ele o deixa mais preciso do que antes.
Um grafo, não onze documentos.
A estratégia e suas prioridades. As capacidades e o que cada uma promete. Os domínios e componentes de que são feitas. As regras de negócio, o modelo operacional, os sistemas, os dados e as pessoas de que dependem. Quem responde pelo quê.
O que foi assumido, o que foi entregue, quanto custou e se funcionou.
Guardado como relações, não como páginas, para que uma pergunta sobre uma parte possa ser rastreada por todas as outras.
Uma pergunta, rastreada
Podemos atender um parceiro que financia suas próprias promoções?
- 01Atribuição de financiamento
- 02Modelo de principal
- 03Regras de promoção
- 04Integração financeira
- 05Dados de liquidação
- 06Time responsável
- 07Dois itens do roadmap se movem
Cinco respostas, cada uma com seu raciocínio anexado.
Já suportado.
O contrato cobre. Siga.
Suportado por configuração.
Nenhuma construção — e aqui está quem faz.
Parcialmente suportado.
Esta parte já foi prometida. Esta não.
Não suportado.
Aqui está o delta: no que a promessa precisa se tornar, o que muda na arquitetura e na pilha, quem responde, do que depende e qual trabalho já assumido se move.
Em conflito.
Isto contradiz uma regra, um princípio arquitetural ou uma decisão já registrada.
Cada resposta carrega suas fontes, premissas, confiança e a versão do contrato usada no raciocínio. Você pode discordar e ver exatamente onde discordar.
O quarto mercado a relatar um problema não deveria ser o primeiro a ser acreditado.
Qualquer pessoa pode registrar o que está vendo — uma conversa com cliente, um negócio perdido, um padrão de suporte, uma carta do regulador. O AugIQ compara isso com tudo o que já está no modelo: pedidos anteriores, outros mercados, contratos existentes, histórico de entregas.
Uma queixa local vira um achado estrutural. Quatro mercados relatando o mesmo problema de cadastro deixam de ser quatro tickets e viram uma pergunta de capacidade, antes de virarem quatro construções.
Prontidão
Observado
Contextualizado
Qualificado
Pronto para decisão
Assumido
Sinais avançam por estágios de prontidão, para que o backlog deixe de ser onde as ideias vão para ser esquecidas.
Um problema válido não é automaticamente uma prioridade.
Uma lacuna real de capacidade ainda precisa conquistar o trimestre contra todas as outras lacunas reais. O AugIQ expõe quanto vale cada opção, o que reaproveita, o que bloqueia, quanto custa, que risco carrega, quão reversível é e qual a confiança em tudo isso.
Uma decisão, registrada, com seu raciocínio
AssumirRodar uma descobertaAgruparResolver por configuraçãoExceção deliberadaAdiar ou recusar
Pedido de cliente não significa automaticamente requisito de produto.
Incrementos coerentes — e evidência de que se sustentaram.
O trabalho assumido sai do AugIQ como incremento de capacidade — uma expansão utilizável da promessa, com dependências, responsáveis e sequência — e não como um punhado de tickets que compartilham um rótulo.
Cada incremento carrega os cenários que o provariam, escritos antes de o trabalho começar. Quando passam, o contrato avança para a próxima versão, com responsável e data. Quando não passam, isso também fica visível.
Sensoriamento aberto. Compromisso governado.
O acesso é largo embaixo e estreito em cima: qualquer pessoa pode perguntar e registrar, menos pessoas podem patrocinar, menos ainda podem marcar algo como pronto para decisão, e só a autoridade certa pode comprometer recursos ou mudar o que uma capacidade promete.
01
Perguntar
Aberto
02
Registrar um sinal
Aberto
03
Redigir uma demanda
Aberto
04
Patrocinar
Patrocinado
05
Marcar como pronta para decisão
Patrocinado
06
Comprometer recursos
Restrito
07
Mudar o contrato
Restrito
Toda conclusão consequente guarda sua evidência, suas premissas, seu responsável e sua confiança. O AugIQ prepara o julgamento; não substitui a autoridade.
Adjacente a várias coisas. Igual a nenhuma delas.
Não é um repositório de arquitetura.
Esses guardam um inventário que alguém precisa manter. Aqui se guardam promessas que a demanda testa continuamente.
Não é uma ferramenta de roadmap.
Roadmaps sequenciam trabalho. Aqui se decide qual deve ser o trabalho — e por que esse e não outro.
Não é um sistema de portfólio ou OKR.
Esses acompanham se você fez o que disse. Aqui se responde se você consegue fazer o que está prestes a dizer.
Não é um assistente de conhecimento.
Esses recuperam o que está escrito. A maior parte do que importa aqui nunca foi escrita — por isso o modelo precisa ser construído antes de ser consultado.
O modelo não se constrói sozinho.
A Cinquelli arquiteta o sistema de capacidades. O AugIQ o mantém verdadeiro enquanto a demanda continua chegando.
O métodoO Padrão de Contrato de Capacidade
Uma especificação aberta para registrar o que uma capacidade promete. Versão 1.0. Livre para usar, adaptar e citar — inclusive por nossos concorrentes.
Toda organização já faz uma versão disto, mal feita — em registros de decisão de arquitetura, em critérios de aceite, na cabeça de duas pessoas sêniores que estão sempre na sala. O padrão dá forma a isso.
O que é um contrato de capacidade.
Um contrato de capacidade é a especificação explícita e versionada do que se espera que uma capacidade atenda, sob quais condições, em qual padrão, com quais garantias e restrições. É escrito para uma capacidade, não para um sistema, e independe da tecnologia que hoje a implementa.
Não é um documento de requisitos, porque descreve o que precisa permanecer verdadeiro, e não o que será construído. Não é um diagrama de arquitetura, porque nada diz sobre o como. Está mais próximo, em espírito, de um contrato de interface em software, elevado ao nível em que um negócio assume compromissos.
O que todo contrato precisa dizer.
Por que existe?
Propósito e resultados
Para que serve a capacidade e quais resultados de negócio dependem dela. Uma ou duas frases. Se leva um parágrafo, provavelmente são duas capacidades.
Quem depende disto?
Consumidores
As pessoas, times, sistemas e outras capacidades que dependem desta promessa. Nomeados. Um consumidor que não sabe que está nesta lista é uma indisponibilidade esperando para acontecer.
Onde ela se mostra?
Situações
Situações reais ou realistas que a capacidade precisa atender, preservando decisões, restrições, envolvidos, prazos e consequências que as tornam difíceis. Não são histórias de usuário. Não são abstrações.
O que precisa fazer?
Comportamento e saídas exigidos
O que a capacidade faz com essas situações e o que precisa produzir. Descrito de modo que alguém de fora do time consiga dizer se aconteceu.
O que nunca pode quebrar?
Invariantes
O que precisa permanecer verdadeiro em toda variação suportada. São as restrições que transformam uma capacidade flexível em uma capacidade confiável.
Quão bem, e quando?
Padrões e condições
A precisão, a velocidade, a qualidade, o custo ou o resultado exigidos — e as circunstâncias em que ainda precisam valer: carga, ambiguidade, informação incompleta, pressão de tempo, envolvidos em conflito.
Onde termina?
Exclusões
O que a capacidade deliberadamente não suporta. Obrigatório. Um contrato sem exclusões é um desejo.
Como saberíamos?
Prova
As situações que demonstrariam que a capacidade se sustenta e o padrão de evidência exigido. Escritas antes do trabalho, não depois.
As regras que mantêm a promessa honesta.
- 01
Uma situação não é um requisito.
É algo que aconteceu ou poderia acontecer, com atores, restrições e consequências intactos. Se pode ser satisfeita por uma tela, não é uma situação.
- 02
Exclusões são obrigatórias.
O valor de um contrato está quase todo concentrado no que ele recusa. Um contrato do qual nada pode ficar de fora é vago demais para ser testado.
- 03
Condições fazem parte da promessa.
Um padrão sem condições é uma afirmação sobre um dia bom.
- 04
Responsabilidade é uma pessoa.
Não um time, não uma função. Alguém precisa poder dizer sim a uma mudança no que se promete.
- 05
Versione a promessa, não o software.
Um release que não muda nada do que é prometido não muda a versão do contrato. Uma mudança de configuração que amplia a promessa muda.
- 06
Três tipos de mudança.
Um esclarecimento não altera a promessa. Uma extensão adiciona situações sem alterar as existentes. Uma ruptura estreita, remove ou altera algo já prometido — e exige avisar cada consumidor nomeado.
- 07
A prova precede o compromisso.
Se a evidência que o satisfaria for escrita depois do trabalho, será escrita para caber no trabalho.
Como é uma promessa escrita.
Uma capacidade comercial, em que a promessa é sobre regras e dinheiro. Uma capacidade operacional, em que a promessa é sobre vazão sob carga. E uma capacidade de julgamento — a mais difícil de contratar e a que a maioria das organizações finge não ter.
Comercial
Pricing e promoção
- Versão
- v1.4
- Responsável
- Diretor de Plataformas Comerciais
- Vigência
- 2026-03-12
- Propósito e resultados
- Permitir que times comerciais executem mecânicas governadas de preço e promoção entre parceiros e mercados sem desenvolvimento sob medida. Previsibilidade de receita, controle de margem e satisfação de parceiros dependem disso.
- Consumidores
- Times comerciais de mercado
- Operações de parceiros
- Liquidação financeira
- Vitrine ao cliente
- Reporte de receita
- Situações
- 01Um fabricante financia uma promoção para um parceiro em dois mercados com janelas de liquidação diferentes, e o financeiro precisa atribuir o financiamento à origem correta em cada um.
- 02Um parceiro pede um desconto exclusivo que se sobrepõe a uma campanha existente, três dias antes do lançamento, sem capacidade de engenharia disponível.
- 03Um regulador restringe um tipo de promoção em um mercado enquanto a mesma mecânica continua válida em outros quatro.
- Comportamento e saídas exigidos
- Configurar, aprovar, publicar, monitorar e liquidar uma promoção, produzindo registro auditável de quem financiou, quem aprovou, quais clientes eram elegíveis e quanto custou.
- Invariantes
- — Toda promoção tem origem de financiamento atribuível.
- — Nenhum cliente vê um preço que nunca foi aprovado.
- — Os valores de liquidação reconciliam com a mecânica aprovada.
- Padrões e condições
- Uma nova promoção de mecânica suportada entra no ar em até dois dias úteis, incluindo aprovação, e se sustenta sob volume de fim de trimestre e campanhas sobrepostas.
- Exclusões
- — Lógica de financiamento que não caiba no conjunto governado de regras.
- — Ramificações de código específicas por mercado.
- — Reprecificação retroativa de transações liquidadas.
- Prova
- As três situações nomeadas executadas de ponta a ponta em ambiente equivalente ao de produção, com liquidação reconciliada e registro de auditoria completo.
Operacional
Onboarding de parceiros
- Versão
- v2.1
- Responsável
- Head de Operações de Parceiros
- Vigência
- 2026-02-04
- Propósito e resultados
- Levar um parceiro aprovado da assinatura à primeira transação válida por um caminho repetível. Tempo até a receita e custo de expansão dependem disso.
- Consumidores
- Times comerciais
- Jurídico e compliance
- Engenharia de integração
- Suporte
- Gerentes gerais de mercado
- Situações
- 01Onze parceiros entram simultaneamente no fim do trimestre, com dois especialistas de integração de férias.
- 02Um parceiro regulado entra com exigências adicionais de verificação e residência de dados inexistentes em qualquer onboarding anterior.
- 03Um parceiro fornece dados mestres incompletos e quer lançar em nove dias para um pico sazonal.
- Comportamento e saídas exigidos
- Verificar, configurar, integrar, testar e ativar um parceiro, produzindo um registro assinado de prontidão que nomeia as exceções concedidas e quem as concedeu.
- Invariantes
- — Nenhuma ativação sem identidade e situação fiscal verificadas.
- — Toda exceção tem aprovador nomeado.
- — Restrições de residência de dados são aplicadas antes de qualquer transação.
- Padrões e condições
- Mediana de vinte dias úteis da assinatura à primeira transação válida, sustentada com até quinze onboardings simultâneos e até trinta por cento dos dados mestres chegando incompletos.
- Exclusões
- — Parceiros que exijam protocolo de integração sob medida.
- — Ativação antes de nomear responsáveis pela evidência e autoridade de exceção.
- — Migração do histórico de transações do parceiro.
- Prova
- Três onboardings consecutivos concluídos dentro do padrão sob carga simultânea, incluindo um parceiro regulado, com registros de prontidão completos.
Julgamento
Compromisso de portfólio
- Versão
- v1.0
- Responsável
- Diretor de Operações
- Vigência
- 2026-01-20
- Propósito e resultados
- Transformar demanda qualificada em compromissos com recursos que a organização consiga defender três trimestres depois. Coerência estratégica e credibilidade do plano dependem disso.
- Consumidores
- Comitê executivo
- Liderança de produto e engenharia
- Liderança de mercado
- Planejamento financeiro
- Os times cujo trabalho é deslocado
- Situações
- 01Três mercados patrocinam a mesma demanda com palavras diferentes, enquanto uma mudança regulatória já assumida consome um quinto da capacidade.
- 02O maior cliente escala uma exigência que duplica uma construção sob medida entregue para outro cliente dezoito meses antes.
- 03Uma decisão precisa ser tomada com estimativa de custo materialmente incompleta e prazo externo rígido.
- Comportamento e saídas exigidos
- Produzir uma decisão de registro — assumir, descobrir, agrupar, configurar, exceção deliberada, adiar ou recusar — com opções, deslocamento, dependências, reversibilidade, confiança e autoridade nomeada.
- Invariantes
- — Nenhum compromisso sem deslocamento declarado.
- — Toda decisão registra sua confiança e suas premissas.
- — Demanda duplicada é reconhecida antes da alocação, não depois.
- Padrões e condições
- Uma demanda pronta para decisão chega a uma decisão registrada em até dez dias úteis, inclusive com estimativas incompletas e patrocinadores em desacordo.
- Exclusões
- — Decidir sem autoridade responsável nomeada.
- — Compromissos cujo deslocamento é desconhecido.
- — Redecidir um compromisso vigente fora do ponto de revisão acordado.
- Prova
- Um trimestre de decisões revisado contra o resultado: deslocamento conforme declarado, nenhuma construção duplicada e níveis de confiança compatíveis com o que de fato aconteceu.
Todos os exemplos são genéricos. Nenhuma empresa, parceiro ou empregador é nomeado.
Onde os contratos falham em silêncio.
Uma lista de funcionalidades vestida de contrato.
Se cada linha descreve algo construído em vez de algo prometido, nada mudou além do nome do arquivo.
Nenhuma exclusão.
Em geral porque nomeá-las pareceu admitir fraqueza. É o oposto: uma capacidade que promete tudo não garante nada.
Adjetivos no lugar de padrões.
Rápido. Preciso. Fluido. Nenhum deles pode reprovar em um teste.
Situações escritas de dentro.
Se a situação só faz sentido para quem já conhece o sistema, ela só será testada por quem já sabe a resposta.
Versionamento que segue releases.
O contrato passa a descrever a história do software, não os compromissos da organização.
Um contrato que ninguém mantém.
De longe a falha mais comum — e a razão de isto ser um padrão, não um template. Uma promessa que não é testada pela demanda que chega vira um documento em dois trimestres.
Pegue e use.
Pegue uma capacidade da qual vários times dependem e que recentemente surpreendeu vocês. Escreva o contrato dela como é hoje, não como você gostaria que fosse. Depois pegue os três últimos pedidos que o time assumiu e leia-os contra o contrato.
Se os três caírem dentro do contrato, ele é vago demais. Se os três caírem fora, a capacidade nunca foi realmente definida. Em algum ponto entre os dois começa a conversa útil.
O template, as definições de campo e os três exemplos trabalhados estão aqui. Atribuição é bem-vinda, não obrigatória.