A history graph can be a useful sanity check, but I'd push back gently on the idea that there's a "correct" shape to look for. What the curve looks like depends so heavily on your window orientation, field of view, cover type, and config that a graph from my setup could look completely different from yours and both be working perfectly.

What a healthy trace does tend to show: the position follows a smooth curve through the middle of the day while the sun is inside your configured FOV, then sits flat at the default position (usually 0% or 100% depending on cover type and your inversion setting) outside the tracking window. If you have weather or manual overrides configured, you'll see occasional flat excursions away from the tracked value. That's about as specific as I can get without knowing your geometry.

The more useful thing to look at is the reason attribute on sensor.{device_name}_cover_position (that's the Target Position entity). It tells you exactly which pipeline rule won at each moment, so you can see things like "Sun Tracking (67%) -> Max Position Limit -> 80%" or "no active condition -- default position 100%". The position_explanation attribute adds detail on how the final number was calculated after the winning handler picked a position. If the reason at a given time makes sense for what the sun and your conditions were doing, ACP is working correctly, regardless of what the curve shape looks like.

There's also sensor.{device_name}_control_method which surfaces the same info as a standalone sensor and is easy to add to a dashboard card.

If you really want to understand what's driving each decision, the companion Lovelace card (jrhubott/adaptive-cover-pro-card) is genuinely the best tool for this. It shows the full decision trace and live positions inline, which gives a much clearer picture than a raw history graph.

For details, see the Entities wiki page.