Valid But Not Useful — the PDELie wedge in one example#

Status: advisory, not a stable contract. This note documents PDELie’s core wedge philosophy — a valid symmetry candidate can pass every empirical check PDELie ships and still fail to improve downstream utility — using a hand-authored static JSON fixture rather than a runnable example. A runnable version will follow once v0.31’s downstream discovery task bridge is available; until then, the JSON fixture is enough to make the principle concrete.

Why this note exists#

PDELie’s public surface reports two categorically different kinds of facts:

  1. Empirical validity — did the candidate transform preserve residuals, pass finite-transform verification, agree with a reference span, and clear the invariant/leakage checks? Everything under pdelie.symmetry.validate_symmetry_candidate, pdelie.verification.verify_translation_generator, pdelie.invariants.*, and pdelie.reporting.summarize_split_leakage_provenance lives here.

  2. Downstream utility — did applying the transform to the data actually improve a subsequent PDE-discovery task? Everything under pdelie.discovery.* and (from v0.31) pdelie.tasks.discovery.* lives here.

The wedge is that these two are not the same fact. A candidate can be validated in category (1) and simultaneously degrade metrics in category (2). PDELie is designed to report both without collapsing them into a single supportability label, precisely because a category-(1) pass can mislead when treated as a category-(2) claim. Everything about the wedge — the vocabulary boundaries, the refusal to add a fifth discovery_task_supportability_label, the resistance to a root pdelie.discover_symmetries API — traces back to this distinction.

A concrete example#

The fixture at docs/strategy/data/valid_but_not_useful_example.json records a hypothetical run using shapes and vocabularies from the actual v0.30.0 public reporting surfaces (symmetry_candidate_validation_report, discovery_bridge_output, discovery_result, downstream_discovery_workflow). It is hand-authored — not the output of a runtime example — so the reader can inspect it without depending on runtime that hasn’t shipped yet, and it is strict-JSON compatible (json.loads(json.dumps(payload, allow_nan=False)) == payload).

The scenario:

  • A user has a scalar 1D periodic Heat-equation-like FieldBatch.

  • They supply a synthetic candidate: xi = 1 + 0.03 * u, tau = 0, phi = 0 — a translation that couples slightly to the field amplitude.

  • They validate it against PDELie’s validate_symmetry_candidate and record every check.

  • They then run PySINDy sparse discovery on the transformed data via the existing pdelie.discovery.build_translation_canonical_discovery_inputs → fit_pysindy_discovery bridge, and independently on the original data as a reference.

What PDELie reports (fixture excerpt):

Category (1) — empirical validity: every check passes.

"validation": {
  "conclusion": "validated",
  "check_reports": {
    "residual_stability":            {"status": "passed", "residual_max_before": 8.2e-05, "residual_max_after": 9.6e-05},
    "finite_transform_verification": {"status": "passed", "classification": "exact", "error_curve_max": 6.7e-13},
    "reference_span_comparison":     {"status": "passed", "max_principal_angle_rad": 1.4e-06}
  }
}

The candidate is validated under the v0.16 vocabulary. Finite-transform verification reports classification == "exact" (v0.4 vocabulary). Residual, span, and principal-angle checks all pass their configured thresholds.

Category (2) — downstream utility: the transform makes recovery worse.

"discovery_result_after_transform": {
  "recovery": {"aggregate": {"support_precision": 0.40, "support_recall": 0.60, "support_f1": 0.48, "exact_support": false, "coefficient_relative_l2_error": 0.83, "exact_count": 0, "partial_count": 1, "failed_count": 0}}
},
"reference_run_without_transform": {"support_precision": 0.90, "support_recall": 0.90, "support_f1": 0.90, "exact_support": true, "coefficient_relative_l2_error": 0.09},
"downstream_gain": {"support_f1_delta": -0.42, "coefficient_relative_l2_delta": 0.74, "sign": "negative"}

The transformed-run F1 is 0.42 lower and the coefficient-recovery relative L2 error is 0.74 higher than the reference. On category (2), this candidate is actively harmful.

What PDELie reports, and what it deliberately does not report#

Reports:

  • both validation results (category 1) and downstream metrics (category 2) side by side;

  • a downstream_gain.sign field that is negative when the transformed run underperforms the reference;

  • the vocabulary of each label family exactly as documented in docs/specs/LABEL_REGISTRY.md.

Does not report:

  • a single scalar “useful yes/no” label. There is no useful_label field on any v0.30 summary, and there will not be one in v0.31 either.

  • a policy that rejects the candidate because downstream metrics got worse. PDELie’s job is evidence, not gatekeeping.

  • a supportability_label that overloads category (1) and (2). The supportability_label family (v0.24) is scoped to the weak-form Heat/Burgers report slice; extending it to cover “candidate is useful for downstream” would break the vocabulary boundary documented in docs/specs/LABEL_REGISTRY.md.

Downstream tooling can consume this fixture (or its runtime successor) and derive a policy — “reject candidates whose downstream_gain.sign is negative” — but that policy is a downstream decision, not a PDELie contract. PDELie surfaces the evidence; the caller decides what to do with it.

Why a static fixture, not a runnable example, right now#

A runnable version of this example needs three things that v0.30.0 does not yet publicly expose:

  1. A supplied-candidate → transform → sparse-discovery task path. The v0.6 pdelie.discovery.build_translation_canonical_discovery_inputs heuristically aligns to a peak; a general amplitude-coupled candidate needs the v0.31 task bridge and its TaskResult schema (docs/design/DISCOVERY_TASK_RESULT_SCHEMA.md).

  2. A reference-run comparison as a first-class field. The downstream_gain block in the fixture is not part of any v0.30 summary; a runnable example would either wire this in via v0.31 or leave the delta computation to the caller.

  3. A policy-consistency guarantee that the negative-gain case doesn’t silently downgrade an upstream label. Today this is guaranteed by the vocabulary rules in docs/specs/LABEL_REGISTRY.md; a runnable example must additionally pass a regression test asserting no upstream summary is coupled to downstream_gain.sign.

Shipping this as prose + committed JSON now stops the wedge from being a slogan while v0.31 is still design-only. Once v0.31 ships runtime, this note gains a paired pdelie.examples.symmetry_without_downstream_gain module that produces a numerically real version of the same fixture from real inputs, and this note updates to reference it. Until then, the fixture is the record.