Thanks @Sfaci for your comments here and an offline discussion. Let's go with the upstream approach: start times are validated when they're set, and invalid times can't be saved, so that nothing has to be adjusted behind the scenes.

Initially, we were thinking that A/A tests shouldn't need to abide by the deployment window: they don't introduce anything! But while A/A tests are intended to not introduce any changes, there is still risk that they could take down the site by overloading EventGate. Low risk, high consequence, and documented in our past (@phuedx please share link!).

"~25% of exposure and impression events are received out of order." [ 1]

@phuedx - if you could chat with SRE re: failures we want to filter out (etc.d) so that we can reduce some of the alert fatigue here.

Because apps enroll and manage experiments separately, they are not in scope here. When Apps use TK to enroll, we'll want to talk through opt out mechanisms and whether they need to be consistent across our surfaces or not.

I want to confirm with @mpopov and @phuedx about this terminology: "fully anonymous", recognizing this is for logged-in users. Is this language appropriate? It raised my spidey senses.

@Sfaci good question. I didn't mean for the different personas to be the main difference. To me the difference is actually what happens.

Hello @RLazarus! Yes, this has long been in our minds (as @Ottomata 's links suggest).

Proposed implementation: follow the same pattern in T439137: editSaved should record editing interface: create a client-side hook that fires when an edit is successfully published via wikitext editor, and editSaved should pick that up.

My only concern would be that experiments end and users won't go in and add their decision or win/loss details. But, the majority of our end users don't use end dates -- it's primarily used by A/A tests for retention.

@Sfaci -- check to see if we can add hyperlinks to custom hooks text. The reason I ask is because in the current state with the checklist, we have a link to "select a data source" that makes it clear to end user where to make that change.

I've written out the user stories and acceptance criteria in T438509: Implement scheduled experiment validation and deployment-window handling

@RHo I checked in with Kirsten and yes -- this is a specific implementation from the Growth team (@Michael) to more easily test a specific experiment (Revise Tone) which has since ended.

Confirming that we are now safe to remove the analytics format from the experiments API

@phuedx is this to say if we have Kotlin and Swift SDKs, or if we want to continue supporting Android and iOS experiments with their current enrollment methods?

We need a spike to determine what's going on here. Looking at the logs, they're clean.

Closing this out: We reviewed the architecture and the decision brief is approved.