Carrier Independent Work Identity Governance¶

Keep a work recognizable as the same work across copies, formats, editions, performances, implementations, and migrations by explicitly governing what may vary and what creates a new work.

Overview¶

Carrier-Independent Work Identity Governance is for cases where the thing that matters is not one concrete file, printed copy, performance, repository, edition, or implementation, but the abstract work that persists through many of those carriers. It turns a vague same-work judgment into an explicit governance pattern: define the work, define the invariants that preserve it, name the variations that remain inside it, and record when a change creates a fork, derivative, successor, or new work.

The archetype is especially useful in archives, libraries, standards, software packages, performance traditions, design-pattern catalogs, and organizational knowledge bases. In all of these settings, a work can survive migration and variation, but only if the system knows what must survive.

When to use it¶

Use this archetype when people need to retrieve, cite, preserve, license, implement, perform, or maintain a work across multiple carriers. The pattern becomes urgent when variations accumulate: translations, editions, ports, scans, remediations, annotated versions, builds, performances, or institutional migrations. At that point, ordinary versioning is not enough. Someone must decide whether each changed instance is still an instance of the same work.

Do not use it for simple backup, ordinary version tracking, or source-of-truth assignment unless the work-level identity boundary is actually at stake.

Core intervention¶

The intervention creates a layer above concrete carriers. First, it states the abstract work in a way that is independent of any one carrier. Then it lists the manifestations through which the work appears. Next, it defines identity-preserving invariants and allowed variation. Finally, it records fork, derivative, supersession, and new-work decisions so future users can interpret changes consistently.

Key components¶

Component	Description
Work Identity Statement ↗	This statement names what persists. It distinguishes the work from its carrier, title, current location, file, edition, or repository. A weak work identity statement causes carrier collapse: the most visible instance becomes mistaken for the work itself.
Identity Preservation Criterion ↗	The criterion says what must remain true for a changed manifestation to count as the same work. Depending on the domain, this may involve semantic content, structure, function, authorship, performance constraint, normative commitment, compatibility, or community practice.
Allowed Variation Zone ↗	Not every difference matters. Formatting changes, minor corrections, medium changes, localization, performance choices, or implementation details may preserve the work when they stay inside the declared variation zone.
Fork Threshold Rule ↗	The fork rule identifies when continuity breaks. A work may become a derivative, successor, edition, branch, or new work when a modification changes the identity-preserving criterion beyond the accepted threshold.
Provenance Lineage Trace ↗	Provenance supplies evidence for identity. It records where a manifestation came from, how it changed, who maintained it, what it derived from, and which identity decisions were made along the way.

Common mechanisms¶

Common mechanisms include abstract work registers, work-expression-manifestation matrices, identity preservation checklists, fork decision records, persistent identifier resolution policies, version lineage graphs, migration context preservation plans, semantic diff reviews, manifestation catalogs, boundary-case tables, archival provenance templates, and governed translation or adaptation reviews.

A mechanism should not be confused with the archetype. A persistent identifier can point to a work, but it does not decide what counts as the same work. A version-control graph can track divergence, but it does not by itself define whether a branch is still the same work.

Parameters and invariants¶

Important parameters include the level of abstraction being governed, the strictness of the identity criterion, the size of the allowed variation zone, the review threshold for changes, the authority model, the provenance evidence required, the persistence requirements for identifiers, and the consequences of supersession.

The main invariants are that the work is not collapsed into one carrier, identity-preserving variation is bounded by an explicit criterion, fork decisions are recorded, and users can tell whether they are dealing with the work, an expression, a manifestation, an edition, an item, a derivative, or a successor.

Neighbor distinctions¶

Versioned Evolution tracks ordered change. This archetype governs same-work identity across carriers and manifestations.

Branching and Merging manages parallel lines of work. This archetype decides whether a divergent line is still a branch of the same work or a new work.

Source-of-Truth Assignment chooses an authoritative current reference. This archetype defines what that reference is a reference to.

Equivalence Class Consolidation groups items for reasoning or simplification. This archetype preserves a persistent work identity, manifestation distinctions, lineage, and fork decisions.

Data Integrity Preservation protects correctness of records. This archetype governs the identity of the work that the records represent.

Examples and non-examples¶

A catalog record that links print editions, digital scans, translations, and copies under one abstract work identity is an example. A standards body deciding whether a changed specification remains the same standard is an example. A software maintainer distinguishing a compatible port from a new project is an example. A performance archive deciding which staging variations remain performances of the same work is an example.

A backup copy, a URL redirect, a commit history, or a one-time equivalence judgment is not this archetype unless it includes the work-level identity criterion and fork boundary.

Common Mechanisms¶

Abstract Work Register
Archival Provenance Metadata Template
Edition and Manifestation Catalog
Fork Decision Record
Governed Translation or Adaptation Review
Identity Boundary-Case Table
Identity Preservation Checklist
Migration Context Preservation Plan
Persistent-Identifier Resolution Policy
Semantic Diff Review
Version Lineage Graph
Work–Expression–Manifestation Matrix

Compression statement¶

Carrier-Independent Work Identity Governance applies when the object of concern is not one physical or digital carrier but a content identity that persists through many carriers. The intervention separates work-level identity from expression, manifestation, edition, copy, implementation, or performance; states the invariant criteria that make instances count as the same work; records allowed variation; defines fork and supersession thresholds; and maintains provenance, identifiers, and review pathways so future changes can be classified consistently.

Canonical formula: Work W persists across carriers c1..cn when each manifestation mi preserves identity criterion I(W); if change Δ violates I(W) beyond threshold T, classify as fork, derivative, supersession, or new work rather than same-work instance.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (7)

Abstract Work: A content identity that persists across its concrete carriers, with an explicit criterion for which instance-variations preserve the work and which fork a new one.
Abstraction: Focus on core elements.
Equivalence Relation: Groups elements into equivalence classes.
Identity-Preserving Modification: An entity undergoes an event that changes some of its properties while an identity-condition licenses calling the after-state a continuation of the same entity rather than its replacement.
Identity-Providing Kind: A category whose membership fixes what it takes for an instance to remain the same instance over time, supplying persistence criteria rather than a temporary description.
Persistent Identifier: A designed token committed to keep resolving to its entity across changes in the entity's location, representation, custodian, or version, via a separately maintained resolver.
Versioning: Tracks incremental changes over time.

Also references 18 related abstractions

Alias-to-Authority Mapping: One canonical form for a referent is maintained while every variant label routes many-to-one to it, so identity aggregates while the referent stays reachable by any name.
Boundary: Defines system limits.
Boundary State Loss: State crossing a carrier boundary through a bounded artifact is constitutively reduced, surfacing later as failure.
Canonical Form: A unique distinguished representative per equivalence class lets equivalence be tested by identity of representatives.
Continuity: Smooth change without jumps.
Data Integrity: Accuracy and consistency preserved.
Design Patterns: Reusable solutions.
Invariance: Properties unchanged under transformation.
Isomorphism: Structure-preserving mapping.
Legacy Integration: Maintains knowledge and identity across organizational discontinuities.

▸ Show 8 more

Variants¶

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Bibliographic Work Identity Management · domain variant · recognized

Govern work, edition, translation, manifestation, and item-level identity in bibliographic or archival collections.

Distinct from parent: The parent is cross-domain; this variant is library, archive, publication, and collection oriented.
Use when: Multiple editions, translations, formats, or copies need to be linked without erasing their differences; Users must cite either the work as such or a specific manifestation; Catalog maintenance must preserve identity through migration or institutional handoff.
Typical domains: library information science, archives, scholarly publishing, cultural heritage
Common mechanisms: abstract work register, edition manifestation catalog, archival provenance metadata template, persistent identifier resolution policy

Design-Pattern Work Identity · domain variant · candidate

Maintain the identity of a design pattern across implementations, examples, notations, and local adaptations.

Distinct from parent: The variant specializes the identity criterion around pattern invariants and implementation variation.
Use when: A pattern is instantiated in many systems or media but should remain recognizable as the same pattern; Teams need to distinguish permissible adaptation from a new pattern; Pattern libraries must support reuse without freezing every incidental feature.
Typical domains: software architecture, organizational design, education, product design
Common mechanisms: identity preservation checklist, identity boundary case table, semantic diff review

Performative Work Identity Governance · domain variant · candidate

Govern identity across performances, renderings, installations, reenactments, or embodied realizations where no single material carrier exhausts the work.

Distinct from parent: The parent covers all carrier-independent identity; this variant handles performance and embodied realization cases.
Use when: A work is realized through performance, interpretation, execution, or audience participation; Variation is expected but must remain bounded by identity criteria; Documentation, notation, recording, and live realization each capture only part of the work.
Typical domains: performing arts, ritual design, interactive media, installation art
Common mechanisms: work expression manifestation matrix, semantic diff review, migration context preservation plan

Software Contract Work Identity · domain variant · candidate

Govern whether code, schemas, APIs, packages, or specifications remain the same work across builds, releases, ports, and compatibility changes.

Distinct from parent: The parent is not software-specific; this variant emphasizes release, API, schema, and dependency semantics.
Use when: A software object persists through concrete builds, packages, repositories, mirrors, or platform ports; Compatibility and semantic versioning interact with identity and fork decisions; Users need to know whether a changed artifact is the same maintained work or a new line.
Typical domains: software engineering, data standards, platform governance
Common mechanisms: version lineage graph, persistent identifier resolution policy, fork decision record, semantic diff review

Near names: Abstract Work Identity Governance, Work Identity Boundary Management, Carrier-Independent Identity Management, Work–Expression–Manifestation Model, Bibliographic Identity Control.