# seals

[coming]

**Proof & cache.** Five agents should not repeat the same passing checkout test against the same code and environment. Seals will let the next worker reuse what the first one proved.

*Like a mark on a path already checked: it counts only while the path is the same.*

*prove it once. changed or unknown? run it.*
*Coming: a passing shop test records code and environment. Matching inputs reuse the seal; changed or unknown inputs run again.*

## the environment is part of the proof

A shop test depends on more than its source file. It also depends on the API it called, its configuration, and the database it used. A passing test will leave a seal of exactly those inputs. Same inputs: reuse. Changed inputs, or inputs antil cannot establish: run.

For example, a checkout test that passed before a product price changed must not justify skipping a test against the changed data. The same applies to a stale Redis catalog entry or an external payment sandbox whose state cannot be checked: antil must run again when it cannot establish a match. These are intended rules, not a shipped cache contract; the exact supported input checks are not defined yet.

[Tunnels](/docs/tunnels/) identify the running apps. [Chambers](/docs/chambers/) identify the resources behind them. The [foundation](/docs/foundation/) gives agents one way to inspect the result.

## what you can do today

You can [run the shop tests through antil](/docs/seals/run-tests/) and inspect their exit status and logs. Every fresh request runs them again. Those records are **not seals**; local result reuse and automatic test selection are not available yet. Local seals are planned for the free, open-source tool.

## when proof crosses machines

A seal from a teammate or a developer laptop needs a trust check before CI can use it. [CI and shared seals](/docs/seals/ci/) belong to **antil cloud: paid, in early access, and not available yet**.