Why This Matters

Governance architectures for high-consequence systems are developing rapidly. Multiple independent layers are converging around similar institutional concerns: runtime evidence, admissibility, continuity, evidentiary closure, and review sufficiency. Without a standard declaration mechanism, three structural failure modes recur:

• Boundary review without declared semantics: adjacent architectures are reviewed or compared against external reference standards without the reviewed layer having declared its own interoperability semantics, creating positioning ambiguities that could have been avoided.
• Undeclared semantic overlap: adjacent systems develop overlapping vocabulary or functional descriptions without a canonical mechanism to distinguish declared scope from incidental convergence.
• Procurement ambiguity: buyers, auditors, and regulators cannot safely or consistently determine what a governance layer claims or excludes without reading extensive vendor documentation subject to interpretation.

GLM addresses this by publishing a structured, versioned, hashable declaration at a predictable well-known URL – making governance layer semantics machine-discoverable without requiring replacement of human-readable documentation.

Manifest Structure

A GLM-compliant entry point is a JSON file published at /.well-known/governance-layer-manifest.json on the canonical domain. From schema 1.3, this entry point may be either a single-layer manifest, or an organization index pointing to independently published layer manifests at separate well-known locations (see manifest_kind below). A single-layer manifest contains the following core sections:

• schema_version – version of the GLM schema specification (e.g. “1.4”)
• manifest_kind – declares whether this file is a single governance layer ("layer", the default) or an organization-level discovery artifact ("organization_index"), introduced in schema 1.3
• manifest_version – version of this specific manifest document, distinct from the GLM schema version (e.g. “7.0” for the EVIDE manifest)
• valid_from – date from which this manifest version is in force (ISO 8601)
• valid_until – date on which this manifest version was superseded, or null if currently active
• layer – product name, owner, layer_type (controlled vocabulary), vendor descriptor
• timing_axis – position on the bind-time axis (pre-bind / at-bind / post-bind / cross-cutting)
• operational_scope – what the layer does and does not do
• claims_boundary – authoritative layer claim, explicit non-claims, consumer-boundary constraint, forbidden_interpretations
• controlling_test – top-level normative principle for evaluating interoperability claims
• interoperability_doctrine – the foundational principle of GLM composability
• composition – composable layer types and declared manifest URLs
• machine_readable_status – boundary_readiness, authority_dependency, execution_capability
• public_anchors – independently verifiable documentation references
• glm_compatibility – schema family, version support range, change policies
• manifest_digest – SHA-256 content integrity verification with canonicalization method, and, from schema 1.4, an optional machine-dispatchable canonicalization_id
• vendor_framework_constructs – optional block for declaring vendor-defined conceptual constructs with canonical URIs, without importing them into the GLM controlled vocabulary

Layer Type Vocabulary (controlled, extensible)

The layer_type field uses a controlled vocabulary to enable machine comparison across implementations. The vocabulary is extensible through future schema revisions. Vendor-specific names are declared separately in vendor_layer_name and vendor_layer_descriptor.

Key Field Definitions

responsibility-bearing closure state: the accountable configuration that exists at the moment a finalized, attributable decision crosses an evidentiary boundary – including declared authority conditions, oversight conditions, and observational-quality state. This state is specific to the crossing moment and cannot be reconstructed from downstream artifacts without losing its evidentiary value.

externally verifiable artifact: an artifact structured so that an independent reviewer can interpret and verify it without access to the originating system, its operators, or its runtime context. Verification must not depend on the producer’s explanation.

authoritative_layer_claim: a single sentence declaring what this layer does that no adjacent layer claims to do. Used by procurement and composition systems to determine non-overlap without requiring bilateral review.

consumer_boundary_constraint: a declaration of what downstream consumers must not infer from this layer’s outputs. Distinct from non-claims – the consumer boundary constraint addresses how outputs may and may not be used after receipt.

forbidden_interpretations: a machine-readable array of semantic uses that are explicitly prohibited for outputs of this layer. Distinct from explicit_non_claims (which declares what the layer does not do) – forbidden_interpretations declares what downstream systems must not conclude or infer from the layer’s outputs. Enables automated validation against semantic collapse.

controlling_test: a top-level normative principle for evaluating interoperability claims. Declared at the manifest root level (not inside claims_boundary) because it applies as a general governance posture across all sections of the manifest, not only to the claims boundary. In v1.0 it is a human-readable principle, not a machine-executable constraint.

interoperability_doctrine: the foundational philosophical principle of GLM composability, declared as a top-level field. GLM does not establish interoperability between systems. It makes the boundary, claims, non-claims, and composability conditions of a governance layer machine-readable and independently readable, so that potential interoperability between layers becomes assessable through inspection and comparison of their manifests – not through bilateral integration agreements between vendors.

glm_compatibility: declares the schema family and version support range for this manifest. Enables multi-actor ecosystems to verify declared GLM schema compatibility without requiring direct communication between implementors. The schema_family field explicitly identifies the GLM framework (not the vendor layer version) as the reference for compatibility declarations.

supersedes / supersedes_digest: chain of custody fields for manifest versioning. From schema 1.2, supersedes is a structured object declaring the prior version’s SHA-256 digest and public archive url. The referenced prior manifest remains the authoritative source for its own valid_from and valid_until values. The root-level supersedes_digest field is retained for backward compatibility with schema 1.0 and 1.1 tooling. When both fields are present, supersedes_digest MUST match supersedes.digest. A manifest where these values differ is non-conformant.

The architectural purpose of this chain goes beyond technical versioning. Prior manifest versions must remain publicly accessible at the URL declared in supersedes.url. This allows any independent party — including external auditors — to retrieve the exact declaration that was in force during a specific period, verify its integrity through the digest, and reconstruct the complete version chain without relying on the layer owner’s retrospective account.

valid_until: declared on the manifest root, this field records the date on which this manifest ceased to be the active declaration. It MUST be null on the currently active manifest and is populated only when the version is archived. It must not be used to pre-declare a future expiry date.

manifest_digest vs manifest_signature: GLM v1.0 uses manifest_digest (SHA-256 of the file as served) for content integrity verification. A manifest_signature (cryptographic signature binding the digest to an identity) is declared separately when available. The digest verifies content integrity; the signature verifies authorship.

machine_readable_status vocabulary: the values for boundary_readiness (stable | provisional | experimental) and reviewability_state (portable | partial | environment_dependent) are working vocabularies proposed in v1.0. They are not yet normative enums defined by a standards body. Future schema revisions may formalize these vocabularies.

boundary_readiness definitions (clarification): boundary_readiness describes the maturity/stability status of the declared boundary definition itself – its structural classification and field content – and nothing else. It is independent of the underlying system’s operational maturity, deployment status, execution capability, output reviewability, authority, interoperability, compliance, or the truthfulness of any claim.

• stable – The boundary definition is settled and subject to explicit version/change control as a stable declared interface.
• provisional – The boundary definition is materially specified and constitutes the declaration currently in effect for the boundary, but has not yet been frozen as a stable declared interface. Its field content – not its structural classification (layer_type, timing_axis, and the overall field-set used) – remains subject to revision.
• experimental – The boundary definition is intentionally being used for exploratory or evaluative purposes, such that its structural classification itself – including layer_type, timing_axis, or the overall architectural approach used to represent the boundary – remains under examination.

Composability declarations are unilateral – a layer may declare compatibility with an adjacent layer without that declaration being reciprocal. Tooling that fetches both manifests can determine whether composability is mutually declared.

vendor_framework_constructs: an optional block allowing a layer owner to declare vendor-defined conceptual constructs publicly, without importing them into the GLM controlled vocabulary. Each construct carries a canonical_uri for namespace isolation, a vendor_local_alias for readability, a label, a purpose description, and a version. The block includes forbidden_interpretations to prevent semantic inheritance or implied interoperability by downstream systems. The purpose field is descriptive, not normative. It declares the vendor-defined operational intent of the construct and must not be interpreted as standardized semantic behavior.

manifest_kind / organization_index: from schema 1.3, a manifest may declare manifest_kind: "organization_index" instead of the implicit default "layer". An organization index is not a governance layer. It declares no claims_boundary, occupies no timing_axis position, and makes no governance claim. Its sole function is discovery: it lists the manifest URLs of independently published GLM layers belonging to the same organization, optionally anchored by each listed manifest’s digest. An organization index MUST declare timing_axis: null and MUST declare forbidden_interpretations covering at minimum organization_as_layer, authority_transfer_between_listed_layers, implied_composability, and interoperability_certification. Each layer referenced by an organization index remains a complete, independent manifest under schema 1.0-1.2 rules, with its own claims_boundary, timing_axis, and supersedes chain. Composability between listed layers, if any, continues to be declared exclusively through each layer’s own composable_with_manifests field. The governing principle: an organization index discovers layers. It does not compose them.

Organization Index (Schema 1.3)

Initial Proposing Implementation

The following illustrates the GLM manifest structure using EVIDE as the initial proposing implementation. The full manifest is available at https://www.certifywebcontent.com/.well-known/governance-layer-manifest.json.

How to Implement GLM

Publishing a GLM-compliant manifest requires three steps:

Independent Verification

Any third party can independently verify that a published GLM manifest has not been altered since its digest was computed. The verification requires no special tools – only a command-line shell and the commands below.

The verification works by downloading the live file, replacing the declared digest value with the standard placeholder, computing the SHA-256 of the normalized file, and comparing the result with the value declared in manifest_digest.value. If they match, the file is intact.

The steps below are the legacy/manual verification path. They predate canonicalization_id and locate manifest_digest.value by text substitution rather than by structural JSON Pointer location, and they do not handle a manifest_signature.value substitution. They remain valid for any manifest that does not declare a canonicalization_id.

Canonicalization ID (Schema 1.4)

canonicalization_method describes the digest transformation in prose. A verifier should not have to interpret natural language to determine what transformation to apply before recomputing a digest. canonicalization_id names that transformation as a machine-dispatchable, versioned identifier. canonicalization_method remains present alongside it as the human-readable description; the two fields are not alternatives to each other.

glm-digest-v1 – normative algorithm

Input: the manifest file exactly as served, as a byte sequence. The file MUST be valid UTF-8. If it is not, a verifier applying glm-digest-v1 MUST reject with reason “not valid UTF-8 – cannot apply glm-digest-v1” rather than attempt any other encoding.

Step 1 – Locate by JSON Pointer, never by text search. Using a JSON parser capable of reporting the byte offset of each token, locate:

• the byte range of the JSON string value (including its surrounding quote characters) at JSON Pointer /manifest_digest/value;
• if the key manifest_signature exists, and its value sub-field is present with JSON type string (not null, not absent): the byte range of the JSON string value at JSON Pointer /manifest_signature/value.

Locating by structural path rather than by string content is what makes the transformation safe: an identical string value appearing under any other key sits at a different JSON Pointer and is never examined. There is no scenario under this algorithm where a coincidentally matching string elsewhere in the file is altered.

Step 2 – Substitute, leaving every other byte untouched. Replace the byte range located for /manifest_digest/value with the exact UTF-8 byte literal, JSON quotes included:

If a byte range was located for /manifest_signature/value in Step 1, replace it with the exact UTF-8 byte literal, JSON quotes included:

These two literals are fixed as part of the glm-digest-v1 definition and cannot be altered without defining a new canonicalization_id. The substitution is performed directly on the original byte buffer at the byte ranges identified in Step 1 – the file is never fully parsed and re-serialized. Every byte outside the identified ranges – whitespace, key order, indentation, line endings, a leading byte-order mark if present, a trailing newline if present – remains byte-for-byte identical to the served file. All byte offsets used in Steps 1 and 2 are offsets into the complete original byte sequence, byte-order mark included when present: the BOM, if it exists, is preserved exactly and is never itself stripped, relocated, or excluded from the sequence being offset into.

Step 3 – Hash. Compute SHA-256 over the byte sequence produced by Step 2, with no further transformation.

Two independent implementations following this definition, using any JSON parser that reports byte offsets for parsed tokens – a widely available capability, not a bespoke one – produce identical output bytes and an identical SHA-256 digest.

Composability Declarations

The composable_with_manifests field allows a layer to identify specific manifests with which it declares composability. This enables tooling to construct a composability graph across participating layers.

Composability declarations are unilateral: a layer may declare compatibility with an adjacent layer without that declaration being reciprocal. When both layers declare each other in their respective manifests, composability is mutually declared and independently checkable by fetching both manifests. This reciprocal declaration does not constitute proof of operational interoperability. This enables:

• Automated procurement verification without requiring bilateral documentation
• Composition graph construction from publicly available manifest files
• Assessment of declared composability relationships by systems consuming governance layer declarations
• Scenario pack validation confirming consistent declarations across participating layers

Questions Raised During Architectural Review

The following questions emerged during architectural review and public discussion of the GLM specification and the EVIDE reference implementation. They are preserved here because they clarify structural distinctions that are not immediately obvious from the specification alone.

Can I implement GLM in my own commercial or research project?

Yes. GLM was specifically designed to encourage independent implementations. You may implement, adapt, extend, or publish a GLM-compliant manifest for commercial, academic, governmental, open-source, or proprietary projects. No permission, registration, licensing agreement, or attribution requirement is imposed by the proposing implementation. Independent implementations are encouraged because they help evaluate the interoperability-assessment value of the declaration model itself. Organizations that publish a public GLM manifest may optionally be referenced in public implementation examples: Validate your GLM manifest here

Why does GLM recommend publication at a well-known URI?

Because discoverability is part of the interoperability model. A boundary declaration that cannot be predictably located cannot be automatically consumed by adjacent systems. The use of well-known URIs follows the same architectural principle used by other internet-scale discovery mechanisms: the declaration should be discoverable without prior bilateral coordination.

Can a governance layer publish a GLM manifest without implementing EVIDE?

Yes. GLM is independent of EVIDE. Any governance layer may publish a GLM-compliant manifest regardless of whether it performs witnessing, admissibility evaluation, execution governance, evidentiary stabilization, reviewability, or any other governance function. GLM describes boundaries. It does not prescribe implementation.

Does publishing a GLM manifest create authority or governance legitimacy?

No. A GLM manifest declares what a layer claims, what it does not claim, where it operates, and how it presents itself for composition. Publication does not create authority, legitimacy, trustworthiness, or interoperability. It creates a machine-readable declaration surface. The validity of the declared claims remains the responsibility of the layer owner.

Can a layer comply with GLM while declaring very broad or unrealistic claims?

Yes. GLM does not validate the truthfulness, quality, correctness, or feasibility of a layer’s claims. A manifest may be syntactically valid while containing claims that are incomplete, exaggerated, or operationally unrealistic. GLM makes those claims machine-readable and independently reviewable. It does not certify them. The responsibility for the declared content remains entirely with the layer owner.

Why doesn’t GLM certify interoperability?

Because interoperability claims and interoperability declarations are different functions. GLM declares boundaries, claims, non-claims, timing position, and composition posture. It does not determine whether two systems are actually compatible, nor does it certify that interoperability has been achieved. Declaring a boundary is not the same thing as validating a relationship across boundaries.

Why does GLM include forbidden_interpretations?

Because many governance failures emerge from assumptions rather than explicit claims. A layer may never claim a capability, yet adjacent systems may gradually begin treating that capability as if it existed. forbidden_interpretations makes those prohibited semantic inheritances machine-readable rather than leaving them implicit.

Why does GLM focus so heavily on non-claims?

Because governance failures often emerge from capabilities that were assumed rather than explicitly claimed. In composable governance ecosystems, understanding what a layer does not determine can be as important as understanding what it does. Non-claims reduce the risk of implicit authority transfer, semantic inheritance, and boundary ambiguity.

The GLM defines a “boundary” layer type. Do you have a view on what should occupy that position in practice, or is that intentionally left open?

Intentionally left open. GLM defines the position on the timing axis and the operational function, but does not prescribe which system should occupy it. The boundary layer resolves admissibility at execution bind-time before consequence commits. What system performs that function is a sovereign implementation decision left to the owner of that layer.

EVIDE appears to sit mainly post-bind / closure-side. How do you handle situations where the pre-bind authority state itself is contested?

EVIDE does not resolve pre-bind contested authority. That is explicitly outside its scope. What EVIDE does is record the declared authority state at the moment of closure, including whether that state was contested, provisional, or unverifiable. A contested pre-bind state does not block stabilization. It becomes part of the evidentiary record, with its limitations declared rather than hidden.

When EVIDE records declared classification context, does it validate the stability of that upstream taxonomy or simply preserve what was declared at the time?

Preserved as declared. EVIDE does not validate the stability or correctness of the upstream taxonomy. It records what was declared at the time of crossing. If the taxonomy later changes or becomes contested, the evidentiary record reflects what was declared at that specific moment — which is precisely its forensic value.

How do you explain the difference between “supports defensibility” and “satisfies a regulatory requirement”?

The distinction is structural. EVIDE supports defensibility by producing an independently verifiable evidentiary record of the closure conditions. Whether that record satisfies a specific regulatory requirement depends on what the regulation requires and how the record is evaluated by the relevant authority. EVIDE does not determine compliance. It provides the evidentiary infrastructure that makes defensibility possible and independently reconstructable.

Are you aiming for GLM to become a formal standard, or is the current aim to establish a practical de facto declaration surface?

The immediate objective is a practical declaration surface. GLM is currently an open specification intended to establish a pattern: machine-readable boundary declarations published at well-known URIs, independently verifiable, without requiring bilateral coordination or authority transfer. Whether that pattern eventually evolves into a formal standardization effort remains an open question. The immediate value is practical rather than institutional.

If multiple boundary declarations exist for the same operational object and those declarations are mutually incompatible, does GLM provide any precedence or conflict resolution mechanism?

No, and intentionally so. GLM can make a conflict visible. It does not resolve the conflict. Once a system begins determining which declaration prevails or how incompatibilities should be resolved, it has moved beyond declaration and into governance. Any precedence model, arbitration mechanism, or conflict-resolution process belongs to whichever layer explicitly claims responsibility for that function. GLM declares. GLM does not adjudicate.

GLM makes a construct discoverable and its declared meaning machine-readable. But does it guarantee that independently governed systems will maintain compatible interpretations over time?

No. Discoverability and interpretive compatibility over time are structurally distinct problems. GLM makes a construct findable and its declared meaning readable at the moment of declaration. It does not guarantee that independently governed observers will maintain compatible interpretations as they accumulate their own assumptions around it. That is precisely why the manifest focuses heavily on forbidden_interpretations, explicit non-claims, authority boundaries, and composition constraints — not as guarantees of semantic permanence, but as mechanisms for reducing silent semantic collapse during interoperability. Whether diverging interpretations require explicit re-alignment remains a coordination problem outside the GLM declaration surface.

How do GLM manifests remain valid as authority, state, and operating conditions change over time?

GLM addresses this through versioning rather than through a permanence assumption. A manifest does not claim to describe a layer’s governance posture indefinitely. It declares what a layer claims, excludes, and how it presents itself for composition at a specific point in time — anchored by valid_from, a computed digest, and a supersedes chain linking back to prior versions.

When authority, state, or operating conditions change, the expectation is that a new manifest version is published — with the prior version remaining independently verifiable through its digest. This is structurally similar to how EVIDE handles closure state: the value of the record is not that it remains true forever, but that it accurately captures what was declared at the moment it was externalized.

Whether versioning alone is sufficient for high-frequency or highly dynamic governance environments is an open question — and one likely to become increasingly relevant as these ecosystems mature.

GLM makes declarations discoverable and machine-readable at the point of publication. But what happens when independently governed systems continue to evolve after a declaration is published — can compatible interpretations remain stable even when the original declaration itself remains unchanged?

This is a structurally distinct problem from discoverability. GLM was designed to make declarations discoverable, machine-readable, and comparable at the point they are published. It allows a layer to declare what it is, where it operates, what it claims, and what it explicitly does not claim.

What GLM does not attempt to determine is whether interpretations remain aligned over time after publication. A manifest may remain unchanged while the surrounding ecosystem evolves, new layers emerge, assumptions shift, or compositional relationships become more complex. Those questions belong to a different problem space.

From the GLM perspective, the objective is narrower: provide a stable declarative surface that allows independently governed systems to expose their boundaries in a consistent and reviewable form. Whether semantic alignment persists across time, revisions, and evolving compositions would require mechanisms beyond declaration itself — mechanisms that sit outside the GLM declaration surface by design.

In that sense, the vocabulary extension review was valuable not simply because a new category was accepted, but because it helped clarify where the responsibility of GLM ends and where other governance questions begin.

What prevents a governance layer from unilaterally changing its declared boundaries after publication?

GLM does not attempt to permanently stabilize boundaries as an architectural primitive. It assumes that a governance layer already has a defined boundary and focuses on making that boundary explicitly declared, machine-readable, and independently reviewable at the moment of publication.

Boundary evolution is not necessarily a failure condition. Systems, governance models, and operational constraints can legitimately change over time. What matters from an evidentiary perspective is whether those changes can be independently reconstructed. A governance layer may declare one set of boundaries today and a different set later. The historical declaration remains independently verifiable through its digest, and the supersedes chain makes the evolution of declared boundaries transparent over time.

In this sense, the focus is less on preventing boundary change and more on preventing the loss of reconstructability when boundary change occurs. Whether boundary ambiguity originates from insufficient initial declaration, boundary drift, or structural factors is a question that becomes answerable precisely because the historical declarations remain independently verifiable.

Should prior manifest versions be kept publicly accessible after a new version is published?

Yes. This is the architectural purpose of the supersedes chain. The current manifest URL always serves the latest version. Prior versions should remain publicly accessible at a stable URL of your choice — an archive path on your domain, a versioned file, or any other publicly reachable location.

The reason is evidentiary. Any independent party reviewing a past governance event, decision, dispute, or audit should be able to retrieve the declaration that was in force at the time that event occurred — and verify through the published digest that the declaration has not been altered since. Without publicly accessible prior versions, that reconstruction is not possible even when the supersedes chain itself is intact.

A governance layer may legitimately update its boundaries as it evolves. What the version chain preserves is the ability to determine what was declared at any specific moment in the past, without relying on the layer owner’s retrospective account. That independence is precisely what makes the chain of custody meaningful.

What remains recoverable and what remains admissible may not be the same thing. How does GLM handle situations where the authority or admissibility conditions that originally supported a governance decision no longer exist?

GLM does not attempt to determine whether historical authority conditions remain valid, enforceable, or admissible in the present. What it attempts to preserve is the ability to independently reconstruct what was declared, when it was declared, and how those declarations evolved over time.

A governance layer may legitimately change its boundaries, dependencies, authority structures, or operating assumptions as it evolves. From the GLM perspective, the critical question is not whether change occurs, but whether the historical state remains independently reconstructable after the change occurs. If a governance layer publishes one set of declarations today and a different set later, the earlier declaration remains independently verifiable through its published digest and supersedes chain.

The distinction between recoverability and admissibility is important and deliberate. GLM supports recoverability. It does not determine admissibility. Whether a recovered declaration is admissible in a specific governance, legal, or institutional context depends on factors outside the GLM declaration surface — including authority frameworks, regulatory requirements, and institutional mandates that GLM was not designed to resolve.

When multiple valid governance layers coexist and their authority claims partially overlap, how should institutions determine which governance declaration prevails?

GLM should not determine which governance declaration prevails. That would move GLM from a declaration layer into an authority-resolution layer, which is not its role. GLM is designed to make governance claims, non-claims, timing position, composability assumptions, and declared boundaries explicit, machine-readable, and independently reviewable.

When multiple valid governance layers coexist and their authority claims partially overlap, the question of prevalence should be resolved by an external authority basis: law, institutional mandate, contractual hierarchy, internal governance charter, regulatory obligation, or another explicitly recognized decision-authority framework. GLM can expose the overlap. It can make the conflict visible. It can show where two layers claim adjacent or competing responsibility. But it should not silently decide legitimacy.

This is where EVIDE becomes complementary. EVIDE does not resolve the authority conflict either. Its role is to preserve reconstructable evidence of what was declared, which layer acted, what authority basis was invoked, what handoff or escalation occurred, and how the decision chain was later stabilized or contested.

GLM declares the governance boundary. Authority frameworks determine precedence. EVIDE preserves the evidence of how that precedence was applied. This separation is important because otherwise a technical declaration layer could unintentionally become a hidden constitutional layer.

What mechanism in the GLM model ensures that governance semantics can be independently reconstructed at a specific moment without relying on implicit state continuity?

The mechanism is the combination of three structural requirements. First, the manifest itself must be contemporaneously published and independently verifiable — the manifest_digest and version chain make the declared content independently checkable over time. Second, the timing_axis forces each layer to declare explicitly where it operates relative to the bind moment, preventing continuity from being silently assumed across timing boundaries. Third, explicit_non_claims and forbidden_interpretations make reconstruction limits visible — a layer that cannot guarantee contemporaneous externalization must declare that limitation rather than leaving it inferential. GLM does not guarantee reconstruction. It makes the conditions under which reconstruction is, or is not, possible machine-readable and independently reviewable. In EVIDE specifically, that gap is addressed through contemporaneous externalization at crossing time: the accountable configuration is externalized when it exists, not reconstructed afterward.

Specification Status

GLM-BD (Governance Layer Manifest — Boundary Declarations) is currently a proposed open specification at schema version 1.4. It was developed within the EVIDE Governance Lab in May 2026 as part of work on governance layer interoperability in high-consequence system architectures.

• Status: Proposed open specification – not yet adopted by any standards body
• License: Implementation-permissive – any governance layer may implement GLM without restriction or attribution requirement toward the proposing vendor
• Manifest authority: GLM declares layer semantics. It does not decide validity, legitimacy, adoption, or conformance. A manifest must not become a meta-authority over sovereign governance primitives. A GLM manifest is self-declared infrastructure metadata, not third-party certification.
• Vocabulary extension: New layer_type values require a documented rationale and a schema version increment
• First external vocabulary extension: The formation layer_type and the source-anchored timing qualifier were accepted on 2026-06-12 following formal rationale review. Proposing implementation: NOUS (Hlias Staurou). Reviewing maintainer: EVIDE Governance Lab. This constitutes schema_version 1.1. Rationale digest (SHA-256): fad8c5a839f601893114b9072f5bedb96d01837bb844c9635339db321d7404bd
• Schema 1.2: The supersedes field was promoted from a plain string to a structured object carrying the prior version’s digest and public archive url. The supersedes_digest field is retained as the stable contract for schema 1.0 and 1.1 tooling, which can continue reading supersedes_digest and ignore the new structured object. Under this framing, schema 1.2 is a non-breaking additive change, consistent with the minor version increment policy. The root-level supersedes_digest field is retained for backward compatibility and MUST match supersedes.digest when both are present. A root-level valid_until field was also added to record when an archived manifest version ceased to be active. This constitutes schema_version 1.2.
• Schema 1.3: Introduces manifest_kind, an optional root-level field distinguishing a single-layer manifest ("layer", the implicit default for all schema 1.0-1.2 manifests) from an organization-level discovery artifact ("organization_index"). The extension addresses organizations publishing multiple independent governance layers that previously had no standard way to declare, at a single predictable location, which layer manifests exist and where they are published. An organization index makes no governance claim, occupies no timing-axis position, and must not be interpreted as implying composability or authority transfer between the layers it lists. Proposing party: EVIDE Governance Lab. Reviewing maintainer: Stone Shi (CLARIXO/TGTRACING). Reviewed and approved in principle on 2026-06-17, following the same proposal/review separation used for the schema 1.1 formation extension. Governing principle: an organization index discovers layers. It does not compose them. This constitutes schema_version 1.3. Forward compatibility note: a consumer that does not recognize manifest_kind MUST treat the artifact as opaque and skip validation, rather than falling through to the implicit layer default and flagging the absent claims_boundary or timing_axis position as non-conformance. This preserves safe forward compatibility for pre-1.3 tooling.
• Schema 1.4: Introduces manifest_digest.canonicalization_id, an optional string field alongside the existing human-readable canonicalization_method. Where canonicalization_method describes the digest transformation in prose, canonicalization_id names it as a machine-dispatchable, versioned identifier a verifier can act on without parsing natural language. The field is additive and OPTIONAL: a manifest omitting it remains fully conformant at any schema version and is treated by verifiers as requiring manual verification. The first defined identifier is glm-digest-v1 – see Canonicalization ID below for its complete normative definition. Once published, the transformation bound to a given canonicalization_id value cannot change; a future transformation requires a new identifier (glm-digest-v2 and so on), never a redefinition of an existing one. Schema 1.4 also documents machine_readable_status.authority_dependency (with its companion authority_dependency_note) as an optional, cross-implementation vocabulary field: independently observed in use by more than one GLM implementation with the same declared value (external_to_execution_system), and documented here for that reason. It is not required, and its presence or absence does not affect conformance. This constitutes schema_version 1.4.
• Schema amendments: Breaking changes require a major version increment. Non-breaking additions may be introduced as minor version increments. Backward compatibility within a major version is a design goal.
• Feedback: Architectural feedback and implementation reports welcome at [email protected]