Useful debugging aid. The shape is right: the new integral_weight_validator operator on the DBSP side, the SQL variable ENFORCE_POSITIVE_INPUTS driving an InsertWeightValidation rewriter that injects a DBSPWeightValidatorOperator after every DBSPSourceMultisetOperator, ToRustVisitor / ToJsonOuterVisitor / CircuitCloneVisitor / CircuitVisitor all wired with the right visit method. The Conditional dispatch in CircuitOptimizer.createOptimizer() keys off metadata::enforcePositiveInputs so zero-cost when the flag is off.

A few real points:

• Doc/code mismatch on weight semantics (crates/dbsp/src/operator/integral_weight_validator.rs). The rustdoc says "if any (key, value, weight) triple in the integral has a non-positive weight, the operator panics" and the # Panics section says "Panics when any weight in the integral is ≤ 0." But the code asserts weight >= 0 — i.e. panics on < 0, accepts weight == 0. In Z-set integration after compaction weight == 0 rows shouldn't surface from the cursor, so the operational behavior is fine, but the doc is wrong. Fix the doc to say "negative" and "< 0", and either drop the per-step step_val() weight check for weight == 0 (it can't happen) or assert weight > 0 and document that.
• integral_weight_validator builds a full integrate. sharded.integrate() materializes the running multiset of the entire table in memory. For an input table that grows to millions of rows this is the cost the user pays for the debugging guarantee. The rustdoc and the grammar.md entry both say "intended for debugging and testing" which is good, but neither says "this operator builds a full integral and is unsuitable for large tables." Worth a one-line warning in both places so users aren't surprised when their pipeline OOMs after flipping the flag in production. (Power of Ten #2 — unbounded resource use — is a useful framing for the doc warning.)
• anand's panic-vs-warning question (line 798 of grammar.md). I think Mihai's call here is right: a panic is the only correct behavior when the invariant is broken, because once a key's integral weight goes negative the multiset is inconsistent and any downstream materialized view that depends on it is now producing wrong results. A "warning" that logs and keeps going would leak garbage data into outputs. The honest user-experience answer is: don't enable ENFORCE_POSITIVE_INPUTS in production; do enable it in CI for the exact test that's misbehaving; the panic is a debugging signal, not a runtime fault. That story should be stated explicitly in grammar.md so the next user with the same question doesn't have to re-derive it. Suggested addition: "This option is intended for debugging only — enabling it in production will crash the pipeline when the invariant is broken, which is the correct behavior for catching upstream bugs but not what you want for live workloads."
• Test integral_weight_validator_panics_on_negative_integral has a great comment block. The companion integral_weight_validator_panics_on_negative_weight test name is slightly misleading — it's not really "the weight went negative", it's "step 0 inserts a delete delta directly", which makes the integral negative on the first step. Worth a one-line comment on that test mirroring the other one.
• InsertWeightValidation only wraps DBSPSourceMultisetOperator, which matches "tables without a primary key." Good. Worth a one-line comment in InsertWeightValidation.java stating the invariant (PK-bearing tables go through DBSPSourceSetOperator or DBSPSourceMapOperator, which already reject illegal updates upstream) so a future reader doesn't wonder why only multiset sources get the check.
• DBSPWeightValidatorOperator.fromJson rebuilds with CalciteEmptyRel.INSTANCE — matches the pattern in other operators, no concern. The addAnnotations round-trip looks correct.
• Regression3Tests.testEnforcePositiveInputs. Good: SQL-level smoke test that the flag drives the actual rewriter + runtime check. Worth also: (a) a test asserting the flag is off by default (so a no-flag REMOVE FROM T VALUES (1) against CREATE TABLE T(x INT NOT NULL) does not panic and produces the "wrong" output silently — pinning the opt-in semantics), and (b) a test for a table with a primary key, asserting that ENFORCE_POSITIVE_INPUTS = TRUE doesn't insert the validator and the existing PK-based rejection path still runs (i.e. confirming the multiset-only narrowing in InsertWeightValidation is intentional).
• SET ENFORCE_POSITIVE_INPUTS = TRUE. What happens if a user writes SET ENFORCE_POSITIVE_INPUTS = OFF after the table is created and then flips to ON? That's a compile-time setting, not runtime, so the question is moot for one program — but worth a one-line note that this is a compile-time setting (consistent with the other FELDERA_* variables documented above the new entry).

Overall direction is right. Address the doc/code mismatch (≤ 0 vs < 0) before merging; the rest are non-blocking.

Re-review on 919f9fe. All my prior points addressed cleanly:

• Doc/code mismatch fixed — rustdoc and # Panics both now say "< 0" and "negative", and the implementation drops the inner per-value loop in favor of a single weight < 0 check on the key in the integrated trace. Consistent now.
• Cost warning in grammar.md added: "this setting is expensive, and will trigger a full backfill for the affected tables." Concise and accurate.
• Hot-path tightening — the new version filters on delta_weight < 0 before doing the trace lookup, so positive deltas pay only a delta-cursor step. Nice.
• Wrapping in circuit.region("integral_weight_validator", ...) gives the integral subgraph a stable label for tracing/profiling — small but good.
• Switching from RootCircuit::build to Runtime::init_circuit(1, ...) + circuit.transaction().expect_err(...) for the negative tests is the right pattern; #[should_panic] against multi-threaded runtimes is fragile.

Non-blocking nits, take or leave:

• integral_weight_validator_panics_on_negative_weight test name still describes the symptom slightly indirectly — the key only has one delta, weight -1, so trace weight after step 0 is -1. Maybe rename to ..._panics_on_delete_without_insert to mirror the negative-integral test's narrative, but truly optional.
• The debug_assert!(trace_cursor.val_valid()) after seek_key_exact returning true is correct (a key with no valid val shouldn't exist in a sharded integrated trace), but a one-line comment explaining the invariant would help a future reader who hasn't internalized the trace cursor contract.

APPROVE.