Research Philosophy
Not what was built. How the decisions about what to trust, publish, and hold back actually get made — answered by pointing at real pages that already do this, not by asserting principles that sound right in the abstract.
What counts as evidence?
Something that was actually run, with the output shown, or a claim explicitly marked as not yet run. Nothing in between. The Pipeline Orchestrator page doesn't say "the kernel works" — it shows the exact command, the exact output, and states plainly that the estimators feeding it were stubs with no predictive claim. That distinction — real execution vs. a plausible-sounding description of execution — is the actual dividing line, checked directly in the Execution-Required Verification rule.
Why prefer structural guarantees over statistical ones?
Because a statistical guarantee degrades exactly when you can least afford it to — under distribution shift, adversarial pressure, or a contaminated training signal — while a structural guarantee (a write pathway that doesn't exist in the schema) holds regardless of how good or bad the surrounding statistics are. This isn't an abstract preference; it's the literal subject of the Estimator Comparison page, which checks that distinction against the real published literature rather than asserting it.
Why separate architecture from learning?
Because conflating them makes both harder to debug. If a model gets something wrong, the honest first question is "was the model's judgment bad, or was the data it saw already contaminated before judgment ever happened?" Those require different fixes. The Signal Smearing result formalizes exactly this: once two categorically different signals are mixed into one measurement, no amount of better learning recovers the information that was lost at collection — the fix has to happen upstream of learning, not inside it.
Why publish assumptions and open problems instead of waiting until they're resolved?
Because an unstated assumption doesn't stop being an assumption — it just stops being visible. The Open Problems page and the Backtest-Only Audit exist because the alternative — presenting only what's finished — makes it impossible for anyone else to tell the difference between "solved" and "not yet attempted." Several open problems on this site have real test data already attached to them, specifically so "open" doesn't collapse into "no evidence exists either way."
What makes a theorem valuable?
That it's checkable independently of trusting the person who wrote it. The Patent Cliff Notes page states this directly for a case where the line matters: Definition 2.2 stipulates a structural fact by construction; Theorem 1 is only valuable because it derives something further from that fact using an independent, external framework (Pearl's do-calculus) — not because it restates the definition in more impressive language. A theorem that can't be separated from the credibility of its author isn't doing the job a theorem is supposed to do.
When is simulation enough, and when is field validation required?
Simulation is enough to establish that a mechanism works as designed — that the code does what it claims to do, under conditions the researcher controlled. It is never enough to establish that the mechanism produces good outcomes for people who weren't part of designing it. The Assignment Tracker is the clearest live example: its core logic is verified, run, and correct — and it still carries an explicit warning that its calibration hasn't been shown to work at ability extremes, because no amount of passing internal tests substitutes for what happens with a real student who wasn't part of the design loop.
What this page is not
Not a claim that any of this is unique or that other researchers don't already work this way. It's a direct answer to how decisions actually get made here, stated plainly enough that disagreeing with it is possible — which is the actual point of writing it down instead of leaving it implicit.