A.6.S:4.6 - State during construction (informative)

Do not mint a new kernel “signature state” unless you need it. In most cases, use:

• edition + explicit continuity/withdrawal links for semantic evolution, and
• a coarse status (Draft/Review/Stable/Deprecated) for process signalling.

If a project needs a reusable state-change policy, place it in the applicable signature’s declared content or in a separately identified policy episteme, according to its actual EntityOfConcern and use. A one-off status change is stated directly. Where state-change policy is normative, express it as a status or state-transition policy for the relevant signature episteme or publication under its effective scheme and ClaimScope, with A.2.4 and F.10 status-use discipline and A.6.5 slot discipline where needed. Do not call the episteme’s status a system role or create a system-role assignment for it; use E.10.ROLE to route bare role wording to the actual status, state, declaration position, or other direct branch.