Before we dig into the specifics for each broad type of SLI, let's formalize the recommendation we made earlier that SLIs should be expressed as the ratio of two numbers, good events divided by valid events. When talking or writing about SLIs, the general form we suggest you use is the proportion of valid events that were good. Expressing all your SLIs in this form has a couple of useful properties. First, your SLIs fall between zero percent and 100 percent, where zero percent means nothing works, and 100 percent means nothing is broken. The scale is intuitive to reason about and directly translates to percentage reliability SLO targets and Error Budgets. Second, your SLIs have a consistent format which can serve as an interface for abstraction. Consistency allows common tooling to be built around your SLIs. Alerting logic Error Budgets and calculations and SLO analysis, and reporting tools can all be written to expect the same inputs. Good events, valid events, and your SLO threshold. But what do we mean by valid, and why do we use valid events not all events in the SLI equation? Sometimes you may need to completely exclude some events recorded by your underlying monitoring metrics from being included in your SLI, so they cannot consume your Error Budget. This phrasing allows you to make this exclusion explicit and specific by declaring those events to be invalid. For systems serving requests over HTTPS, validity is often determined by request parameters like host name or requested path to scope the SLI to a particular set of serving tasks, or response handlers. For data processing systems, validity is usually determined by the selection of inputs to scope the SLI to a subset of data. The definition of good changes considerably depending on the expected behavior of the system, but there are some common patterns that you may find useful. In the next couple of videos, we'll talk about how to specify the common types of SLIs we've discussed already, and touch on some of these patterns.