É possível separar pesquisa, risco e execução desde o primeiro MVP?
Integrar uma DLL nativa e dados tick-by-tick sem permitir que falhas de infraestrutura contaminem risco e domínio.
CASE FILE. 01 / QUANT / FINTECH
Project Renaissance
Sistema quantitativo em .NET 10 com ProfitDLL, ticks, backtests, estratégias e OMS/Risk. Opera em shadow; execução real exige habilitação explícita.
- .NET 10
- ASP.NET Core
- PostgreSQL
- ClickHouse
- ProfitDLL
BRIEF. 01 / PROBLEMA E FRONTEIRA
O produto em uma leitura.
Um recorte deliberado do estado atual. Métricas e hipótese continuam editoriais até que exista evidência pública para substituí-las.
- DADOS
- TICK-BY-TICK RÓTULO EDITORIAL
- CONTROLE
- OMS + RISK RÓTULO EDITORIAL
- CAPACIDADES
- 4 backend / data / realtime / integrations
- PORTA PÚBLICA
- NÃO SUPERFÍCIE PRIVADA
SYSTEM TRACE. 02 / FLUXO PRINCIPAL
Fronteiras antes de frameworks.
Pesquisa e backtest → OMS/Risk → adaptador x64 isolado → corretora, com telemetria e persistência separadas.
- 01INGEST→
Market data
ProfitDLL x64 / ticks normalizados
- 02REPLAY→
Research engine
Backtest e reprodução determinística
- 03POLICY→
OMS / Risk
Gates, limites e intenção de ordem
- 04EXEC
Broker adapter
Shadow, paper e habilitação explícita
intent → policy → authoritative state → observable effectEXECUTION TRACE / ILLUSTRATIVE
Um caminho. Cada decisão à vista.
Sequência editorial para discutir contrato, autoridade e efeito. Não representa telemetria real de produção.
- INGEST
Valida contrato, sequência e relógio do tick.
tick.accepted - REPLAY
Executa a estratégia ativa sobre o mesmo estado reproduzível.
intent.created | no_op - POLICY
Aplica risco, idempotência e gates do modo corrente.
intent.allowed | blocked - EXEC
Registra a simulação sem autorizar efeito financeiro real.
execution.simulated
DECISION LOG. 03 / TRADE-OFFS
Toda escolha cobra algo.
Colocar a ProfitDLL em processo próprio e manter execução real atrás de gates explícitos; shadow e paper são o padrão.
- 01 / ISOLAMENTO
Adaptador nativo fora do núcleo
- GANHO
- Falhas da DLL não contaminam domínio e processo principal.
- CUSTO
- Mais coordenação entre processos, health checks e reconexão.
- 02 / DADOS
PostgreSQL + ClickHouse
- GANHO
- Estado operacional e séries densas recebem modelos adequados.
- CUSTO
- Dois armazenamentos exigem sincronização e operação consciente.
- 03 / SEGURANÇA
Shadow e paper por padrão
- GANHO
- Pesquisa pode evoluir sem ganhar autoridade financeira silenciosa.
- CUSTO
- Promoção para execução real exige critérios e cerimônia explícitos.
RELIABILITY. 04 / FALHAR COM CONTEXTO
Modo de falha. Sinal de volta.
Não são métricas de produção publicadas. São os riscos que o desenho precisa tornar observáveis e os sinais candidatos para a próxima rodada.
- 01
Desconexão ou travamento do processo que hospeda a DLL nativa.
- 02
Ticks ausentes, duplicados ou fora de ordem durante ingestão e replay.
- 03
Intenção de ordem repetida depois de timeout ou reconexão.
- 01
Replays idênticos produzem a mesma sequência de decisões.
- 02
Taxa e motivo de bloqueio nos gates do OMS/Risk.
- 03
Diferença entre sinal, preço paper e resultado de execução simulado.
INCIDENT DRILL. 05 / CONTENÇÃO → RECUPERAÇÃO → PROVA
Quando a hipótese quebra.
Exercícios editoriais de resiliência, não incidentes reais nem runbooks de produção. Cada drill transforma um modo de falha em uma resposta discutível e testável.
DRILL-01Desconexão ou travamento do processo que hospeda a DLL nativa.SIMULATION / NATIVE
Resposta para: Desconexão ou travamento do processo que hospeda a DLL nativa.
- CONTAIN
- Abrir o circuit breaker, retirar autoridade do adaptador e bloquear novas intenções antes de tentar reconectar.
- RECOVER
- Reiniciar o processo isolado, restaurar assinatura de market data e reconciliar o cursor da sessão supervisionada.
- PROVE
- Confirmar health check estável, ausência de gap e nenhuma ordem externa sem intenção correspondente no ledger.
DRILL-02Ticks ausentes, duplicados ou fora de ordem durante ingestão e replay.SIMULATION / NATIVE
Resposta para: Ticks ausentes, duplicados ou fora de ordem durante ingestão e replay.
- CONTAIN
- Quarentenar o segmento inconsistente e impedir que a estratégia avance sobre uma sequência não confiável.
- RECOVER
- Solicitar backfill, normalizar a ordem e refazer o trecho a partir do último checkpoint determinístico.
- PROVE
- Comparar sequência, checksum e decisões do replay recuperado com um corte íntegro da mesma janela.
DRILL-03Intenção de ordem repetida depois de timeout ou reconexão.SIMULATION / NATIVE
Resposta para: Intenção de ordem repetida depois de timeout ou reconexão.
- CONTAIN
- Manter a mesma chave idempotente e suspender a retentativa até consultar o estado conhecido do adaptador.
- RECOVER
- Reconciliar intenção, aceite e execução antes de decidir entre concluir, cancelar ou reenviar o comando.
- PROVE
- Demonstrar um único efeito financeiro possível e uma cadeia causal completa para cada intenção persistida.
DESIGN EXERCISE / REVISAR CONTRA TELEMETRIA E RUNBOOKS REAIS ANTES DE OPERAR
EVIDENCE. 06 / O QUE PODE SER DEFENDIDO
Fato à vista. Lacuna também.
Expandir replays determinísticos, critérios de promoção de estratégia e observabilidade de execução paper.
- Codinome: Jim Simons / Medallion Fund
- Núcleo .NET 10 / ASP.NET Core
- ProfitDLL isolada em processo x64
- Ticks, backtests, ClickHouse + PostgreSQL
- Shadow/Paper; execução real sob gates
- Experimental; não é recomendação financeira
Nenhuma captura foi publicada para este corte. O portfólio preserva a lacuna em vez de fabricar uma evidência visual.
INTERVIEW MODE. 07 / APROFUNDE A CONVERSA
Três pontos para abrir no quadro.
Perguntas que conectam o case a system design, produto e operação sem transformar uma decisão contextual em regra universal.
- 01
Como desenhar idempotência entre intenção de ordem e adaptador externo.
↗ - 02
Onde separar pesquisa, política de risco e infraestrutura de corretora.
↗ - 03
Como promover uma estratégia sem transformar backtest em promessa.
↗
CASE FILE / 01