Source: https://guthlabs.ai/docs/instruments/bitwise-operations-calculator/
instrument / verified-clean
# Bitwise Operations 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]()[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**: Computing & Information
**Tranche**: tranche-2
**Evidence ID**: t2-028
**Ledger rows**: 1
No ledger note is attached.
## Review findings
The truth-table concept for AND, OR, and XOR is standard, but the instrument is not fully specified for fixed-width behavior. The exact unresolved ambiguities are operand signedness, pre-operation masking, result masking, shift-count handling, rotate-count normalization, right-shift semantics, supported maximum width, decimal output convention, and the input shape for unary NOT.
### Formula and scope findings
- The rotate formula is incomplete: it needs masking to n bits and normalization of k, such as k = ((k mod n) + n) mod n, followed by ((x << k) | (x >>> (n - k))) & ((1 << n) - 1). As written, rotating an n-bit value by n can produce a value wider than n bits.
- The rotate formula does not state whether the right shift is logical or arithmetic; rotation requires a logical right shift over the selected width.
- NOT requires width masking, for example (~x) & ((1 << n) - 1). A raw NOT operation can produce a negative signed result rather than an n-bit complement.
- The semantics of <<, >>, and >>> at a selected bit width are unspecified, including overflow truncation, signedness, and whether operands are masked before shifting.
- The specification does not define whether decimal output is unsigned or signed two's-complement, nor how negative input integers are represented.
- The specification says two operands even though NOT is unary; the required input shape for NOT is unspecified.
### Unit assumptions
- Bit width n is a positive integer and is dimensionless.
- Operands and shift counts are integers; shift counts are dimensionless integers.
- For these test vectors, operands are interpreted as unsigned n-bit values and masked to 0 through 2^n - 1.
- Binary output is exactly n bits with leading zero padding; hexadecimal output is the corresponding unsigned value padded to the selected width where applicable.
- The >>> operation is interpreted as a logical right shift within the selected width.
- For rotation, k is normalized modulo n.
## Boundary hardening
**BREAK_CLAIMED** · SELF_FLAGGED
A zero-bit rotate produces an undefined negative shift count and has no valid result, so the calculator must reject it. The rotate operation also has a left-versus-right direction ambiguity unless the supplied formula and n-bit masking convention are enforced.
## 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": {
"operation": "AND",
"x": 172,
"y": 102,
"bit_width": 8
},
"expected_outputs": {
"result_bin": "00100100",
"result_hex": "0x24",
"result_dec": 36
},
"working": "172 = 10101100₂ and 102 = 01100110₂. Bit by bit: 1&0=0, 0&1=0, 1&1=1, 0&0=0, 1&0=0, 1&1=1, 0&1=0, 0&0=0. Therefore 10101100₂ AND 01100110₂ = 00100100₂ = 0x24 = 36."
}
````
## 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-tranche2/tranche2-results.json`
- `BOUNDARY_HAZARD_CATALOG.json`