Dicionário de Dados e Estrutura do Banco Científico AT.RFG2P

Este documento transforma o Protocolo Científico ATB3 — AT.RFG2P v1.0 em uma estrutura operacional de dados. O objetivo é criar uma base que permita responder, de maneira rastreável, perguntas como: qual ativo foi analisado, em qual data, qual era o preço disponível no momento da projeção, quais foram os níveis 1P a 9P, qual tolerância foi utilizada, o nível foi atingido, houve toque/rejeição/rompimento, quanto tempo demorou, qual era a volatilidade e o regime de mercado, qual versão do método gerou o resultado e se o resultado pertence à amostra de desenvolvimento ou à validação fora da amostra.

A base deverá permitir que um terceiro reconstrua o experimento sem depender de interpretação subjetiva.

A unidade fundamental do banco será a combinação ativo + data + nível + experimento. Exemplo: PETR4 + 22/09/2025 + 3P + EXP-001. Uma observação não é apenas "PETR4 acertou" — ela é uma observação completa, rastreável e auditável.

A estrutura recomendada é dividida em 8 camadas, para evitar misturar dado bruto → cálculo → resultado → estatística:

1. Identificação
2. Dados de mercado
3. AT.RFG2P
4. Eventos / resultados
5. Contexto de mercado
6. Metadados
7. Auditoria
8. Estatística

Cada registro deverá possuir um observation_id no formato ATB3-DATA-ATIVO-NÍVEL-EXPERIMENTO. Exemplo: ATB3-20250922-PETR4-3P-EXP001. Esse identificador deverá ser único.

Esta é a principal tabela científica.

A base final deverá permitir consultar os níveis em formato de tabela horizontal (ativo × data × 1P…9P), mas para análise científica a estrutura principal deverá ser vertical — uma linha por nível, ex.: PETR4 | 22/09/25 | 1P, PETR4 | 22/09/25 | 2P ... Isso facilita análises estatísticas.

Não basta registrar acertou/errou — também é preciso armazenar a distância entre o preço observado (P) e o nível projetado (L), em valor absoluto e em percentual. Isso permite análises muito mais sofisticadas.

A tolerância é armazenada individualmente em tolerance_value (ex.: 0,00 / 0,01 / 0,05 / 0,10) e em tolerance_rule (REGRA_A / B / C / D). Isso permite comparar diferentes especificações sem apagar o resultado original.

Cada experimento deverá possuir window_start e window_end — essencial para definir quando um nível poderia ser considerado atingido.

Cada cálculo deverá registrar method_version (ex.: AT.RFG2P-v1.0). Resultados de versões diferentes não deverão ser misturados silenciosamente.

Também será registrado protocol_version (ex.: ATB3-PROTOCOL-v1.0), para saber exatamente sob qual regra cada resultado foi produzido.

Campo sample_type, com valores IN_SAMPLE, OUT_OF_SAMPLE, VALIDATION ou ROBUSTNESS.

Campo market_regime: BULL, BEAR, SIDEWAYS, HIGH_VOLATILITY, LOW_VOLATILITY, CRISIS ou UNKNOWN. Essa classificação deverá possuir metodologia própria — não é permitido classificar um período como "bull" ou "bear" apenas porque o resultado do AT.RFG2P foi melhor ou pior.

A base deverá armazenar as medidas de volatilidade utilizadas: retorno, volatilidade histórica e, quando aplicável, ATR, volatilidade realizada, desvio-padrão e volatilidade intradiária. Cada métrica com seu próprio campo.

Campo gap_pct, calculado a partir da abertura vs. fechamento anterior. O tratamento de gaps deverá ser definido previamente em cada experimento.

Cada registro deverá possuir created_at, updated_at, created_by, calculation_id e, quando tecnicamente possível, data_hash — para impedir que resultados sejam alterados sem rastreabilidade.

Cada artigo deverá ter seus experimentos registrados na tabela experiments.

A estatística agregada não substitui os dados individuais — ela é derivada deles.

robustness_tests — exemplos: ROB-001 (tolerância 0,00) até ROB-004 (tolerância 0,10), ROB-005 (exclusão de baixa liquidez), ROB-006/007 (setor financeiro/energia), ROB-008/009 (mercado de alta/baixa), ROB-010 (out-of-sample).

Arquitetura final: ATB3_DATABASE com as tabelas assets, market_data, experiments, observations, events, market_regimes, method_versions, protocol_versions, articles, statistical_results, robustness_tests e audit_log.

Artigos → Experimentos → Observações → (Ativos, Dados de Mercado, Eventos, Versão AT.RFG2P, Versão do Protocolo) → Resultados → Robustez.

A base deverá separar claramente quatro camadas — nunca substituir o dado original pelo resultado calculado:

O banco deverá rejeitar: registro sem ativo, sem data ou sem nível; nível diferente de 1P–9P; observação duplicada; resultado sem projeção; resultado calculado antes da projeção; observação OOS utilizada para ajuste.

Nunca transformar automaticamente dado ausente em zero. Usar códigos específicos: NA (não disponível), ND (não determinado), EX (excluído). Isso evita distorções estatísticas.

Recomenda-se manter três versões, seguindo o fluxo Fonte → RAW → CLEAN → RESEARCH → Experimento → Artigo. Nunca editar manualmente o RAW.

Para o primeiro estudo, referência de 50 ações × 30 pregões = 1.500 observações de ativo/data. Como existem nove níveis, isso resulta em até 13.500 observações potenciais de nível — substancialmente mais informativo do que trabalhar com algumas dezenas de operações. O número final efetivamente utilizado deverá ser determinado após aplicação dos critérios de elegibilidade e qualidade dos dados.

O banco deverá permitir gerar automaticamente uma tabela com ativos, pregões, observações ativo/data, níveis, observações de níveis, sucessos, erros, taxa de sucesso, IC 95%, z, p-valor e permutação — preenchida somente após a execução efetiva do experimento.

A mesma base mestra permite derivar os experimentos dos Artigos 2 a 10 (benchmark, modelo aleatório, comparação 1P–9P, comparação entre ações e setores, out-of-sample, gestão de risco, histórico de longo prazo e consolidação) — não é necessário criar dez bancos diferentes.

1. Imutabilidade do histórico — dados brutos não são sobrescritos.
2. Versionamento — toda alteração relevante possui versão.
3. Rastreabilidade — todo resultado pode voltar ao dado original.
4. Reprodutibilidade — outro pesquisador deve conseguir reconstruir o cálculo.

Antes de iniciar o Artigo 1: criar bancos RAW/CLEAN/RESEARCH; definir universo, período, fonte oficial e frequência; formalizar matematicamente o AT.RFG2P, os níveis 1P–9P, tolerância, toque, rejeição, rompimento, acerto e erro; definir horário de corte; implementar controle de look-ahead; definir in-sample/out-of-sample; criar IDs de experimentos, controle de versões e log de auditoria; validar consistência da base; executar teste piloto; congelar protocolo; gerar base definitiva do Artigo 1.

Até este documento, a leitura era principalmente AT.RFG2P → resultado → taxa de acerto. A partir daqui, a arquitetura passa a ser:

Isso é muito mais adequado para uma linha de pesquisa científica.