Authoring Standard Definitions
Admins and editors create and edit compliance standards in the Standards Library. Only organisation administrators with the Admin role for the Standards module can build new definitions, duplicate existing ones, edit draft requirements, and publish versions for sites to adopt.
Who can author definitions
Authoring is limited to organisation administrators with the Admin role for the Standards module. You can create, duplicate, edit metadata, and author requirements for user-sourced definitions owned by your organisation. System and partner definitions are view-and-duplicate only. See Standards Permissions and Access for the full role mapping.
Start from the Standards Library
All authoring actions begin on the Standards Library page. Open the library from the main navigation, then choose the action that matches what you want to do:
Start a new blank standard definition.
Duplicate an existing definition to copy its metadata, parameters, requirement tree, roles, evidence slots, and classifications into a new user-sourced definition.
Open an existing draft and choose Edit Requirements.
For details on browsing and searching the library, see Browse the Standards Library.
Create a blank standard definition
When you start a new organisation-owned definition, the builder opens in three steps.
On the Details step, name and describe your standard. The helper text explains that you can configure version settings in the next step.
Click Next: Version Settings to move to the version step.
On the Version Settings step, configure the version parameters. Then proceed to the Overview step to review the definition before it is saved as a draft.
After the overview is complete, the new definition appears in the Standards Library as a draft.
Duplicate an existing standard
Duplicating copies an existing definition into a new user-sourced draft.
In the Standards Library, select the definition you want to copy.
Choose Duplicate from the detail panel.
The system creates a new draft definition with the same metadata, parameters, requirement tree, roles, evidence slots, and classifications.
System and partner definitions can only be duplicated; you cannot edit them directly.
Edit a draft version
Opening a draft takes you to the Draft Standard page, the authoring surface for the requirement tree and metadata.
Edit the requirement tree
The requirement tree shows a nested structure of section headers and trackable requirements. You can reorder or remove draft requirements as needed.
Parent nodes may be section headers or trackable requirements.
Leaf requirements must always be trackable.
Evidence, roles, and attestation apply only to trackable requirements; section headers do not define these.
Edit a single requirement
Select a requirement in the tree to open its details. Each trackable requirement has four independently saved editor sections. Changes are saved per section; you can return to the Draft Standard page to continue editing the tree.
Roles
Define named roles that determine who is accountable for the requirement. The Owner role is required and is created automatically when the Roles section is empty; its role key is fixed and cannot be removed, but you can edit its label. A requirement may define up to 10 roles in total.
When a site adopts the standard, it assigns people to these roles according to the Allowed Party Types you choose. For each role, enter a Role Key of 32 characters or fewer using only lowercase letters, numbers, and underscores, and a Label of 100 characters or fewer. Choose at least one Allowed Party Type from User, Person, Company, Person From Company, or Group.
Only users who have access to the Standards module at the site can be assigned. Members with Standards access can be chosen, but users with no Standards access at all cannot. Save roles with Save Roles. For step-by-step instructions, see Set up roles and attestation for a draft requirement.
Evidence
Define the expected evidence slots that sites must fulfil after adoption. Each slot tells the system what kind of proof the site should provide. The available evidence types are:
Documents — a published policy or procedure that the site must link.
Distributions — a form or document that has been sent to staff for acknowledgment.
Risk assessments — a current risk assessment that covers the relevant area.
Work schedules — preventive or inspection work from operations that demonstrates ongoing compliance.
Files — uploaded evidence such as certificates or test results.
Manual confirmations — a written confirmation recorded specifically for this requirement.
You can also add supplementary evidence that is not required for compliance but is useful for context. Save evidence with Save Evidence.
For step-by-step instructions on adding open slots, specific slots, and alternative groups, see Build evidence requirements in standards.
Attestation
Enable Require Periodic Attestation to add a recurring review to the requirement. Choose a review interval such as 3 months, 6 months, 12 months, or 1 Year. This interval is part of the standard definition, so every site that adopts the standard inherits the same review schedule.
While editing the requirement, you can map attestation to an existing review policy or create a new one directly. After adoption, the site manager links the requirement to an actual review policy and assigns the recipients who will perform the review. Save attestation with Save Attestation. For step-by-step instructions, see Set up roles and attestation for a draft requirement.
Classifications
Classifications are namespaced metadata for library filtering and cross-standard grouping. They include fields such as discipline, obligation, topic, and health-and-safety clause identifiers. Save classifications with Save Classifications.
Two relation panels also appear in the Classifications section. Builds On lists requirement codes this requirement builds on, and Equivalent To lists requirement codes it is equivalent to. In each panel, enter a value and click Add; values appear as removable chips, and blank or duplicate values are not added. Builds On accepts an unprefixed code from the same framework, such as L1.POR.5, or a framework-prefixed code such as dfe-sems:L1.POR.5 for a requirement in another pack. Equivalent To values always use the framework-prefixed format, such as dfe-sems:L1.FIRE.1. Each value can be up to 128 characters, and a panel holds up to 10 values.
Relation classifications are optional metadata. They do not change whether a requirement applies at a site. Sites can reuse evidence across the requirements they connect; for how that works after adoption, see Link Evidence to a Standard.
Set conditional adoption questions
While editing an organisation-owned draft, you can make an adoption question appear only when an earlier answer makes it relevant, and decide how strictly sites can exclude a parameter-driven requirement once it is in scope. Sites can only adopt published versions, so these settings take effect when the draft is published.
Show a question only when it applies
Use Only Ask When on an adoption question to show it only when an earlier Yes/No or Single Choice question has the selected answer.
At adoption, a hidden question is treated as not applicable, not as an unanswered required question: the site is not asked for it, its answer is not submitted or stored, and requirements driven by that hidden answer are out of scope. The exclusion identifies the parent answer that hid them. If the parent answer changes while the form is open, the question reappears with what was typed; saving while it is hidden drops that value.
Set When In Scope on a parameter-driven requirement
For a requirement driven by an adoption parameter, choose When In Scope: Mandatory or Optional. Automatic exclusion when the parameter says the requirement does not apply is unchanged.
Mandatory — once the requirement is in scope, a site can mark it out of scope only with the Admin role for the Standards module. The change requires a justification and creates a high-visibility audit record.
Optional — sites exclude it through the normal Standards scope workflow with a justification.
Publish a draft version
When the draft is ready, publish it from the authoring surface so sites can adopt it.
On the Draft Standard page, start the publish flow. The dialog title is Publish Standard Definition.
The system runs readiness checks and displays Checking publish readiness... while it validates the definition.
If there are blockers, the dialog shows Resolve these items before publishing: and lists the issues that must be fixed.
Once readiness checks pass, confirm Publish to make the version available.
You can cancel the dialog at any time to return to editing.
What happens after publishing
After a version is published, the standard becomes available in the Standards Library for sites to adopt. The published version is read-only; further edits require creating a new draft version. For how sites adopt a published standard, see Adopt a Standard at This Site. For upgrading an existing adoption to a newer version, see Upgrade a Standard to a New Version.