# Life and Rift
Associated to every Azimuth point are two non-negative integers known as *life* and *rift*. This numbering system partition messages according to the quantity of networking key changes and quantity of [breaches](/user-manual/id/guide-to-resets.md), respectively. This is explained in more detail below. These values are utilized by [Ames](/urbit-os/kernel/ames.md) and [Jael](/urbit-os/kernel/jael.md) to ensure that communication between ships is always done with the most recent set of networking keys, and that networking state is appropriately reset when a breach has occurred.
Every ship begins with a `$life` and `$rift` of 0. For galaxies, stars, and planets, these values are stored in the [Azimuth PKI](/urbit-id/azimuth-eth.md#points) as `keyRevisionNumber` and `continuityNumber`, while for moons, these values are stored by their parent. Comets cannot change their networking keys, nor can they breach, and so their `$life` and `$rift` are always 0.
You can check your current `$life` and `$rift` number by running the `+keys our` generator in dojo. You can inspect another ship's `$life` and `$rift` by running `+keys ~sampel-palnet`.
## Life
A ship's `$life`, or *key revision number*, is a count of the number of times which a ship's networking keys have been altered. The initial value of each key is always zero, and the initial `$life` is always 0.
Thus, setting the keys of a ship to a nonzero value for the first time will increment the `$life` from 0 to 1. Rotating to a new set of keys will then increment the `$life` to 2. Setting the keys back to zero would increment the `$life` once more, to 3.
## Rift
A ship's `$rift`, or *continuity number*, is a count of the number of times that a ship has breached, also known as broken continuity.
In other words, a ship's `$rift` will remain at 0 until the first time it is breached.
Network-wide breaches do not affect the `$rift` of any ship. They are only used to count the number of personal breaches.
## Edge cases
Configuring the keys to the same value they already were (i.e. a no-op) is possible, but has no effect on the `$life`. Thus `$life` is actually a measure of networking key *revisions*, and not the number of times they've been set.
Thus under ordinary circumstances, a breach will increment both `$life` and `$rift` since a breach typically also involves changing the networking keys. However, it is possible to breach without changing the networking keys. If the new keys specified as part of a breach are the same as the old, `$rift` will increment while `$life` will not.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.urbit.org/urbit-id/life-and-rift.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.