Guth
NewsDocs
Page actions
View as Markdown ↗
Explore MCP tools ↗

instrument mechanism / verified-clean

Summation & Product Notation Evaluator mechanism

The inspectable method record for Summation & Product Notation Evaluator, kept separate from implementation and qualification.

Status: VERIFIED_CLEANLifecycle: verified-clean

Model scope

The direct finite-sum approach is standard under an explicitly defined integer-bound convention, and the three listed polynomial closed forms are standard for sums from 1 through N. The specification needs exact lower/upper-bound semantics, geometric term indexing, r=1 handling, empty-range behavior, product support, numeric precision policy, and the meaning of closed-form matching. The empty honest_label field is a concern: the instrument should honestly state whether it supports finite sums only, finite products, symbolic parsing, and which closed forms are recognized.

  • The specification claims to evaluate Π expressions, but provides no explicit product algorithm, identity value, or supported product syntax.
  • The listed closed forms are underspecified: Σn, Σn², and Σn³ require a precise index range, and the geometric-series formula requires a stated term convention and a separate r=1 case.
  • The phrase "closed-form match if known" does not define which expressions qualify as known or how symbolic equivalence is determined.

Units and conventions

  • Index bounds are integer and inclusive for finite sums unless an alternate convention is explicitly specified.
  • For Σn, Σn², and Σn³, the standard closed forms assume terms indexed from 1 through N; including k=0 does not change these particular sums.
  • For a geometric series, terms are assumed to be a·r^k for k=0 through N−1, with dimensionless ratio r and finite integer N.
  • All arithmetic operands must use compatible units; no unit conversion is defined or performed.
  • No unit conversion is applicable to the test vectors because all values are dimensionless numerical quantities.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "operation": "sum",
    "expression": "k",
    "index": "k",
    "lower_bound": 1,
    "upper_bound": 10
  },
  "expected_outputs": {
    "numeric_total": 55,
    "closed_form_match": true,
    "closed_form": "N(N+1)/2"
  },
  "working": "Direct sum: 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 = 55. Closed form with N = 10: N(N+1)/2 = 10×11/2 = 110/2 = 55."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

The evaluator has an undefined-result failure mode when an expression such as 1/k includes k=0; it must reject the input instead of producing a numeric result. Geometric closed-form evaluation also requires a separate r=1 branch because the ordinary formula divides by 1-r.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

  • VERIFIED_LEDGER.json
  • evidence-tranche4/tranche4-results.json
  • BOUNDARY_HAZARD_CATALOG.json