Source: https://guthlabs.ai/docs/instruments/battery-charge-time-estimator/

instrument / verified-clean

# Battery Charge Time Estimator

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/battery-charge-time-estimator/>)[02**Mechanism**Method and assumptions](<https://guthlabs.ai/docs/instruments/battery-charge-time-estimator/mechanism/>)[03**Implementation**Binding and validation](<https://guthlabs.ai/docs/instruments/battery-charge-time-estimator/implementation/>)[04**Qualification**Evidence and errata](<https://guthlabs.ai/docs/instruments/battery-charge-time-estimator/qualification/>)

## Ledger state

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

**Area**: Electrical & Electronics Engineering — Circuits, Power Systems, Electronics Lab

**Tranche**: tranche-4

**Evidence ID**: t4-138

**Ledger rows**: 1

No ledger note is attached.

## Review findings

The core arithmetic is appropriate for a rough CC estimate, but the specification needs explicit unit conventions and an explicit percentage-to-fraction conversion before implementation. The verdict is NEEDS_REVIEW because those ambiguities can materially change the output.

### Formula and scope findings

- The formula is standard for a rough constant-current estimate only when efficiency is a dimensionless fraction. Because the input is specified as efficiency %, the implementation must convert it as efficiency_fraction = efficiency_percent / 100; using the percentage value directly produces a 100-fold error.

- The formula does not explicitly define capacity and charger-current units, so the result unit is ambiguous unless capacity is in Ah and current is in A, or equivalent units are consistently used.

- The CC-CV taper is mentioned but not modeled; therefore the result is not a full battery charge-time calculation and will generally underestimate actual time.

### Unit assumptions

- Capacity is in ampere-hours (Ah) and charger current is in amperes (A), producing time in hours.

- Capacity and current may use other matching prefixes, such as mAh and mA, because their ratio remains in hours; mixed units require conversion first.

- Efficiency input is a percentage from greater than 0% through 100%, converted to a fraction by dividing by 100.

- The charger current is treated as a constant effective current during the modeled charging interval.

## Boundary hardening

**BREAK_CLAIMED** · SELF_FLAGGED

A zero charging current produces an undefined division-by-zero result, and the CC-CV note describes a second regime without supplying a CV taper formula or data needed to calculate it. Negative-current handling is also unspecified and can produce a nonsensical negative time if applied literally.

## 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": {
    "capacity_Ah": 2.4,
    "charge_current_A": 1.5,
    "efficiency_percent": 90
  },
  "expected_outputs": {
    "estimated_charge_time_hours": 1.77777778
  },
  "working": "efficiency_fraction = 90 / 100 = 0.90; base_time = 2.4 Ah / 1.5 A = 1.6 h; estimated_time = 1.6 h × (1 / 0.90) = 1.6 / 0.90 = 1.77777778 h."
}
````

## Related workflows

[Off-Grid Solar Designerrecharge](<https://guthlabs.ai/docs/instrument-workflows/solar-offgrid/>)

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

- `BOUNDARY_HAZARD_CATALOG.json`
