Constraint-configuration history

This report reads the audit trail as a record of what editors have done over time. A constraint configuration is not just a blob of settings that happens to produce a recommendation list. In ADR-0015, it is the named tuple that joins soft weights, hard-rule settings, promoted articles, timestamps, and actors. That tuple is where editorial intent becomes queryable. The analyst's job is to notice when the tuple changes, then ask whether the system's behaviour moved in the direction the newsroom meant.

The first table is intentionally literal. It shows every configuration version from constraint_configurations with the weights and hard-rule settings still attached. The useful part is not the number of rows; the useful part is that the rows are ordered decisions. A report can therefore talk about transitions rather than snapshots. The difference between a dashboard and an audit report is exactly that: a dashboard says what the setting is, while an audit report asks how the setting got there.

The first interesting transition is clicks_first to balanced. The starting configuration is a system-authored baseline: diversity weight at 0.00, recency weight at 0.20, sentiment weight at 0.10, the sensitive-topic guard enabled, and max_sensitive held at 0. Half an hour later, editorial ops moves the system into a balanced posture. Diversity rises to 0.30, recency rises to 0.40, and sentiment rises to 0.20. That is not just parameter tuning. It is an editorial claim that pure click pressure is not enough for the product surface.

The second transition is balanced to diversity_forward. This one is more subtle because the recency weight stays at 0.40 while the half-life stretches from 24 hours to 36 hours. The newsroom is not simply asking for "newer." It is relaxing the freshness curve while pushing diversity from 0.30 to 0.60 and sentiment from 0.20 to 0.30. At the same time, max_sensitive moves from 0 to 1 while the guard remains enabled. That combination reads like a controlled editorial experiment: allow one sensitive item, keep the hard guardrail in place, and use soft weights to widen the rest of the list.

The line chart makes the shape of those transitions easier to read. Diversity is the steepest soft-weight move, sentiment follows, and recency rises once before holding steady. That pattern matters because ADR-0010 separates soft weights from hard rules. Soft weights can be blended into the score and moved gradually. Hard rules, like promoted articles and the sensitive-topic cap, are enforceable boundaries. When the audit trail shows a soft-weight rise and a hard-rule setting change in the same edit, the analyst should not flatten them into one "policy changed" note. They have different operational meanings.

That is the practical value of storing configuration history as data. It prevents the organisation from treating editorial policy as folklore. If someone asks why a list became more diverse, the answer is not "the model changed" by default. The answer can be traced to a timestamped configuration row, then checked against the Pareto and sensitive-topic reports. If someone asks whether a hard guardrail was relaxed, the answer is equally concrete: the guard stayed enabled, while the allowed count moved from zero to one in the diversity-forward configuration.

The report does not claim those decisions are automatically correct. It claims they are inspectable. That is the standard the platform needs to meet for an editorial organisation. A configuration history page that only lists settings would satisfy a compliance checklist. An analyst report should do more: name the transitions, separate soft tuning from hard enforcement, and give editors a shared record they can argue from.