nomue Protocol opens Release 4 public discussion for two-factor experiments

A proposal researchers and developers can now challenge

Public discussion opened on September 9, 2026 for a nomue Protocol Release 4 proposal covering balanced two-factor experiments. The proposal brings the statistical scope, data relationships, result meaning, and verification evidence into one document that researchers and developers can inspect and challenge.

This is a specification proposal open for comment. An unissued numerical, report and controlled-execution candidate has since reached independently reviewed final readiness. That does not establish a supported calculation range or add a verifier capability.Read the fixed proposal orjoin the public discussion.

Two factors, four experimental conditions

Consider two temperature levels and two materials. Their combinations make four conditions. With the same number of independent observations in each condition, a two-factor analysis can describe each factor’s average effect and whether the effect of one factor changes with the other. That last quantity is an interaction.

The proposal covers two fixed factors with two levels each, at least two independent experimental units per condition, and one continuous outcome. It retains the interaction in the model and declares independent normal errors with a common positive variance. Under that model, it describes signed effect estimates and individual F tests for the two main effects and the interaction. The F tests compare each effect’s variation with residual variation within conditions.

This makes the planned expansion beyond two-group comparison concrete: a future verification call would need to identify the exact experimental design, the claim being tested, and the evidence for that claim.

What the proposal asks a verification record to preserve

A method name and a p-value leave important questions unanswered. Which observations belong to each condition? What model assumptions were declared? Which effect does each result describe? What should happen when a reference points to missing data?

The proposed rules address those questions in three connected parts:

• Explicit evidence relationships. Connect observations, conditions, model declarations, and each reported effect without guessing missing facts.
• Distinct failure meanings. Separate a malformed record or broken reference from a validly represented design outside the proposed scope, and specify which dependent checks must stop.
• Compatibility. Introduce separate proposed data structures and identifiers while preserving existing Release 1 records and their interpretation.

These choices can be discussed before selecting a production numerical algorithm. The bounded proposal uses no Release 3 identifier, schema, or procedure, so its discussion can proceed independently of Release 3’s schedule. The separate Release 3 independent-group proposal is also now open for comment.

The evidence behind this stage

The accepted normal-model work separates what the supplied Tian and Styan paper contributes from the project’s probability derivation. A separate review checked that division and independently reconstructed the retained derivation. Subsequent proposal reviews examined the scope, record relationships, failure rules, and compatibility plan; their findings were repaired before opening.

The final opening confirmation returned GO with no additional findings. It reuses earlier scientific review and discloses its context and independence limits; it is not a new journal peer review or a numerical implementation certification.

Our earlier 945-case floating-point study explains why those numerical questions remain important: storing inputs can change a tiny effect, and later arithmetic can introduce a different error. That study provides bounded coefficient-level evidence, not a guarantee for every F statistic or p-value in the proposal.

The source and scope acceptance recordand draft integration PRpreserve the evidence and its boundaries. The proposal does not depend on obtaining every original source for the wider Release 4 research programme; those broader questions remain outside this opening scope.

What remains to be decided and built

The first proposal is deliberately bounded. It excludes unequal or missing cells, repeated or clustered units, random or mixed factors, confidence intervals, multiple-testing guarantees, and causal claims. The three individual tests do not jointly guarantee control of errors across all three claims. The stated normal-model result also does not establish exact calibration after inputs are rounded or selected for admission.

The candidate now fixes procedures, bounded execution conditions, report behavior and review evidence for this narrow scope. Formal adoption, authoritative identifiers and registration, public CLI treatment, support activation and Release 4 remain open. Current public verifier support remains Release 1 Welch.

September 10: arithmetic and fixed-F tail candidates reviewed

Separate limited reviews covered exact-input arithmetic through F and upper-tail bounds for fixed floating-point F inputs. Our engineering article explains the numerical findings and a checker limitation: interval overlap and matching rounded answers do not prove containment. Later work connected those parts to Record checks, report behavior and controlled execution. This progress adds no supported capability and changes neither the original discussion scope nor its window.

September 17: the unissued candidate reached final review readiness

The T09–T14 chain now connects the checked Record to exact ratios, bounded probability evidence, a complete report and controlled execution. Thefinal-readiness intake records a GO disposition for the fixed candidate. A separateadoption-readiness packet records the bounded decisions and the formal acts that remain.

These public records preserve maintainer-provided review results rather than publishing every original reviewer receipt. They do not turn the candidate into an issued Requirement, schema, check, bundle, CLI behavior or supported Protocol capability.

September 18: D01 and D07 entered a separate amendment discussion

A separate public amendment windownow covers two bounded changes. D01 compares the declared and recomputed values only after nearest-ties-to-even binary64 projection, then requires strict equality. D07 distinguishes a completed indeterminate comparison from both a pass and a proved mismatch; it does not invent a point result.

The fixed amendment input leaves the existing five CLI exit-code meanings unchanged. Opening this amendment is not adoption, issuance or implementation approval, and it does not reset or extend the original RFC clock.

How to take part

Comment on the original public discussion issue with the clause or field concerned, a concrete example or counterexample, and a proposed correction where possible. Feedback on the statistical scope, evidence format, failure handling, compatibility, and unresolved numerical design is welcome.

The minimum discussion period is 30 calendar days under the Protocol’s STABLE-INTENT process. It began at 05:59:47 UTC on September 9, 2026. The earliest adoption decision is 05:59:47 UTC on October 9, 2026. That date is neither automatic adoption nor a promised product release.

GitHub recorded the D01/D07 amendment comment at 01:51:08 UTC on September 18, 2026. Its separate earliest decision is 01:51:08 UTC on October 18, 2026. The two clocks must not be substituted for one another.

September 19 timing clarification: the comment body declared01:50:49 UTC. The later GitHub creation time controls the minimum window, correcting this article's earlier amendment time by nineteen seconds. A unified decision including D01/D07 must wait for that later window.

The formal decision packet has completed its review

The formal decision packet and its repair confirmation are now merged. They collect the fixed inputs, evidence and decisions still required from the steward. This closes the packet review, not adoption, implementation approval or Release 4 publication.

One required decision concerns a completed report containing an indeterminate result but no failed check. It cannot use exit code zero under the unchanged CLI meanings. The decision must constrain the supported procedure to resolved outcomes or defer that report state to a separately versioned successor.