BLOCKED: assess a symbolic mathematics engine only after deep statistical validation

[hyperpolymath]

Suggested labels: enhancement, blocked, design-review, scientific-risk.
Depends on: Validated statistics and numeric-integrity layer.

Mandatory hold — user instruction

Do not proceed with the symbolic engine until the statistics layer is fully and deeply tested. This is not an easy extension and carries significant design risk and risk to end users.

This issue records future intent and the mandatory gate. It does not authorise implementation, engine integration, experimental user-facing exposure, or a symbolic dependency added in anticipation of later approval. Do not treat symbolic mathematics as an automatic next release, a low-risk enhancement, or a way to bypass statistical validation.

Why this needs a separate stage

A symbolic engine could eventually support selected formula derivations, model inspection, differentiation and verification. Its practical value must first be demonstrated against user needs and safer alternatives such as existing numeric methods, automatic differentiation or offline mathematical review.

Symbolic output can appear authoritative while being invalid outside unstated assumptions. A mathematically valid expression also does not establish that its statistical model or biological interpretation is appropriate.

Risks requiring explicit review after the gate opens

• Incorrect simplification due to unstated domains, assumptions, singularities, branch cuts or boundary conditions.
• Loss of domain restrictions during cancellation or transformation, causing inequivalent expressions to appear interchangeable.
• Disagreement between symbolic forms and numeric evaluation, derivatives or likelihood optimisation.
• Expression growth, nontermination, excessive memory use and denial-of-service risk.
• Unsafe parsing, generated-code execution or arbitrary evaluation of user-supplied expressions.
• Dependency licensing, maintenance, offline bundling and x86-64/ARM64 compatibility.
• Reproducibility and serialization of expressions, assumptions, engine versions and transformation histories.
• UI presentation that hides caveats or leads users to mistake “symbolic/exact” for experimentally certain, statistically valid or formally proven.
• Added maintenance and architectural complexity affecting an already validated numerical/statistical layer.

Conditions required before work may proceed

• The companion statistics issue meets its declared acceptance criteria, including independent references, simulated and representative biological data, adversarial cases, negative controls and appropriate mutation/fuzz evidence.
• Precision, data conversion, provenance, concurrency, performance budgets and failure handling are validated end to end.
• Critical scientific-correctness, security and data-integrity blockers are resolved; remaining limitations and residual risks are documented and reviewed.
• Statistical/scientific reviewers have approved the evidence, and the supported scope is clearly bounded.
• The repository owner explicitly authorises opening this symbolic-design stage, with links to validation evidence and the approval decision.

No automatic unblocking: a closed issue, passing unit suite or released statistics UI is not sufficient. Validation is necessarily scoped; nobody should claim testing has eliminated all scientific or design risk.

Work allowed only after explicit unblocking

1. Identify a small set of concrete user problems and assess whether an engine is necessary.
2. Compare candidate engines and non-symbolic alternatives against correctness, assumptions, licensing, maintenance, resource and offline/platform constraints.
3. Produce a design and threat model covering a constrained expression language, domain/assumption tracking, resource limits, cancellation, safe evaluation and isolation where appropriate.
4. Define independent mathematical/numerical validation, adversarial fixtures and regression requirements before integrating an engine.
5. Design user-facing explanations, unsupported-case handling, provenance and opt-in behaviour. Never silently reinterpret existing analyses.
6. Obtain a separate architecture, scientific and security review approving any implementation plan.

If a safe and useful design cannot be justified, defer or close the proposal rather than implementing it to satisfy a roadmap. Any eventual implementation must remain Julia-owned where practical, preserve the existing application and statistics layer, and undergo its own release-readiness review.

Publication note

This issue is blocked by #1. The dependency is explicitly recorded here; a native GitHub blocking relationship has not been configured. Keep the mandatory hold prominent in the title and issue body; a label alone is insufficient.