Box

Projects and environments Beta

A box holds projects. A project holds environments. An environment is where events actually land, and it is the unit that owns keys, a chain, and a retention period of its own.

Building a project

Add the project. Name it after the system that will send events, not after a team or a quarter. The name has to still make sense to whoever reads the trail in two years.
Two environments arrive with it. Creating a project makes dev and prod. Add more later if you need them.
Choose retention at creation, within your plan's allowance. It can be lengthened later but never shortened once anything is sealed.
Issue a key for the first sender, from the environment's keys screen. The secret is shown once.
Send a test event and fetch its receipt. Ninety seconds, and you know the path works end to end. See send events.

Why environments are separate chains

Each environment has its own keys and its own hash chain. Development traffic is not filtered out of production evidence; it was never in the same chain to begin with.

This is the first thing a sceptical reviewer probes. The honest answer here is that a development key cannot produce a record in the production chain, because it signs a different one, and no setting anywhere changes that.

Retention

Rule	Why
From 90 days, up to what your box size allows	S keeps evidence 180 days, M 365, L and XL 1,095. Instant proof is 90 days on every size. Retention is chosen when the project is created.
Once a batch is sealed, retention can only grow	Retention becomes the lock on the sealed files themselves, and a lock cannot be shortened. Allowing a lower setting would promise something the archive will not do.

Limits worth knowing before you design around them

Ten environments per project. Enough for the usual development, staging, production shape with room spare. If you need more, that is usually a second project.
One live key per slot, with two slots per environment. That is what makes rotation seamless, and it is covered in key lifecycle.
A box keeps its own system project for its own records. It cannot be closed or deleted, because a box that stopped recording its own activity would be a strange thing to sell.

Closing something down

Nothing is deleted casually, and the order is enforced by the database rather than by a screen asking you twice.

Closing an environment revokes its keys first, and revocation is final. Nothing can still be sending to something you believe is closed. The trail, receipts, verification and downloads keep working until retention runs out.
Closing a project requires its environments to be closed already.
Reopening brings nothing old back: the revoked keys stay revoked and you issue new ones. Reopening a project reopens the project alone, and each environment is reopened on its own.
Deleting is only possible while something is genuinely unused: no key was ever issued on it, and nothing was sealed, refused or recorded. The moment it has been used it can be closed, never removed — evidence does not get tidied away.

Closed is not deleted, and that is the point. A closed environment keeps everything it sealed, and every receipt from it still verifies. Closing stops new events; it does not touch old ones.

Every change is on the record

Creating a project, adding an environment, issuing or revoking a key, changing retention, closing anything: each writes its record in the same transaction as the change, so a change cannot commit without it. The configuration of the thing that holds your evidence is itself evidence, which is the only way the answer to "when did that key exist?" can be trusted.

One detail worth knowing: an environment's records go on its own chain only once it is in use — once a key has been issued, or something sealed. Before that they sit on the box's system chain, which is what keeps a never-used environment deletable.