Everything lanyard does, today.

A request is created pending. The policy engine either auto-approves it or leaves it for a human with the approve verb. Once approved it becomes active for its requested duration, then the reconciler transitions it to expired on its own — or a revoker ends it early, moving it straight to revoked. Both are terminal; a grant never outlives its expires_at while still reporting itself active.

In short: every endpoint but /auth/login expects Authorization: Bearer <token>, identity always comes from the resolved token (never the body), unknown fields are rejected with 400, and internal errors return a generic {"error":"internal error"} — full detail is logged server-side, never leaked.

Config file

Anything above that is not a client-side or secret value can live in a YAML file instead, so a deployment does not need a wall of exports. Environment variables always win over the file — that ordering is what lets a container override one setting without rewriting the file.

Delegation

A delegation is a time-bounded, pattern-scoped transfer of one actor's approval authority to another — for leave, or on-call handover. It confers nothing by itself: at approval time the delegator must currently hold the approving level's role, so a delegation can never hand over authority the delegator has since lost. It is non-transitive by construction — eligibility never chains through a second delegation — and, like a grant, it must be time-bounded.

The delegator is always the caller — you cannot delegate authority you do not hold, nor delegate on someone else's behalf. expires_at is required and must be in the future: there is no unbounded delegation. An approval made under one records both the delegate and the delegator in the audit trail, so accountability is not laundered through it.

Approver notifications

Set LANYARD_NOTIFY_WEBHOOK to a secret reference and lanyard POSTs a summary of every pending grant to that endpoint. The body is the de-facto incoming-webhook shape ({"text": …}), so it renders in Slack, Discord and Mattermost with no extra configuration, and is readable by any custom consumer. Unset means notifications are simply off.

One provider can have several integrations, which is why --name is required — a broker fronting two GitHub orgs registers each separately, and the entitlement's instance segment is what picks between them at grant time (ADR 0007). Registering an integration is itself a gated, audited action: it needs management authority over integrations, because an integration points lanyard's credentials at a target.

New providers implement one port — Grant, Revoke, HasAccess, List — and are validated against a shared conformance kit (internal/testutil) before they ship. The kit fatals on an incomplete fixture set, so a check that was skipped can never read as a check that passed.

Migrations and upgrades

Schema and binary move independently. lanyard db:migrate applies pending schema migrations; lanyard update upgrades the binary. Run the migration after an upgrade that ships one (ADR 0016). A fresh database is baselined at its actual version rather than assumed to be at head, so adopting an existing deployment does not skip migrations it still needs.

Is enforcement still running?

Every sweep records its outcome durably, so GET /reconciliation can answer whether lanyard is still enforcing expiry — not just whether the last sweep found nothing. This matters because the failure modes look identical from outside: a sweep that ran and found no problems and a sweep that never ran both report zero problems. The status carries when the last sweep completed, what it repaired, and what it could not (ADR 0014). The console surfaces it at /console/reconciliation, and reconciliation is its own role_view resource so someone on call can read it without being able to read the audit trail.

fully_recorded is served rather than left for you to derive from record_failures. "A sweep that lost observations is never shown as healthy" is a safety property, and deriving it separately in the API and the front-end is exactly how the two come to disagree.

Is the record intact?

Every event is linked into a tamper-evident hash chain, each entry covering the one before it. GET /audit/verify walks the chain and reports the first break, so a deleted or rewritten row is detectable rather than merely unlikely (ADR 0006). Each event answers who, what, when, where, why and how, and for configuration changes it carries the before/after values — a widened role shows exactly what widened (ADR 0015).