VN vnlemanhthanh@gmail.com

derived identifiers identifier comparison structured value scoped identifier comparison domain exact equivalence Derived identifier constructions that combine local material with identifiers from other systems need a defined comparison domain. This document defines a structured value model for such constructions and their profiles. A Value contains exact context octets, exact content octets, and a finite set of scoped opaque identifiers. Structural admission and equivalence are independent of serialization. Equality includes context, content, and complete identifier-set membership. The specification gives source mappings and profiles common obligations for fixed inputs, imported comparison adaptation, and preservation of participation distinctions. Surrounding specifications define concrete mappings, representations, identifier derivations, and the shared interpretation needed for interoperability. The model defines no global semantic namespace, wire format, cryptographic construction, or trust mechanism.

Introduction Derived identifier constructions can combine local data with identifiers produced by other systems. A trade-document description, for example, can include a document reference and identifiers for a buyer, seller, and carrier. Independent implementations need to agree on which material enters comparison, how identifiers from different namespaces are qualified, and which participant associations distinguish the value being identified. This specification provides a common structural comparison domain. A Value groups context, content, and a finite set of scoped opaque identifiers. Context selects interpretation, content carries local material, and the identifier field provides reusable qualification and complete-set comparison rules for imported results. Equality compares exact octets and complete membership. Profiles can reuse these qualification and set-comparison rules across concrete encodings and derivations. Independent implementations can compare their mapped Values before testing any profile-specific encoding or cryptographic operation. The comparison-contract framework in describes the source-to-result obligations surrounding derived identifiers. This document fixes one admitted value domain and its exact equivalence relation. A source mapping defines which source distinctions enter that domain; a derived identifier profile defines how Values produce identifiers and what output comparison supports. Complete membership suits descriptions and configuration snapshots; continuity across changed descriptions is addressed in . distinguishes the three comparison boundaries. P denotes one fixed source mapping and F one fixed profile derivation. Each application of F requires a Value in that profile's derivation domain. Dotted lines mark comparisons; the arrows alone assert no preservation or reflection property.

Mapping and Derivation Comparison Boundaries | V1 | -- F --> | i1 | +-----------+ +-----------+ +-----------+ : : : source model output comparison equality comparison : : : +-----------+ +-----------+ +-----------+ | s2 | -- P --> | V2 | -- F --> | i2 | +-----------+ +-----------+ +-----------+]]>

Shared interpretation depends on the applicable surrounding definitions; this model establishes no global semantic namespace. Concrete representations, cryptographic constructions, and trust mechanisms belong to surrounding specifications. defines the model and gives a short example; specifies mapping obligations; specifies profile obligations; and develops the trade-document mappings.

Conventions and Conformance Scope The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. An octet string is a finite sequence of octets. A source mapping converts accepted source material into a Value. A derived identifier profile defines how admitted Values in its domain produce identifiers. A single specification can define both. The definitions in Sections through and the applicable requirements in Sections , , and govern mappings, profiles, and implementations that adopt this model. A conformance claim identifies whether it concerns model comparison, a source mapping, a derived identifier profile, or a combination, together with the applicable definitions and comparison claims. Correct Value comparison alone does not establish conformance to a mapping or profile. Mapping and profile implementations apply their selected definitions. Sections , , , and , together with , provide explanation and examples. These conceptual boundaries do not require separate implementation stages or exposed intermediate objects.

Value Model

Value Types A scoped identifier is a pair of octet strings: ScopedIdentifier := { scope : finite octet string, identifier : finite octet string } Two ScopedIdentifier values are equal if and only if their scope octets are equal and their identifier octets are equal. Both components are opaque to the model. Imported interpretation is specified under . The comparison domain consists of records of the following type: Value := { context : finite octet string, content : finite octet string, identifiers : finite set of ScopedIdentifier } context selects an interpretation within the applicable surrounding definitions. content carries exact local material. identifiers carries the complete set of imported identifier members participating in comparison. Sections through specify how mappings populate these fields.

Structural Admission and Empty Values A candidate is structurally admitted if and only if it is a Value of the type in : context and content are finite octet strings, and identifiers is a finite mathematical set whose members each contain finite scope and identifier octet strings. Each octet string can be empty, and identifiers can be the empty set. An empty scope or identifier is part of an exact member value. In particular, the empty set and a set containing the pair of two empty strings are different. A Value with no imported identifiers still has the same type; context and content supply its other comparison material. Structural admission does not validate arbitrary identifier octets against an imported system. A mapping defines any imported-system validation and restrictions, including non-empty requirements, before producing the Value. Profile domain restrictions do not redefine this mathematical domain. Conformance to a claimed source mapping is addressed in . These admission conditions are independent of local memory, time, storage, or other resource availability. An inability to process an admitted Value is an operational refusal, not evidence that the Value lies outside the model domain.

Equivalence Two admitted Values are equivalent if and only if all of the following hold:

• Their context octet strings are equal.
• Their content octet strings are equal.
• Their identifiers are the same mathematical set under the ScopedIdentifier equality of .

This relation, denoted by ~, is reflexive, symmetric, and transitive. It is equality of abstract Values. Order of set presentation and repeated presentations of the same member do not distinguish Values. Multiplicity or occurrence identity requires explicit representation under . With context and content unchanged, adding, removing, or substituting members so that the mathematical set changes produces a non-equivalent Value. Whether a source change is permitted by an application does not alter this equality rule. Implementations comparing admitted Values MUST apply this relation. Implementation strategies and resource limits MUST NOT change the logical Value, its exact member equality, or its set membership. Imported meaning is specified separately under .

A Value in Use This informative example uses the mapping specified in . A trade document references party-a as seller and party-b as buyer. The mapping records the document reference in content and each party's role in its scope: context = "example.org/trade-document/participants/v1" content = "commercial-invoice:1234" identifiers = { ("trade-party/v1/role/buyer", "party-b"), ("trade-party/v1/role/seller", "party-a") } The strings denote exact ASCII octets and the braces denote a mathematical set. Changing the order in which the two members are displayed leaves the Value unchanged. Swapping the parties between buyer and seller changes the scoped members and therefore the Value. shows an alternative mapping that carries these associations in content.

Source Mappings and Imported Identifiers

Fixed Inputs and Mapping Semantics A source mapping specifies accepted source material, explicit inputs, and source comparison claims. The requirements below cover reproducible Values, intentional projection, and preservation and reflection of the declared comparison. For fixed mapping semantics, the same accepted source and explicit inputs MUST determine one admitted Value, including its complete identifier set. Result-affecting choices MUST NOT be left to implementation discretion or ambient mutable state. A dependency that can change the Value or its interpretation MUST be an explicit input or fixed unambiguously by the applicable rules. This includes any relevant version of a schema, normalization rule, imported definition, resolver result, clock value, or registry state. Fixing a locator without fixing its relevant interpretation is insufficient. Acquisition can require a service; model comparison does not itself require that service to remain reachable. A mapping can project a richer source object. It MUST make every source distinction that its comparison claims require observable in the admitted Value. Intentional exclusions are part of the defined source comparison. If an omitted distinction is later required by a consumer, that consumer cannot recover it from the resulting Value alone. Source absence, null, sentinels, or exceptional values are not additional model values. A source mapping MUST NOT silently coerce them to empty model values. It can explicitly define such a projection, but its result MUST be an admitted Value. Representation admission and decoding are addressed in . A mapping claiming to represent a source equivalence relation by model equality MUST define that relation and preserve it: under fixed mapping semantics and explicit inputs, equivalent accepted sources produce equal Values. It MUST also reflect that relation: non-equivalent accepted sources produce different Values. These obligations concern the declared comparison, not every distinction in a richer source object. The obligations apply to the complete Value. A source comparison can retain distinctions ignored by an imported comparison, but those distinctions then belong to the declared source relation. Adapting imported members alone does not establish whole-source preservation or reflection. A comparison property established directly for the complete source-to-output construction does not by itself establish preservation by the mapping.

Context and Content A surrounding specification defines the exact context octets and their interpretation. Within one fixed applicable definition, it MUST NOT assign incompatible interpretations to the same context octets or silently change an existing imported meaning associated with a context and scope. This is a consistency requirement within those definitions, not a global allocation rule. Independently governed environments can select equal context octets without agreeing on their meaning. A consumer drawing conclusions under imported semantics needs agreement on the applicable definitions. Selection, distribution, and authentication of those definitions are surrounding protocol responsibilities; they do not add a field to Value equality. A new distinct scope meaning can be added without changing context octets when existing meanings remain unchanged. Any associated change in profile acceptance or mapping rules remains subject to . content is exact local material after the source mapping. The model performs no normalization, character conversion, decompression, defaulting, or canonicalization. A mapping starting from richer content defines any such processing before admission. Context identifies the interpretation of the Value as a whole; content holds the local material compared within that interpretation.

Imported Interpretation A mapping that imports an identifier system MUST define, for every context value it uses, how scope octets select imported identifier semantics and which exact identifier octets are carried. Within that applicable context definition, incompatible imported semantics MUST NOT use the same scope octets. Different context values can reuse a scope because context participates in Value equality. The imported meaning of a member is qualified by: (context, scope, identifier) A distinction that changes the imported identifier interpretation or comparison relation MUST be fixed by this tuple under the applicable definitions. It MUST NOT exist only in content or ambient state if that would give the same tuple incompatible imported meanings. Participation that does not change the imported interpretation is addressed separately in . This requirement makes imported members interpretable from their qualified tuples under the applicable definitions, without consulting content. It is additional to whole-source preservation and reflection: distinguishing complete Values through content does not establish unambiguous imported meaning for each member. Context is carried once in the containing Value. A consumer copying out a ScopedIdentifier MUST NOT assume that its imported meaning is preserved under another context unless a surrounding specification establishes that compatibility. A scope can use an allocated name, a self-certifying value, a URI or URN, or another stable octet string. The model specifies no scope grammar or lookup mechanism. Equal identifier octets under different scopes do not establish a cross-system identity or equivalence relation.

Adapting Imported Comparison A mapping MUST identify the imported equivalence relation represented at the exact ScopedIdentifier boundary. If the relevant native matching behavior, under its fixed interpretation, is not an equivalence relation, the mapping MUST define the equivalence being projected into the model. Such a projection is a choice of comparison semantics; this model supplies no default conversion of a directional or other non-equivalence match into equality. For example, nonempty overlap between identifier sets is not transitive: {a} overlaps {a, b}, and {a, b} overlaps {b}, but {a} does not overlap {b}. Equality of one independently computed identifier per set cannot represent this relation unchanged. Selecting complete-set equality or an equivalence closure changes the comparison and requires an explicitly defined source relation. For a fixed imported interpretation and fixed participation qualification, equivalent accepted native instances MUST produce equal ScopedIdentifier values. A mapping claiming to preserve the imported comparison unchanged MUST also reflect that relation: accepted native instances produce an equal pair only if they are equivalent under the imported relation. A deliberate merge of native classes is upstream projection and cannot support an unchanged-comparison claim. Native adaptation and participation qualification are distinct responsibilities. The requirement above governs the resulting pair under a fixed qualification; it does not require a separately materialized native class representative. Alias representative selection MUST be deterministic under the fixed interpretation. Direct copying suffices when native equality is already exact octet equality and the applicable interpretation and qualification are fixed. An imported identifier can remain opaque when those octets already represent its relevant comparison. The model need not parse or reproduce the imported construction. Any source distinction already lost within that construction remains lost at this boundary. Retaining its output exactly does not establish uniqueness of its preimages or repair its own false matches. illustrates adaptation of imported members together with the content that records their associations.

Participation and Member Associations A source can use an imported identifier in a particular role, relationship, position, or occurrence. A mapping MUST preserve every such distinction required by its source comparison in the complete Value. It can qualify the member's scope or encode the participation and its association with the member in content. When qualification is carried in scope, two roles can produce different ScopedIdentifier members for the same native identifier class. When it is carried in content, the same member can participate in both roles; content then preserves their associations. The imported interpretation itself remains governed by . scope is not a general metadata channel. Material placed there qualifies that member; it does not replace context for the interpretation of the whole Value. A profile can define a family of scope encodings, while the model continues to treat each resulting scope as opaque octets. A qualification MAY be carried in scope when it is specific to one imported member's participation at this comparison boundary. When a comparison-relevant relationship depends on two or more participants, content provides a direct place to encode the participants together. If a mapping instead uses member scopes, those scopes MUST encode enough association material to preserve the relationship; independently qualifying each endpoint is insufficient. A mapping preserving a relationship MUST retain the association between its participants and their roles, not just the endpoint identifiers or separate collections of labels. Order, multiplicity, and occurrence distinctions likewise require explicit material, such as position-qualified scopes or a defined structure in content. They cannot reside only in an external relationship table while the same Value is supplied to derivation. These rules specify comparison material without imposing a graph topology or requiring traversal or resolution. illustrates grouping between imported members, with the different pairings shown in . Application relationship semantics are discussed in .

Complete Membership and Source Changes Fixed mapping inputs determine the entire identifier set under . An implementation cannot substitute a locally discovered or supported subset for that set. A mapping can use a selected snapshot or other explicit source input, but changing that input can change the Value. For example, let A and B be distinct ScopedIdentifier values. With equal context and content, Values containing {A} and {A, B} are different even if an application describes B as a newly learned alias. The application determines whether B belongs in the identity-bearing input, is adapted by a fixed import rule to an existing member, or remains descriptive information outside this Value. Complete membership can therefore describe a configuration or inventory snapshot whose changes are intended to affect comparison. It does not by itself provide continuity of an entity across changed descriptions. An application needing that continuity selects stable identity-bearing inputs or defines a relation between successive Values. Calling two members aliases or alternatives does not change the model's set equality.

Derived Identifier Profiles A source mapping determines a Value. A derived identifier profile takes Values in its domain and specifies their representations, derivation, and output comparison. The requirements below apply after the source distinctions have been represented in the Value.

Profile Domains and Representations A profile MAY restrict its derivation domain to a subset of structurally admitted Values when required by its encoding or downstream operation. Domain membership MUST be determined from the Value under fixed profile rules, independent of its accepted representation and of local resource availability. Because model equivalence is equality of abstract Values, a domain defined solely from the Value is automatically closed under that equivalence. A profile defines the admission and decoding of its concrete representations. Representation rejection, exclusion from a profile domain, and operational inability to process an admitted Value are different conditions. None redefines the model's structural admission or equality. Capability minima and operational limits are not additional Value fields. The set model does not require every decoder to accept duplicate or reordered presentations. A profile specifies which presentations it accepts and how they map into a Value. Accepted presentations of the same Value MUST NOT change model equality or split a model equivalence class in derivation. In particular, an accepted duplicate presentation does not create a second occurrence in a mathematical set. Representation rules specify any transformations and treatment of unsupported source forms; they do not infer model membership merely from what a host parser can store.

Derivation and Comparison Claims A profile specifies how Values in its derivation domain produce identifiers. Under the same fixed applicable derivation semantics, equivalent Values in that domain MUST produce equal identifier values at the profile's defined output comparison boundary. A profile claiming independent recomputation MUST fix enough input material, rules, and dependencies for separate implementations to reproduce that result without hidden result-affecting state. The profile defines its encoding or other pre-processing, any cryptographic compression, and the construction and comparison of the output. It distinguishes comparison of a carrier representation from comparison of a decoded identifier value. Different profile semantics need not produce equal identifiers for the same Value. Source mapping and derivation have separate comparison responsibilities. A mapping can merge source distinctions before admission; an encoding can merge non-equivalent Values before a later primitive receives its input. When a deterministic remaining computation receives the same complete input, its equal outputs are not a collision of that later primitive. Such loss is considered separately from the primitive's false match properties. Exact model equality does not establish that a profile's derivation is free of false matches. The profile characterizes the comparison conclusions its construction supports. Consumers also establish any binding they rely on between a received identifier and its claimed Value or source. Structural admission and profile-domain admission alone do not establish conformance to a claimed source mapping. If a consumer relies on that claim, the mapping or surrounding protocol defines the required consistency checks or evidence, including any relationship between content associations and identifier-set membership. If reliance depends on validation before mapping, the surrounding protocol specifies how completion of that validation is established. For example, the content octets "00:" are structurally valid, but no accepted source under the mapping in produces them. An empty document reference and empty pair set instead produce "0:". Checking this mapping rule is distinct from checking the Value's type. For further background on comparison contracts and the limits of supporting evidence, see .

Changes to Applicable Semantics A change only in representation leaves a Value unchanged when the accepted representation still denotes that Value. A change affecting mapping results, profile-domain membership, source or imported comparison rules, imported interpretation, or derivation and output comparison rules changes the applicable comparison semantics. Such changes do not redefine the model equality specified in . Existing Values and identifiers MUST NOT be silently reinterpreted under incompatible changed semantics. A surrounding specification identifies the applicable definitions and any compatibility, migration, or continuity rules it provides. A semantic change does not automatically require a new model field or globally allocated context. The relevant mapping, context definition, or profile specifies how the change is distinguished.

Worked Trade-Document Mapping Examples Each example fixes an accepted source domain and its mapping rules. An input outside that domain has no mapped result under those rules; additional preprocessing requires an explicitly defined mapping. These examples define no API or error format.

Source Comparison and Mapping This informative example uses a simplified trade-document participant model. It is shaped after multi-party commercial-invoice, packing-list, and transport-document workflows. UN Verifiable Trade Documents (UNVTD) provides application context for these document families. This example defines its own source domain and comparison relation; it does not adopt an external document schema or assert document, shipment, legal, or party identity outside that relation. A source contains an exact ASCII document reference and a finite sequence of role and party-identifier pairs. Roles are the exact ASCII strings buyer, seller, and carrier. Party identifiers are nonempty ASCII tokens using lowercase letters, digits, and hyphen. Source equivalence requires equal document references and equal sets of role and party-identifier pairs. Entry order and duplicate presentations of a pair are irrelevant. No resolver, mutable alias state, or additional relationship semantics participates. The mapping uses the ASCII context example.org/trade-document/participants/v1. It places the exact document reference in content. For each source entry, it imports the party identifier and qualifies its scope by the participation role: scope = "trade-party/v1/role/" followed by the role identifier = exact party identifier identifiers is the set of the resulting pairs. These displayed strings denote exact ASCII octets; the notation is illustrative, not a wire format. Source A has document reference commercial-invoice:1234 and entries: [(seller, party-a), (buyer, party-b)] Its complete mapped Value is shown in . The mapping retains exactly the document reference and pair set defining source equivalence. The fixed scope prefix and restricted role alphabet distinguish participation, and exact identifier octets distinguish the party identifiers. This gives a general preservation and reflection argument for this example's source relation.

Comparison Cases Each case uses the same mapping and document reference commercial-invoice:1234 unless stated otherwise: A: [(seller, party-a), (buyer, party-b)] B: [(buyer, party-b), (seller, party-a), (seller, party-a)] C: [(seller, party-b), (buyer, party-a)] D: [(seller, party-a), (buyer, party-a)] E: document commercial-invoice:1235 with A's entries F: A's entries plus (carrier, party-c) A and B yield equivalent Values. Entry order and repeated presentation of an existing role/party pair do not change the mathematical set. A and C yield non-equivalent Values because the party/role associations are reversed. Retaining {buyer, seller} separately from {party-a, party-b} would erase that distinction. D contains two different scoped members even though both identifier components are party-a. It differs from A and from a source containing only one of D's roles. Repetition of one exact member would not express the other role. E differs from A in content while preserving the identifier set. F differs from A by an additional distinct set member while preserving context and content. These are model inequalities regardless of whether a trade workflow permits the source changes. An empty participant sequence maps to the empty identifier set and retains the exact document reference in content. Model admission permits that Value. Any application requirement for particular trade roles belongs to its source or profile rules.

Carrying Participation in Content An alternative mapping uses context example.org/trade-document/participants-content/v2 and unqualified scope trade-party/v1. Its identifier set contains each distinct party identifier once. Content carries the document reference and the complete association structure. illustrates this mapping for Source A. C abbreviates the context above, and S abbreviates the scope trade-party/v1. Adjacent quoted content fragments concatenate without added octets; their line breaks are only for display. In this mapping, the identifiers field retains the distinct scoped party identifiers, while content retains the document reference and role/party associations.

Source A Mapped into Content Associations party-a | P | "23:commercial-invoice:1234" | | | -----> | ";buyer=party-b" | | buyer --> party-b | | ";seller=party-a" | | | | | | | +-------------------------------+ +-------------------------+ | identifiers = { | | (S, "party-a"), | | (S, "party-b") | | } | +-------------------------------+]]>

Start content with the length of the document reference in octets, encoded as ASCII decimal digits with no leading zeros except "0" for an empty reference. Append ":" and the exact reference octets. Then sort the distinct role/party pairs lexicographically by ASCII role and then ASCII party identifier, with a proper prefix ordered before the longer string. Append each pair as ";" followed by the role, "=" and the party identifier. An empty pair set adds no suffix. The length prefix delimits the reference even when it contains ":", ";", "=", or text resembling a role/party suffix. The restricted role and party alphabets make the remaining suffix unambiguous. A and B then produce: context = "example.org/trade-document/participants-content/v2" content = "23:commercial-invoice:1234;buyer=party-b;seller=party-a" identifiers = { ("trade-party/v1", "party-a"), ("trade-party/v1", "party-b") } C has the same identifier set but different content: "23:commercial-invoice:1234;buyer=party-a;seller=party-b" D produces one identifier member and content retaining both roles: identifiers = {("trade-party/v1", "party-a")} content = "23:commercial-invoice:1234;buyer=party-a;seller=party-a" Thus the complete Value retains participation even when the member itself does not distinguish roles. Equal source references and pair sets produce identical framed content and identifier sets. Conversely, the length prefix recovers the exact reference; the remaining suffix recovers the complete role/party pair set. Equal Values therefore imply source equivalence. This establishes preservation and reflection for this mapping. The context version identifies these framing rules under . This mapping and the scope-qualified mapping in produce different Values. They are distinct mappings, so the model requires no convergence between their derived identifiers. These examples instantiate no derivation; their arguments establish mapping and model-equality properties only. gives additional cases for this mapping, including proper-prefix ordering and empty inputs.

Combining Independently Governed Systems This further example combines two fictional, independently governed party-identifier systems used by one trade application. The global system compares identifiers exactly. The local system also compares identifiers exactly but only within an exact jurisdiction namespace. Their interpretation rules are fixed here; no registry, resolver, or mutable alias information participates. A source contains an exact ASCII document reference and a finite sequence of entries, each in exactly one of these forms: (global, role, identifier) (local, jurisdiction, role, identifier) global and local are literal system tags. Roles are buyer, seller, or carrier. Jurisdiction and identifier values are nonempty ASCII tokens using lowercase letters, digits, and hyphen. Source equivalence requires equal document references and equal sets of entries. System tags, jurisdictions, roles, and identifiers remain exact. Order and repeated presentations of the same entry are irrelevant. These rules assert no identity relation between the two systems. The mapping uses context example.org/trade-document/two-systems/v1 and the exact document reference as content. For each entry, it constructs a member as follows; identifiers is the set of those members: global entry: scope = "trade-registry/v1/role/" followed by role identifier = exact identifier local entry: scope = "local-party/v1/jurisdiction/" followed by jurisdiction, then "/role/" followed by role identifier = exact identifier These strings denote exact ASCII octets. The disjoint system prefixes and restricted jurisdiction alphabet make the scope encoding unambiguous. A source with document reference bill-of-lading:5678 and these entries: [(global, seller, party-a), (local, east, buyer, party-a), (local, west, buyer, party-a)] maps to: context = "example.org/trade-document/two-systems/v1" content = "bill-of-lading:5678" identifiers = { ("trade-registry/v1/role/seller", "party-a"), ("local-party/v1/jurisdiction/east/role/buyer", "party-a"), ("local-party/v1/jurisdiction/west/role/buyer", "party-a") } All three identifier components have equal octets, but the scoped members are distinct. Reordering or repeating entries leaves the Value unchanged. Changing a role changes participation without changing the underlying identifier octets. Changing jurisdiction east to north instead changes the imported namespace. Encoding jurisdiction only in content while reusing one scope for all local namespaces would violate , even if complete Values remained distinguishable. Participation can instead be carried with its associations in content by a separately specified mapping, as in . The document reference is retained exactly. Each member uniquely retains its system, role, identifier, and jurisdiction where applicable. Sources with equal document references and equal entry sets yield equal Values; equal Values recover those same source components. This establishes preservation and reflection for the declared source relation without selecting an identifier derivation.

Adapting Native Spellings This separate example uses a fictional party-identifier system with ASCII case-insensitive comparison. Sources have the form defined in , except that party identifiers can also contain uppercase ASCII letters. Roles and document references remain exact. No resolver or mutable alias state participates. Define lower(p) by replacing each ASCII letter A through Z with its corresponding letter a through z and leaving every other accepted octet unchanged. Native identifiers are equivalent exactly when their lower(p) octets are equal. Source equivalence requires equal document references and equal sets of (role, lower(p)) pairs. Entry order and repetitions of a normalized pair are irrelevant. The mapping uses context example.org/trade-document/ascii-ci/v1 and scope trade-party-ascii-ci/v1. It replaces each party identifier p with lower(p), then applies the content framing, distinct-pair sorting, and identifier-set construction from to those normalized entries. The reference octets are unchanged. All displayed strings denote exact ASCII octets. With document reference invoice:1, these sources are equivalent: S1: [(seller, Party-A), (buyer, party-b)] S2: [(buyer, PARTY-B), (seller, party-a), (seller, PARTY-A)] Both produce: context = "example.org/trade-document/ascii-ci/v1" content = "9:invoice:1;buyer=party-b;seller=party-a" identifiers = { ("trade-party-ascii-ci/v1", "party-a"), ("trade-party-ascii-ci/v1", "party-b") } Equal source classes produce identical content and identifier sets. Conversely, the framed content recovers the exact reference and normalized role/party pair set that define source equivalence. The mapping therefore preserves and reflects that relation. Different normalized role/party pair sets remain distinguishable. If only imported members were adapted while content retained native party spellings, S1 and S2 would have equal identifier sets but different Values. That would violate whole-source preservation for this declared source relation, despite successful member adaptation. The model performs no further normalization to repair such a mapping.

Preserving Associations Between Parties This example records directed document-exchange links between parties. A source contains an exact ASCII document reference and a finite sequence of ordered (sender, recipient) pairs. Each endpoint is a nonempty ASCII party identifier using lowercase letters, digits, and hyphen, compared exactly under the fictional trade-party/v1 system. Source equivalence requires equal document references and equal sets of ordered pairs. Sequence order and repeated presentations of a pair are irrelevant. The links describe associations; they do not prove delivery or authorization. The mapping uses context example.org/trade-document/links/v1 and scope trade-party/v1. The identifier set contains each distinct endpoint identifier once, regardless of which position it occupies. Start content with the length-prefixed document reference defined in . Sort the distinct ordered pairs lexicographically by ASCII sender and then recipient, with a proper prefix before the longer string. Append each pair as ";", the sender, ">", and the recipient. An empty pair set adds no suffix. The restricted endpoint alphabet excludes both separators. With document reference invoice:1, compare: X: [(party-a, party-b), (party-c, party-d)] Y: [(party-a, party-d), (party-c, party-b)] shows the same endpoint sets with different ordered pairs. In graphical renderings, the Y links may cross; such a crossing does not join the links or introduce another party.

Same Endpoints with Different Pairings party-b party-a ----> party-d party-c ----> party-d party-c ----> party-b]]>

Both Values have: context = "example.org/trade-document/links/v1" identifiers = { ("trade-party/v1", "party-a"), ("trade-party/v1", "party-b"), ("trade-party/v1", "party-c"), ("trade-party/v1", "party-d") } Their content differs: X: "9:invoice:1;party-a>party-b;party-c>party-d" Y: "9:invoice:1;party-a>party-d;party-c>party-b" The sources have the same sender set and the same recipient set. Separate collections of sender-qualified and recipient-qualified identifiers would therefore erase their different pairings. The mapped content preserves those pairings, so X and Y yield non-equivalent Values. Reordering or repeating a source's existing pairs leaves its Value unchanged. Equal document references and ordered-pair sets produce identical content and identifier sets. Conversely, the length prefix recovers the exact reference, and the delimited suffix recovers every ordered pair. Equal Values therefore imply source equivalence. This establishes preservation and reflection for the mapping, including empty references, empty pair sets, and links whose sender and recipient identifiers are equal.

Relationship to Existing Work Scoped identifiers, composite records, exact octet comparison, and finite sets are established techniques. This specification combines them into a reusable comparison domain with obligations for mappings and profiles. The same information could be expressed in another structure or entirely within content; the dedicated identifier field provides reuse of qualification and set comparison rules, not additional expressive power. discusses canonicalization and other identifier comparison methods. distinguishes information models from data models; that distinction is an architectural analogy. separates an abstract data model from serialization choices. This document defines values independently of representation, leaving concrete encodings to profiles. provides the broader comparison-contract framework. Other specifications give collections of identifiers and relationships different meanings. describes aliases identifying the same subject. uses reference identifiers when matching service identities; its Section 6.5 preserves the association between an application service type and its domain name rather than recombining components from different reference identifiers. This is a concrete precedent for the association-preservation concern in . UNVTD provides schemas and semantic resources for trade documents, including commercial invoices, packing lists, and bills of lading. These document families provide application context for , whose source comparison relations and mappings are specified independently here. The UN Transparency Protocol Identity Resolver supports discovery and verification across identifier schemes and specifies conventions for consistent identifier representation. Its "Identifier Representation" section illustrates failed matching across credentials when one product is named using different URL and URN forms. In this model, any adaptation of such forms is fixed by the surrounding mapping under and ; model equality compares the resulting exact octets. Resolution and verification remain operations of the surrounding system. Controlled Identifiers and DIDs define application-specific alias, verification, and control relationships. The version of Recognized Entities cited here defines recognition and action relationships among entities and recognition systems. Those application relationships require their own interpretation. Recognition, authorization, control, succession, validity, and trust semantics remain properties of the surrounding system. When a source comparison requires a relationship among imported members, a source mapping can represent the comparison-relevant association under ; bare co-membership alone does not encode it. The model does not absorb the imported systems' internal derivation, resolution, lifecycle, or trust mechanisms.

Security Considerations A mapping can erase a required distinction or make equivalent sources yield non-equivalent Values through ambiguous parsing, unadapted native spellings, omitted associations, or inconsistent source processing. A consumer assesses these properties against the intended source relation. Loss within imported identifiers and loss in a later derivation are separate boundaries, as described in Sections and . Changing the admitted identifier set changes Value equality even when the application authorizes that change. An unauthorized omission, insertion, or substitution is an integrity failure when it violates the applicable mapping or the binding required by the consuming protocol. Duplicate presentations that leave the mathematical set unchanged do not by themselves change model equality. These effects are determined before attributing any equality to a downstream cryptographic collision. A surrounding protocol MUST protect the definitions that affect comparison and any attacker-controlled selection of those definitions according to its threat model. Protection can concern both acquiring authentic material and selecting the applicable mapping, context, imported interpretation, or profile. A stable name or authenticated locator alone does not fix mutable interpretation. Model equality authenticates neither a source nor its claimed identifier binding. Authority, freshness, revocation, provenance, and trust require separate evidence. Local resource limits remain necessary where appropriate for denial-of-service protection; refusal is not evidence of non-equivalence.

Privacy Considerations Stable or low-entropy material in a Value can permit correlation or offline guessing when used in a deterministic derived identifier. Hashing alone does not make that material confidential. Combining identifiers from independently governed systems can create linkage even when model co-membership asserts no cross-system identity. A particular combination can identify a smaller set of possible sources than any member alone. Exposing only a stable opaque result for that combination can retain correlation or guessing risks without exposing the individual member octets. Applications assess which identifying inputs are necessary, how widely derived identifiers are exposed, and whether their comparison purpose permits excluding unnecessary material. Persistent identifiers and linkability are discussed more generally in . Model opacity is a comparison boundary, not a confidentiality guarantee.

IANA Considerations This document has no IANA actions.

References Normative References Informative References United Nations Centre for Trade Facilitation and Electronic Business Project overview, last updated 28 July 2026. Accessed 11 September 2026. United Nations Centre for Trade Facilitation and Electronic Business Versioned specification for pre-production pilot implementations. Accessed 11 September 2026. Latest version available at . Latest version available at . Latest version available at .

Model Test Considerations These informative cases test model semantics without choosing a wire format, hash, API, or minimum resource capacity.

• Distinguish an empty set from a set containing an empty scope and identifier pair. Accept finite empty octet strings at the model boundary; apply any imported-system restrictions in the mapping or profile.
• Preserve arbitrary octets, including zero octets and values outside ASCII. Changing a scope or identifier octet changes the pair; a leading zero octet is not discarded by model comparison.
• For presentations accepted by a profile, verify that order and repeated members do not change the represented set. Test representation rejection separately; model set equality does not prescribe decoder acceptance.
• Hold imported interpretation and participation fixed when testing equivalent native spellings. Exercise reflection as well as preservation when an import mapping claims to retain native comparison unchanged.
• Test declared source equivalence against the complete Value. Equal imported members do not compensate for content that retains a spelling distinction excluded by the source relation. Exercise the equivalent sources and the incomplete-adaptation case in .
• Test role swaps, the same native identifier in different roles, and distinctions in position or occurrence. Check the association structure when participation is carried in content.
• In , compare "invoice:1" with pairs {(buyer, party-a), (seller, party-a)} against "invoice:1;buyer=party-a" with only {(seller, party-a)}. The identifier sets are equal; the framed content differs. Cover delimiter characters, suffix-like reference text, and empty references and pair sets, separately and together.
• Preserve grouping across multiple relationships when the source relation requires it. The edge sets {(a, b), (c, d)} and {(a, d), (c, b)} differ even though their input and output endpoint sets are identical. Role-qualified endpoints alone lose grouping. supplies a complete mapping and mapped Values for this case.
• Keep equal identifier octets under different systems or tenants distinct when their imported meanings differ. Vary participation separately from imported interpretation, as in .
• Check the intended native relation before adapting it to equality. Non-transitive overlap, as in , cannot be preserved unchanged by one independently computed identifier per source.
• Change context, content, or a distinct set member independently and check the resulting model inequality. Equal context octets from unrelated definitions do not establish imported semantic compatibility.
• Test fixed-input mapping reproducibility and explicit dependency selection. Keep structural rejection, profile-domain exclusion, and resource refusal distinct. A structurally admitted Value with inconsistent content associations and identifier-set membership is not evidence of conformance to the mapping in .
• In a concrete derivation profile, test tuple framing, complete set encoding, and equivalent accepted representations. Evidence about these profile properties is additional to evidence about model equality.

The additional cases in use the mapping in . Every Value has context example.org/trade-document/participants-content/v2. The following input sequences P0, P1, and P2 produce identifier sets I0, I1, and I2, respectively: P0 = [] P1 = [(buyer, party-a)] P2 = [(seller, party-ab), (seller, party-a)] I0 = {} I1 = {("trade-party/v1", "party-a")} I2 = {("trade-party/v1", "party-a"), ("trade-party/v1", "party-ab")} Additional Content-Framing Cases

Case	Reference	Pairs	Content
T1	""	P0	"0:"
T2	"invoice:1"	P0	"9:invoice:1"
T3	""	P1	"0:;buyer=party-a"
T4	""	P2	"0:;seller=party-a;seller=party-ab"
T5	hex 00	P0	hex 31 3a 00

Quoted strings denote exact ASCII octets without the quotation marks. In T5, hex notation denotes octets directly: the reference is one NUL octet, and content is ASCII "1:" followed by that octet. The ASCII reference domain does not exclude control octets. T4 exercises proper-prefix ordering of party-a before party-ab under the same role. These cases do not extend the example's source domain to non-ASCII octets. Selected cases can refute a universal claim but do not establish it over an unbounded domain. Mapping arguments in rely on the declared source relation and complete mapping rules, not solely on the displayed cases.