Repository navigation
Conversation
The event dashboard (/tools/event-dashboard) runs the changepoint API over the three weeks up to a picked date for one country and domain, shows every network as a mosaic coloured by its state on that date, and stacks the detector's per-layer state timelines of the networks picked from it. Picking a network and resolver opens an inspector: hourly measurement charts per layer from /rule_counts, with the detector state behind each and the changepoints of that layer on top, or the fastpath counts; hourly observation counts by failure; and, for a clicked hour, one section per measurement laid out like the measurement viewer, next to the control. An hour's observations are fetched per measurement_uid together with probe_cc, probe_asn and the day, so the lookups stay on obs_web's sort key; the uids come from the hourly observation aggregation, and the fastpath counts from the hourly aggregation, so no measurement_meta or report_id queries are made. The measurement viewer exports the pieces the inspector reuses, its DNS section can take a different control panel, and its verdict panel can be shown without fastpath metadata. The dev server proxies the OONI and changepoint APIs, neither of which serves CORS to localhost. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A guided page (/tools/changepoint-labeler) for recording ground truth on detected changepoints. An operator loads the changepoints of a country, domain and period into a queue and, for each one, reads the evidence in the event dashboard's inspector, picks a verdict (blocked, ok or undecided), brackets the transition by selecting hours on the charts (last ok / first blocked, or last blocked / first ok) and saves. Labels have the shape of changepoint_label rows and are append-only, the newest one being the current label. Reading changepoints and reading and writing labels go through a three-call LabelApi; until its real implementation exists a mock serves changepoints from the changepoint API's on-the-fly detection, with stable uuids, and keeps labels in the browser, with a JSON export. The inspector takes extra chart marks, reports its selected hour, and can drop its close link and its scroll-into-view so the labeler can embed it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The queue is now every changepoint the detector job stored in a date range, read from /stored_changepoints, so picking a country and domain is no longer needed; the queue can still be narrowed to a country or a domain. Labels are saved with POST /changepoint_labels, replacing the mock. The evidence for a changepoint comes from re-running /changepoints for its country and domain over the queue's range plus a week on each side, shared by every changepoint of that country and domain. The API cannot list labels yet, so the labels posted from this browser are kept locally to mark what is done and show a changepoint's history. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each queue entry, the queue's country filter and the changepoint header carry the country's flag, built from its code as Unicode regional indicator letters. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Member
Author
After some conversation on this with @LDiazN we concluded that probably a good way to do this is to think of the changepoints as a way to discover events, but what we are labeling are things at a higher order. Specifically we will introduce the is_event field to indicate if something actually changed or not. |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implement work discussed with @LDiazN related to event detector v2 improvements and labelling.
This is a new UI we implemented for viewing the changepoints, measurements and observation and performing labeling.
Requires the following pieces of code that need to be rolled out into prod:
is_eventto address the fact that we might be labelling a change-point that is not realAn open question we have that we need to reach a more concrete decision on is how to handle cases in which the source of the issue in the changepoint/event detection was actually the analysis being incorrect. Options include either marking those as undecided, pipeline fail, or what we believe the true outcome to be assuming that the pipeline will get fixed.
Then once this lands we should delete all the old code, on which part of this is based on, for viewing measurements, labelling them and seeing observations since it's a bit redundant.
Eventually part of this should end up inside of explorer.