Patch catalog

The patch catalog records the identifier and title a team uses to recognize a release. Product and version give the operator context before selecting an asset. Severity helps the change reviewer decide which work to examine first, while the release date distinguishes an older release from a newly available one. These fields describe the patch. They do not say that any particular asset has received it.

Suppose an operating system update affects a service the team considers important. Admin records the patch ID, title, product, version, severity and release date. A Patch Operator checks those details before creating an attempt against an assigned asset. If the product or version differs from the intended release, the operator corrects the catalog selection before the attempt is recorded. That simple check prevents the attempt history from being attached to the wrong release.

• Catalog identity. Keep the patch ID and title meaningful to the team that will review the attempt later.
• Release context. Product, version and release date tell the operator which release the record represents.
• Severity. Use the recorded severity to prioritize review without treating it as an installation result.

Agree who maintains the catalog and where patch details originate. An external advisory feed or scanner can supply candidates through a connection, but someone still needs to decide which record represents the release the team intends to use. Agree on how the team writes product and version names so duplicates are easy to spot. Also decide when a new release deserves a separate record instead of rewriting an older one that already has attempts linked to it.

Patch severity belongs to the release record. Service criticality belongs to the service record. A high severity release affecting a lower criticality service may need a different work window from the same release affecting a critical service. Keep those judgments in the change review, where the service context and rollback plan are visible.

Choose one catalog entry and one asset. Confirm that the operator can read the intended patch ID, product and version before making an attempt. Then open the attempt and confirm it points back to that catalog entry. Try a second asset for the same patch: the two attempts should remain separate, while the release identity stays shared. Review an older release as well so a new version does not obscure earlier attempt outcomes.

• Patches by severity — Review high and critical releases with their product, version and release date.
• Scheduled patch attempts — See which selected releases have an attempt marked Scheduled for an asset.

Plan an asset patch and review the model.