1. Standardized module interface
   • Every powered module should use the same mechanical alignment datum, pogo-pin contact zone, polarity convention, and interface definition.
   • A stable interface reduces tooling variation, simplifies assembly, and supports future module families.
2. Low-voltage power distribution
   • The powered base should convert external power to a safe low-voltage DC bus before distributing power through the module stack.
   • Current rating, contact resistance, thermal rise, and stack height must be validated rather than assumed.
3. Mechanical self-alignment
   • Magnets should provide repeatable gross alignment.
   • Mechanical geometry should provide final anti-rotation and contact-position accuracy so pogo pins are not forced to carry alignment loads.
4. Separable power and data strategy
   • Initial versions may use power-only pogo interfaces.
   • Future versions should reserve interface positions for module identification, communication, or configuration recognition.
5. Serviceable modular architecture
   • Modules should be replaceable without tools where practical.
   • The interface should tolerate normal user handling, repeated mating cycles, and minor contamination.
6. Future-compatible intelligence layer
   • Embedded identification elements, module metadata, lifecycle tracking, authentication systems, configuration recognition, and distributed module communication should be considered without forcing premature complexity into the first version.

• Accept external power input.
• Provide isolated or safely limited low-voltage DC output as required by the product class.
• Distribute power to the first module through pogo contacts.
• Optionally host the primary controller, wireless module, current monitoring, and stack detection circuitry.

• Power conversion and protection are centralized, improving serviceability and simplifying passive modules.
• The base becomes the main safety-critical assembly and should receive the most complete electrical validation.

• Provide repeatable mechanical alignment.
• Transfer power through spring-loaded contacts.
• Optionally transfer data, identification, or configuration signals.
• Define mating orientation and polarity protection strategy.

• Interface standardization is the core platform asset.
• Contact layout, pitch, wiping action, plating, spring force, and contamination tolerance affect long-term reliability.

• Receive low-voltage power.
• Drive local LEDs directly or through a local driver.
• Pass power upward to additional modules if stacking is allowed above it.
• Optionally expose local identification or control electronics.

• Passive lighting modules are simpler and cheaper.
• Intelligent lighting modules require local regulation, addressing, firmware support, and potentially ESD protection on data contacts.

• Modify height, optical output, spacing, or appearance.
• May be electrically passive or may pass power and data through.

• Passive modules still need controlled geometry and contact pass-through reliability if they sit between powered modules.
• Non-electrical modules should be clearly keyed so users do not expect them to transmit power unless designed to do so.

• Optionally identify installed modules.
• Determine stack configuration.
• Control lighting outputs.
• Support firmware updates, diagnostics, and future module families.

• ESP32-class control is plausible for wireless control and local intelligence.
• Distributed module communication must account for hot-plug behavior, stack ordering, contact bounce, addressing, and fault isolation.

• Positive low-voltage bus
• Ground return
• Optional duplicated positive and ground contacts for current sharing and redundancy

• Simple, manufacturable, and easier to validate.
• Lowest firmware burden.
• Good first production architecture if intelligent module detection is not required immediately.

• No automatic module identification.
• No per-module control unless each module is independently switched or electrically encoded.

• Power bus positive
• Power bus ground
• Identification signal
• Communication data
• Communication clock or second data line
• Optional detect or presence pin

• Allows a stable mechanical interface to support later intelligent modules.
• Avoids redesigning all module tooling when intelligence is added.

• More contacts increase cost, footprint, tolerance sensitivity, and contamination risk.
• Unused contacts still require mechanical and ESD planning.

• Low-cost module type recognition.
• Simple lighting accessories with limited variants.

• Limited number of reliable IDs.
• Tolerance, contact resistance, and stacked combinations can complicate readings.
• Not suitable for authentication or rich metadata.

• Unique ID, module type, revision, and lifecycle tracking.
• Moderate scalability with minimal contacts.

• Requires firmware protocol handling.
• Stack topology and addressing need careful design.

• Non-contact identification.
• Module metadata, production tracking, service records, and authentication systems.

• Read reliability depends on antenna placement, materials, stack geometry, and reader range.
• Identifying multiple stacked modules may require deliberate reader/antenna architecture.

• Addressable lighting, sensors, future non-lighting modules, diagnostics, and firmware-defined behavior.

• Requires bus electrical design, addressing, ESD protection, hot-plug handling, and protocol validation.
• More complex manufacturing test requirements.

• Define a nominal bus voltage early, such as a low-voltage DC rail appropriate for LED power and safety requirements.
• Size pogo contacts for worst-case stack current, not average current.
• Consider duplicated contacts for positive and ground rails if current or reliability requires it.
• Measure voltage drop across the full stack under load.
• Validate thermal rise at contacts, traces, and LED drivers.

• Include reverse polarity protection if contact orientation can be ambiguous.
• Include current limiting or fault shutdown in the powered base.
• Include ESD protection on exposed signal contacts.
• Consider inrush control if modules include local bulk capacitance.

• Use a single shared low-voltage return through the stack for basic lighting.
• If communication or sensing is added, treat ground bounce and contact resistance as design constraints.

• Assume users may add, remove, or rotate modules while power is present unless the product physically prevents it.
• Firmware and power circuitry should tolerate contact bounce and partial mating events.

• Power-up self-check.
• Detect stack presence.
• Identify modules if identification hardware exists.
• Build a module configuration table.
• Apply lighting control rules.
• Monitor current, faults, and thermal indicators if sensors are present.
• Handle user input or wireless control.
• Store firmware version, hardware revision, and configuration data.

• Report module type, revision, capabilities, and status.
• Accept commands from the base.
• Control local LED channels or local functions.
• Report faults where applicable.

1. Base power applied.
2. Base enables protected low-voltage bus.
3. Base checks current and presence signal.
4. If identification exists, base queries module metadata.
5. Base validates configuration.
6. Base enables lighting behavior.
7. Base monitors faults and stack changes.

Text
SOLX/
  00_Product_Requirements/
  01_System_Architecture/
  02_Electrical/
  03_Mechanical_Interface/
  04_Firmware/
  05_Manufacturing/
  06_Test_Validation/
  07_BOM_Sourcing/
  08_Patent_Support/
  09_Revision_History/

• System architecture brief
• Electrical interface control document
• Pogo-pin pinout and contact rating table
• Power budget
• Stack current and voltage drop analysis
• Firmware architecture note
• Manufacturing assembly workflow
• End-of-line test plan
• Module revision matrix
• BOM with approved alternates
• Patent-supporting technical diagrams

• Measure bus voltage at each stack level under load.
• Measure contact temperature rise at maximum current.
• Test short-circuit and overload behavior.
• Test hot-plug and contact bounce behavior.
• Validate ESD robustness on exposed contacts.

• Cycle module mating and removal.
• Verify pogo-pin compression range.
• Verify magnet alignment repeatability.
• Test tolerance stack-up across multiple modules.
• Test contamination sensitivity at contacts.

• Verify startup sequence.
• Verify module detection logic.
• Verify fault recovery behavior.
• Verify configuration recognition across supported module combinations.
• Verify update and version tracking procedure if applicable.

• Define incoming inspection for magnets, pogo pins, PCBs, and housings.
• Define assembly torque, adhesive, or press-fit requirements if used.
• Define electrical continuity test fixtures.
• Define final functional test workflow.

• Standardized magnetic electrical interface for stacked modules.
• Combined mechanical alignment and electrical pass-through architecture.
• Modular configuration recognition using embedded identification elements.
• Lifecycle tracking and module metadata associated with physical lighting modules.
• Distributed module communication over a vertical stack interface.
• Tool-less serviceable lighting modules sharing a common power and data interface.

1. Define the first-generation interface pin count and pin functions.
2. Define nominal bus voltage, maximum stack current, and maximum number of powered modules.
3. Decide whether first revision is power-only or reserves contacts for identification and communication.
4. Create an electrical interface control document.
5. Create a preliminary power budget.
6. Create a pogo-pin contact reliability test plan.
7. Create a module revision and metadata schema.
8. Create basic firmware state-machine documentation if ESP32 integration is included.