JS vs Python Execution Model

In the current release, JS and Python do different jobs.

JS primarily handles product-facing orchestration such as request handling, routing, validation, and packaging of user-facing responses. Python is used for numerical execution where the engine needs stable computational behavior.

This matters because many statistical defaults are best understood as engine policy rather than UI wording or route-layer behavior.

Why statistical defaults live here

When Licklider chooses a default statistical behavior, that choice is usually part of the execution model of the numerical engine.

In other words, the product does not merely label a test. It relies on a computation layer that encodes a specific default policy for choosing, running, and reporting that analysis.

Welch's t-test as the default

For independent two-group comparisons, the default engine policy uses Welch's t-test rather than requiring an equality-of-variance assumption up front.

The rationale is practical and statistical:

Welch remains valid when group variances differ
pre-testing variances before deciding between Student's and Welch can create avoidable decision instability
the safer default is to treat unequal variance as plausible unless there is a specific reason not to

Student's t-test may still exist as an intentional override or explicit choice, but it is not the safest default policy for the general case.

Normality and variance checks

Normality and variance checks are part of engine decision support, not magical ground truth detectors.

Their role is to inform whether a parametric path is still appropriate, not to replace judgment about design quality or measurement context.

In practice, that means:

normality tests help signal when a non-parametric alternative may be more appropriate
variance-oriented checks help determine whether equal-variance assumptions should be avoided
these checks are part of a broader decision policy rather than a single hard yes-or-no gate

Type II sum of squares for two-way ANOVA

In the current release, two-way ANOVA defaults should be read as an engine-level policy rather than a presentation-layer preference.

Type II sum of squares is the current default because it provides a practical main-effect reading without forcing the product to assume a different default interpretation contract.

If a different ANOVA sum-of-squares convention is needed for a specific analysis, that should be treated as an explicit analytical choice rather than an invisible default.

Effect sizes are part of the computational contract

Effect sizes are not an optional decorative add-on to a p-value. They are part of the intended computation and reporting surface.

That means the engine should be read as producing:

a significance result
an effect magnitude estimate
interval context where applicable

This design keeps the product aligned with interpretation-oriented reporting rather than minimal null-hypothesis output.

Outlier sensitivity as execution policy

Outlier handling should also be read partly as execution policy. When the product evaluates outlier sensitivity, the important point is not only that an outlier exists, but that the engine can compare analysis behavior with and without that observation under a defined computational path.

The deeper interpretation of that warning belongs in Known Limitations and Interpreting Guards and Heuristics.

What does not belong here

This page explains execution policy. It does not define the full meaning of design warnings, limitations, or blocked exports.

For example:

pseudoreplication detection limits belong under limitations
warning interpretation belongs under guard interpretation
export and audit payload details belong under schemas and exports

Practical reading rule

If you are asking "why did the engine default to this method or reporting behavior?", this page is the right place to start.

If you are asking "can the system detect this design flaw reliably?" or "what does this warning mean for export?", continue to the limitations section.