Endpoints, proof, and management

Every row on the Manage page is an endpoint — a hostname (and port) the Hub knows about. Two independent facts describe each one, and keeping them separate is what makes the page honest:

Fact	Question it answers
Proof	Has the Hub observed this endpoint serving a certificate?
Management	Has an operator put this endpoint under management?

They are orthogonal, and every combination is meaningful:

• Proof without management is the normal starting state: a Scout saw the endpoint serving, nobody has adopted it yet.
• Management without current proof is a coverage gap: the endpoint is yours to renew, but nothing has confirmed lately what it serves.

The states you see

Untracked — the endpoint serves a certificate (proof exists) but is not under management. Its offer is Adopt. When the certificate that covers it belongs to a managed sibling — one certificate covering several names, some already adopted — the row is labelled covered instead: that certificate already renews on the sibling's behalf, which is why the row is quiet. A covered row still offers its own one-click Promote, and eligible covered siblings are in any case adopted automatically once a renewal of the covering certificate verifies.

Unproven — the Hub knows the name but has never seen it serve. All it offers is a probe. No renewal automation, no autopilot, no scoring-driven remediation: the Hub will not manage what it has never observed.

Stale — the endpoint had served proof once, but no active Scout has scanned it within the last 30 days (or the Scout that used to is gone). Staleness is a statement about freshness, not a revocation of proof: the endpoint is still known to have served, but nothing current confirms what it serves now. Hub-side probes do not reset this clock — only a Scout observation does, because staleness is specifically "no agent is watching this."

Managed — adopted, actively lifecycle-managed. This is where Renew Now, renewal profiles, and autopilot live. Live served proof is what authorizes the page's posture claims: the score, the findings, and any remediation offers all rest on a current observation.

There is no 'monitor but don't manage' state

Either an endpoint is managed or it isn't. A watch-only stratum was deliberately removed from the product: it reported nothing actionable and blurred the one question that matters. If you want the Hub renewing an endpoint, adopt it; if not, it stays Untracked and still gets observed.

Adoption and its inverse

Adopt is offered on the untracked endpoint's row — as a one-click Promote when its certificate group already has a renewal profile (the profile is inherited, not asked for twice), or with a profile picker when nothing in the group has one yet. Its effect is certificate-shaped: the profile you assign is written across the whole group, and once a renewal of that certificate verifies, eligible untracked siblings are adopted automatically (see Certificates: identity and observation for how groups work). That automatic sweep is deliberately conservative: it skips endpoints without served proof (an unproven name is never swept into management by a sibling), endpoints on a different Scout, and endpoints in protected postures — a group converges on managed without quietly erasing a state someone set on purpose.

Delete is the way back out, and it is available on every endpoint. It lives in the endpoint drawer and requires the hostname typed back — that is the safeguard. A managed endpoint is demoted as part of the delete: any in-flight renewal is cancelled and the Scout releases its parked work before the row goes. It removes the endpoint's row and its delivery wiring, but keeps history — scans, renewals, deployments, the audit trail — because those record what was true. Deleting a wildcard removes the wildcard's own row; the hosts served under it are their own endpoints and stay.

Coverage gaps are named, not dramatized

The Hub sees an endpoint from up to two vantages: internal (the Scout on the box, probing what it actually serves) and external (a probe from the Hub's network position). When one vantage is missing or not current, that is reported as a coverage gap — "waiting on re-check", "no external observation" — never as a disagreement. A mismatch verdict is reserved for two current observations that genuinely differ, because an alarm that fires on missing data teaches you to ignore alarms.