Abstract Work¶
Core Idea¶
Abstract work is the structural commitment to recognize a content identity distinct from any of its concrete carriers — the play apart from any performance, the symphony apart from any recording, the algorithm apart from any source file, the recipe apart from any meal, the statute apart from any printed copy, the design apart from any manufactured unit. The work is what persists when one carrier is swapped for another; the carriers are what change while the work stays the same. Five roles travel together: the work, the abstract identity itself; the set of instances, its concrete realizations; the identity criterion, specifying what counts as the same work across different instances versus a different work — same content, allowable variation, requisite faithfulness; the attribution, who or what produced the work, often distinct from who produced any given instance; and the lineage, the revisions and editions that count as updates to the same work versus those that fork a new one.
The pattern is prime-shaped because the choice of where to draw the work/instance line is forced wherever the same content is realized in multiple carriers. Drawing it wrong is a recognizable failure: collapse the distinction and one cannot ask whether two performances are of the same piece or whether a translation is of the same novel; over-multiply it and every printing becomes its own work while lineage shatters into noise. The skeleton — work, instance, identity criterion, attribution, lineage — recurs across every substrate where the question "is this the same thing or a different one?" is non-trivial.
The structural force is the separation of identity from carrier. By committing to a content identity that persists across realizations, the pattern lets operations and queries range over carriers — "any version of this," "the canonical form of," "all renditions of that" — which are unaskable in a system that can refer only to the carriers themselves. The identity criterion is the load-bearing role: it is what does the work of deciding which variations preserve the work and which create a new one, and a schema that omits it has not earned the work level. The pattern is substrate-neutral in its skeleton, even though its central term — "work" — is most at home among cultural artifacts; the bare structural cousin, the type-token distinction, shows the same separation applied to symbols.
How would you explain it like I'm…
Same Song, Many Ways
The Story Behind The Copies
The Work Versus Its Copies
Structural Signature¶
the abstract content-identity (work) — the set of concrete carriers (instances) — the identity criterion partitioning same-work from different-work variation — the attribution of the work — the lineage of updates versus forks — the separation-of-identity-from-carrier invariant
The pattern is present when each of the following holds:
- A persisting content-identity. Something is taken to remain the same thing across a swap of its concrete carriers — the content that persists when one realization is exchanged for another.
- A set of instances. Two or more concrete realizations are recognized as carriers of that identity, distinct from it and distinct from one another.
- An identity criterion. An explicit rule decides which instance-variations preserve the work and which constitute a different work — same content, allowable variation, requisite faithfulness. This is the load-bearing role: a schema lacking it has only carriers, not works.
- An attribution. The work has a producer-of-record, potentially distinct from the producer of any given instance.
- A lineage. Revisions and editions are sorted into those that count as updates to the same work and those that fork a new one.
- The separation invariant. Identity is held apart from carrier, so operations and queries can range over carriers — "any version of," "the canonical form of," "all renditions of" — which are unaskable in a system that can refer only to carriers.
The identity criterion governs two opposite failures: set too loose, it collapses distinct works and makes "same thing" unaskably broad; set too tight, it multiplies works per carrier and shatters lineage. Composed, the roles give operations a correct altitude — work-level for citation and recall, instance-level for audit and reproduction.
What It Is Not¶
- Not
abstractionin general. Abstraction is the purpose-driven selection of structure from detail; abstract work is the specific output of that operation when the result is a content-identity carried across multiple swappable carriers. Not every abstraction yields a work — a conceptual category abstracts without producing instances that range under one name. - Not the type-token distinction alone. Type-token is the bare structural cousin, applied to symbolic occurrences; abstract work generalizes it to non-symbolic content (designs, procedures, performances) and adds the load-bearing roles type-token lacks — an explicit identity criterion, attribution, and lineage.
- Not
form_and_content. Form-and-content is a dualism within a single carrier (the same content rendered as prose or verse). Abstract work concerns identity across multiple carriers; a work has both form and content, and its instances replicate both. - Not
versioning. Versioning tracks the ordered succession of an artifact's states; abstract work is the prior commitment that decides which of those versions count as the same work and which fork a new one. Versioning operates inside a lineage the identity criterion has already delimited. - Not
provenance. Provenance tracks where a particular carrier came from and through whose hands; abstract work tracks what identity persists across carriers regardless of their individual histories. A faithful instance and a corrupt one share the work but have different provenance. - Not
representation. A representation stands for something else; the work's instances do not represent the work, they are realizations of it. A performance is not a sign pointing at the symphony; it is an instance of it. - Common misclassification. Declaring a "work layer" present merely because a system has an abstract record above its copies. The catch is the identity-criterion test: if there is no operational rule deciding which instance-variations preserve the work and which fork a new one, the system has only carriers under a shared label, not works.
Broad Use¶
The content-identity-across-carriers pattern recurs across substrates that share the structure while differing in vocabulary. In bibliographic systems it is the four-level distinction between a work, its expressions such as particular texts or translations, its manifestations such as particular editions, and its items such as a physical copy[1] — which lets a catalog answer "do you have any version of this?" rather than only "do you have this exact edition?" In music, the composition is the work while individual performances, recordings, and score editions are instances, and royalty and copyright law turns on the distinction.[2] In software, the program is the work while a binary build, a running process, and a deployed container are instances; source versioning operates on the work, build pipelines on instances.[3] In engineering and design, a design or type-certificate is the work while manufactured units are instances, so recalls target the work and serial-number tracking targets the instances.[4] In law, a statute is the work while printed copies and database renderings are instances[5] — the work has legal effect, the instances are renditions of it. In recipes and procedures, the recipe or protocol is the work while each meal or each run is an instance. And in philosophy and linguistics, the type-token distinction is the same pattern applied to symbolic occurrences.[6] In every case the work/instance line is drawn, an identity criterion governs it, and operations route to the appropriate level.
Clarity¶
The diagnostic is sharp: pick any system that handles repeatable content and ask what travels under the same name across different carriers and what changes between carriers. If the system has a stable answer — the work-criterion is operational — abstract work is present. If the system can refer only to the carriers, with no way to say "the same thing in a different copy," then the work layer has not been built, and the system will struggle with any question that ranges across carriers.
The clarifying force is that the prime separates abstract work from several neighbors it is routinely fused with. General abstraction is the purpose-driven selection of structure from detail; abstract work is the specific output of that operation when the result is a content identity persisting across carriers — not every abstraction is a work, since a conceptual category abstracts without yielding a carried-across-copies identity. Form and content is a dualism within a single carrier — the same content told as prose or verse — while abstract work concerns identity across multiple instantiations; a work has both form and content, and its instances replicate both. Signifier and signified concern how a sign refers, while abstract work concerns identity-across-copies — a play is not the signifier of itself; its performances are instances of it. And the type-token distinction is essentially the same pattern applied to symbolic occurrences, which abstract work generalizes to non-symbolic content such as designs, procedures, and performances. By drawing these lines, the prime makes precise that the operative role is the identity criterion, and that a system without one has only carriers, not works.
Manages Complexity¶
Without the work/instance separation, every concrete copy is its own thing, and there is no way to say "all versions of this," "any rendition of that," or "the canonical form of." With the separation, queries and updates operate at the right level: a recall targets a work, an audit targets an instance, a citation targets a work with optional precision to an instance. The compression is large: instead of many independent entries, the system holds one work plus many instance links, together with a lineage that records which instances count as the same work.
The deeper complexity-management insight is that the work level gives operations a correct altitude to act at, which prevents two opposite pathologies at once. Operating only at the instance level — treating each copy as sui generis — makes cross-carrier operations impossible and forces every query to enumerate carriers, an unbounded and error-prone task. Operating only at a collapsed work level — ignoring the instances — makes per-carrier operations such as audit and reproduction impossible, since there is nothing to inspect. By holding both levels and an explicit identity criterion that links them, the prime lets each operation choose its altitude: range over carriers when the question is about the work, drill to a carrier when the question is about a particular realization. This is the structural reason mature systems for repeatable content all develop a work layer — it is the only way to keep cross-carrier queries cheap without losing the ability to act on individual carriers.
Abstract Reasoning¶
The pattern lets a reasoner carry intuitions across domains. The questions a cataloguer asks — when is a new translation a new work, when is a paperback merely a new instance — are the same questions a software engineer asks — is this fork a new project or a new release, is a patch a new instance or a new work — the same a luthier asks about a restored instrument, and the same a legal scholar asks about whether a codified version is the same statute as the original enactment. The identity-criterion choices in one field illuminate the choices in another because they are choices about the same role.
The reasoning is portable because it is stated over the five roles, none of which mentions a substrate. The work, the instances, the identity criterion, the attribution, and the lineage are present in every case, and the two failure modes follow mechanically from how the identity criterion is set: too permissive a criterion collapses distinct works into one and makes "same thing" unaskably broad, while too strict a criterion multiplies works per carrier and shatters lineage. A reasoner who has internalized the prime predicts a system's pathologies from how it draws the line — a music platform that conflates performances with compositions cannot route royalties, a code repository that conflates programs with build artifacts cannot reproduce a bug, a museum that conflates a sculpture's identity with its physical material cannot decide whether a restored work is still the same. In each, the diagnosis is the same: locate the identity criterion, check whether it is set too loose or too tight, and predict the corresponding failure.
Knowledge Transfer¶
A reader who sees the pattern recognizes it in new domains and notices when systems lack it. The fix is the same in every case: separate the work, specify the identity criterion, and let the instances multiply without losing the thread. A music platform that cannot route royalties, a repository that cannot reproduce a bug, and a museum that cannot decide whether a restoration is the same sculpture all have the same gap — no operational work layer — and the same remedy.
What makes the transfer genuine is that the five roles map cleanly across substrates that share no vocabulary. A novel existing in an original language, several translations, an audiobook, dozens of print editions, and an e-book file — one work, several expressions, many manifestations, many items — has its roles mirror exactly onto an application distributed as one program in several versions compiled for several builds installed as many instances, even though one substrate is literature and the other is software. A reasoner who has internalized the prime reads a new system by locating the five roles and inherits the full discipline: build a work level, make the identity criterion operational, track attribution and lineage at the work level with optional per-instance attribution, and route each operation — citation, recall, license to the work; inventory, audit, reproduction to the instance — to its correct altitude. The pattern's skeleton is structural, but its central term imports cultural-artifact framing, so the transfer is anchored in cultural-artifact substrates — bibliography, music, software, design, law, procedure — with the type-token distinction as its bare structural cousin reaching into symbols. Within that range it is broad and well-documented, and the prime's distinctive value is that it lets a practitioner who has mastered the work/instance line in one medium immediately understand why a system in another medium succeeds or fails at ranging across its carriers, because all of them turn on the same separation of identity from carrier and the same load-bearing identity criterion.
Examples¶
Formal/abstract¶
The bibliographic four-level model is the canonical formal instance, because it makes the identity criterion explicit at three nested layers.[1] Take a novel: the work is the abstract content-identity (the novel as an intellectual creation); its expressions are realizations that preserve the work while differing in intellectual form — the original-language text, a French translation, an abridgement, an audiobook reading; its manifestations are physical or digital embodiments of an expression — a hardcover edition, a paperback, an e-book file; and its items are individual copies — the specific paperback on a particular shelf.[1] The identity criterion is layered: a translation is a new expression of the same work (the content persists, the language varies within the allowable bound), whereas a sequel is a new work (the content forks).[1] This is exactly the load-bearing role of the prime — the rule that partitions same-work variation from different-work variation — operationalized so a catalog can answer "do you have any version of this?" by querying at the work level rather than enumerating items. The two failure modes are concrete here: set the criterion too loose and distinct works (a novel and its film adaptation) collapse into one, making "the same thing" unaskably broad; set it too tight and every reprint becomes its own work, shattering the lineage that links editions. Operations route to their correct altitude: a citation targets the work, an interlibrary loan targets the item, and a "find me a large-print copy" query traverses from work down to a manifestation with the right attributes.
Mapped back: The work–expression–manifestation–item hierarchy instantiates the prime's five roles, with the layered identity criterion deciding at each level which variation preserves the work and which forks it, and the two opposite mis-settings producing the predicted collapse-versus-shatter failures.
Applied/industry¶
Two industry cases turn on the same separation. In software release engineering, the program is the work; a version compiled for several targets is an expression-like layer; a build artifact (a specific binary or container image, identified by a content digest) is an instance.[7] The identity criterion is what a release process must make operational: a backward-compatible patch is an update to the same work (the version lineage continues), whereas a hard fork under a new name is a different work. Getting the line wrong has direct consequences the prime predicts — a repository that conflates the program with its build artifacts cannot reproduce a reported bug, because the bug report cites the work while reproduction requires the exact instance, and the missing work/instance separation means the instance was never addressable. In product-safety and manufacturing, the type design (or type certificate) is the work and each manufactured serial-numbered unit is an instance.[4] A recall operates at the correct altitude precisely because the levels are separated: a design-level defect triggers a recall of the work (every unit built to that design), while a single damaged unit is an instance-level event tracked by serial number. A firm that conflates the two cannot scope a recall — it either over-recalls (treating an instance defect as a design defect) or under-recalls (failing to propagate a design defect to all units), the same collapse-versus-shatter pathologies the identity criterion governs. In both cases the remedy is identical to the prime's prescription: build an operational work layer, make the identity criterion explicit, and route each operation — bug reproduction, recall, citation, audit — to the work or the instance as its altitude demands.
Mapped back: Software builds and manufactured units span computing and engineering; in each the work/instance line plus an operational identity criterion is what makes work-level operations (recall, reproduction) and instance-level operations (audit, serial tracking) both possible, and conflating the levels reproduces the collapse-or-shatter failure.
Structural Tensions¶
T1 — Criterion Looseness versus Tightness (measurement). The identity criterion is a dial, and both extremes are pathologies the prime names: too loose and distinct works collapse so "same thing" becomes unaskably broad; too tight and every reprint forks a new work, shattering lineage. The criterion is not given by the substrate — it is a stipulation the system must make and defend. The failure mode is leaving it implicit and discovering only in dispute that two operators read it differently. Diagnostic: present a borderline case (a translation, a remaster, a refactor) and check whether the system gives one determinate answer; if reasonable operators disagree, the criterion is under-specified.
T2 — Update versus Fork in Lineage (temporal). Lineage must sort revisions into "same work, new instance" and "new work." But the two regimes blur over time: a long sequence of small backward-compatible patches can accumulate until the result shares almost nothing with the original, with no single edit being the fork. The failure mode is creeping identity — a work that has silently become a different work while every step claimed continuity, so citations to "the work" now reach content the original author would not recognize. Diagnostic: compare the current instance against the founding one, not against its immediate predecessor; the question is whether the chain as a whole preserved the work, not whether each link did.
T3 — Attribution of Work versus Instance (scopal). The producer of the work and the producer of an instance can differ — a composer versus a performer, an author versus a translator, a designer versus a manufacturer. The prime separates them, but operations routinely need both and conflate them. The failure mode is crediting or blaming the wrong level: routing royalties for a performance to the composer alone, or attributing an instance defect to the work's author. Diagnostic: for any attribution claim ask whether it is a claim about the content-identity or about a particular realization; if the system stores only one attribution slot, it cannot answer mixed-level questions.
T4 — Work as Real versus Work as Convention (scopal). The prime reifies the work as a thing that persists across carriers, but in many substrates the work has no existence apart from an institutional decision to treat a set of instances as one — there is no symphony "out there" beyond the convention that these performances are of it. Where the work is purely conventional, disputes about identity are disputes about authority, not about facts. The failure mode is arguing about "what the work really is" when the real question is "who gets to decide." Diagnostic: ask whether any test independent of the maintaining institution could settle a same-work dispute; if not, the work is a governance object, not a discovered one.
T5 — Instance Faithfulness versus Drift (sign/direction). The criterion permits allowable variation, but instances can drift far enough to misrepresent the work while still claiming to instantiate it — a corrupt build, a sloppy performance, a mistranslation. The separation invariant lets queries say "any version of this," which is exactly the danger: an unfaithful instance inherits the work's authority. The failure mode is treating every carrier bearing the work's name as a trustworthy realization of it, so a defective instance discredits the work. Diagnostic: distinguish "is an instance of" from "is a faithful instance of"; a system that tracks only the former cannot quarantine a bad carrier.
T6 — Abstract Work versus Abstraction (coupling). Abstract work is the output of an abstraction operation only when the result is a content-identity carried across copies; not every abstraction yields a work, and the prime overreaches if applied to abstractions that have no instances to range over. The boundary with general abstraction is where the prime stops being the whole story. The failure mode is forcing a work/instance frame onto a conceptual category that has carriers of no kind, manufacturing a phantom instance layer. Diagnostic: ask whether there are genuinely distinct concrete carriers that could be swapped while the identity persists; if the "instances" are just sub-cases of a concept, this is abstraction, not abstract work.
Structural–Framed Character¶
Abstract work sits at the mixed-structural midpoint of the structural–framed spectrum, at an aggregate of 0.4 — a genuinely structural skeleton wearing a cultural-artifact frame, with four of the five diagnostics at the half-mark. The skeleton is the separation of a content-identity from its carriers: a work, a set of instances, an identity criterion deciding which variations preserve the work, an attribution, and a lineage.
Only one diagnostic reads fully structural — evaluative_weight at 0 — because drawing the work/instance line carries no inherent approval; it is a neutral modeling choice, not a verdict on the work's merit. The other four sit at 0.5, and they trace to a single fact: the prime's central term, "work," is most at home among cultural artifacts. vocab_travels is 0.5 because the work/instance idiom — edition, rendition, the same piece — partly travels with the pattern. institutional_origin and human_practice_bound are each 0.5 because the canonical cases (FRBR bibliographic works, musical compositions, statutes, software releases) are products of human cultural practice and the maintaining institutions that distinguish editions from new works. import_vs_recognize is 0.5 because invoking "work" tends to import the cultural-artifact framing rather than purely spot a structure.
What keeps every framed criterion at half rather than full — and earns the mixed-structural rather than framed label — is the bare structural cousin sitting underneath: the type/token distinction, which applies the same identity-from-carrier separation to plain symbols with no cultural framing at all. Because the skeleton genuinely transfers to that substrate-neutral case, and because the identity criterion is a structural role that any multi-carrier domain must fill, the prime is balanced at the midpoint rather than pulled into the framed interior.
Substrate Independence¶
Abstract work is a strongly substrate-independent prime — composite 4 / 5 on the substrate-independence scale. Its five-role skeleton — work, instance set, identity criterion, attribution, lineage, held together by the separation-of-identity-from-carrier invariant — is genuinely cross-substrate and can be stated without naming any medium, which sustains the structural-abstraction mark. The domain breadth is wide: the same work/instance line is drawn in bibliographic systems (the FRBR work–expression–manifestation–item hierarchy), in music (composition versus performances and recordings), in software (program versus build artifacts and deployed containers), in engineering (type design versus manufactured units), in law (statute versus printed renditions), and in recipes and procedures (the protocol versus each run), with the type/token distinction as the bare structural cousin reaching into symbols. Transfer evidence is concrete: the identity-criterion choices a cataloguer makes (when a translation is a new work) map cleanly onto the choices a release engineer makes (when a fork is a new project), and the same collapse-versus-shatter failure modes recur across the substrates. What pins it to 4 rather than 5 is that its central term, "work," is most at home among cultural artifacts and its canonical cases are products of human cultural practice — there is no work "out there" in physics or biology — so the pattern is anchored in cultural-artifact substrates even though its skeleton transfers cleanly within them.
- Composite substrate independence — 4 / 5
- Domain breadth — 4 / 5
- Structural abstraction — 4 / 5
- Transfer evidence — 4 / 5
Relationships to Other Abstractions¶
Current abstraction Abstract Work Prime
Parents (2) — more general patterns this builds on
-
Abstract Work is a kind of Type–Token Distinction Prime
Abstract Work is the enriched work-and-carrier species of the bare type-and-token split, adding a content identity criterion, attribution, and lineage.A Work is a repeatable identity distinct from its numerically distinct concrete realizations, with facts and operations routed separately to the shared identity and to each realization. The Work species adds culturally anchored content identity, a same-work boundary, producer attribution, and revision-versus-fork lineage.
-
Abstract Work presupposes, typical Abstraction Prime
Abstract_work is the output of an abstraction operation when the result is a content-identity carried across swappable carriers — presupposes abstraction but adds the load-bearing instance-set and identity-criterion that abstraction-in-general lacks.The 0.93 similarity is parent-to-product. Abstraction supplies the prerequisite condition: Focus on core elements. Abstract Work operates against that background: 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. If the parent condition is removed, the child relation becomes undefined or loses the mechanism asserted by this edge; the parent can obtain independently, so the relation is presupposition rather than subsumption. The typical qualifier limits the claim to the characteristic route, not a constitutive requirement of every instance; exceptions must retain the child's identity through another mechanism.
Children (1) — more specific cases that build on this
-
Item (Copy) Domain-specific presupposes Abstract Work
Calling one copy an Item at the bottom of WEMI presupposes a content identity that persists above its concrete carriers and fixes which variations remain realizations of the same Work.The entry's Item-level identity, one-Manifestation-to-many-Items cardinality, property routing, and bounded copy operations are intelligible only inside a Work/Expression/Manifestation/Item model that separates a Work from its realizations. Abstract Work carries that work-versus-carrier commitment and its identity criterion. The edge does not claim that Abstract Work is the bare Type/Token distinction: the source and prime both explicitly distinguish that thinner missing parent from the richer work identity.
Hierarchy paths (2) — routes to 1 parentless root
- Abstract Work → Type–Token Distinction → Abstraction
- Abstract Work → Abstraction
Neighborhood in Abstraction Space¶
Abstract Work sits among the more crowded primes in the catalog (21st percentile for distinctiveness): several abstractions describe nearly the same structure, so a description that fits it will tend to fit its neighbors too — transporting it usually means disambiguating within this family rather than landing on it exactly.
Family — Unclustered & Miscellaneous (424 primes)
Nearest neighbors
- Identity (philosophy) — 0.75
- Legacy Integration — 0.75
- Design Patterns — 0.73
- Identity-Preserving Modification — 0.73
- Boundary State Loss — 0.73
Computed from structural-signature embeddings · 2026-09-10
Not to Be Confused With¶
The dominant confusion — and the embedding-nearest neighbor at similarity 0.93 — is with abstraction itself. The two are genuinely related: abstract work is a product of abstraction, the case where abstracting from carriers yields a stable content-identity. But abstraction is a far broader operation, and most of its outputs are not works. Abstraction selects salient structure and discards detail for a purpose — a category, a model, an interface, a principle — and many of these have no concrete carriers to range over at all. The defining extra that abstract work carries is the instance set plus an identity criterion: there must be genuinely distinct carriers that could be swapped while the identity persists, and a rule deciding which swaps preserve the work. The mammal concept abstracts over animals but has no "copies" you could audit or recall; the symphony abstracts into a work precisely because performances and recordings are swappable carriers governed by a same-work rule. Conflating them leads a designer to impose a work/instance frame on a pure concept (manufacturing a phantom instance layer, the failure named in T6) or, conversely, to treat a genuine work as a mere abstraction and lose the ability to address its individual carriers for audit and reproduction.
A second, subtler confusion is with versioning. Both deal with multiplicity and change over a thing's identity, and versioning systems are where the work/instance question usually gets forced. The distinction is one of logical priority. Versioning operates inside an already-drawn identity: given that these revisions all belong to the same work, it orders and labels them. Abstract work is the prior commitment that draws the boundary — it owns the fork-versus-update decision that versioning presupposes. When a long chain of backward-compatible patches accumulates until the result shares almost nothing with the original (the creeping-identity failure of T2), versioning has dutifully recorded every step while the work has silently become a different work — a judgment versioning cannot make, because it never owned the identity criterion. A practitioner who treats versioning as sufficient mistakes a record of changes for a theory of sameness, and discovers too late that "the same work" now reaches content the original would not recognize.
A third confusion, common in semiotics-adjacent settings, is with representation. A representation stands for something else across a referential gap — a map for terrain, a word for a meaning. It is tempting to say the instances "represent" the work. But the relation is realization, not reference: a performance does not point at the symphony the way a signifier points at a signified; it instantiates it. The work is present in each faithful instance, not designated by it. This matters because representational thinking invites questions of accuracy and fidelity-of-pointing, whereas the work/instance relation invites questions of identity-preservation and allowable variation. A corrupt build or sloppy performance (the drift failure of T5) is not an inaccurate sign of the work; it is an unfaithful realization of it — a different diagnosis with a different remedy.
These distinctions matter because each guards against a different practical error. Confusing abstract work with abstraction makes one either over-apply the work frame to carrier-less concepts or under-apply it to genuine works that need addressable instances. Confusing it with versioning makes one mistake change-tracking for identity-governance and miss creeping forks. And confusing it with representation makes one treat realizations as signs and apply fidelity-of-reference reasoning where identity-preservation reasoning belongs. In every case the discriminating role is the same: the explicit identity criterion partitioning same-work from different-work variation, which only abstract work carries.
Solution Archetypes¶
Solution archetypes in the catalog that build on this prime — directly (this prime is a source ingredient) or as a related prime.
Built directly on this prime (3)
- Aspect-Scoped Identity Projection: Represent one underlying entity under a defined aspect or role as a linked derived bearer, so properties, rights, obligations, identifiers, and lifecycle rules attach only where they belong.▸ Mechanisms (9)
- Aspect Lifecycle Register — Tracks each aspect's state through time — proposed, active, suspended, superseded, retired — with the persistence rules that decide every transition and the evidence that triggered it.
- Context-Sensitive Classification
- Database View or Entity Projection — Exposes an entity under one aspect as a derived record assembled at read time from the underlying source, showing only the columns and rows that aspect is entitled to.
- Legal Capacity or Status Record — Establishes a person or organization acting in a specific legal capacity as a formal, authority-backed record naming the capacity and the evidence that created it.
- Role-Based Access Profile — Grants an account the permissions of a named role, scoped and purpose-limited so what one capacity may do never leaks into another.
- Role-Scoped Record Type — Defines a distinct stored record type for an entity under a role, with its own key and its own rules for reconciling clashes with the underlying entity.
- Scoped Namespace Suffix — Makes an aspect independently addressable by attaching a scope qualifier to the underlying entity's name, keeping the link to the base visible inside the identifier itself.
- Typed Identity-Relation Edge — Represents the bond between an underlying entity and one of its aspects as a single typed, first-class edge that can carry its own precedence and conflict rules.
- Work / Expression / Manifestation / Item Model — Splits a creative artifact into a four-level ladder — work, expression, manifestation, item — so each abstraction level bears only the properties that belong to it.
- 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.▸ Mechanisms (12)
- Abstract Work Register — The canonical, resolver-backed record that fixes what a work's identity is and who may speak for it, so every carrier points back to one authoritative source.
- Archival Provenance Metadata Template — A structured template for capturing an instance's origin, custody, and transformation history, so that a claim to be the same work rests on documented evidence rather than assertion.
- Edition and Manifestation Catalog — A running list of every concrete manifestation of a work across carriers, each tagged with its release or supersession status and its canonical citation form.
- Fork Decision Record — A per-change record that pronounces — and preserves the reasoning for — whether a modification stays the same work or crosses the threshold into a new one.
- Governed Translation or Adaptation Review — A review that decides whether a translation, adaptation, or re-implementation is still the same work in a new expression, or a derivative that starts its own line.
- Identity Boundary-Case Table — A curated set of clearly-same, clearly-new, and contested instances used to pressure-test and calibrate the work-identity criterion.
- Identity Preservation Checklist — Screens a proposed change against the attributes that define the work — content, structure, function, authorship, interpretation, obligations — to catch, before it ships, whether identity survives or a new work has begun.
- Migration Context Preservation Plan — Carries a work's meaning across a change of carrier by moving its metadata, interpretation context, dependencies, and usage conditions with it — not just the bytes.
- Persistent-Identifier Resolution Policy — Pins a stable identifier to the work and defines how it keeps resolving to the right thing through changes of location, format, custodian, and version.
- Semantic Diff Review — Judges whether a change altered what the work MEANS — its function, its commitments, its recognizable identity — rather than only how it looks.
- Version Lineage Graph — Draws the family tree of a work — editions, releases, translations, branches, superseded versions, and the forks that became new works — so every instance's place in the line is visible.
- Work–Expression–Manifestation Matrix — Separates the abstract work from its expressions and its concrete manifestations so each identity decision is made at the level it actually belongs to.
- Open Reuse Publication Infrastructure: Make an artifact reusable by strangers by publishing it as a stable, openly accessible, license-clear, machine-readable, versioned, and maintained public dependency rather than as a private handoff.▸ Mechanisms (14)
- Changelog and Release Notes — A maintained, per-version record of what changed — features, fixes, deprecations, breaking changes, and how to migrate — so downstream users can decide whether and how to upgrade.
- Community Contribution Guidelines — The published rules for how outsiders report issues, propose changes, and share stewardship — turning a one-way publication into an artifact a community can extend and keep alive.
- Deprecation Notice Feed — A subscribable, machine-readable signal that actively warns downstream users when something they depend on is being retired or about to break — pushed to them rather than waiting to be read.
- Example Corpus or Test Fixture — A published bundle of sample inputs, expected outputs, and conformance cases that lets a reuser run their integration and check it behaves correctly — turning ambiguous spec prose into checkable behavior.
- Integrity Checksum or Signature — A checksum or cryptographic signature published beside an artifact so any stranger can verify the bytes they fetched are unmodified and from the claimed author before reusing them.
- Machine-Readable Manifest — A structured, parseable descriptor shipped with an artifact that exposes its identity, version, license, dependencies, and provenance so tools can resolve and reuse it without a human in the loop.
- Metadata Harvesting Endpoint — A machine endpoint that lets external catalogs, search engines, and aggregators pull an artifact's metadata in bulk, so it can be discovered without anyone ever visiting its home site.
- Open License Declaration — A published rights file that states — in human- and machine-readable form — exactly what reuse is permitted and what obligations travel with the artifact, so downstream users never have to ask.
- Package Manager Distribution — Delivers the artifact through a package manager, data portal, or model hub so downstream systems can retrieve the right version and resolve its dependencies automatically, without a human in the loop.
- Persistent Identifier Minting — Assigns a durable, resolvable identifier — a DOI, handle, accession, or reserved package name — that keeps pointing at the artifact even after it moves, is mirrored, or is superseded.
- Public Artifact Registry — A searchable public catalog that lets strangers discover the artifact, compare its versions, licenses, and owners, and reach a retrieval endpoint — turning contact-dependent circulation into open findability.
- Reference Implementation Repository — A public repository whose runnable reference implementation — a working client, parser, or validator — lets an integrator check their own build against canonical behavior instead of guessing from prose.
- Schema or API Specification Publication — Publishes the integration contract itself — the schema, API description, or protocol definition, with its normative scope and conformance rules — so outsiders integrate correctly instead of merely accessing the artifact.
- Semantic Versioning or Release Scheme — A release-numbering scheme whose version numbers themselves encode compatibility — signaling whether an update is safe, additive, or breaking — so dependents can upgrade on rules rather than by re-testing everything.
Also a related prime in 6 archetypes
- Abstraction–Substrate Traceability Guardrail: Keep abstractions useful without letting them harden into substitute reality by requiring each action-guiding abstraction to carry its representational claim, validity boundary, substrate trace, and re-grounding trigger.
- Durable Identifier Binding: Create a durable handle for a referent, bind it in an authoritative record, and maintain enough lookup, lifecycle, and audit rules that later references can rely on the handle without re-describing the entity.
- Entity Individuation Criteria Design: Make entity identity explicit by defining unity, same-as, persistence, split/merge, and countability rules before records, identifiers, rights, measurements, or decisions depend on them.
- Identity-Bounded Change: Modify an existing entity only inside an explicit identity boundary, retain its stable identity and lineage when continuity tests pass, and declare replacement or a fork when they do not.
- Process-Imprint Source Attribution: Use stable, involuntary marks left by a production process to infer where an output came from, with controls for confounders, spoofing, and over-attribution.
- Selective Legacy Integration: Carry forward what gives a predecessor system knowledge, trust, and identity while redesigning it for the successor context.
References¶
[1] IFLA Study Group on the Functional Requirements for Bibliographic Records. Functional Requirements for Bibliographic Records: Final Report. Munich: K. G. Saur, 1998. Defines the four-level work–expression–manifestation–item hierarchy and the relationship rules by which a translation, abridgement, or revision is a new expression of the same work while a derived work with a new primary author (e.g. a sequel) is a new work — the canonical operationalisation of the identity criterion across nested layers. registry ↩a ↩b ↩c ↩d
[2] Goehr, Lydia. The Imaginary Museum of Musical Works: An Essay in the Philosophy of Music. Oxford: Clarendon Press, 1992. Foundational philosophical account of the musical work as an abstract content-identity distinct from its performances and scores, and of when that work-concept crystallised, on which composition-versus-performance attribution turns. registry ↩
[3] Humble, Jez, and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Boston: Addison-Wesley, 2010. Standard software-engineering reference distinguishing the versioned program/source (operated on by version control) from the build artifacts and deployed instances produced by the build-and-release pipeline — the program-as-work / build-artifact-as-instance separation. registry ↩
[4] U.S. Federal Aviation Administration. Certification Procedures for Products and Articles, 14 C.F.R. Part 21. Washington, DC: Code of Federal Regulations. Establishes the type certificate (the approved design = the work) as distinct from production approval of individual conforming, serial-numbered units (instances), so that airworthiness directives and recalls act at the design level while serial-number tracking acts at the unit level. registry ↩a ↩b
[5] Uniform Law Commission. Uniform Electronic Legal Material Act. Chicago: Uniform Law Commission, 2011. Establishes that a state-designated official (authenticated) version of legal material — statutes, codified laws, regulations — carries authoritative legal status, while other renderings are presumed copies of it; the legal basis for treating the statute as the work and printed/database renditions as instances. registry ↩
[6] Peirce, Charles Sanders. Collected Papers of Charles Sanders Peirce, vol. 4: The Simplest Mathematics (ed. Charles Hartshorne and Paul Weiss). Cambridge, MA: Harvard University Press, 1933 (type/token introduced c. 1906, CP 4.537). Introduces the type/token distinction — the abstract type versus its concrete symbolic occurrences — the bare structural cousin of the work/instance separation applied to symbols. registry ↩
[7] Open Container Initiative. OCI Image Format Specification. Open Container Initiative, v1.0+, 2017–. Defines a content-addressable image model in which each build artifact (manifest, configuration, layers, and the image as a whole) is uniquely identified by a cryptographic content digest — making the build artifact an individually addressable instance distinct from the program/version it realises. registry ↩