1. Specify Cell Configuration and Product Role
Ask the battery-system owner for the released series-cell configuration and the chemistry requirement. Preserve the existing design reference and full protector code beside those inputs. The series configuration belongs to the component requirement because a generic battery-protection label leaves it unresolved. Purchasing should obtain the accepted configuration from the responsible owner rather than reconstructing it from a pack description or photograph.
Identify the product role independently. A protector requirement concerns the protection functions the design calls for; a charger requirement concerns a different part of the battery system. Keep the two purchase lines and their owners distinguishable when both are present. A supplier response covering a battery-management category needs clarification before it can be compared with the specific protector item in the released BOM.
Use the existing design record to distinguish confirmed inputs from proposed changes. If the programme is considering a different series configuration or chemistry, identify that as a separate engineering question. Keep the original protector requirement visible during the discussion. This allows a sourcing enquiry to investigate candidates without allowing a changed pack assumption to become an undocumented part of the confirmed purchase description.
2. Separate Single-Cell and Pack Examples
TI describes BQ2970 within the single-cell protection role. BQ77915 is described as a battery-pack protector with a stackable interface. Preserve those separate descriptions when discussing the examples. The first identifies a single-cell context; the second includes an architecture for scaling. Neither description should be reduced to a universal protector entry that omits the series-cell configuration required by the particular design.
Distinguish the configuration addressed by an individual device from the scope of a stackable architecture. A family description of wider pack applications is not a statement that one unidentified IC directly covers that entire range. Ask the design owner to identify the exact device and approved architecture used in the released pack. Keep the component's own configuration evidence attached to that identity.
For another proposed protector, request its manufacturer documentation under its own code. Record the supported configuration description and the requirement it is intended to answer. If the information only identifies a broad pack category, leave the exact match unresolved. This keeps the comparison focused on the requested configuration without supplying a stacking arrangement or assuming that two protection families perform the same role.
3. Retain Factory Variant Functions
The TI examples separate protection-function descriptions from factory-programmed configuration information. BQ2970 lists fault functions and programmed thresholds and timers; BQ77915 describes programmed thresholds and delays available in different configurations. Preserve that distinction in the part record. A family-level function statement can identify the review topic while leaving the exact variant's configuration to be matched against the released requirement.
Ask the battery owner to identify the accepted functions and the exact variant that implements them. Keep the supporting manufacturer reference and design decision together. If a shortened ordering code conceals a configured option, resolve the identity before ranking a candidate. Similar function names do not supply the missing threshold or timer choice, and purchasing should retain an unresolved option as a question for its owner.
Build a variant comparison with separate entries for configuration identity and required protection functions. Attach the engineering disposition to each material difference. This gives a supplier a defined item to quote and gives the owner a readable exception list. The method is useful even when no numerical setting is included in the public enquiry, provided the responsible team retains the accepted detailed requirement in its controlled records.
4. Keep Pack Approval Outside the Category Match
Release the exact protector requirement with its series-cell context, product role, required functions and accepted variant identity. Keep the pack design revision and responsible owner identifiable. A record that says battery protector approved without those fields can hide whether the component decision covers the current design or an earlier battery arrangement. The purchase line should point to the applicable accepted requirement.
Keep pack-level approval as its own decision. The owner determines which application and safety assessments apply and where their results are recorded. A correct category or variant identity is part of that process; it does not supply the evidence for the assembled pack. Retain open architecture or function questions with their owners so a component comparison remains meaningful within the wider battery-system review.
For an ICULTRA enquiry, send the permitted protector code, quantity and destination, with the accepted cell-configuration description and shareable variant references. Label a different device or configuration as a proposal. Keep charger questions on their own line so the offered item remains clear. After the battery owner accepts a revised selection, update the controlled requirement before treating it as the confirmed purchase item.
Sources and further reading
Manufacturer documents support the technical guidance above. They do not confirm our stock, authorisation or the condition of any offered lot.