diff --git a/vehicle-data-platform/docs/product-spec.md b/vehicle-data-platform/docs/product-spec.md
index a1c16628..d078709a 100644
--- a/vehicle-data-platform/docs/product-spec.md
+++ b/vehicle-data-platform/docs/product-spec.md
@@ -14,6 +14,21 @@ The current product goal is to evolve toward a production vehicle data managemen
 
 The product must not expose GB32960, JT808, and Yutong MQTT as three final products. They are acquisition paths. The final product is a vehicle service that answers online state, current location, historical trajectory, source reliability, alert responsibility, and statistical evidence for one vehicle.
 
+## Adjusted Product Goal
+
+The active goal is now a vehicle data management middle platform for production operations, not a protocol demo or raw-data console. The reference shape is a mature commercial telematics platform:
+
+- Realtime monitoring: map-first fleet status, vehicle online state, source freshness, abnormal location and current telemetry.
+- Trajectory replay: vehicle/time-window playback, AMap route context, speed and mileage evidence, gap detection, and raw-frame jump links.
+- Historical query: paged location, raw frame, parsed fields, and export with field trimming for large responses.
+- Alert events: source outage, no realtime update, VIN/binding failure, location missing, mileage abnormality, parse failure, and cross-source inconsistency.
+- Notification workflow: rule owner, channel, escalation window, affected vehicle scope, recovery evidence, and copyable notification text.
+- Statistics: daily/range mileage, online rate, offline duration, completeness, source consistency, and evidence-backed drill-down.
+- Vehicle governance: VIN-centered identity, plate, phone, OEM, binding health, source coverage, and missing-source remediation.
+- Ops quality: gateway, queue, Redis, TDengine, MySQL, AMap, release, capacity, and lag health.
+
+The dashboard should behave like a command center for vehicle service operations. It should not use marketing-style hero composition. The first screen should expose operating state, map capability, alert pressure, and direct workflow entry points.
+
 ## Primary Screens
 
 The platform navigation should use vehicle-service language rather than protocol-product language: