Source: https://guthlabs.ai/docs/instruments/base-n-number-system-converter/
instrument / verified-clean
# Base-N & Number System Converter
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]()[02**Mechanism**Method and assumptions]()[03**Implementation**Binding and validation]()[04**Qualification**Evidence and errata]()
## 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-6
**Evidence ID**: t6-056
**Ledger rows**: 1
No ledger note is attached.
## Review findings
The positional conversion claim is broadly standard, but the Roman and especially Egyptian-fraction claims are underspecified. The empty honest_label should be replaced with an explicit scope such as supported base syntax, exactness/precision policy, canonical Roman range, and the chosen Egyptian-fraction algorithm.
### Formula and scope findings
- Positional expansion/collapse is appropriate for bases 2-36, but the specification does not define the digit alphabet and case rules, validation of digits, signed numbers, or handling of finite versus repeating fractional expansions.
- A Roman numeral symbol lookup table alone is insufficient: the formatter/parser must define standard subtractive pairs, canonical output rules, valid range, and treatment of zero, negatives, and values above the supported range.
- Egyptian-fraction conversion is claimed but no Egyptian-fraction algorithm is specified. The result is non-unique unless a convention such as greedy unit-fraction decomposition is required.
- The input description only mentions number and source/target base, but Roman-numeral and Egyptian-fraction modes require an explicit mode and representation contract.
### Unit assumptions
- All values are dimensionless exact integers or rational numbers; no physical-unit conversion is involved.
- A positional numeral in base b represents the sum of digit times b raised to each place value, with b an integer from 2 through 36.
- For these vectors, base digits use 0-9 followed by A-Z, case-insensitively, and fractional parts are interpreted as exact finite base expansions.
- Roman numerals use canonical modern notation with subtractive pairs IV, IX, XL, XC, CD, and CM, and the supported positive range is assumed to be 1 through 3999.
- Egyptian fractions are assumed to mean positive rational numbers represented as a sum of distinct positive unit fractions, using the greedy algorithm.
## Boundary hardening
### Recorded hazards
- Reject source or target bases outside the inclusive range 2-36, and reject digits whose numeric value is at least the base.
- Define behavior for lowercase versus uppercase digits and for signs, whitespace, malformed radix points, and multiple radix points.
- A finite fraction in one base may require a repeating expansion in another base; the implementation needs a repeating notation, precision limit, or explicit exact-fraction output policy.
- Protect against integer overflow or loss of exactness in JavaScript Number arithmetic; BigInt or rational arithmetic may be required for exact conversions.
- Roman numeral parsing must reject noncanonical or invalid subtractive forms and define behavior for zero, negative values, and values greater than 3999.
- Egyptian fractions can have multiple valid decompositions; without a stated algorithm and canonicality rule, outputs cannot be uniquely verified.
- Egyptian-fraction input must reject a zero denominator and define behavior for zero, negative, improper, or non-reduced fractions.
- Repeated division by the radix must terminate for integer conversion, but fractional conversion can fail to terminate without a stopping policy.
## 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": {
"mode": "positional",
"number": "0",
"source_base": 10,
"target_base": 2
},
"expected_outputs": {
"converted": "0",
"value_in_source_base": 0
},
"working": "0 in base 10 has no nonzero place values. The same value in every positional base is 0, so 0_10 = 0_2. This is the zero-value boundary case."
}
````
## 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-tranche6/tranche6-results.json`