Source: https://guthlabs.ai/docs/instruments/torque-calculator/

instrument / verified-clean

# Torque Calculator

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

Status: **VERIFIED_CLEAN**Lifecycle: **verified-clean**

## Inspectable records

[01**Overview**Purpose and lifecycle](<https://guthlabs.ai/docs/instruments/torque-calculator/>)[02**Mechanism**Method and assumptions](<https://guthlabs.ai/docs/instruments/torque-calculator/mechanism/>)[03**Implementation**Binding and validation](<https://guthlabs.ai/docs/instruments/torque-calculator/implementation/>)[04**Qualification**Evidence and errata](<https://guthlabs.ai/docs/instruments/torque-calculator/qualification/>)

## Ledger state

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

**Area**: Physics — Kinematics/Projectiles/Orbits, Forces/Energy/Momentum, Rotational Dynamics, Gravitation, Oscillations/Waves, Optics, E&M Fields, Relativity, Quantum, Statistical Thermo

**Tranche**: tranche-5

**Evidence ID**: t5-010

**Ledger rows**: 1

No ledger note is attached.

## Review findings

The single-force magnitude formula is standard under the stated angle interpretation. The specification needs an explicit angle-unit policy, a direction-input/sign convention, and a signed summation formula for multiple forces before it can receive PASS.

### Formula and scope findings

- τ=rFsinθ is the correct scalar magnitude of torque only when θ is the included angle between the position vector r and the force vector F; it does not by itself determine clockwise versus counterclockwise direction.

- No explicit formula is provided for net torque from multiple forces. A standard 2D implementation should assign a sign by rotation sense and compute τ_net=Στ_i, commonly taking counterclockwise as positive and clockwise as negative.

- The inputs do not specify how the clockwise/counterclockwise sense is supplied or inferred. The scalar values r, F, and θ alone cannot uniquely determine torque direction.

### Unit assumptions

- r must be a length, typically in meters; F must be in newtons; torque is then in newton-metres (N·m).

- θ must be interpreted as the included angle between r and F and supplied in degrees or radians consistently; the implementation must explicitly document and convert the chosen input unit.

- For multiple forces, all torque values must use the same length and force units before summation.

- The test vectors use counterclockwise as positive and clockwise as negative for net torque.

## Boundary hardening

**BREAK_CLAIMED** · SELF_FLAGGED

The extreme finite inputs r=1e308 and F=1e308 overflow the plain JavaScript arithmetic result to Infinity instead of producing a finite torque. The specification also leaves angle units and sign conventions implicit, creating additional ambiguity.

## 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": {
    "r_m": 0.4,
    "F_N": 50,
    "theta_deg": 30,
    "rotation_sense": "CCW"
  },
  "expected_outputs": {
    "torque_Nm": 10,
    "direction": "CCW"
  },
  "working": "sin(30°)=0.5. τ=rFsinθ=(0.4 m)(50 N)(0.5)=20×0.5=10 N·m. The supplied rotation sense is CCW, so direction=CCW."
}
````

## 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-tranche5/tranche5-results.json`

- `BOUNDARY_HAZARD_CATALOG.json`