Protected applications

The Protected applications page is the registry of every application Churchill protects in your tenant. Each application appears as a card. Selecting a card opens that application’s detail page. A count next to the page title shows how many applications are registered.

To add an application, select + Register application in the page header. Registration is host-driven: the console issues a one-time provisioning code, chrlctl, the Churchill Host CLI, discovers the application on the host, and the result is submitted as a change request for CAB approval. See Registering an application.

Discovered apps awaiting review

When a registration reached the point where the host uploaded its configuration, but nobody reviewed it, it parks here. The Discovered apps awaiting review card lists each pending registration with its bound host (by name where the fleet has one), upload age, tenant, environment, and code digest, plus two actions:

• Resume… re-enters the registration wizard at the discovery step and carries you to review.
• Discard… revokes the registration’s provisioning code after a typed confirmation of the code digest. A discarded configuration can no longer be reviewed or staged. To register the application later, run chrlctl on the host again.

The card only appears while something is pending. See Leaving and resuming a registration for the full story.

The application cards

Each card shows the application’s name and id, plus three fields: manifest (the SHA-256 of the approved manifest), source (where the record came from), and change (the id of the current change request, when one exists). A retired application also shows when it was retired, and its card renders dimmed.

Two pills sit in the corner of every card: a lifecycle chip and a governance pill. Understanding those two is most of understanding this page.

Two statuses, two questions

Every application carries two independent statuses:

• The lifecycle chip answers: what is the application doing on its host right now?
• The governance pill answers: where does its change request stand with the CAB?

Lifecycle

Chip	Meaning
running	The application is up on its approved baseline. No change is in flight.
stopping	A stop was issued and the host is bringing the application down.
change pending	The application is stopped and held under a change window. This is when you make your change on the host.
awaiting approval	The host reported the changed binary and the change request waits on the CAB.
approved · adopting	The change was approved. The host is adopting the new baseline and restarting the application.
online	The application came back up on its newly adopted baseline. Churchill shows this only after the host confirms the application is up, never before.
lockdown	The change was denied, or the window closed without a clean outcome, and the host locked down.
retiring · awaiting host	The application was retired and the host has not yet confirmed the teardown.
retired	The host confirmed the decommission. The record is terminal.

Governance

Pill	Meaning
draft	The application is registered but no change request was submitted yet.
pending approval	The change request is collecting CAB approvals.
quorum satisfied	Enough approvals are in. The change is ready to be authorized.
published	The change was authorized and the new baseline published to the host.
deployed	The host adopted the published baseline.
rejected	The change was denied.
expired	The change request aged out before it was approved.

Approvals themselves happen on the governance screens. See Approvals.

The two pills can honestly disagree. A published governance pill can sit beside an approved · adopting lifecycle chip while the host restarts the application. This is by design. “The CAB approved it” and “the host is running it” are different facts, and the console never merges them into one status.

The detail page

Selecting a card opens the application’s detail page: a back button to the registry, the application’s name with both pills, and two tabs (overview and change history).

Overview

The Application record card lists the full record:

Field	Meaning
app id	The application’s stable unique identifier.
name	The name given at registration.
lifecycle	The lifecycle chip, as above.
source	Where the record came from.
governance	The governance pill, as above.
change	The current change request id, when one exists.
manifest	The SHA-256 of the approved manifest.
exec path	The path of the protected binary on its host.
systemd unit	The unit the application runs as.
binary	The SHA-256 of the approved binary.
scan cadence	How often the host re-checks the binary against its baseline.

The overview also shows the Sandbox configuration card: the monitored paths, environment extras, and the egress allowlist.

While a change is live, a Change window card appears below the record. It shows the reason the change was opened, who requested it, and the deadline with a ticking countdown (“2h 14m remaining”, then “deadline passed”). A stop declared as an emergency adds an emergency pill in the card’s corner. Once the host rescans and reports, the card adds two hash rows: expected (the approved baseline) and proposed (what is on disk now). Until then it reads “Hash comparison pending the host’s rescan report.”

A retired application shows a Decommission card instead. Its pill tracks the teardown: awaiting confirmation while the directive is with the host, host confirmed once the host tears protection down, host not reached when the control plane could not hand the directive over, and no host to reach when the record had no live host. The rows record when it was retired, when the directive was issued, how often it was served, and whether the host confirmed the teardown.

Change history

A table of every change request the application carried: the change id, its state (shown as the governance pill), its type, its manifest hash, and when it was created. An application with no change requests shows “No change requests”.

The action rail

The rail on the right of the detail page holds every action, in two groups. All of them are disabled once the application is being decommissioned.

Change control

These two start and advance a change. The full flow lives on Change control.

• Stop… is available only while the application is running or online. Stopping holds the application under a change window: hash-diff enforcement is suspended for this application only, until the change is approved or rejected. You give a reason (1-200 bytes, no quotes or backslashes) and type the application’s name to confirm. Inside your organization’s change window this is a routine stop. Outside it, the same dialog becomes an emergency declaration: the button reads Declare emergency & stop, the reason is recorded on the audit chain, and the change request is flagged for immediate CAB review.
• Rescan… is available only while the application is held (change pending). Rescanning re-hashes the held binary on the host and reports the result to the control plane. If the hash diverges from the approved baseline, a change request opens for CAB review. Type the application’s name to confirm.

A stop applies to the application as a whole. It is dispatched to the application’s registered host. Stopping an application on a single host is not available.

Note

There is no Start button, and that is deliberate. Restart is automatic: once the CAB approves the change and the re-baseline is authorized, the host adopts the new baseline and restarts the service. If you abandon the change instead (put the original binary back before the deadline), the host restarts the application on its old baseline when the window expires. A window that expires with the binary still changed ends in lockdown.

Registration

• Edit configuration… edits the registered configuration (monitored paths, environment extras, egress allowlist, and an optional description) after a typed confirmation of the application’s name. It is disabled while the registration is under CAB review.
• Recompose… rebuilds the application’s bundles, after a typed confirmation of the name.
• Retire… permanently decommissions the application, after a typed confirmation of the name. The dialog carries a high-risk badge and is explicit: retirement is permanent and irreversible, it decommissions the host, and the application name is released for reuse. The Decommission card on the overview then tracks the teardown.

Before the CAB is active

Until the CAB genesis baseline is sealed, this page is gated. It shows: “Protected-app registration is gated — CAB uninitialized. The genesis baseline must be sealed by the Change Advisory Board before applications can be registered.” Sealing the baseline is the final step of CAB onboarding. See CAB onboarding.

Empty and error states

With the CAB active but nothing registered yet, the page shows “No protected applications registered yet”. Select + Register application to add your first.

If the console cannot load the inventory, it shows “Application inventory unavailable” with a short reason. The registry lives on the control plane, so this usually means the control plane is unreachable. Revisit the page once the console can reach it again.