Governance Specification for an Embedded Semantics Concept Registry

Full report

On this page

Executive architecture and governing principles

Executive summary. Embedded Semantics is already built around the right architectural distinction for a durable semantic registry: a ConceptCode is intended to represent stable semantic identity, while language expressions are governed evidence for that identity rather than the identity itself. Its public materials say that reviewed multilingual expressions attach to stable concepts with provenance and equivalence evidence; exact production lookup is registry-first and deterministic; unseen expressions cause abstention; and model vectors may supply retrieval evidence but are not the semantic source of truth. The site also treats concept definitions, expressions, relationships, model profiles, prototype evidence, and evaluation outcomes as independently trackable artifacts rather than things that should rewrite ConceptCode identity.

That distinction should become a constitutional rule of the registry:

A ConceptCode identifies a governed semantic identity. It MUST NOT identify whichever definition, label, embedding, model output, or interpretation happens to be current.

As of August 23, 2026, the public deployment reported zero published concepts, zero exact expressions, and zero languages, while its status materials described a deterministic prerelease bundle expected to contain 11 concepts and 55 expressions. The prerelease manifest identifies two source packs with separate pack versions. This is therefore an unusually good point at which to establish governance before operational history hardens weaker assumptions into compatibility obligations.

The central recommendation of this report is an event-sourced, evidence-governed, non-reassignable semantic registry. Published ConceptCodes survive indefinitely. An erroneous concept is not silently repaired into a different meaning; it is inactivated, deprecated, merged, split, or superseded through explicit historical relationships. An erroneous expression assertion is not rewritten invisibly; the assertion is superseded or inactivated by a later decision. Software that stored an old ConceptCode therefore continues to refer to the semantic identity that existed when it was stored, even when the registry later recommends migration.

This approach combines several proven governance patterns. Unicode gives implementations unusually strong stability guarantees and does not change fundamental character identity after publication; even errors in immutable character names are handled through aliases and annotations rather than repurposing the old identifier. SNOMED CT retains identifiers while inactivating components and records reasons and historical successor associations. SPDX endeavors not to change license identifiers and leaves deprecated identifiers valid. Wikidata explicitly treats merged item identifiers as persistent and instructs maintainers to redirect rather than reuse them. These are much closer analogues to ConceptCodes than a mutable search index.

The IANA model supplies the complementary governance lesson: define the information required for registration, the change controller, the registration policy, and explicit expert-review criteria before populating a registry. Its “Specification Required” policy requires both expert approval and stable public documentation detailed enough for independent implementations, while designated experts are expected to be accountable, to recuse for conflicts of interest, and to apply published criteria rather than exercise unreviewable discretion. IANA also treats deprecation and obsolescence as annotations while retaining historical registry information.

The resulting governance constitution should rest on the following governance principles.

A crucial consequence is that the registry needs three different kinds of identity, not one mutable “concept row”:

Concept identity is the persistent semantic object represented by the ConceptCode. Its identity-defining meaning must remain stable.

Concept revision is an immutable snapshot of the concept record: definition wording, explanatory notes, evidence, relationships, administrative metadata, and status at a particular point.

Expression assertion is an independently identified claim that a particular linguistic expression bears a specified semantic relationship to a Concept under a stated scope.

That separation is analogous to UMLS distinguishing concept identifiers from strings and to terminology systems retaining historical identifiers while separately managing the descriptive material associated with them. UMLS describes the CUI as representing a meaning and maintains history for merges, splits, and deleted concepts rather than assuming terminology remains static forever.

Direct answers to the key governance questions are summarized below; the remainder of the specification makes each answer operational.

The standard should therefore distinguish reversing a governance decision from rewriting history. The former must be possible; the latter must not. A reviewer may have been wrong. An appeal may overturn a decision. New science may show that a concept was conflated. A language community may demonstrate that a supposed translation is misleading. Governance must permit all those corrections while preserving exactly what previous software and humans were told at the time.

Authority, evidence, review, and multilingual governance

Actor/role model. Long-lived trust requires separating semantic authority, operational authority, and cryptographic authority. Certificate ecosystems make a similar distinction between applicant verification, issuance, revocation, lifecycle administration, and auditing; the CA/Browser Forum explicitly treats identity proofing, lifecycle management, and audit as an integrated trust system rather than assuming possession of a signing key is sufficient.

The registry should define the following roles.

IANA provides particularly strong precedent for expert accountability: a designated expert can consult other experts or a wider community, must be able to defend decisions, should recuse when conflicted, and can be temporarily replaced where all regular experts are conflicted. Embedded Semantics should adopt those principles almost verbatim at the governance level, though with more demanding multilingual and semantic evidence requirements.

Reviewer competence. The registry should not equate credentials with competence, but neither should it accept anonymous self-assertion for high-trust reviews. Every reviewer should have a public or appropriately access-controlled Reviewer Qualification Record containing:

For public high-assurance review, reviewer authorization should be periodically renewed rather than permanent. A reasonable default is reevaluation at least every two years, and immediately following serious quality failures, undisclosed conflicts, loss of relevant credentials where credentials are essential, or material policy changes.

Review levels. Registration policy should scale with semantic risk, borrowing the useful principle from IANA that registries can use different levels of review for different allocation circumstances instead of one universal process. RFC 8126 explicitly recognizes multiple registration policies and permits combinations where different requests justify different levels of scrutiny.

A submission cannot bootstrap its own trust level. An AI-generated candidate can eventually become Critical only through the same human evidence and review process as a human proposal.

Review-state machine. A single status field is insufficient. Workflow, publication, semantic lifecycle, and dispute status should be orthogonal. Otherwise an “active but disputed” record or a “deprecated record under appeal” becomes impossible to represent correctly.

The workflow state should move as follows:

draft → submitted → triage → evidence_complete → in_review → approved → release_pending → published

with legitimate side transitions to changes_requested, rejected, or withdrawn.

Once a substantive objection exists, a review may enter adjudication. A published or pending decision can acquire a separate challenged flag. A qualifying appeal creates an appeal_pending state and eventually an appeal_upheld, appeal_reversed, or appeal_modified event.

The important implementation rule is that state transitions are events, not destructive replacements. The current record can say active, but the audit trail must show the exact path by which it became active.

Evidence requirements for a Concept. There is no single source type that makes a Concept “real.” The required evidence depends on what kind of Concept is being registered. ISO/IEC 11179's metadata-registry model is useful here because it treats administration, identification, naming, and definition as governed registry concerns rather than treating a name alone as sufficient metadata.

A publishable Concept proposal must contain a semantic anchor comprising:

Four evidence profiles should be recognized.

For a standards-defined or legally defined Concept, the strongest evidence is the governing standard, law, regulation, controlled terminology, or responsible issuing authority. Secondary literature may explain but must not silently override the normative source.

For a scientific or professional Concept, recognized terminology, peer-reviewed/authoritative reference works, professional use, and specialist review should establish the boundary.

For a lexical/descriptive Concept, independent attestations of usage, linguistic references, relevant corpora, and language-community review matter more than a single organization's definition.

For an enterprise-defined Concept, external literature may be irrelevant: the constitutive evidence may be a controlled business policy, data contract, operating model, or regulation that legitimately defines the enterprise meaning. Such a concept must nevertheless be namespace-scoped so that a private definition is not represented as globally authoritative.

Evidence requirements for expression-to-Concept equivalence. This is the registry's highest-risk recurring judgment because the same surface expression can be ambiguous, historically unstable, culturally specific, broader than the Concept, narrower than the Concept, or equivalent only in a particular professional context.

The assertion should therefore not be a binary database relation such as:

"car" = C123

It should be a governed claim closer to:

expression E891 --[exactEquivalent, en-US, automotive-domain, policy P4, decision D77]--> Concept C123

An exact production equivalence should require all of the following:

First, the expression's language and script must be identified using a stable language-tagging policy; region and register must be included where materially relevant. The exact submitted string must be retained even when the resolver also stores normalized lookup forms.

Second, reviewers must test denotational equivalence, not merely similarity. Within the declared scope, normal use of the expression in the asserted sense must pick out the governed Concept rather than a broader, narrower, related, metaphorical, or culturally different meaning.

Third, the submission must include ambiguity analysis. A word that can express multiple Concepts is not disqualified, but the assertion cannot authorize unconditional exact resolution where the registry cannot distinguish the senses.

Fourth, evidence must include one or more authoritative linguistic/domain sources when such sources exist, plus reviewer judgment about actual usage. An official terminology or standard that explicitly defines the expression is stronger evidence than a machine-generated translation or dictionary gloss.

Fifth, exact claims should include negative tests: closely neighboring concepts for which the expression must not be treated as equivalent.

Sixth, retrieval embeddings, LLM output, translation systems, frequency statistics, and string similarity may rank candidates or reveal missing evidence but cannot constitute sole approval evidence. This rule follows Embedded Semantics' own stated design boundary between retrieval evidence and governed identity.

SPDX supplies an instructive analogue: its matching rules deliberately distinguish substantive license text from variations that may safely be disregarded, take a conservative approach to substantive differences, and aim to ensure that independently produced identifiers actually refer to the same governed license. Semantic expressions need an analogous, explicitly documented equivalence specification, not an undocumented similarity threshold.

The registry should support at least these assertion types:

This separation is conceptually aligned with W3C SKOS's decision to offer distinct exact, close, broader, narrower, and related mapping relationships instead of collapsing all mappings into “same.”

Provenance fields. Provenance should be represented as first-class data rather than free-text notes. W3C PROV provides a useful exchange model around Entities, Activities, and Agents, together with generation, derivation, use, and association relationships. The registry need not internally store RDF, but its data should map cleanly to this model.

Every Concept, Concept revision, expression assertion, mapping, review decision, appeal, and release should be traceable to:

Evidence must itself be version-aware. Linking only to “the current web page” is inadequate for decades-long auditability. IANA's Specification Required model specifically values documentation expected to remain findable long after registration. Where licensing permits it, the registry should archive evidence snapshots; otherwise it should retain stable bibliographic metadata, version identifiers, and appropriately designed integrity commitments.

Multilingual review policy. Embedded Semantics is correct not to assume that cultures partition meaning identically or that translation is inherently lossless. Its public materials explicitly acknowledge that unresolved distinctions should be retained rather than forced away. Unicode's CLDR provides relevant operational precedent: CLDR says its linguistic data is vetted by native speakers and linguistic experts, and its contributor guidance emphasizes language-community competence. SNOMED translation processes likewise treat translation quality as a specialized review problem rather than a mechanical string substitution.

The Embedded Semantics policy should be slightly more inclusive than a literal “native speaker required” rule. Nativeness is not the governance objective; competent, authentic command of the relevant language variety is. Immigration, multilingual childhoods, diaspora usage, indigenous/community expertise, second-language professional mastery, and languages without formal credentialing make a birthplace-based test both unreliable and exclusionary.

For an Assured or Critical multilingual exact-equivalence assertion, the registry should require at least one reviewer who demonstrates advanced functional fluency and active familiarity with the relevant language community or locale. Where the term is technical, medical, legal, cultural, or otherwise specialized, domain expertise must also be represented; it may be held by the same person only if both competencies are independently established.

Language review must record at least language, script, relevant locale/region, register, technical domain, sense qualifier, connotation/taboo concerns where relevant, morphology/inflection considerations, and whether the expression is actually used rather than merely understandable.

Where no sufficiently qualified reviewer can be found for a low-resource language, publication at a lower trust tier may be allowed with an explicit linguisticReviewLimited qualification. The system must not compensate for missing community competence by silently substituting machine translation.

Lifecycle, disputes, and semantic change control

Concept lifecycle. A Concept should progress through draft, submitted, review, approved, published/active, and eventually one of several non-destructive terminal or advisory states. Publication is the decisive boundary: before publication a proposed code may be disposable; after publication the ConceptCode is part of the infrastructure.

A published Concept can subsequently become:

active — suitable for new use.

deprecated — still valid and resolvable but no longer recommended for new use.

inactive — historical identity retained, but active semantic assertion should not be created against it except where policy explicitly allows historical annotation.

merged — inactive because reviewers concluded it is equivalent to another Concept.

split — inactive because the original was found to conflate multiple meanings.

superseded — replaced for future usage by another concept or construction that is not necessarily semantically identical.

erroneous — retained because publication was materially mistaken and no exact successor exists.

A concept's current status may change, but its historical semantic anchor may not.

SNOMED's model is a useful precedent: inactivation records include the reason for inactivation and historical associations to active concepts representing the same, similar, or otherwise relevant replacement meaning.

Expression lifecycle. Expressions deserve an independent lifecycle because an expression can become obsolete, offensive, regionally misleading, ambiguous, or technically incorrect without the Concept itself changing.

A submitted expression assertion progresses through candidate, review, approved, published/active, and potentially contested, deprecated, or inactive states. Its immutable identity should be an ExpressionAssertionId; the string itself is data inside that assertion.

A published expression's text must not simply be edited from one string to another. If the registered expression itself was misspelled or wrong, inactivate that assertion and publish the corrected expression as another assertion linked through corrects. This makes it possible for a historical system to prove exactly which expression-to-Concept assertion it relied upon.

Changing a lookup normalization algorithm is also not an editorial implementation detail. If it changes which user input resolves to which Concept, it is a resolver compatibility change and must be released and classified accordingly.

Corrections versus deletions. The following distinctions should be constitutional:

A correction repairs a mistake while leaving the identity-defining meaning unchanged. A punctuation error in explanatory prose, wrong source-page locator, or harmless typo in a non-normative note may produce a new revision of the same ConceptCode. The previous revision remains retrievable.

A semantic correction is a dangerous phrase and should generally be forbidden. If the correction changes inclusion/exclusion boundaries, necessary characteristics, denotation, or reasonable interpretation, it is not a correction to the same semantic identity. It requires a new Concept, split, merge, or supersession.

A deletion removes information from normal use or visibility. Published semantic identities must not be hard-deleted merely because they are wrong, unpopular, obsolete, duplicated, or embarrassing. IANA retains deprecated/obsolete entries for historical purposes; SPDX retains deprecated identifiers; package ecosystems similarly use non-destructive mechanisms because deletion can break already-recorded dependencies.

Hard deletion should be permitted only for unpublished drafts, obvious prepublication spam, or legally/security-compelled removal of payload data. Even then, a published identifier should retain a minimal tombstone unless law itself prohibits retaining the metadata. Sensitive content hashes should not automatically be placed in a public log because low-entropy or identifying material can sometimes be inferred from hashes; the cryptographic commitment policy needs privacy review.

Deprecation policy. Deprecation means “do not create new dependencies on this semantic identity,” not “pretend it never existed.” This closely follows the useful SPDX distinction: a deprecated license identifier remains valid but another identifier is preferred.

A deprecation event must contain a standardized reason, effective date, decision and policy references, impact classification, replacement guidance, and successor relationships where applicable. Reason codes should include outdated, duplicate, conflated, ambiguous, superseded, erroneous, jurisdictionWithdrawn, unsafeForNewUse, and governancePolicyViolation.

Deprecation may be reversed by a later, equally governed event if the reason no longer applies. The original deprecation remains in history. LOINC and other mature terminologies demonstrate why status itself must be treated as release data rather than assumed permanent.

Supersession policy. “Successor” must never be represented by an untyped pointer. Different successor relationships have radically different migration safety:

The UMLS and SNOMED history mechanisms provide precedents for maintaining more than a simplistic deleted→replacement relation, including merged concepts and historical relationships that may be same, similar, or otherwise connected.

Merge policy. A semantic merge should require more evidence than an ordinary expression addition because it affects existing identity networks.

A merge is permissible only where reviewers conclude that two published Concepts represent the same semantic identity within their declared scopes, not merely that one can substitute operationally for the other.

Before approval, reviewers must compare definitions, inclusion/exclusion boundaries, examples, hard negatives, expressions across languages, downstream mappings, jurisdiction/domain scopes, and historically relied-upon distinctions.

The default canonical survivor should be the older stable identifier when its semantic anchor is sound, because that minimizes unnecessary migration. Downstream adoption, neutrality of governance, external-standard alignment, and quality of semantic definition may justify a different survivor, but commercial prominence alone must not.

The losing ConceptCode becomes merged; it never becomes available for reassignment. Wikidata's explicit rule that persistent merged IDs should redirect and must never be reused is an excellent precedent.

Embedded Semantics should be even more conservative than a web redirect: resolving the old ConceptCode should return its historical record with:

status: merged
canonicalSuccessor: <surviving ConceptCode>
relationship: mergedInto
effectiveFrom: <release>

It should not silently pretend that the caller supplied the surviving code. That distinction preserves auditability.

Expressions attached to the losing Concept must each be re-reviewed or migrated through explicit machine-readable governance events. A merge of Concepts does not logically prove that every prior expression is an unambiguous expression of the survivor.

Where two identities are operationally hard to distinguish but semantic equivalence is not provable, do not merge them. Leave both active and publish a mapping.

Split policy. Splits are the most important protection against semantic drift.

Suppose Concept C100 was published as one meaning and later reviewers discover that it conflated meanings A and B. The registry must never redefine C100 to mean A and create only a new code for B. Doing so would retroactively reinterpret every historical use of C100.

Instead:

C100  status = split
C100  splitInto -> C201
C100  splitInto -> C202

Both C201 and C202 receive newly minted ConceptCodes. C100 remains resolvable forever as the historical conflated identity.

No automatic one-to-many migration is permitted. A downstream record containing C100 lacks enough information to determine whether C201 or C202 was intended. Migration therefore requires original context, additional data, human adjudication, or explicit acceptance of uncertainty.

Every expression previously attached to C100 must be reviewed again. Some may cleanly migrate to a child; some may remain ambiguous across both; some may be rejected.

This is where semantic infrastructure differs fundamentally from a conventional taxonomy editor: preserving the old ambiguity is more important than presenting a tidy current tree.

Competing semantic interpretations. A trustworthy registry must support disagreement without collapsing it into data corruption.

Competing interpretations can coexist in four ways:

First, the same expression may have multiple exact assertions to different Concepts, with separate domain/sense qualifiers. Exact lookup without enough context then returns ambiguous_expression, consistent with Embedded Semantics' documented approach to ambiguity.

Second, multiple Concepts may represent intentionally distinct conceptualizations of approximately the same subject. Their differences belong in definitions, provenance, scheme/authority, and mappings.

Third, different jurisdictions or communities may define the same lexical term differently. Each governed meaning should receive its own authority-scoped ConceptCode rather than forcing a politically convenient universal identity.

Fourth, cross-registry exactMatch, closeMatch, broader, narrower, or related mappings can represent interoperability without making either authority surrender its own identity model. SKOS's differentiated mapping vocabulary provides a useful conceptual precedent.

Conflict/dispute policy. Any person or affected organization should be able to file a documented challenge against a public Concept, expression assertion, equivalence type, mapping, evidence item, reviewer conflict, or process failure. Anonymous reports may trigger investigation, but an anonymous assertion alone should not change semantic status.

A challenge record must identify the challenged assertion, grounds, supporting evidence, requested remedy, challenger disclosure where available, and whether urgent harm is alleged.

Ordinarily the existing publication remains operative while challenged, but acquires contested: true. For a credible safety, fraud, security, discriminatory-harm, or severe interoperability risk, an independent duty officer may issue a temporary suspendedForReview event. Suspension must not erase the identity.

The original reviewers and submitter receive an opportunity to respond. A new adjudicator who was not the sole original decision maker evaluates the complete packet. The decision must explicitly address material arguments rather than record only “approved” or “rejected.”

For public high-trust records, the decision rationale, evidence list, dissent, conflicts, and policy basis should be public unless confidentiality, privacy, or law requires redaction.

Appeal process. Appeals should be possible but narrower than a fresh vote. IANA registration decisions use an escalation path rather than treating designated-expert judgments as unappealable, while current W3C governance uses a Council process for Formal Objections and seeks renewed consensus before final resolution where possible.

An appeal should be admissible on one or more of four grounds: significant procedural error; material evidence that could not reasonably have been considered earlier; undisclosed or improperly handled conflict of interest; or substantial misapplication of the governing semantic/evidence policy.

An appeal panel should normally contain at least three people for Assured/Critical cases, none of whom cast the decisive vote below. At least one panelist should possess competence in the relevant semantic/domain question; multilingual appeals must include appropriate language-community competence.

The panel may affirm, reverse, remand for new review, or modify the remedy. It cannot erase the original decision. A reversal therefore appears as:

Decision D100: approve E55 as exactEquivalent
Decision D188: appeal reverses D100
Expression E55: inactive effective Release 4.0.0
Reason: equivalence not established

There should be one ordinary appeal as of right. Extraordinary reconsideration thereafter should require genuinely new evidence or an exceptional governance failure, preventing indefinite procedural denial-of-service.

Release, compatibility, audit, and cryptographic trust

Registry release/version model. Versioning needs to describe several different moving parts. Embedded Semantics' current prerelease manifest already demonstrates why this matters: it identifies a prerelease registry bundle while its constituent packs use different-looking pack-version conventions. That is not inherently wrong, but a mature registry should make the semantics of every version field explicit before external consumers depend on them.

The registry should use five independent coordinates:

Every release additionally requires a publication timestamp, canonical content digest, signer/key information, compatibility report, previous-release reference, and manifest listing additions and changes.

Semantic Versioning's core idea is valuable: patch releases are compatible fixes, minor releases add compatible capability, major releases signal incompatible public-contract changes, and a published version is immutable. But a semantic registry has more compatibility dimensions than a software library, so a single number is insufficient.

Each change should independently declare:

semanticMeaningImpact
resolverBehaviorImpact
schema/APIImpact
trustPolicyImpact
migrationImpact

with values such as none, additive, advisory, or breaking.

The release number is then derived conservatively:

PATCH changes contain no change to an existing production resolution result or identity interpretation. Examples include provenance enrichment, typo fixes in non-semantic notes, source-location repairs, or additional audit metadata.

MINOR changes are backward-compatible additions or advisories: new ConceptCodes, new exact expressions that previously resolved unknown, new languages, new non-breaking mappings, additional evidence, or deprecation notices that leave existing code and expression resolution functioning. Consumers should still be warned that an input previously classified as unknown can now become known.

MAJOR changes include any modification to the result for an input that was already authoritatively recognized, an active expression remapping or inactivation, concept split/merge requiring consumer migration, incompatible normalization/resolver-policy change, incompatible API/schema change, or trust-policy change that makes previously accepted data unacceptable to conformant consumers.

A direct change to the identity-defining meaning of an existing ConceptCode should not merely trigger MAJOR. It is forbidden. A new ConceptCode is required.

This distinction is critical: versioning tells consumers that the world changed; it must never be used as permission to make a persistent identifier mean something else.

Backward-compatibility policy. The registry's strongest compatibility contract should be:

Every published ConceptCode remains resolvable to its historical semantic identity indefinitely.

The fact that it is no longer recommended may change. Its successor links may grow. Its evidence may be challenged. But the historical object does not become 404, and certainly does not become a new meaning.

Confluent Schema Registry provides a useful conceptual vocabulary for compatibility: it distinguishes compatibility with only the latest version from transitive compatibility against all historical versions, including BACKWARD_TRANSITIVE and FULL_TRANSITIVE. Semantic identity should adopt the stricter historical intuition: the compatibility test for changes to a mature Concept cannot consider only the immediately previous release.

Every production API should support an asOfRelease or equivalent historical query. A caller must be able to ask, “What did ConceptCode X mean and what status did it have under release 2.4.1?”

A system storing a semantic result should preferably persist:

authority
ConceptCode
registryRelease
expressionAssertionId   # when resolution from language caused the assignment
resolutionPolicyVersion

The ConceptCode remains the semantic identity, while the accompanying information makes the original decision reproducible.

Downstream migration is never automatic simply because a successor exists. A merge may support safe canonicalization after local policy permits it. A split must require context-sensitive migration. A merely replacedBy relation must not be presented as exact identity.

Schema registries also demonstrate the value of retaining IDs after soft deletion; Confluent explicitly states that soft-deleted schema IDs remain available and are not reusable. For semantic infrastructure, this nonreuse principle should apply even more strongly, and the equivalent of ordinary hard deletion should be unavailable for published ConceptCodes.

Downstream change discovery. Every release should expose an immutable full snapshot and an immutable signed delta from at least the immediately preceding release. IANA makes registry information available for bulk retrieval, a useful precedent for treating registry state as distributable infrastructure rather than requiring consumers to scrape interactive pages.

A release manifest should contain at minimum:

release
previousRelease
publishedAt
schemaVersion
policyVersionsUsed
contentDigest
signingIdentity
addedConcepts[]
changedConcepts[]
deprecatedConcepts[]
mergedConcepts[]
splitConcepts[]
changedExpressions[]
changedMappings[]
trustTierChanges[]
breakingChanges[]
migrationAdvisories[]

The service should provide a machine-readable changesSince(release) API or feed. Webhooks can improve latency but should not be the sole notification mechanism because delivery can fail. Critical consumers should verify signed manifests or periodically reconcile against the authoritative feed.

For materially breaking changes, the registry should publish a change proposal or pre-release, migration analysis, and effective date before the stable release except in urgent safety/security cases.

What constitutes a breaking semantic change. The following cases are breaking:

Audit model. The authoritative history should be an append-only sequence of governance events. The materialized database is merely a projection of those events.

Every event should include:

eventId
registrySequence
eventType
objectType
objectId
authority
previousRevisionDigest
newRevisionDigest
actorId
actorRole
organization
submittedAt
recordedAt
policyId
policyVersion
evidenceRefs[]
reviewDecisionRefs[]
conflictDisclosureRefs[]
reasonCode
humanRationale
semanticImpact
resolverImpact
trustImpact
releaseId
signatureOrAttestationRef
previousEventCommitment

A registry auditor should be able to reconstruct every public release solely from a prior release plus its governed events. Reproducibility should be continuously tested.

ISO governance requires committees to maintain records of official transactions, minutes, resolutions, working documents, and ballot results. CA/Browser Forum requirements likewise require archiving relevant audit and verification/issuance/revocation records. Semantic infrastructure that is meant to survive decades warrants at least as much attention to its decision trail.

Published identity and decision records should be retained indefinitely. Confidential enterprise evidence can have separate legal retention rules, but the fact that a decision occurred and the semantic result that was published should not depend on a short database-retention cycle.

Should every mutation be append-only? Every post-publication governance mutation should be.

This does not mean every UI keystroke or draft edit must be permanently public. Drafts can use ordinary document editing, although Critical-tier systems should retain internal draft audit trails.

Once an assertion has been published or relied upon in a signed release, changing its authoritative effect must require another event. The current-state projection may say only inactive, but the registry must retain the event that made it active and the later event that made it inactive.

This is event sourcing, not immutable ignorance: current truth can change while historical truth remains inspectable.

Transparency-log options. There are four increasingly strong implementation choices.

A simple hash chain should not be oversold. An operator controlling the database and signing keys could regenerate an entirely new chain and present it to users who lack an independently known checkpoint.

RFC 9162's Certificate Transparency design uses Merkle consistency mechanisms to demonstrate append-only behavior. Sigstore's Rekor applies the same general architecture to software attestations: entries are append-only, Merkle-tree state is signed, and independent monitoring is considered necessary for long-term trust.

For public Embedded Semantics infrastructure, a Merkle transparency log should eventually contain commitments to every published governance event and release manifest. Independent organizations should monitor consistency and archive signed checkpoints.

The log must not blindly publish confidential evidence, personal reviewer details, proprietary enterprise documents, or sensitive linguistic material. It can instead log opaque event identifiers and appropriately designed commitments to protected records.

Cryptographic attestation options. Cryptographic governance should cover four distinct questions:

Who approved this decision?

Which exact bytes constituted the decision?

Which exact records constitute this registry release?

Can an observer detect later rewriting or rollback?

Every stable release must be digitally signed over a canonical release manifest. The manifest includes the complete dataset digest and digest(s) of policy/schema dependencies.

The key architecture should include an offline or strongly protected governance root and delegated release-signing keys. Critical public infrastructure should use threshold authorization for root changes so that one compromised administrator cannot silently replace the trust root. The Update Framework's approach to versioned signed metadata, threshold root authorization, and rollback/freeze resistance is a useful software-supply-chain precedent.

Reviewer-level digital signatures are useful but should not be mandatory for every low-risk human interaction. More important is that the final decision record cryptographically commits to the reviewer determinations and that the responsible approval authority attests to the result.

An in-toto-style attestation is a good conceptual envelope: in-toto is specifically intended to make actions, actors, and ordering in a supply chain transparent. SLSA similarly treats provenance as a signed, verifiable claim connecting an artifact to the trusted system and process that produced it. An Embedded Semantics decision attestation could analogously connect a semantic record to the submission, evidence, reviewers, policy, and release process that produced it.

Cryptographic algorithms must be algorithm-agile. The registry should record algorithm identifiers and permit future re-attestation of preserved historical digests when algorithms age. Re-signing history under a stronger algorithm does not replace the original signature; it adds a new attestation.

Key compromise should result in a key-revocation event, investigation window, and re-attestation of affected releases where possible. Semantic decisions are not automatically false because a signing key later becomes compromised; trust status and cryptographic validity must be represented separately.

Trust tiers. Trust tiers summarize the complete assurance package, not simply how many reviewers clicked “approve.”

A trust tier applies to a particular assertion or release, not as a permanent halo around an organization. A globally respected registry can still have a low-assurance newly proposed expression. Trust should therefore be machine-readable at Concept, expression assertion, mapping, and release levels.

Federation, enterprise deployment, and capture resistance

Federation governance. A globally useful registry should not require a single organization to become the semantic sovereign for every domain and language. IANA's hierarchical-allocation model recognizes that authority can be delegated where local expertise exists while retaining coordination at the namespace level. ISO's registry framework likewise contemplates Registration Authorities administering registry items.

A federated Concept identifier should therefore be treated logically as:

(authorityIdentifier, localConceptCode)

even when the user-facing syntax compresses those components.

The authority identifier itself must be persistent and must not depend solely on current DNS ownership or a company name that can be sold. The federation should maintain an Authority Registry containing stable authority ID, legal/operator identity, namespace, public keys, governance policy, supported trust tiers, jurisdiction, contact, start date, suspension state, and succession history.

Delegated authorities may mint Concepts only inside their namespace.

A federation should authenticate and distribute signed authority metadata, not approve each local semantic decision. Federation-level intervention is warranted where an authority violates common guarantees such as code reuse, fraudulent trust-tier claims, log manipulation, security failures, or failure to preserve historical identifiers.

An authority that loses accreditation may be prohibited from issuing new Public-Assured Concepts while its existing identifiers remain resolvable and archived. Revoking the issuer must not revoke history.

Authority succession requires explicit governance. If Organization A dissolves, a purchaser of its domain name must not automatically gain the power to reinterpret A's old ConceptCodes. Transfer should require a signed succession event from the prior authority where possible or a federation-governed recovery proceeding, followed by an immutable authority-history record.

Cross-registry mappings are separate semantic assertions. An authority may unilaterally state:

our:C1 closeEquivalent external:C9

but a federation-wide high-trust exactEquivalent mapping should preferably require review acceptable to both authorities or clearly identify it as one party's assertion.

A private registry that imports a public Concept must either preserve the upstream authority and signed semantic identity unchanged or mint a local ConceptCode. It must never copy a public ConceptCode and quietly redefine it.

Enterprise/private-registry considerations. Private governance needs the same semantic invariants but different transparency boundaries.

A private registry may have proprietary definitions, trade-secret evidence, restricted legal interpretations, unreleased product semantics, or sensitive regulated terminology. The registry therefore needs field-level access controls and evidence classifications such as public, organization, restrictedReviewer, and legalPrivilege.

A confidential evidence source should still have a public/internal provenance stub identifying its existence, authority class, version, access policy, and reviewer-access status. Depending on confidentiality risk, a digest or encrypted-object commitment may be preserved so later auditors can demonstrate which document was reviewed.

Private ConceptCodes must use enterprise-controlled namespaces that cannot collide with public codes. Promotion of a private Concept to the public federation should mint or formally register the public identifier through public governance; private history may be referenced but should not silently become public authority.

Enterprises should separate semantic roles through RBAC and, for Critical internal concepts, dual control. The same product owner should not be able to propose an enterprise meaning, approve its equivalences, sign the release, and delete its audit evidence.

A private mirror of the public registry should pin verified releases and preserve upstream signatures. Local annotations should use a separate layer rather than mutating imported records.

Business continuity deserves explicit treatment. For long-lived infrastructure, organizations need escrow/archive plans for registry data, signing metadata, authority succession, and recovery if the vendor or operating unit disappears.

Abuse and capture risks. Semantic infrastructure creates incentives that ordinary string indexes do not. Controlling the accepted identity of a concept can affect interoperability, regulatory reporting, procurement, search, AI behavior, cultural representation, and downstream analytics.

The primary abuse cases are:

The system should publish governance metrics without turning them into competitive reviewer leaderboards: median review age, challenges by class, reversal rates, unresolved disputes, language coverage, reviewer diversity, trust-tier distribution, and number of breaking changes. These reveal capture or process degradation without incentivizing fast approvals at the expense of accuracy.

Records, worked history, and decision matrix

Example governance records. The following are proposed schemas, not representations of current Embedded Semantics production records. They illustrate the minimum information needed for governance.

A Concept record could look like:

{
  "conceptCode": "example.semantic.stable_concept_identity",
  "authority": "authority:example-public-registry",
  "status": "active",
  "trustTier": "public-assured",
  "currentRevision": 7,
  "firstPublishedRelease": "1.3.0",
  "semanticAnchor": {
    "definition": "A persistent governed identity assigned to a semantic concept and preserved independently of changing linguistic expressions or retrieval models.",
    "scope": [
      "semantic registries",
      "machine-readable knowledge infrastructure"
    ],
    "identityCriteria": [
      "denotes a governed semantic identity",
      "identifier is stable after publication",
      "meaning is not defined by any single expression or embedding"
    ],
    "excludes": [
      "ephemeral embedding coordinates",
      "unreviewed search-result identifiers",
      "pure lexical string identifiers"
    ],
    "examples": [
      "a ConceptCode whose meaning remains addressable after labels change"
    ],
    "hardNegatives": [
      "a vector index row ID reassigned after model retraining"
    ]
  },
  "steward": "authority:example-public-registry",
  "provenance": {
    "creationEvent": "evt-003871",
    "policy": "governance-policy:2.1.0",
    "decision": "decision-00884"
  },
  "lifecycleRelations": [],
  "contentDigest": "sha256:<digest>"
}

The important feature is that the semantic anchor is explicit enough to detect drift. A reviewer evaluating revision 8 can ask whether the proposed change merely improves prose or actually changes one of the identity criteria.

An Expression Assertion should be its own governed object:

{
  "expressionAssertionId": "expr-01JEXAMPLE9Z",
  "conceptCode": "example.semantic.stable_concept_identity",
  "expression": "stable semantic identity",
  "language": "en",
  "script": "Latn",
  "localeScope": null,
  "domain": "semantic-registry",
  "senseQualifier": "persistent governed identity",
  "relationship": "exactEquivalent",
  "preferred": true,
  "status": "active",
  "normalization": {
    "profile": "exact-lookup-profile:1.2.0",
    "normalizedKey": "stable semantic identity"
  },
  "evidence": [
    "evidence-551",
    "evidence-552"
  ],
  "review": {
    "level": "assured",
    "decision": "decision-00891",
    "reviewers": [
      {
        "reviewerId": "reviewer-104",
        "role": "semantic-reviewer",
        "determination": "approve"
      },
      {
        "reviewerId": "reviewer-231",
        "role": "domain-reviewer",
        "determination": "approve"
      }
    ]
  },
  "policy": "expression-equivalence-policy:2.0.0",
  "firstPublishedRelease": "1.3.0",
  "revision": 1,
  "contentDigest": "sha256:<digest>"
}

A review decision then exists independently:

{
  "decisionId": "decision-00891",
  "subject": "expr-01JEXAMPLE9Z",
  "decisionType": "expression-equivalence",
  "result": "approved",
  "equivalenceAccepted": "exactEquivalent",
  "policy": {
    "id": "expression-equivalence-policy",
    "version": "2.0.0",
    "digest": "sha256:<policy-digest>"
  },
  "evidenceUsed": [
    "evidence-551",
    "evidence-552"
  ],
  "reviewerDeterminations": [
    {
      "reviewer": "reviewer-104",
      "competenceScope": ["semantic-registry"],
      "conflict": "none-declared",
      "result": "approve"
    },
    {
      "reviewer": "reviewer-231",
      "competenceScope": ["semantic-governance"],
      "conflict": "none-declared",
      "result": "approve"
    }
  ],
  "rationale": "Evidence and boundary testing establish the expression as denotationally equivalent within the declared domain.",
  "recordedAt": "2027-02-14T18:42:11Z",
  "semanticImpact": "additive",
  "previousEventCommitment": "sha256:<previous-event>",
  "attestation": "attestation-144"
}

An evidence record should preserve the exact source context:

{
  "evidenceId": "evidence-551",
  "evidenceType": "normative-specification",
  "source": {
    "title": "Example Semantic Identity Standard",
    "issuingAuthority": "Example Standards Body",
    "edition": "3",
    "publicationDate": "2026-11-03",
    "section": "5.2",
    "language": "en",
    "retrievedAt": "2027-01-20T09:00:00Z",
    "archivalReference": "archive-object-882",
    "digest": "sha256:<source-snapshot-digest>",
    "accessClass": "public"
  },
  "submittedBy": "submitter-88",
  "extractionMethod": "human",
  "supports": [
    "concept-definition",
    "expression-equivalence"
  ]
}

This maps naturally to the W3C PROV distinction among entities, activities, and responsible agents without making W3C PROV serialization mandatory internally.

Example Concept change history. Consider a fictional concept initially thought to represent “portable personal computing device.”

This history illustrates the essential guarantee: governance can improve the current semantic model without falsifying what an old ConceptCode meant when software stored it.

Decision matrix.

The matrix deliberately gives several changes a harsher classification than ordinary database administrators would choose. That is appropriate: once ConceptCodes are embedded in records, APIs, standards, models, archival datasets, and public infrastructure, “administrative convenience” is itself a systemic-risk factor.

Minimum viable governance, roadmap, and bibliography

Recommended minimum viable governance system. The current prerelease stage should not attempt to launch every institutional feature at once, but several guarantees need to exist before public ConceptCodes become widely relied upon.

The minimum viable trustworthy registry should implement the following as release-blocking requirements.

First, publish a normative governance policy defining Concept identity, expression assertions, evidence, ambiguity, review authority, conflicts, appeals, lifecycle states, and change classes. A registry without published decision criteria turns expert review into reputation-based discretion; IANA's practice of requiring explicit registration and expert criteria is the better model.

Second, make ConceptCode nonreuse an invariant enforced both by governance and storage. A previously published code must be impossible to allocate again. Unicode, SPDX, Wikidata, GS1 identification policy, and package ecosystems all demonstrate the interoperability value of preserving assigned identifiers rather than recycling them.

Third, separate Concept records from expression assertions and mappings. Every expression relationship receives its own persistent assertion ID, evidence, scope, reviewer decisions, lifecycle, and history.

Fourth, require a semantic anchor with inclusion/exclusion boundaries and hard negatives for every published Concept.

Fifth, require at least two-person human review for public authoritative Concepts and exact expressions, with one person independent of the submitter. Relevant language competence becomes mandatory for multilingual exact claims.

Sixth, preserve ambiguity. A collision between multiple active exact senses must produce an explicit ambiguous/abstaining outcome unless supplied context uniquely identifies one, matching the core Embedded Semantics resolver principle.

Seventh, implement append-only governance events and immutable published releases. All previous stable releases should remain retrievable.

Eighth, provide deprecation, inactivation, typed supersession, merge, and split records before the first durable release. Retrofitting these after consumers have assumed deletion or overwrite semantics is much harder.

Ninth, version and sign every stable registry release. Publish the release manifest, full snapshot, changed-object list, policy/schema versions, digest, and compatibility classification.

Tenth, publish a basic dispute and independent appeal process. No semantic expert should exercise unreviewable authority.

Eleventh, store reviewer competence scopes and conflict declarations.

Twelfth, expose a machine-readable changes feed and historical asOfRelease lookup.

Thirteenth, keep model-derived evidence explicitly non-authoritative. This is already consistent with Embedded Semantics' public architecture and should become governance law rather than merely an implementation convention.

A credible first stable public release should therefore mean more than “the API works.” It should mean that the project is institutionally willing to guarantee nonreuse, historical resolution, governed semantic anchors, evidence-backed review, explicit ambiguity, immutable releases, and reversible decisions without rewritten history.

Advanced governance roadmap. After that baseline is operational and tested, the registry should evolve by assurance capability rather than feature count.

The next maturity stage should introduce reviewer calibration datasets, formal language/community reviewer pools, standardized evidence-quality categories, public challenge queues, reviewer recusal workflows, machine-readable migration plans, and automated checks that block illegal identity reuse or semantic-anchor mutation.

The following stage should add a Merkle transparency log, independent monitors, threshold root governance, offline recovery keys, content-addressed release archives, reproducible release generation, cryptographic decision attestations, and external archival mirrors. Certificate Transparency and Sigstore demonstrate that an append-only cryptographic structure gains substantially more value when independent parties monitor consistency rather than trusting the log operator alone.

Federation maturity should then add authority accreditation, cryptographically authenticated namespace delegation, authority succession procedures, cross-registry mapping attestations, policy-profile discovery, and portability rules for private-to-public Concepts. IANA's hierarchical/delegated governance and ISO's Registration Authority concepts are useful precedents for distributing expertise without surrendering coordination.

Critical-infrastructure maturity should add independent periodic governance audits, public reviewer-diversity/capture metrics, incident-response drills, trust-root recovery exercises, long-term archival replication across institutions, formal LTS release commitments, external log witnesses, and governance succession independent of any one commercial operator.

Finally, the registry should develop a semantic conformance test suite. It should include historical compatibility tests, ambiguous-expression cases, hard negatives, merge/split migration cases, multilingual equivalence cases, resolver normalization invariants, and replay tests proving that every historical release can be reconstructed. Schema-registry systems already use automated compatibility checking against prior versions; semantic infrastructure should develop the analogous discipline for governed meaning.

The desired end state is not a registry where errors never occur. No serious decades-long terminology system can honestly promise that. The desired end state is one where an error cannot disappear without leaving an accountable trace, cannot steal an old identifier for a new meaning, cannot silently reinterpret downstream data, and can be corrected without destroying history.

Bibliography. The governance model above draws primarily from first-party standards, registry documentation, and official project specifications.

The overarching design conclusion is that a Concept Registry should be governed less like a search index and more like a combination of a standards registry, a terminology system, a public-key trust system, and an append-only supply-chain ledger. Search systems optimize for the best present answer. Long-lived semantic infrastructure has the harder obligation: it must preserve what an identifier meant, who asserted it, why they were entitled to assert it, what evidence justified the assertion, which policy governed the decision, how later experts challenged it, and how downstream software can continue to understand data written decades earlier.