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.

Is this one architecture, or does it keep changing?

It might look, moving through this site, like the specific formula keeps shifting — different channel definitions for education versus Tesla versus industrial domains, real dead ends discarded, a first attempt at a structured signal honestly reported as worse than a second attempt. That's not drift, and it's not searching for one final, fixed architecture that hasn't been found yet. The actual constant across all of it is the method — keep genuinely independent signal classes structurally separate, verify by running real code against real data, report the failures next to the successes — not any single instantiation of what those channels specifically mean in a given domain. The Domain Applications page maps S/D/I/C differently for industrial, athletic, and co-pilot contexts on purpose; the Tesla work's honestly-reported second attempt landed worse than the first, by design of the reporting, not by accident. Different domains earn different specific formulas. The discipline producing them is the same discipline every time, and that discipline is what reliably gets you a closer state estimate — not any one particular equation being declared final.

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.