Guide: EVCC operations and backend orchestration
The EVCC path is how you drive loopback sessions, backend adapter checks, and differential proof. The snapshot includes native EVCC reference profiles plus adapter-backed Josev and EVerest surfaces.
Backends in the snapshot
Backend |
Execution posture |
Use it for |
|---|---|---|
native |
in_process |
health-check, capability-probe, native-session-launch, timeout-capture … |
josev |
external_process |
health-check, capability-probe, external-process-start-hook, external-process-stop-hook … |
everest |
external_process_or_container |
health-check, capability-probe, external-process-start-hook, external-process-stop-hook … |
When to stay native
For fast loopback bring-up and profile sanity checks.
When you want deterministic reference coverage that is controlled entirely inside ChargeLink.
When you need a fast debugging baseline before moving to Josev, EVerest, or hardware EVCC.
When to use external backends
When you need vendor-aware differential behavior.
When the release question is about adapter readiness, orchestration, or partner proof.
When MCS differential matrices or external EVCC runtime proof are part of the gate.