> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kealinks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Quarantine

> Why every link starts at status 1, and why it does not matter to whoever scans it.

Every link is created with `status: 1` — quarantine. Yours will be too. This is
normal and it is not a restriction on your account.

## What it actually does

A quarantined link runs a live safety check on the destination at each
resolution. An active link (`status: 0`) does not.

That is the whole difference. A quarantined link resolves. Scanning the code
works. Nobody sees a warning, an interstitial, or a delay they would notice.

## How a link leaves quarantine

It earns it:

<Steps>
  <Step title="Three clean checks">
    Observed at resolution, on real traffic.
  </Step>

  <Step title="At least seven days old">
    Both conditions, not either.
  </Step>
</Steps>

Nothing about *you* is involved. Not your plan, not your payment history, not how
long you have been a customer. Quarantine is a property of the link, and a
brand-new destination is unproven whoever published it.

<Note>
  That is deliberate, and it is load-bearing. If release depended on subscription
  status, something on the redirect path would have to ask about billing — and
  the guarantee in [Permanence](/permanence) would become a policy we intend to
  keep rather than a fact about the system.
</Note>

## Editing sends it back

Change a destination and the link returns to quarantine, its verification count
resets to zero, and its version increments.

This is not bureaucracy. Bank three clean checks on a harmless destination, wait
for release, then swap in a malicious one, and you would have a link the fast
path has stopped checking. The version guard closes it: every verification event
carries the version it was observed under, so a check still in flight when you
edit credits nothing toward the replacement.

The cost to you is that a repointed code re-earns release from scratch. It keeps
resolving throughout.

## Statuses

| Value | Meaning                                                   |
| ----- | --------------------------------------------------------- |
| `0`   | Active — resolves directly                                |
| `1`   | Quarantine — resolves, with a live safety check each time |
| `2`   | Abuse — refused with `410`                                |

A link at `2` is never rewound by an edit or by a verification. That is the one
state that does stop a code resolving, and it is reserved for destinations that
failed a real safety check.

## Destinations are checked at write time too

Every destination is validated and scanned before it is stored — on creation and
on **every** edit. `http`/`https` only; no localhost, no private ranges, no cloud
metadata endpoints. A destination that fails returns `422`.

Quarantine supplements that check rather than replacing it: the live re-check at
resolution fails *open* by design, because a safety-provider outage must never
break a printed code. So the write-time scan is what stands between a never-scanned
destination and being served during such an outage.