Status: Normative
This document defines the normative requirements for conformance with the Governance Boundary (GB).
GB is a downstream specification that conforms to Structural Explainability (SE). All SE neutrality constraints apply.
Keywords MUST, MUST NOT, SHOULD, and MAY are to be interpreted as described in RFC 2119.
Use of terms such as "canonical" denotes structural role only and does not imply epistemic, causal, or normative preference.
This specification does not prescribe editorial structure, terminology preference, or documentation layout beyond identifier semantics.
Some requirements describe what the governance structures MAY represent, while others constrain how such representations MUST NOT be interpreted.
Overlap between these classes is intentional: representation permissions do not imply explanatory, epistemic, or normative commitment.
Each requirement in this document is identified by a stable identifier
of the form GB.*.
Identifiers are the sole normative reference for conformance. Textual wording MAY be clarified over time without changing meaning; any change that alters the requirement MUST result in a new identifier.
Renaming, reordering, or relocating identifiers constitutes a semantic change and is therefore intentionally diff-visible.
Repository paths, filenames, and section ordering are non-normative and do not affect identifier meaning.
Any system claiming conformance with this specification MUST also conform to the Structural Explainability (SE) specification.
GB MUST NOT weaken, override, or reinterpret any SE neutrality constraints.
Governance Boundary defines a structural layer for recording governance-level artifacts and actions that operate relative to, but do not modify, the neutral substrate.
GB defines structural forms for:
- governance artifacts
- governance actions
- structural dependency relations
- structural provenance for governance events
GB does not define semantics, authority, or enforcement.
GB MUST provide a structural form for declaring adapter identity, scope, and claimed compatibility.
Adapter manifests:
- record claims only
- MUST NOT imply endorsement
- MUST NOT assert correctness, safety, or compliance
- MUST be interpretable without domain-specific knowledge
GB MUST define requirements for canonical encoding of governance artifacts and identifiers.
Canonical encoding:
- ensures stable comparison
- supports reproducibility and traceability
- MUST NOT encode interpretive semantics
GB MUST define a structural dependency graph describing relationships among governance artifacts.
Dependency graphs:
- are identifier-based
- are non-causal
- MUST NOT imply execution order, authority, or obligation beyond declared dependency
GB MUST define a structural fingerprint mechanism for identifying governance artifacts or states.
Fingerprints:
- support traceability
- support change detection
- MUST NOT be interpreted as endorsements or guarantees
GB MUST define structural records for governance actions applied to artifacts, including but not limited to publication, approval, deprecation, or supersession.
Governance actions:
- record that an action occurred
- do not assert why it occurred
- do not assert who is authoritative
GB MUST define structural provenance for governance actions and artifact lifecycle events.
Governance provenance:
- records lineage and process
- MUST remain interpretation-neutral
- MUST NOT assert epistemic validity or legitimacy
GB MUST define versioning rules for governance artifacts and specifications.
Versioning:
- MUST be explicit
- MUST be stable
- MUST NOT allow silent or implicit change
This specification does not define:
- domain vocabularies
- behavioral models
- causal explanations
- epistemic evaluation
- normative judgment or enforcement
- exchange or interaction mechanisms
These concerns are explicitly out of scope.