The connected cloud owns command lifecycle state; only an approved vehicle service supplies terminal physical outcome evidence.
AutoBuild your programIF-04 · Cloud interface
Remote-service intent, dispatch and outcome
Separate user intent, policy authorization, dispatch receipt, device acknowledgement and verified physical outcome for approved remote services.
Authority model
Name the source—and name what it cannot prove.
The same message can be observation, projection, plan, receipt or physical evidence. This contract keeps those meanings separate.
Timeout, replay, ownership change, invalid vehicle state or missing acknowledgement remain uncertain or failed—never successful by assumption.
A request, HTTP response, queue receipt or TCU acknowledgement is not proof that the vehicle changed state.
Product allocation
Producer and consumer responsibilities are explicit.
A product can appear on both sides when it transforms one authority into another; each transformation retains its own evidence.
versioned→fail-closed
Transport allocation
Choose transport after semantics are fixed.
The program can select one or more transports without changing the source authority or failure contract.
Authenticated command APICommand event and acknowledgementOEM vehicle-service adapter
Compatibility vector
- schema or ABI version
- producer release
- consumer release
- policy and entitlement revision
- content/configuration revision
- territory/platform profile
Acceptance evidence
- contract compatibility
- nominal and negative scenarios
- ordering, replay and idempotency
- latency, capacity and resource bounds
- security, privacy and role enforcement
- offline, recovery and rollback
- target or operational acceptance
OEM program workshop
Freeze the Remote-service intent, dispatch and outcome contract before integration.
Allocate owners, transport, schema, releases, policy, content, degradation, replay and target acceptance in one controlled baseline.