CARITO NAMING AND SERIAL LAW v1.0
================================

Document: 02_Naming_and_Serial_Law.txt
Status: Foundational / Non-Negotiable
Applies To: All Carrito grids, modules, power frames, accessories, shops, and builders

--------------------------------------------------
1. PURPOSE
--------------------------------------------------
This law defines the mandatory system for naming, labeling, and serializing all Carrito components.
Its purpose is to ensure clarity, compatibility, honesty, and long-term maintainability across
the entire Carrito ecosystem.

All components must be identifiable without relying on marketing language or verbal explanation.

--------------------------------------------------
2. TWO NAMES RULE
--------------------------------------------------
Every Carrito component has two identities:

1) Display Name
   - Human-readable
   - Marketing-friendly
   - Non-authoritative

2) Serial Identifier
   - Technical
   - Permanent
   - Authoritative

If a conflict exists, the Serial Identifier is always correct.

--------------------------------------------------
3. UNIVERSAL SERIAL STRUCTURE
--------------------------------------------------
All serialized Carrito components must follow this structure:

CAR-[GRID]-[MODULE]-[CONFIG]-[COMPAT]-[UPGRADES]-[REV]

Each segment represents a single, verifiable fact.

--------------------------------------------------
4. SERIAL SEGMENT DEFINITIONS
--------------------------------------------------

[CAR]
Fixed prefix identifying the Carrito platform.

--------------------------------------
[GRID]
--------------------------------------
SG   Small Grid
LG   Large Grid
DLG  Deluxe Large Grid

--------------------------------------
[MODULE]
--------------------------------------
MMF   Motor Modular Frame (outer cage)
PF    Power Frame (inner sled)
HH    Helping Hand module
BAT   Battery module
GEN   Generator module
EV    Electric drive module

--------------------------------------
[CONFIG]
--------------------------------------
Describes the primary functional configuration.

Examples:
HF212     Commercial small engine (212cc class)
GEN4000  Generator-based 4000W system
EV72V    72V electric system
CAR-M1   Carrito Motor v1
MOTO650  Motorcycle engine class (special)

--------------------------------------
[COMPAT]
--------------------------------------
Compatibility class declaration:

A  Fully compliant, future-compatible
B  Optimized, limited future compatibility
C  Experimental or extended, no future guarantee

Compatibility must be explicit.

--------------------------------------
[UPGRADES]
--------------------------------------
Upgrade codes indicate supported capabilities, not installed accessories.

Multiple codes may be combined.

Approved codes include:
HH    Helping Hand compatible
HH2   Dual Helping Hand compatible
GEN   Generator capable
HYB   Hybrid capable
BAT1  One battery bay
BAT2  Two battery bays
QC    Quick-connect service interfaces
CLP   Clamp-based service system
STD   No special upgrades

--------------------------------------
[REV]
--------------------------------------
Revision identifier:
R1, R2, R3, etc.
Optional -P suffix for prototype units.

--------------------------------------------------
5. SERIAL EXAMPLES
--------------------------------------------------

CAR-SG-MMF-CAGE-A-STD-R1
CAR-SG-PF-GEN4000-A-HYB-BAT1-R1
CAR-SG-PF-HF212-B-STD-R2
CAR-SG-HH-2ARM-A-QC-R1
CAR-SG-PF-CAR-M1-A-HYB-HH-R1

--------------------------------------------------
6. UPGRADE CODE GOVERNANCE
--------------------------------------------------
Upgrade codes may only exist if they:
- Affect compatibility or expansion
- Require design accommodation
- Are relevant to builders, shops, or inspectors

Cosmetic or easily reversible features must not be encoded.

--------------------------------------------------
7. COMPATIBILITY PROMISE
--------------------------------------------------
The compatibility class is a binding declaration.

Mislabeling compatibility is a violation of platform law.

--------------------------------------------------
8. SERIAL INHERITANCE
--------------------------------------------------
Capabilities belong to the component that physically supports them.

A module must not claim an upgrade that it does not structurally enable.

--------------------------------------------------
9. PHYSICAL LABELING REQUIREMENTS
--------------------------------------------------
All serialized components must include:
- Permanent serial marking
- Grid identification
- QR code linking to specification page (when possible)

Labels must survive repainting and normal service.

--------------------------------------------------
10. SHOP RESPONSIBILITY
--------------------------------------------------
Any shop selling or installing Carrito components must:
- Declare the correct serial
- Disclose compatibility class
- Disclose deviations from standard

Silence is not disclosure.

--------------------------------------------------
11. INSPECTION USE
--------------------------------------------------
Inspectors may rely on serial identifiers to determine:
- Grid size
- Baseline eligibility
- Experimental status

No additional explanation is required beyond the serial.

--------------------------------------------------
12. AMENDMENTS
--------------------------------------------------
Changes to this law require:
- Version increment
- Change log entry
- Platform justification

--------------------------------------------------
END OF NAMING AND SERIAL LAW
--------------------------------------------------
