Source: https://guthlabs.ai/docs/instruments/subnet-splitter-vlsm-planner/mechanism/

instrument mechanism / verified-clean

# Subnet Splitter / VLSM Planner mechanism

The inspectable method record for Subnet Splitter / VLSM Planner, kept separate from implementation and qualification.

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

## Model scope

The host-sizing arithmetic is standard under the stated IPv4 usable-host assumptions, but the spec is incomplete and ambiguous about address-family scope, zero-host and /31-/32 behavior, allocation ordering, and capacity/alignment validation. The empty honest_label is also a labeling concern: the instrument should explicitly state that it is an IPv4 VLSM planner using conventional network/broadcast reservations and that it does not support arbitrary subnet semantics without additional policy.

- needed_bits=ceil(log2(hosts+2)) is correct only for conventional IPv4 subnets where two addresses are reserved for the network and broadcast; it does not cover RFC 3021 /31 point-to-point links, /32 host routes, or zero-host allocations.

- The specification does not define the allocation-order rule. Correct VLSM planning normally sorts requirements from largest to smallest before allocating aligned blocks; merely allocating in the supplied order can create avoidable gaps or failure.

- The specification omits the block-alignment, address-capacity, and exhaustion checks required to ensure every allocated subnet fits inside the base network.

- The formula does not define behavior for non-integer or negative host counts, IPv6, or host counts that exceed the address capacity of the base network.

## Units and conventions

- Inputs are IPv4 CIDR networks and required host counts are integer counts of usable IPv4 host addresses.

- The +2 reserves one network address and one broadcast address per subnet.

- Subnet sizes are powers of two addresses; block size is 2^needed_bits and prefix length is 32-needed_bits.

- Allocation examples assume requirements are processed largest-first, with each block placed at the next valid CIDR boundary.

- Ranges include network and broadcast addresses; usable ranges exclude those two reserved addresses.

## Inspectable vector

One of 4 source-bound review vectors:

````
{
  "inputs": {
    "base_network": "192.168.10.0/24",
    "required_hosts": [
      100,
      50,
      10
    ]
  },
  "expected_outputs": {
    "allocations": [
      {
        "required_hosts": 100,
        "cidr": "192.168.10.0/25",
        "mask": "255.255.255.128",
        "address_range": "192.168.10.0-192.168.10.127",
        "usable_range": "192.168.10.1-192.168.10.126"
      },
      {
        "required_hosts": 50,
        "cidr": "192.168.10.128/26",
        "mask": "255.255.255.192",
        "address_range": "192.168.10.128-192.168.10.191",
        "usable_range": "192.168.10.129-192.168.10.190"
      },
      {
        "required_hosts": 10,
        "cidr": "192.168.10.192/28",
        "mask": "255.255.255.240",
        "address_range": "192.168.10.192-192.168.10.207",
        "usable_range": "192.168.10.193-192.168.10.206"
      }
    ]
  },
  "working": "100+2=102; ceil(log2(102))=7; block=2^7=128 addresses; prefix=32-7=/25. 50+2=52; ceil(log2(52))=6; block=2^6=64; prefix=/26. 10+2=12; ceil(log2(12))=4; block=2^4=16; prefix=/28. Starting at .0, the /25 consumes .0-.127; the next aligned /26 starts at .128 and consumes .128-.191; the next aligned /28 starts at .192 and consumes .192-.207."
}
````

## Failure boundary

**BREAK_CLAIMED** · SELF_FLAGGED

The specification gives no stated validation behavior for negative host counts, so an input of -2 reaches log2(0), an undefined result. It also leaves host-count and /31 network conventions ambiguous.

## Other records

[01**Overview**](<https://guthlabs.ai/docs/instruments/subnet-splitter-vlsm-planner/>)[03**Implementation**](<https://guthlabs.ai/docs/instruments/subnet-splitter-vlsm-planner/implementation/>)[04**Qualification**](<https://guthlabs.ai/docs/instruments/subnet-splitter-vlsm-planner/qualification/>)

## 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`