Ir para o conteúdo

Especificação de uma estratégia sistemática

Documento versionado que torna uma estratégia implementável e verificável: hipótese, dados, sinais, carteira, ordens, custos, controles e critérios decisórios.

Para quem é esta página — Para quem precisa transformar uma ideia em regras que outra pessoa ou outro programa consiga implementar, testar e supervisionar sem adivinhar a intenção do autor.

A especificação de uma estratégia sistemática é o documento versionado que descreve a estratégia antes da avaliação: finalidade, hipótese, informações permitidas, transformações, sinais, posições, risco, ordens, custos, benchmark, controles e critérios de revisão. Ela funciona como contrato de pesquisa, interface entre pesquisa e produção e trilha de auditoria.

“Comprar o rompimento com volume” não é uma especificação. Permanecem indefinidos universo, calendário, ajustes, janela, inclusão da barra corrente, horário do cálculo, primeiro preço executável, tamanho, saída, gaps e dados ausentes. Cada ambiguidade permite introduzir retrospectivamente no backtest uma decisão que não existiria em tempo real.

Especificação de uma estratégia sistemáticaAs coordenadas necessárias para tornar uma regra reproduzível. Checklist estrutural, não modelo universal nem recomendação operacional.Especificação de uma estratégia sistemáticaAs coordenadas necessárias para tornar uma regra reproduzívelChecklist estrutural, não modelo universal nem recomendação operacional.Finalidade euniversoObjetivo,instrumentospermitidos, exclusõese disponibilidadehistórica.RelógioinformativoTimestamp, timezone,calendário e primeiroinstante utilizável.SinalInputs,transformações,parâmetros e direçãoda medida.Posição etamanhoDo sinal ao alvo comrestrições,alavancagem e riscodeclarados.Ordens e fillsTipo, validade,prioridade, atrasos egestão dos fillsparciais.Custos ecapacidadeComissões, spread,slippage, impacto,borrow e fundingpertinentes.Métricas ebenchmarksUnidade, frequência,capital e comparaçãocoerente com oobjetivo.Versão eparadaResponsável, changelog, limites,suspensão e rollback.Cyclepedia · esquema educacional condicionado, não previsão nem promessa
Uma especificação completa conecta a decisão econômica aos eventos observáveis e às ações realmente executáveis.

Blocos mínimos

Bloco Conteúdo verificável Pergunta de revisão
Finalidade e uso previsto decisão apoiada, usuários, frequência e limites o que o sistema não deve fazer?
Hipótese mecanismo, previsão falsificável e condições de falha qual alternativa explica o mesmo resultado?
Universo inclusão, exclusão, composição histórica e data efetiva aparecem apenas os sobreviventes atuais?
Dados fonte, campo, timestamp, timezone, lag, revisão e versão o valor era conhecido na decisão?
Sinal fórmula, janela, estado, missing e ordem dos eventos existem ramos indeterminados?
Carteira mapeamento sinal–posição, restrições, netting e rebalanceamento qual exposição realmente domina?
Risco limites, cenários, sizing, escalonamento e fail-safe o que ocorre se um input ou limite falhar?
Execução tipo de ordem, venue, timing, fill, borrow, funding e custos o preço simulado era alcançável?
Avaliação benchmark, métricas, splits, tentativas e critério decisório o teste final influencia a escolha?
Monitoramento responsável, limites motivados, alertas, suspensão e rollback quem decide e com qual evidência?

Os campos podem estar em texto, configuração e código, desde que sejam reconciliáveis. As unidades precisam ser explícitas: percentual do capital, nocional, volatilidade, delta, moeda e frequência não são intercambiáveis.


O relógio causal

informação disponível → sinal calculado → ordem enviada → fill possível

“Preço de fechamento do dia” não basta. O fechamento oficial pode ser conhecido apenas depois do leilão; um fundamento pode se referir a um trimestre e ser publicado semanas depois; uma série macro pode ser revisada. Se o sinal usa o close e o backtest compra no mesmo close, é necessária uma mecânica explícita que permita participar do leilão com a informação exigida. Sem ela, o primeiro preço posterior é mais coerente, mas também precisa modelar gaps e custos.

Para cada input, são úteis a data econômica, a publicação inicial e a versão/vintage usada. Para cada ordem, registram-se estado, timestamp, quantidade solicitada e executada, preço e motivo de rejeição ou cancelamento.


Estados e exceções

Uma estratégia real não vive apenas no ramo “sinal presente → ordem executada”. A especificação determina o que ocorre quando um dado falta ou atrasa; um instrumento é suspenso, delistado ou muda de identificador; um futuro entra na janela de rolagem; o empréstimo de títulos não existe ou custa demais; a ordem é parcial, rejeitada ou permanece aberta; preço, posição, margem ou P&L não reconciliam; ou o controle de risco e a conexão com a corretora falham.

“Não fazer nada” só é uma regra completa quando define o estado resultante: manter, reduzir ou liquidar a posição ou bloquear novas ordens geram riscos diferentes.


Protocolo de pesquisa associado

Antes de observar o resultado usado na decisão, registram-se:

  1. pergunta e hipótese falsificável;
  2. versão da especificação e repositório do código;
  3. dataset, período e universo;
  4. baseline e benchmark coerentes;
  5. métricas primárias e secundárias, brutas e líquidas;
  6. desenho in-sample, validação e teste final;
  7. conjunto de parâmetros ou modelos candidatos;
  8. premissas de custo, liquidez e capacidade;
  9. critério para continuar, alterar ou descartar;
  10. registro de todos os testes, inclusive os negativos.

O critério não precisa ser um único limiar. Pode exigir coerência econômica, sinal estável em vários segmentos, incerteza aceitável, materialidade líquida e ausência de dependência de um único ponto. O rigor acompanha o uso: uma ferramenta exploratória interna e uma estratégia que move capital têm consequências diferentes.


Versões, reprodutibilidade e replicação

Cada resultado deve identificar commit ou release, configuração, ambiente, dependências, seeds, versão do dataset e saída. Snapshot ou hash ajuda a provar que o input não mudou. Reexecutar o mesmo código nos mesmos dados trata de reprodutibilidade; encontrar evidência coerente em realização independente trata de replicação. São propriedades próximas, não equivalentes.

Quando um teste out-of-sample provoca uma mudança, nasce nova versão. O segmento consultado não volta a ser intacto: deve ser registrado como informação de desenvolvimento. Essa genealogia impede que iterações acumulem data snooping invisível.

Separar funções pode fortalecer a revisão, mas “independente” não significa necessariamente externo. Significa que quem questiona premissas, implementação e uso tem competência, autoridade e incentivos para contestar o resultado.


Exemplo: sinal no fim do dia

Uma especificação hipotética usa apenas dados consolidados até o fechamento de t, calcula o sinal após receber os arquivos finais e permite enviar ordens somente a partir da abertura de t+1. O universo preserva a composição histórica; instrumentos não negociáveis geram exceção; a quantidade respeita participação e concentração; e o custo depende de spread e volume.

O exemplo não diz que a abertura seguinte é sempre correta. Ele mostra como tornar a causalidade auditável. Participar do leilão de fechamento exigiria sinais calculáveis antes do cutoff e execução coerente com aquele leilão.


Critérios de qualidade

  • Um implementador independente não precisa inventar regra ausente.
  • Cada variável possui definição, unidade, timestamp e comportamento em missing.
  • Os resultados remetem a uma versão imutável.
  • Premissas de backtest e produção podem ser comparadas linha a linha.
  • Exceções conduzem a estados seguros e observáveis.
  • Limites se ligam a risco, capacidade ou uso previsto, não a números decorativos.
  • Toda mudança material reabre as verificações afetadas.

A especificação não elimina o risco de modelo. Ela torna as escolhas visíveis e permite separar erro de pesquisa, implementação e uso.


Fontes

Conexões