Maintain custom framework requirements

Open Management systems, choose a system, then open a framework from its Frameworks tab to review its edition and catalog requirements. Framework records identify whether they belong to the Global catalog or Workspace catalog. Workspace owners and administrators with active Platform and IMS access can maintain custom workspace records where the management controls appear.

Keep catalog requirements separate from their use in a system. A catalog requirement defines the requirement and its expected templates. A register entry records that requirement's applicability, owner, status, and supporting content for one management system. Follow Used in management systems to work on a particular system's entry.

Inspect the framework and requirement contextCopy Anchor Link

Check the framework's name, short name, revision, edition, publisher, reference link, description, and active or archived status before editing. Its requirement browser supports narrowing the list and browsing direct children of a selected requirement. Clear or reset filters if a saved filter is invalid or hides the records you need.

Open a requirement to read its identifier, summary, hierarchy, kind, assessment settings, system uses, mappings, and Expected artifact templates. The badges explain whether it can be assessed, whether linked artifacts are needed, and whether exclusion with justification is allowed. Follow a parent, framework, template, mapping, or system-use link to inspect the relevant context.

Edit a custom frameworkCopy Anchor Link

1. Open its framework record and find Manage this framework.
2. Open the framework editor and update the name, short name, description, publisher, edition, reference link, or extra aliases as needed. Extra aliases are comma separated, with up to 20 aliases.
3. Save and check the refreshed framework record before making a further change.

Use Archive this custom framework when an edition should no longer be offered for new declarations. Existing declarations remain readable. Clear that choice to make the edition available for new declarations again.

Delete framework asks for confirmation and removes the custom framework and its requirements when deletion is permitted. Frameworks still in use may need to be undeclared first. Review the affected system declarations before removing them: removing a declaration can affect its register entries and framework sections, and linked content may block removal.

If an action was accepted but the result cannot be confirmed, choose Review current version before another action. Do not repeat deletion merely because the view did not refresh.

Add a root or child requirementCopy Anchor Link

In Manage this framework, use Add requirement for a custom workspace framework.

1. Enter the Identifier, Title, and Summary.
2. Choose its Kind, whether it Can be assessed, and whether it Can be excluded with justification.
3. Add any comma-separated aliases. Each alias can contain up to 253 characters, with up to 20 aliases.
4. Under Position, choose Root requirement or Child of an existing requirement. For a child, select its Parent requirement in this framework.
5. Choose Save requirement and check the saved identifier and title in the receipt.

Identifiers remain reserved after a requirement is renamed or withdrawn. Choose a distinct identifier for a new record rather than assuming that an old name is available again.

To change an existing requirement, open its record and use Edit requirement under Manage requirement. You can maintain its identifier, title, summary, kind, assessment and exclusion choices, and aliases. The parent-position choices belong to creation. Check the hierarchy when adding a child so that it appears under the intended parent.

If the saved record changes while you are editing, use Reload current values and discard this draft to start from the current values. For an unsaved new requirement, Review framework and start a new proposal resets the proposal after checking the framework. These actions discard the current draft; keep any wording you still need before using them.

Withdraw or reactivate a subtreeCopy Anchor Link

Open a custom requirement and choose Withdraw subtree or Reactivate subtree under Manage requirement. Review the confirmation carefully: the action affects that requirement and every child. Existing identifiers remain reserved, and current register entries retain their history.

After confirmation, check the affected requirement count and the active or withdrawn status. If the confirmation becomes stale because the requirement or your access changed, close it, reload, and review the action again. An accepted action that needs review must be checked with Review current version before another change.

Delete requirement permanently removes the custom requirement only when its usage permits deletion. Use withdrawal when you need the record and its historical context to remain available. After deletion, return to the framework catalog to check the remaining hierarchy.

Define an expected document templateCopy Anchor Link

An artifact expectation connects a catalog requirement to a template and describes why that template is expected. The expectation can name relevant sections and a review cadence. It is separate from linking an existing document to a management-system register entry.

For an eligible custom requirement, use Set an artifact expectation. The requirement must be active and assessable, and must require linked artifacts. The editor explains the reason if it is not eligible.

1. Use Find a catalog template and choose an active Artifact template. Use Previous templates and Next templates when needed.
2. Select up to 100 distinct sections from the current template. Section choices show whether they are always included or conditional on particular frameworks. Changing the template clears your section choices.
3. Set Review cadence, or choose Inherit default to use the template or requirement default.
4. Set the Obligation. A clause can use Required when you also supply a Clause locator. Controls and criteria offer auditor-expected or good-practice obligations.
5. Enter a clause locator and rationale where useful, then save the expectation.

Selecting a template adds or replaces that template's expectation. An empty section selection clears its section mappings. This does not mean that a blank section choice selects every section. Check the intended selection before saving.

After saving, choose Review current requirement and check Expected artifact templates for the template, obligation, locator, and rationale. Section and review details appear when available. The editor requires this review before another expectation change. If the requirement changed while you were preparing the expectation, reload and review it before saving again.

Check shared document links and mappingsCopy Anchor Link

From a requirement's linked content, Reuse on related requirements lets you select other eligible requirements that should link the same document. Review each requirement and management system, then choose Link to ... requirements. Entries marked Already linked remain selected and cannot be added again. The source content stays in its original location.

If some links cannot be added, the selection is retained. Review the updated list, resolve access or busy-requirement issues, and try again for the remaining targets. A shared link means later edits to that source document matter to every requirement that uses it.

Open a requirement mapping to inspect its source, target, relation, rationale, catalog or workspace origin, and use in management systems. The detail also shows suppression information when present. Some entries can be excluded from the list because they do not apply or are outside your access. Follow the requirement or system links to inspect the records you can read.