Inactivating a Namespace or Category

You can mark a namespace, or a single category within one, as inactive — and reactivate it later the same way. Passing an explicit "activate" or "inactivate" flag does the job; leaving it out entirely just leaves the current state untouched, which is useful when you're only renaming something.

Inactivating does not move, inactivate, or remove any check underneath it. Checks already in scope stay exactly where they are, keep running as part of any suite that already contains them, and keep being evaluated normally. What it blocks is any further registration activity for every check in that namespace, or that one category: creating a new check, updating an existing one while leaving it active, copying a check into or out of that scope, adding a check to a suite, and setting or clearing a threshold. Each of these raises an error if the check involved belongs to an inactive namespace or category.

Two things are deliberately exempt from this guard, and always work regardless: inactivating a check itself, and removing a check from a suite. This means an administrator can still inactivate individual checks, or trim them out of suites, while in the middle of winding down a namespace or category on its way out.

This is computed live every time, from the namespace or category's current state — there's no separate flag stored anywhere else that needs to be kept in sync, so reactivating instantly restores normal behaviour for every check underneath it. The bulk-add-by-pattern function (covered in the Adding Your Own Checks book) surfaces this ahead of time in its preview mode, so you can see which matches would fail before attempting a real add.

One deliberate exception

Inactivating the built-in PGHF namespace, or one of its categories, never blocks the framework's own automatic seeding function from running. Re-seeding rebuilds suite membership and default thresholds through its own internal, ungated path — the same reasoning that already lets seeding bypass a check's own retired state (see Resetting to Defaults). Otherwise, inactivating the built-in namespace would permanently cut you off from picking up a future version's fixes through re-seeding, which would defeat the entire point of the guard existing in the first place.

Continue to Resetting to Defaults.