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

instrument / verified-clean

Binomial Theorem Expander

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Status: VERIFIED_CLEANLifecycle: verified-clean

Inspectable records

Ledger state

The current ledger marks this instrument verified clean within the source-bound verification corpus.

Area
Mathematics — arithmetic through advanced (algebra, matrices, calculus, sequences/series, number theory, combinatorics, graphing, complex numbers, geometry, logic, sets)
Tranche
tranche-4
Evidence ID
t4-117
Ledger rows
1

No ledger note is attached.

Review findings

The mathematical identity is correct under the stated domain and commutative-algebra assumptions, but the specification lacks the required n domain, explicit summation bounds, binomial-coefficient definition, and symbolic-input grammar. The honest label should state that n must be a nonnegative integer and that a and b must be compatible commutative terms.

Formula and scope findings

  • The formula is standard only when n is a nonnegative integer and the summation bounds are explicitly k=0 through k=n; these constraints are omitted.
  • C(n,k) is not defined in the specification; it should be defined as n!/(k!(n-k)!) or an equivalent binomial-coefficient operation.
  • The input description 'a, b terms' is ambiguous about whether symbolic terms are commutative algebraic expressions and what syntax is accepted.

Unit assumptions

  • a and b are commutative algebraic terms that may be added and multiplied.
  • If a and b carry units, they must have compatible identical units for a+b to be meaningful; every resulting term then has those units raised to the nth power.
  • n is dimensionless and restricted to a nonnegative integer; no unit conversion is performed.

Boundary hardening

Recorded hazards

  • Reject or clearly handle n values that are negative, nonintegral, NaN, infinite, or otherwise outside the polynomial binomial-theorem domain.
  • The implementation must enforce or document the summation range k=0..n; an unrestricted sum is ambiguous and can produce invalid terms.
  • Avoid factorial overflow for large n; use a stable binomial-coefficient recurrence or arbitrary-precision arithmetic where appropriate.
  • Handle zero coefficients, coefficient 1, negative terms, parentheses, and canonical ordering correctly in the output string.
  • The b=0 edge case requires consistent handling of the k=0 factor b^0; the mathematical result is 1 for that factor, not an error.
  • Symbolic parsing and formatting rules are unspecified, including implicit multiplication, operator precedence, parentheses, powers, and variable names.

Errata and corrections

No applied erratum is attached to this unique-name record.

Inspectable example

4 review vectors are recorded. One source-bound sample is shown below.

{
  "inputs": {
    "a": "x",
    "b": "2",
    "n": 3
  },
  "expected_outputs": {
    "expanded": "x^3 + 6x^2 + 12x + 8"
  },
  "working": "k=0: C(3,0)x^3*2^0 = 1*x^3*1 = x^3. k=1: C(3,1)x^2*2^1 = 3*x^2*2 = 6x^2. k=2: C(3,2)x^1*2^2 = 3*x*4 = 12x. k=3: C(3,3)x^0*2^3 = 1*1*8 = 8. Therefore (x+2)^3 = x^3 + 6x^2 + 12x + 8."
}

Related workflows

No source-defined multi-instrument workflow membership is recorded.

Sources and evidence

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

  • VERIFIED_LEDGER.json · VERIFIED_CLEAN
  • evidence-tranche4/tranche4-results.json