feat(jc): pillar 10 (Pflug-Pichler) + sigker crate + pillar 11 stub

[AdaWorldAPI]

Summary

Three additions following the two-hop walk through the Vienna 2023 research report (see EPIPHANY discussion):

1. Pillar 10 (Pflug-Pichler 2012) in crates/jc/src/pflug.rs — nested-distance Lipschitz continuity on Sigma DN-trees
2. crates/sigker/ — new standalone crate for path-signature representations (Chen-Lyons + Cuchiero randomized signatures + signature kernels)
3. Pillar 11 stub (Hambly-Lyons 2010) in crates/jc/src/hambly_lyons.rs — DEFERRED, certifies sigker's Index-regime classification once wired

Architectural rationale

The decision matrix for these three, given the existing jc / bgz17 / deepnsm constitution:

Topic	Placement	Reason
Pflug nested distance	Pillar in jc	Certifies an existing operation (CAM-PQ on DN-trees), zero deps, ~ms runtime, fits the concentration-ladder pattern of pillars 5/7/8/9 (ℝ → Hadamard → Hilbert → SPD-path → trees-with-filtration)
Cuchiero / sigker	Separate crate	Provides a new representation, has consumers (planner, OSINT pipeline), eventually needs ndarray for kernel PDE solver, doesn't fit the "zero deps, certifies" jc constitution
Hambly-Lyons	Pillar stub in jc	Certifies sigker (a property of external machinery, exactly what jc is for), activation is mechanical once sigker is reachable from jc dev-deps

Pillar 10 — Pflug-Pichler (executable)

Pillar 10 continues the concentration ladder beyond pillars 5/7/8/9 into the carrier the Sigma DN-tree actually lives in: discrete-time stochastic processes with branching structure. Two trees are "close" only if both their values and their filtrations (information structure / branching topology) are close.

The probe builds T=4 binary scenario trees, sweeps 32 perturbations of the branching parameter δ, computes the recursive Pflug-Pichler nested distance via 2-way conditional couplings, and verifies three claims:

1. |ΔV| ≤ L · d_nested (Pflug-Pichler 2012 bound holds)
2. d_nested ≥ d_Wasserstein on every sample (nested dominates the loose comparator)
3. L_wasserstein ≥ L_nested (Wasserstein-only would need a worse Lipschitz constant — the operational reason CAM-PQ on DN-trees needs the nested metric, not Hamming/Wasserstein on terminal marginals)

Brute-force recursion is fine at HORIZON=4 (15 nodes per tree, ~ms total). Auction-algorithm acceleration from Qu-Tran 2021 is the production path for larger horizons; documented in the header.

Numerics cross-checked in Python before commit: T(δ=1.0) vs T(δ=1.2) gives nested = 0.40, Wasserstein = 0.20 — clean dominance, pillar logic should pass.

Citation: Pflug & Pichler, "A distance for multistage stochastic optimization models", SIAM J. Optim. 22(1), 2012; full theory in Pflug & Pichler, Multistage Stochastic Optimization, Springer 2014.

Sigker crate

Same constitution as bgz17/deepnsm/jc: zero deps, opt-in build via --manifest-path, workspace-excluded.

File	What
signature.rs	Truncated Chen-Lyons signature with working depth-2 implementation; Chen's identity test green; structurally supports depth N
shuffle.rs	Shuffle product on multi-indices; multinomial counts verified
randomized.rs	Cuchiero-Cuchiero-Schmocker-Teichmann 2021 randomized signatures; SplitMix64 + Box-Muller for zero-dep determinism
kernel.rs	Truncated signature kernel (Cauchy-Schwarz verified); signature_kernel_pde surface stubbed for production extension (Salvi-Cass-Foster-Lyons-Lemercier 2020)
codec.rs	CodecRouteSigker enum mirroring lance-graph-contract::cam::CodecRoute; classifies sigker as Index regime for Path carrier kind, lossless on tree-quotient by Hambly-Lyons uniqueness

Two examples:

• sig_vs_hamming.rs — correlation bench against bitpacked Hamming
• randomized_signature_demo.rs — universality + reparametrization invariance

Pillar 11 stub — Hambly-Lyons

Returns PillarResult::deferred(...) with a fully-documented activation path. Same DEFERRED pattern as pillars 2 and 4 used in their dormant phase. Probe design specified in the doc-comment so when sigker is reachable from jc dev-deps the activation is mechanical: replace prove() body with the forward (tree-equivalent paths same signature) + converse (non-tree perturbation differs) + discrimination test.

What this PR does NOT do

• Does not wire sigker into CodecRoute in lance-graph-contract. That's a one-line addition + one routing rule, gated on sigker being benchmarked at production carrier widths. Separate follow-up.
• Does not run cargo check — sandbox didn't have a Rust toolchain. Files follow the exact patterns of koestenberger.rs etc. Expect minor lint cleanup on first build.
• Does not implement the Goursat-PDE solver for the full untruncated signature kernel. signature_kernel_pde currently delegates to depth-4 truncated; surface exists so consumers can wire against it.
• Does not implement nested-distance auction algorithm. Brute force at HORIZON=4 is sufficient for pillar certification.

Diff stats

13 files changed, 1867 insertions(+)

Two modified (Cargo.toml, crates/jc/src/lib.rs), eleven new.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f8dd307fa1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Make the shuffle test sortable

Running cargo test --manifest-path crates/sigker/Cargo.toml fails before executing the new crate's tests because Vec<(Vec<usize>, f64)> cannot be sorted with sort(): f64 does not implement Ord, so the tuple does not implement Ord either. This blocks the documented opt-in validation path for sigker; sort by the word component or compare grouped maps instead.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Enforce matching path dimensions in release builds

When callers pass paths with different point dimensions, this check disappears in release builds, so signature_kernel either silently ignores extra coefficients when x has fewer level entries than y or panics later when x has more. For example, a depth-1 kernel between a 1-D path and a 2-D path returns a value using only the first coordinate instead of rejecting the invalid input; this should be a normal assertion or explicit validation before taking the dot product.

Useful? React with 👍 / 👎.