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

instrument mechanism / verified-clean

Modular Arithmetic Toolkit mechanism

The inspectable method record for Modular Arithmetic Toolkit, kept separate from implementation and qualification.

Status: VERIFIED_CLEANLifecycle: verified-clean

Model scope

The algorithms named are standard, but the instrument cannot receive a full PASS until the exact CRT and congruence-solving semantics, modulus and exponent constraints, canonical residue policy, numeric-precision policy, and step-trace schema are documented. The empty honest_label is a concern: the product should honestly disclose that it is an integer modular-arithmetic tool, not a complete cryptographic implementation, and that JavaScript precision limits may apply.

  • The listed algorithms are standard, but the specification does not define exact input/output schemas for CRT reconstruction or congruence solving.
  • “Congruence solving” is ambiguous: it must specify whether the target is a linear congruence ax ≡ b (mod m), a system of congruences, or another problem class.
  • CRT reconstruction must state whether moduli are required to be pairwise coprime, or whether generalized CRT is supported.
  • Fast exponentiation must specify that the exponent is a nonnegative integer and that results are reduced modulo a positive modulus.
  • Modular inverse must state the required existence condition gcd(a,m)=1 and the canonical output range.

Units and conventions

  • All values are integers; modular arithmetic is dimensionless and has no physical units.
  • The modulus m is assumed to be a positive integer, with residues returned in the canonical range 0 through m-1.
  • Negative input values are normalized by the mathematical modulo operation, so -14 mod 10 = 6.
  • For CRT, the test assumes pairwise coprime positive moduli and returns the least nonnegative solution modulo their product.
  • For linear congruence solving, the assumed form is ax ≡ b (mod m), with all distinct solutions reported as residue classes modulo m.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "operation": "add",
    "values": [
      37,
      -14
    ],
    "modulus": 10
  },
  "expected_outputs": {
    "result": 3
  },
  "working": "37 + (-14) = 23. 23 = 2·10 + 3, so 23 mod 10 = 3."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

The test set exposes two required safeguards: modulus zero must be rejected because modular reduction is undefined, and congruence solving must branch on whether gcd(a,m) divides b. Negative operands also expose a convention hazard if canonical residues are not distinguished from signed language-level remainders.

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