Glossary
These are the terms used throughout the Churchill documentation, grouped so that related ideas sit together rather than in strict alphabetical order.
Core concepts
Section titled “Core concepts”A Linux machine you have brought under Churchill’s protection. Each host runs the on-host parts of Churchill and reports its health to your control plane.
Protected application
Section titled “Protected application”An application on a host that you have registered for protection. Churchill watches it while it runs and will terminate it if it is tampered with.
Operator
Section titled “Operator”A person who uses the Churchill dashboard to enroll hosts, register applications, watch the fleet, review evidence, and manage lockdowns and governance.
The operator role that can run the CAB ceremony, admit CAB members, manage operator accounts, and view the setup receipt. Every tenant has an owner. Other operators sign in with the standard operator role.
Tenant
Section titled “Tenant”Your organization’s isolated space within Churchill. All of your hosts, applications, users, and evidence live within your tenant and are separated from those of other organizations.
Enrollment and identity
Section titled “Enrollment and identity”Provisioning code
Section titled “Provisioning code”A one-time code, starting chrl1-, that you issue from the Register application wizard in the dashboard. A host redeems it once, within its lifetime, to pair with the control plane. It carries the control plane’s address, its server key pin, your tenant ID, and a single-use secret; no host keys or bundles ride on it. Every code in the tenant is tracked on the Provisioning codes register, where a live code can also be revoked.
chrlctl (Churchill Host CLI)
Section titled “chrlctl (Churchill Host CLI)”The host-side command-line tool, and the only Churchill executable that needs to be placed on the host’s disk. You run chrlctl register with a provisioning code; it contacts the control plane, proves the host’s identity, and brings the rest of Churchill onto the host. See Running chrlctl.
Session
Section titled “Session”An authenticated connection between an enrolled host and the control plane, tracked with its own health state. The Sessions column on the Fleet page counts how many are currently active on each host, and the host’s Sessions tab lists them. A session is not a recording. See Recording below.
Enrollment status
Section titled “Enrollment status”Where a host’s identity stands in the enrollment register: enrolled, quarantined, retired, or locked. It appears in the Enrollment column on Fleet and on the host’s detail rail.
Containment
Section titled “Containment”The operator actions that move an enrolled identity between statuses: Quarantine cuts a suspect host off, Release returns a quarantined host to service, Unlock clears a lockdown the control plane holds over the host, and Retire permanently decommissions it. Each is confirmed by typing the host’s client identity, and Unlock also takes a written reason. See Fleet.
Baseline
Section titled “Baseline”The trusted, known-good state of a protected application that Churchill enforces. Everything the application does is measured against its baseline, and drift from it is treated as a compromise. An enforced baseline never changes in place. It is only replaced through change control with a newly approved one.
Manifest
Section titled “Manifest”The hash-pinned list of what a protected application may run and consume. It is what a baseline contains and what Churchill checks at execution time.
Monitoring and detection
Section titled “Monitoring and detection”Heartbeat
Section titled “Heartbeat”A regular signal a protected host sends to the control plane to show it is alive and healthy. A gap in heartbeats tells you a host has gone quiet and needs attention.
Compromise
Section titled “Compromise”Any unauthorized modification of a protected application or its host that Churchill detects, such as runtime tampering, memory injection, unauthorized privilege escalation, or library hijacking. A confirmed compromise leads to termination and lockdown.
Soft deny
Section titled “Soft deny”The refusal of a merely unauthorized action, such as a “stranger” binary not on the manifest trying to execute. The workload sees an ordinary permission error, the refusal is recorded as evidence, and nothing is terminated. A soft deny never escalates to a kill or lockdown.
Written φ. A heartbeat-health score computed for each host from its own observed heartbeat rhythm, so the scale adapts to how that host normally checks in. It stays low while heartbeats arrive on cadence and climbs as they run late. The dashboard marks a host warning at 8 and critical at 12; you will see the score in the φ column on the Fleet page.
Lockdown
Section titled “Lockdown”The state a host enters after Churchill terminates a compromised process. While a host is in lockdown it will not silently restart the protected workload. The state is held by the control plane, not by a file on the host, so a reboot does not clear it. You review the evidence and then Unlock the host from the console, with a reason, to return it to service.
Host posture
Section titled “Host posture”What the control plane asserts about a host, independently of its heartbeat health: isolated (the host is running but has lost control-plane contact), lockdown (the host is contained), or stale (the host has been silent past its heartbeat budget). A host with none of these shows a dash. It appears in the Posture column on Fleet, with the reason and the operator or control plane that asserted it.
Capture posture
Section titled “Capture posture”Whether a host records interactive terminal sessions. The dashboard shows it as recording, not recording, arm failed, tampered, retired, or not reported. A posture of not recording, arm failed, or tampered is a coverage gap: an empty session list on such a host is not evidence that no sessions occurred. See Recordings.
Evidence and recordings
Section titled “Evidence and recordings”Evidence
Section titled “Evidence”The tamper-resistant record of what a host has observed and reported, which you review when investigating an event. Evidence is what you use to understand and justify any action you take. You browse and filter it on the Evidence page.
Audit chain
Section titled “Audit chain”The append-only record of operator actions in the dashboard: sign-ins, approvals, stops, replays. Each entry is hash-linked to the one before it and signed, so history cannot be altered or removed without detection. It gives you a trustworthy, ordered history for forensics and compliance. What hosts observed and enforced is evidence, above.
Recording
Section titled “Recording”A sealed capture of an interactive terminal session on a protected host, which you can replay from the dashboard. Recording is armed per host: chrlctl asks whether to record interactive logins during registration, and a host that declines stays unarmed until it is registered again. Input typed with echo off (a password at a prompt, for example) is redacted at capture time and never enters the recording. See Recordings.
Governance and change control
Section titled “Governance and change control”CAB (Change Advisory Board)
Section titled “CAB (Change Advisory Board)”Churchill’s governance body for reviewing and approving planned changes before they take effect, so that legitimate changes follow an auditable approval process rather than being made silently. A board has at least two members, and each member signs with their own passkey. See CAB overview.
CAB chair
Section titled “CAB chair”The organization owner who runs the CAB ceremony and facilitates the board. The chair may or may not also be a voting member. When sign-in locks you out, the console directs you to contact your CAB chair.
Genesis baseline
Section titled “Genesis baseline”The sealed founding record of your tenant’s governance: the CAB member roster and initial system state, hashed and approved unanimously during the setup ceremony. Every later change is voted against this root, and there is exactly one genesis per tenant.
Quorum
Section titled “Quorum”The number of CAB approvals a change request needs before it takes effect. The genesis baseline is the one exception: it requires unanimous approval from every member.
Receipt
Section titled “Receipt”A CAB member’s signed verdict on a change request, cast as an ed25519 signature with the member’s passkey. Approvals and rejections are both cast as receipts. Every receipt is recorded with the change request and on the audit chain.
Change request
Section titled “Change request”A proposed change to what runs under protection, such as registering a new application or re-baselining one whose binary changed. The CAB approves or vetoes it. A change request moves through pending approval, quorum satisfied, published, and deployed, or it ends rejected or expired.
Change window
Section titled “Change window”The held state a protected application enters when you stop it for a change. While the window is open, hash enforcement is suspended for that application until the change resolves. Every window carries a deadline, 4 hours by default.
Emergency change
Section titled “Emergency change”A stop declared outside the configured change window. The declaration is recorded on the audit chain and flagged for immediate CAB review.
Adoption
Section titled “Adoption”The host-side half of a published change. Published means the control plane has issued a new baseline; adopted means the host has picked it up and restarted the application on it. The console tracks the two as separate facts and never merges them.
The components
Section titled “The components”Host sentinel
Section titled “Host sentinel”The on-host guardian. It watches the host and the protected process from the outside and is the component that terminates a compromised process and places the host into lockdown.
In-process sentinel
Section titled “In-process sentinel”The lightweight sentinel that runs inside a protected application and watches it from within its own memory for signs of tampering, able to stop the application instantly if something is wrong.
Control plane
Section titled “Control plane”The off-host part of Churchill. It collects heartbeats and evidence from every host, locks in each host’s baseline, and dispatches lockdown and recovery commands. The dashboard is your window into it.