Can research, risk, and execution be separated from the first MVP?
Integrate a native DLL and tick-by-tick data without letting infrastructure failures contaminate the risk and domain layers.
CASE FILE. 01 / QUANT / FINTECH
Project Renaissance
A quantitative system built with .NET 10, ProfitDLL, ticks, backtests, strategies, and OMS/Risk. It runs in shadow mode; live execution requires explicit enablement.
- .NET 10
- ASP.NET Core
- PostgreSQL
- ClickHouse
- ProfitDLL
BRIEF. 01 / PROBLEM AND BOUNDARY
The product in one read.
A deliberate view of the current state. Metrics and the hypothesis remain editorial until public evidence can replace them.
- DATA
- TICK-BY-TICK EDITORIAL LABEL
- CONTROL
- OMS + RISK EDITORIAL LABEL
- CAPABILITIES
- 4 backend / data / realtime / integrations
- PUBLIC DOOR
- NO PRIVATE SURFACE
SYSTEM TRACE. 02 / PRIMARY FLOW
Boundaries before frameworks.
Research and backtesting → OMS/Risk → isolated x64 adapter → broker, with separate telemetry and persistence.
- 01INGEST→
Market data
ProfitDLL x64 / normalized ticks
- 02REPLAY→
Research engine
Backtesting and deterministic replay
- 03POLICY→
OMS / Risk
Gates, limits, and order intent
- 04EXEC
Broker adapter
Shadow, paper, and explicit enablement
intent → policy → authoritative state → observable effectEXECUTION TRACE / ILLUSTRATIVE
One path. Every decision in view.
An editorial sequence for discussing contract, authority, and effect. It does not represent real production telemetry.
- INGEST
Validates the tick contract, sequence, and clock.
tick.accepted - REPLAY
Runs the active strategy against the same reproducible state.
intent.created | no_op - POLICY
Applies risk, idempotency, and the current mode gates.
intent.allowed | blocked - EXEC
Records the simulation without authorizing a real financial effect.
execution.simulated
DECISION LOG. 03 / TRADE-OFFS
Every choice costs something.
Run ProfitDLL in its own process and keep live execution behind explicit gates; shadow and paper are the defaults.
- 01 / ISOLATION
Native adapter outside the core
- GAIN
- DLL failures cannot contaminate the domain or primary process.
- COST
- More inter-process coordination, health checks, and reconnection.
- 02 / DATA
PostgreSQL + ClickHouse
- GAIN
- Operational state and dense series receive appropriate models.
- COST
- Two stores require synchronization and deliberate operations.
- 03 / SAFETY
Shadow and paper by default
- GAIN
- Research can evolve without silently gaining financial authority.
- COST
- Promotion to live execution requires explicit criteria and ceremony.
RELIABILITY. 04 / FAIL WITH CONTEXT
Failure mode. Signal back.
These are not published production metrics. They are risks the design must make observable and candidate signals for the next round.
- 01
Disconnection or crash in the process that hosts the native DLL.
- 02
Missing, duplicated, or out-of-order ticks during ingestion and replay.
- 03
An order intent is repeated after a timeout or reconnection.
- 01
Identical replays produce the same decision sequence.
- 02
Block rate and reason across OMS/Risk gates.
- 03
Difference between signal, paper price, and simulated execution result.
INCIDENT DRILL. 05 / CONTAINMENT → RECOVERY → PROOF
When the hypothesis breaks.
Editorial resilience exercises, not real incidents or production runbooks. Each drill turns a failure mode into a response that can be discussed and tested.
DRILL-01Disconnection or crash in the process that hosts the native DLL.SIMULATION / NATIVE
Response to: Disconnection or crash in the process that hosts the native DLL.
- CONTAIN
- Open the circuit breaker, remove adapter authority, and block new intents before reconnecting.
- RECOVER
- Restart the isolated process, restore the market-data subscription, and reconcile the supervised session cursor.
- PROVE
- Confirm a stable health check, no data gap, and no external order without a corresponding ledger intent.
DRILL-02Missing, duplicated, or out-of-order ticks during ingestion and replay.SIMULATION / NATIVE
Response to: Missing, duplicated, or out-of-order ticks during ingestion and replay.
- CONTAIN
- Quarantine the inconsistent segment and prevent the strategy from advancing on an untrusted sequence.
- RECOVER
- Request a backfill, normalize order, and replay from the last deterministic checkpoint.
- PROVE
- Compare sequence, checksum, and recovered replay decisions with an intact cut of the same window.
DRILL-03An order intent is repeated after a timeout or reconnection.SIMULATION / NATIVE
Response to: An order intent is repeated after a timeout or reconnection.
- CONTAIN
- Keep the same idempotency key and suspend retry until the adapter state is known.
- RECOVER
- Reconcile intent, acceptance, and execution before completing, canceling, or resending the command.
- PROVE
- Demonstrate one possible financial effect and a complete causal chain for every persisted intent.
DESIGN EXERCISE / REVIEW AGAINST REAL TELEMETRY AND RUNBOOKS BEFORE OPERATING
EVIDENCE. 06 / WHAT CAN BE DEFENDED
Facts in view. Gaps too.
Expand deterministic replays, strategy-promotion criteria, and paper-execution observability.
- Codename: Jim Simons / Medallion Fund
- .NET 10 / ASP.NET Core core
- ProfitDLL isolated in an x64 process
- Ticks, backtests, ClickHouse + PostgreSQL
- Shadow/Paper; live execution behind gates
- Experimental; not financial advice
No capture was published for this cut. The portfolio preserves the gap instead of manufacturing visual evidence.
INTERVIEW MODE. 07 / DEEPEN THE CONVERSATION
Three points to open on the board.
Questions that connect the case to system design, product, and operations without turning a contextual decision into a universal rule.
- 01
How to design idempotency between an order intent and an external adapter.
↗ - 02
Where to separate research, risk policy, and broker infrastructure.
↗ - 03
How to promote a strategy without turning a backtest into a promise.
↗
CASE FILE / 01