janderscience-skills 0.0.0-stage → 1.0.0

package/sources/headcount/plugins/it-operations/skills/identity-lifecycle-administration/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: identity-lifecycle-administration
+description: Executes joiner, mover and leaver processes — provisioning, group membership, access changes on role change, and complete deprovisioning. Use this to set up or fix joiner-mover-leaver, deprovision someone completely, clean up accumulated access, audit group membership, or find accounts that outlived their owners.
+---
+
+# Identity lifecycle administration
+
+This is execution: creating, changing and removing access as people arrive, move and leave.
+**Policy — what a role should be entitled to, and least privilege — belongs to
+`security:access-and-identity`.** This skill runs the process that policy defines, and the gap
+between the two is where most access problems live.
+
+## Joiners
+
+Provision from the role, not by copying a colleague. Copying is the single largest source of
+privilege accumulation: it inherits everything that person collected, including access they should
+not have had, and it propagates that indefinitely.
+
+Define role-based bundles for the common cases so a standard joiner is one action, and treat
+anything outside them as an exception requiring approval. Exceptions are fine; unrecorded exceptions
+are not.
+
+Time provisioning to be complete before the start date — coordinated through
+`people:onboarding-and-offboarding`.
+
+## Movers are the neglected case
+
+Leavers get attention because someone is going. Movers do not, and so access accrues: the person who
+has worked in three departments has permissions from all three, and nobody ever removed the first
+two.
+
+Treat a role change as a **revoke and re-provision**, not an addition. This is the single highest-
+value fix available in most organizations, and it is almost always skipped because the person is
+still present and nothing appears broken.
+
+## Leavers, completely
+
+Disable promptly at the agreed time, then work a checklist that reaches past the directory: systems
+outside single sign-on, local accounts, shared credentials the person knew, API keys and tokens they
+created, external services procured on a personal login, and any mail or calendar delegation.
+
+The gap is almost always the systems identity management does not reach. Maintain the list of them
+explicitly rather than discovering it during an audit.
+
+Preserve rather than delete where there is any prospect of investigation or legal hold — deletion is
+irreversible and occasionally very expensive.
+
+## Recertify, and act on it
+
+Periodically, system owners confirm who should still have access. This is worth doing only if
+non-response defaults to removal; where non-response means retain, recertification becomes a
+formality that certifies whatever exists.
+
+Hunt specifically for orphaned accounts — accounts with no owner, service accounts nobody claims,
+and credentials that have not been used in months but still work.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Tooling
+
+Directory and SSO: Microsoft Entra ID, Okta, Google Workspace, JumpCloud, and similar.
+
+HRIS as the trigger: Workday, BambooHR, Rippling, HiBob, Gusto, ADP, and similar. Identity
+should follow the HRIS record rather than a separate list of who works here.
+
+Provisioning runs on SCIM wherever the application supports it. Where it does not, the
+joiner-mover-leaver steps are manual and belong in a ticket template, not in someone's head.
+
+## Never
+
+- Provision by copying an existing user.
+- Add access on a role change without removing the old.
+- Consider a leaver deprovisioned when the directory account is disabled.
+- Run recertification where non-response means retain.

package/sources/headcount/plugins/it-operations/skills/identity-lifecycle-administration/references/sources.md

@@ -0,0 +1,53 @@
+# Sources — `it-operations:identity-lifecycle-administration`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## NIST SP 800-207: Zero Trust Architecture
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/207/final>
+
+**Authoritative for:** What zero trust denotes — the policy engine, administrator and enforcement point model, and the tenets — so that a vendor cannot redefine the term mid-conversation.
+
+## NIST SP 800-63: Digital Identity Guidelines
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/63/4/final>
+
+Machine-readable: <https://pages.nist.gov/800-63-4/>
+
+**Authoritative for:** What each identity, authenticator and federation assurance level requires — and, notably, that forced periodic password rotation and composition rules are not among them.
+
+## OpenID Connect Core 1.0
+
+OpenID Foundation · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://openid.net/specs/openid-connect-core-1_0.html>
+
+**Authoritative for:** What an ID token is, which claims are standard, and what a conformant party must do in each flow. Settles arguments that begin 'our provider does it differently'.
+
+## RFC 7644: System for Cross-domain Identity Management Protocol
+
+IETF · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://www.rfc-editor.org/rfc/rfc7644.html>
+
+Machine-readable: <https://www.rfc-editor.org/rfc/rfc7643.html>
+
+**Authoritative for:** How provisioning and deprovisioning are transacted between an identity provider and a downstream application — endpoints, patch semantics, filtering, and the canonical user and group attributes.
+
+## RFC 9700: Best Current Practice for OAuth 2.0 Security
+
+IETF · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://www.rfc-editor.org/rfc/rfc9700.html>
+
+**Authoritative for:** Which OAuth 2.0 patterns remain permitted — that the implicit grant and password grant must not be used, that PKCE is required, and that redirect URIs must match exactly.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/it-operations/skills/it-asset-management/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: it-asset-management
+description: Tracks hardware and software assets through their life — procurement, ownership, licensing, refresh, and disposal. Use this to build an asset register, prepare for a software audit, plan a refresh cycle, control license spend, or dispose of equipment safely.
+---
+
+# IT asset management
+
+The register exists to answer operational questions: what do we have, who has it, is it supported, is
+it licensed, and when does it need replacing. An inventory that answers none of those is an
+accounting artifact.
+
+## One register, reconciled against reality
+
+A register maintained by hand diverges immediately. Feed it from discovery — what is actually on the
+network and enrolled in management — and reconcile against procurement and finance records.
+
+The valuable output is the **discrepancy list**: assets in the register that discovery cannot find,
+and devices discovery finds that the register does not know about. The second category is the
+security problem, since an unknown device is unmanaged by definition.
+
+## Ownership, not just location
+
+Every asset needs a named accountable person. "The engineering team" is not an owner; when the device
+needs patching, returning or replacing, a team does not answer.
+
+Track state through the lifecycle — ordered, in stock, assigned, in repair, retired, disposed — and
+require the state change at the moment of handover. A register updated in batches is a register that
+is wrong between batches, which is most of the time.
+
+## Software licensing
+
+Under-licensing is a financial and legal exposure that surfaces at audit; over-licensing is money
+spent on nothing, and it is usually the larger number.
+
+Reconcile entitlements against actual installs and actual use. Reclaiming licenses from people who
+stopped using a tool typically funds a meaningful fraction of the next renewal, and the data for it
+already exists.
+
+Watch license models that change cost with infrastructure — per-core, per-socket, per-user in a
+system that provisions freely. A routine infrastructure change can multiply a license bill with no
+procurement decision anywhere in the path.
+
+## Refresh and disposal
+
+Plan refresh on a cycle and budget it as a steady cost through
+`finance:budgeting-and-forecasting`. Refresh driven by failure produces an unpredictable expense and
+a worse experience, and it always arrives at the wrong moment.
+
+Disposal is where data escapes. Require certified destruction or verified wipe, keep the certificate,
+and treat storage devices as data until proven otherwise. A drive in a cupboard nobody logged is a
+breach with no date attached.
+
+## Tooling
+
+Discovery and hardware inventory: Lansweeper, Snipe-IT, ServiceNow ITAM, Device42, and similar;
+the endpoint management platform already knows most of the fleet and is the cheapest starting
+point.
+
+Software licensing and SaaS spend: Flexera, Torii, Zylo, Productiv, and similar. The SaaS half is
+where the money hides, and it is discovered through the expense system and single sign-on logs as
+much as through any inventory tool.
+
+Reconcile the register against the endpoint platform, the identity provider and the finance system
+on a schedule. Three systems each holding a partial truth is the normal state, and the gaps between
+them are the assets nobody is managing.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Maintain a register by hand and trust it.
+- Record a team as an asset owner.
+- Renew licenses without reconciling against actual use.
+- Dispose of storage without evidence of destruction or wipe.

package/sources/headcount/plugins/it-operations/skills/it-asset-management/references/sources.md

@@ -0,0 +1,17 @@
+# Sources — `it-operations:it-asset-management`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## NIST SP 1800-5: IT Asset Management
+
+NIST / National Cybersecurity Center of Excellence · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/1800/5/final>
+
+**Authoritative for:** What an ITAM solution must be able to answer — which assets exist, who owns them, what software is running, whether it is licensed, and the discrepancy list that flags unmanaged devices as the primary security indicator.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/it-operations/skills/network-administration/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: network-administration
+description: Designs and operates the corporate network — segmentation, remote access, wireless, DNS and addressing, and diagnosing network problems. Use this to segment a network, set up or fix remote access, diagnose intermittent connectivity, plan addressing or DNS, or assess whether the network's trust assumptions still hold.
+---
+
+# Network administration
+
+The network is the substrate everything else assumes works. It gets attention when it fails and is
+otherwise expected to be invisible, which is why its design debts persist for years.
+
+## Segment by trust, and mean it
+
+A flat network means one compromised laptop reaches the finance server. Segmentation is the highest-
+value structural control available and the most commonly deferred.
+
+Separate at minimum: user devices, servers, management interfaces, guest, and anything unmanaged —
+printers, cameras, building systems, contractor equipment. That last category is the recurring entry
+point, because it is rarely patched and rarely owned.
+
+Default deny between segments, and permit specific flows. Rules that accumulate without review become
+an allow-all with extra steps; review them on a cadence and remove what no longer has a reason.
+
+## Remote access
+
+The perimeter stopped being a perimeter when the workforce and the workloads left it. Treat network
+location as weak evidence of trust: being on the corporate network should not by itself grant access
+to anything sensitive.
+
+Prefer per-application access over full network access. A remote user needing one internal
+application does not need a route to the entire internal estate, which is what a traditional VPN
+grants by default.
+
+Authentication and authorization policy belongs to `security:access-and-identity`; this skill
+implements the network path.
+
+## DNS and addressing are load-bearing
+
+DNS failure presents as everything being broken, which is why it is misdiagnosed for the first
+twenty minutes of many incidents. Run it redundantly, monitor resolution from the client's
+perspective rather than the server's, and keep records under change control.
+
+Plan addressing with room to grow and document it. Overlapping private ranges is the problem that
+surfaces years later during an acquisition or a site merge and is expensive at exactly that moment.
+
+## Diagnose in layers
+
+Work bottom-up and prove each layer before moving on: physical, then addressing, then routing, then
+name resolution, then the application. Most misdiagnosis comes from starting at the application
+because that is where the complaint originated.
+
+Intermittent problems are the hard case and need data over time, not a test at the moment someone
+complains. Capture continuously at the affected point; a test that passes while nobody is suffering
+proves nothing.
+
+## Multiple sites multiply the failure modes, not the work
+
+A second location does not double the network; it introduces a class of problem the first site
+never had. Traffic now crosses a link you do not own, and every service the remote site depends on
+becomes a question of where it lives.
+
+Decide deliberately what is central and what is local. Authentication, name resolution, and print
+are the three that hurt most when a site link drops — a location that cannot log in because the
+domain controller is elsewhere is offline for every purpose, not just the one that failed. Local
+survivability for those three is usually worth the cost; centralizing everything else usually is.
+
+**Site links fail partially more often than completely.** A circuit that is up but degraded is
+harder than one that is down, because nothing alerts and everything is slow. Monitor the link from
+both ends and on the path rather than trusting the provider's portal, which reports their view of
+their equipment.
+
+Where a software-defined WAN is in use, it makes the degraded case survivable by steering traffic
+between circuits, and it makes the topology something you configure centrally rather than per site.
+That is a real gain and a real concentration of risk: the controller becomes a thing whose failure
+is everyone's failure, so treat it as production infrastructure rather than a management tool.
+
+Small sites accumulate exceptions. A closet without cooling, a switch nobody has patched, an
+address range someone reused. Budget for a periodic physical visit — remote management does not
+show you the cable run someone added, and the sites without permanent IT staff are exactly the ones
+that drift furthest from the standard.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Run a flat network and rely on host controls alone.
+- Grant full network access where application access would do.
+- Treat network location as sufficient evidence of trust.
+- Diagnose from the application layer down.

package/sources/headcount/plugins/it-operations/skills/network-administration/references/sources.md

@@ -0,0 +1,45 @@
+# Sources — `it-operations:network-administration`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## NIST SP 800-207: Zero Trust Architecture
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/207/final>
+
+**Authoritative for:** What zero trust denotes — the policy engine, administrator and enforcement point model, and the tenets — so that a vendor cannot redefine the term mid-conversation.
+
+## RFC 1035: Domain Names — Implementation and Specification
+
+IETF · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://www.rfc-editor.org/rfc/rfc1035.html>
+
+Machine-readable: <https://www.rfc-editor.org/rfc/rfc1034.html>
+
+**Authoritative for:** DNS record semantics and constraints, including why a CNAME cannot coexist with other records at the same name, and how TTL behaves.
+
+## RFC 1918: Address Allocation for Private Internets
+
+IETF · global · **read and cite only — copyrighted, do not reproduce**
+
+<https://www.rfc-editor.org/rfc/rfc1918.html>
+
+**Authoritative for:** Which address ranges are private and must not be routed publicly. The definitive answer whenever an addressing plan is proposed.
+
+## Security Technical Implementation Guides
+
+Defense Information Systems Agency, US Department of Defense · US · public domain (US government) — quote freely
+
+<https://public.cyber.mil/stigs/>
+
+Machine-readable: <https://public.cyber.mil/stigs/downloads/>
+
+**Authoritative for:** The exact required configuration of a given operating system, hypervisor or appliance, setting by setting with severity. When two administrators disagree about a hardening value, this states the required one.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.

package/sources/headcount/plugins/it-operations/skills/service-desk/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: service-desk
+description: Runs the IT service desk — intake, triage, prioritization, escalation, knowledge, and the metrics that improve service rather than distort it. Use this to set up or fix a service desk, design ticket priority and escalation, reduce repeat contacts, structure a knowledge base, or work out why a desk hitting its targets still frustrates everyone.
+---
+
+# Service desk
+
+The service desk is where the whole IT organization is judged, usually by people having a bad day.
+Most of what makes it good is intake discipline and honest measurement.
+
+## Intake determines everything downstream
+
+Capture enough at first contact to route correctly and act without a second exchange: who, what
+they were doing, what happened, what they expected, and how blocked they are.
+
+Give the requester a single channel that works. Multiple half-supported channels — a queue, a chat, a
+shoulder tap, a manager's direct message — mean the loudest request wins rather than the most urgent,
+and the desk's workload becomes unmeasurable because most of it is invisible.
+
+## Priority is impact against urgency
+
+Priority is not a feeling. Define it on two axes — how many people are affected and how blocked they
+are — and publish the matrix so it can be applied consistently rather than argued each time.
+
+Keep **incidents** (something broken) separate from **requests** (something wanted). They have
+different clocks, different queues, and different success conditions, and merging them lets routine
+requests bury outages.
+
+Escalation should be time-based and automatic. Relying on someone to notice a ticket aging means the
+tickets that age are the ones nobody is watching.
+
+## Measure service, not activity
+
+Tickets closed measures activity, and optimizing it produces premature closure and reopened tickets.
+Better:
+
+- **First-contact resolution** — resolved without a handoff.
+- **Time to resolution at the percentile users feel**, not the mean.
+- **Reopen rate** — the direct check on premature closure.
+- **Repeat contacts for the same underlying cause** — the number that points at problems worth
+  eliminating.
+
+Never target an individual on volume. It reliably produces cherry-picking of easy tickets and quiet
+avoidance of hard ones.
+
+## Eliminate demand rather than absorbing it
+
+A desk that handles the same failure two hundred times has done two hundred units of work and solved
+nothing. Cluster tickets by underlying cause and feed the top few into permanent fixes — a
+configuration change, a fix at source, or self-service that genuinely resolves.
+
+Knowledge articles should be written for the person with the problem, not the person who fixed it:
+the symptom as experienced, then the steps. An article filed under the internal cause is not
+findable by anyone who does not already know the answer.
+
+## Tiers are a design decision, not a headcount ladder
+
+Most desks describe themselves in tiers without having decided what defines one. The useful
+definition is not seniority — it is **what a tier is permitted to resolve without escalating**.
+Tier 1 owns the known and the documented. Tier 2 owns diagnosis: problems with no article yet.
+Tier 3 owns the systems themselves, and is the same people who build them.
+
+Two failure modes, and they look opposite while sharing a cause:
+
+- **Tiers drawn too high.** Tier 1 escalates anything unfamiliar, so it becomes a routing desk and
+  the expensive people handle password resets. The tell is a high escalation rate on tickets that
+  close with a documented fix.
+- **Tiers drawn too low.** Tier 1 is expected to resolve things it has no access or training for,
+  so it improvises, and the improvisations become the estate's undocumented configuration. The tell
+  is repeat contacts on the same asset and fixes nobody can explain later.
+
+Draw the boundary at access, not difficulty. A tier that cannot be granted the permission to fix a
+class of problem should not be the tier that owns it, and granting the permission anyway to avoid
+an escalation is how the least-experienced people end up with the most rights — see
+`it-operations:identity-lifecycle-administration`.
+
+Write the escalation criteria down as conditions rather than judgment: elapsed time, blast radius,
+or a named system. "Escalate when you are stuck" produces wildly different behavior between two
+people on the same shift, and the quieter one escalates later.
+
+Each tier needs its own definition of done. Tier 1 closing a ticket by handing it upward has not
+resolved anything, and counting that as a resolution is how a desk reports success while the
+backlog grows one layer up.
+
+## Tooling
+
+ITSM platforms: Jira Service Management, Freshservice, ServiceNow, Ivanti Neurons,
+SolarWinds Service Desk, and similar. ServiceNow is a program rather than a purchase — do
+not take it on without the people to run it.
+
+Remote support: TeamViewer, ScreenConnect, Splashtop, and similar.
+
+Whatever the platform, a ticket has to carry the asset, the person, and a resolution
+category, or the reporting built on it is fiction.
+
+## Never
+
+- Run parallel unofficial intake channels and treat the ticket queue as the workload.
+- Merge incidents and requests into one queue.
+- Target individuals on ticket volume.
+- Close a recurring issue repeatedly without escalating it as a problem to eliminate.

package/sources/headcount/plugins/it-operations/skills/systems-administration/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: systems-administration
+description: Runs servers and corporate systems — patching, configuration baselines, change control, capacity, and the routine that prevents incidents. Use this to establish a patching cadence, standardize server configuration, plan a maintenance window, decide change control for infrastructure, or clean up systems that have drifted from any known state.
+---
+
+# Systems administration
+
+Well-run systems are boring. The work is in the routine that keeps them that way, and almost every
+serious incident traces back to a routine that was skipped.
+
+Cloud environment design belongs to `technology:cloud-infrastructure`; this is operating the systems
+the company runs on.
+
+## Configuration baselines and drift
+
+Every system class needs a defined baseline: build, hardening, agents, logging, accounts. Systems
+built by hand from memory diverge immediately and cannot be reasoned about as a group.
+
+Drift is the real enemy. Detect it continuously and correct rather than document — a system that no
+longer matches its baseline is a system whose behavior under patching or failover is unknown.
+
+The strongest form is disposability: rebuild rather than repair. A system you can rebuild in an hour
+never accumulates the sediment of a decade of manual fixes.
+
+## Patching as a cadence
+
+Set a regular, predictable window and hold it. Ad hoc patching means patching happens when someone
+worries, which is never in proportion to actual risk.
+
+Tier by exposure: internet-facing systems on the shortest cycle, then internal, then isolated.
+Emergency patching is a separate path with its own authority, used for actively exploited
+vulnerabilities — `security:vulnerability-management` decides what is urgent, this skill executes it.
+
+Track **coverage**, not activity. "Patching is running" is not an answer; "97% of servers are within
+30 days, here are the twelve that are not and why" is.
+
+## Change control proportionate to risk
+
+Heavyweight approval for trivial changes produces circumvention, and circumvention produces
+unrecorded changes, which is worse than no process.
+
+Tier it: standard pre-approved changes, normal changes with review, emergency changes with
+after-the-fact record. Every change needs an owner, a back-out plan, and a record — the back-out plan
+being the part most often assumed rather than written.
+
+Maintenance windows exist to make disruption predictable. Announce them, keep them, and finish inside
+them.
+
+## Know what you have
+
+An unmanaged system is a system nobody patches. Reconcile what is running against
+`it-operations:it-asset-management` regularly, and treat anything unaccounted for as urgent — the
+server nobody owns is the one still running an unsupported operating system.
+
+## Sources
+
+`references/sources.md` in this skill lists the outside authorities that settle the questions
+here — what each one is authoritative for, and what you may do with it. Check them before
+answering on anything they cover, and cite what you used. Most are free to read and not free
+to reproduce; the use note on each is binding.
+
+## Never
+
+- Repair a drifted system without correcting the baseline that let it drift.
+- Patch on worry rather than cadence.
+- Make a change with no back-out plan.
+- Leave a discovered unmanaged system unclaimed.

package/sources/headcount/plugins/it-operations/skills/systems-administration/references/sources.md

@@ -0,0 +1,35 @@
+# Sources — `it-operations:systems-administration`
+
+<!-- Generated by scripts/build-sources.py from sources/*.toml. Do not edit. -->
+
+Check these before answering on anything they cover, and cite what you used. The use note on each one is binding: most of what a professional cites is free to read and not free to reproduce.
+
+## CIS Benchmarks
+
+Center for Internet Security · global · **account required — cite it; the user fetches it**
+
+<https://www.cisecurity.org/cis-benchmarks>
+
+**Authoritative for:** The consensus hardening baseline for a specific product version, with two profile levels. The non-defense equivalent of a STIG and the baseline most commercial audits cite.
+
+## NIST SP 800-40: Guide to Enterprise Patch Management Planning
+
+NIST · US · public domain (US government) — quote freely
+
+<https://csrc.nist.gov/pubs/sp/800/40/r4/final>
+
+**Authoritative for:** What a defensible patch program contains — maintenance windows, phased deployment, and the position that leaving something unpatched requires documented compensating controls rather than silence.
+
+## Security Technical Implementation Guides
+
+Defense Information Systems Agency, US Department of Defense · US · public domain (US government) — quote freely
+
+<https://public.cyber.mil/stigs/>
+
+Machine-readable: <https://public.cyber.mil/stigs/downloads/>
+
+**Authoritative for:** The exact required configuration of a given operating system, hypervisor or appliance, setting by setting with severity. When two administrators disagree about a hardening value, this states the required one.
+
+---
+
+Sources are maintained in `sources/` upstream, not here. If one is wrong, out of date, or missing, fix it there — this file is regenerated and an edit to it is lost.