How this account builds software

The projects here differ in domain, but they are built the same way, and the way is the point. These are the practices, each with the code that demonstrates it — not aspirations, but things you can go and check.

The expected answer exists before the code does

Where a result can be computed by hand, the hand computation is the acceptance oracle, and it is committed separately from the engine so the two can disagree. dc-twin's reference numbers are worked out on paper in the reference scenario document, committed as a fixture that lives deliberately apart from the engine, and reconciled in CI by a script that replays every scenario and requires exact matches. If the engine drifts from the paper answer, the build fails, and the paper wins the argument until someone shows where the paper is wrong. The quant risk engine and the investment lab do the same at smaller grain: every worked example in their methodology documents is hand-calculated and asserted by tests, digit for digit.

Conventions are documented, not assumed

Most quantitative disagreements are not bugs; they are two people using different defensible conventions. So every convention gets written down where a reviewer will find it: the 252-day annualization, the n − 1 volatility denominator, and the sign of a VaR in the risk engine's methodology; the nine-column contract the validator enforces; the data contract that makes the dispatch model reject a timestamp without an explicit UTC offset. A documented convention turns "your number is wrong" into "your number used a different rule", which is a conversation that ends.

Determinism is a feature, not an accident

Same inputs, same output, always — because a result that cannot be reproduced cannot be reviewed. dc-twin commits to a SHA-256 result hash per run and ships a replay command that verifies it. The risk engine's reports embed no timestamp anywhere, so the same spec produces byte-identical artifacts, and a test asserts exactly that. Monte Carlo layers in both financial projects require the seed as an argument rather than defaulting to entropy. Even the synthetic fixtures are deterministic: generator scripts are committed, and test suites fail if the committed data and the generator ever disagree.

Tests prove design claims, not just code paths

Coverage tells you the code ran; the more interesting tests demonstrate that a design promise holds. The risk engine's backtest promises that its policy interface exposes only observations strictly preceding the decision date — caller-supplied policies remain responsible for not accessing future data through external state or external data sources — so its test suite includes a deliberately cheating policy, fed the full price series around the interface, that measurably beats every honest policy, and a companion test shows the cheat's first move fails when attempted through the interface. The facilities manager claims redundant equipment cannot be maintained simultaneously, so a test starts the second order and asserts the refusal names the constraint and the conflicting order. The validator claims CSV and XLSX are treated identically, so the same register goes through both parsers and must yield the same findings. The sudoku app claims each puzzle has exactly one solution, and a bounded solver in the test suite proves all 24. A claim without a test is a hope.

Limitations are content, not fine print

Every repository states what the tool does not do, at the same level of prominence as what it does: dc-twin lists the physics it deliberately omits, the validator says it checks data quality and not electrical correctness, the dispatch model's limitations page is a first-class document. And when a stated goal met a measured limit — a full-year benchmark that completed once and then failed to finish on a rerun — the benchmark page publishes the failure with the environment and hashes needed to repeat it. A tool's edges are part of its specification.

All data is fictional, always

Every topology, register, price series, campus, and scenario in these repositories was invented for the repository it lives in, and several projects document the rule explicitly — dc-twin in a data-provenance document where every sample declares itself synthetic. This is partly professional hygiene, since real registers and topologies describe real infrastructure, and partly what makes the rest possible: the reasoning can be fully public precisely because no real site is in it.

Written to be read

Documentation is written in plain language and aimed at a reader, not at completeness. dc-twin carries a plain-language explainer that assumes no electrical background. The financial CLIs write committee-style reports meant to be read in minutes, caveats included. Error responses follow RFC 9457 and say what actually conflicts, by name. If a page on this site or in these repositories reads as padding, that is a bug.

None of these habits is novel, and that is the point: they are the software equivalent of checking a protection relay against a hand calculation before trusting it. The case studies show several of them under pressure, on days when they earned their keep.