Leave Room for a Python Runtime Maintenance Loop Before Automation Turns Brittle

Suggested cover: a more serious dashboard view where validation metrics, operator guidance and a quiet refresh tail all sit below the main charts.

The lower part of the page is where the dashboard proves it can think and react

By the time the file reaches this final section, the operator has already seen filters, KPI cards and charts. What remains is the layer that often decides whether the screen feels impressive for one minute or genuinely useful over time. This is where the script evaluates a forecasting model, surfaces dispatcher-style recommendations, exposes a small monitoring counter and finally decides when to sleep and rerun.

The vocabulary changes again here, and for good reason. Terms like validation metric, operator guidance and refresh tail belong together because they all answer the same higher-level question: can the interface support judgment rather than just observation. Once a dashboard begins scoring a model, warning about density and quietly refreshing itself, it stops being a static report and starts behaving like a workstation.

This tail end also carries a lot of emotional weight. It is where the page either earns trust or starts overpromising. That is why the blocks below need to stay orderly and source-faithful. The last part of the file should feel like a clear landing.

Ops term	Meaning	Why it matters here
Validation metric	A numeric check on how well the forecasting model matches held-out data.	It tells the reader whether the predictive layer deserves confidence.
Operator guidance	A rule-based message aimed at a dispatcher or monitoring person.	It translates numerical conditions into practical action.
Refresh tail	The final sleep-and-rerun path that keeps the dashboard alive.	It defines the tempo of the whole screen after every render cycle.

The forecasting section turns cached history into a small validation run

                model = GradientBoostingRegressor().fit(train[['hour']], train['intensity'])
                pred = model.predict(test[['hour']])
                c1, c2 = st.columns(2)
                c1.metric("MAE", f"{mean_absolute_error(test['intensity'], pred):.1f}")
                c2.metric("RMSE", f"{np.sqrt(mean_squared_error(test['intensity'], pred)):.1f}")
                fig = go.Figure()
                fig.add_trace(go.Scatter(y=test['intensity'].values, name="Actual"))
                fig.add_trace(go.Scatter(y=pred, name="Forecast", line=dict(dash='dash')))
                fig.update_layout(
                    title="Forecast vs Actual on Validation",
                    xaxis_title="Time Intervals (Test Data Order)",
                    yaxis_title="Traffic Intensity (veh/hour)"
                )
                st.plotly_chart(fig, use_container_width=True)

The evaluation block fits the regressor, measures MAE and RMSE, and then plots fact against prediction in one visible pass.

That makes the predictive layer feel concrete rather than mystical. The file does not merely announce a forecast. It exposes the validation routine right beside the metric cards.

The tail still admits when data is thin and then turns to dispatcher guidance

            else:
                st.info(f"More data is needed to train the model (currently {len(full_df)} records)")
            
            # Dispatcher recommendations
            st.subheader("Dispatcher Recommendations")
            if last['intensity'] > 200:
                st.warning("High density! Reduce speed to 40 km/h")
            if last['avg_speed'] < 30:
                st.error("Traffic jam detected! Activate the warning sign.")

One branch says there is not enough data to train, and the next branch translates the latest intensity and speed into blunt operator-facing messages.

That pairing is helpful because it keeps the dashboard honest on both fronts. It can say when the model is underfed, and it can still offer simple rule-based guidance from the newest row.

The monitoring block stays nested beside the most urgent warning path

                
                # Monitoring (without the hourly error metric)
                st.sidebar.subheader("Monitoring")
                conn = psycopg2.connect(**db_config)
                cur = conn.cursor()
                cur.execute("CREATE TABLE IF NOT EXISTS mart.quality_log (id SERIAL PRIMARY KEY, issue INT, ts TIMESTAMP DEFAULT NOW())")
                cnt = pd.read_sql("SELECT COUNT(*) as c FROM mart.current_traffic", conn)['c'].iloc[0]
                st.sidebar.metric("Records in Stream", cnt)
                conn.close()

The sidebar counter sits inside the same urgent branch as the congestion warning, which makes the file's operational priorities unusually visible.

It is not the cleanest structure in the world, but it does make the decision point visible: the page escalates into extra monitoring only when the stream starts looking unhealthy.

The rerun tail and top-level exception path close the file in full view

    
    time.sleep(5)
    st.rerun()
    
except Exception as e:
    st.error(f"Error: {e}")

The final visible code block keeps the rerun cadence and outer exception path together, so the refresh cycle and failure path stay visible in one place.

This closing order matters because the page finishes on operations, not decoration: render the warning state, refresh the sidebar count, wait briefly and then loop into the next pass.

• This final section covers the validation fallback, operator guidance and the rerun loop that keeps the page alive.
• The code still flows in order, and the last block stays focused on refresh behavior and exception handling.
• The surrounding text remains centered on monitoring, recovery and repeat execution.

A live dashboard earns long-term trust when it can evaluate itself, advise a human and then quietly prepare for the next pass.