Asset Library

Mutable Metadata, Relationships, Articles, and Editorial Organization

Working title: Asset Library
Working URL: catalog.org/lib/
Author: Roberto Bourgonjen
Status: Draft
Date: 2026-04-21

1. Introduction

Asset Library is the descriptive and organizational core of the Catalog suite, which also comprises Catalog.ID, Asset Registry, Encrypted Filestorage, Asset Market, Bitcash, and Chat.

Where the other modules focus on durable identity, durable claims, immutable encrypted blob storage, sales and payments, payment metering, and messaging, Asset Library focuses on the parts of digital archiving and publishing that must remain changeable over time — the descriptive, relational, and editorial layer above immutable evidence.

Asset Library exists to answer questions such as:

• What is this asset currently called?
• Which files and blobs presently belong to it?
• In which collections, folders, or groups does it currently appear?
• Which descriptions, tags, and licensing statements are currently active?
• Which authored article describes it, and how does it relate to other articles?
• Who currently owns it, and who is authorized to act on it?

Asset Library does not replace immutable history. It provides the current mutable view — the living record of how an asset is described, organized, and presented.

In this model:

• Catalog.ID identifies actors and verified claims about them.
• Asset Registry mints AssetIDs and records durable signed claims about assets.
• Encrypted Filestorage stores immutable encrypted blobs.
• Asset Market handles offers, acceptances, settlements, payment rails, and the deliverable taxonomy through which Asset Library state is sold.
• Bitcash provides payment and metering for protocol fees.
• Chat carries messages and notifications.
• Asset Library maintains mutable metadata, mutable organization, mutable licensing state, and the editorial expression of an archive or publication.

Asset Library is therefore the layer in which assets become understandable, navigable, and manageable over time. Sales and commerce are not Library concerns — those live in Asset Market, which references Library state to know what is being offered, and who is authorized to offer it.

2. Problem Statement

Immutable systems are excellent at preserving evidence, provenance, and stored bytes. They are not sufficient on their own to operate a living archive or publication platform.

Real-world collections constantly change. Titles are corrected. Descriptions evolve. New tags are added. Files are regrouped. Collections are reorganized. Embargoes expire. Active license terms are revised. Ownership or stewardship may change. New relationships are discovered between existing assets.

If all of this mutable state were forced into immutable storage or immutable claim systems, ordinary administration would become cumbersome, noisy, and conceptually confused.

Asset Library solves this by separating:

• immutable storage from mutable description;
• immutable historical claims from current active presentation;
• durable archival evidence from current organizational state;

while keeping mutable description, organizational structure, and licensing state in a single coherent module so that what is described, how it is grouped, and how it is currently licensed are expressed together.

3. Design Goals

Asset Library is designed to satisfy the following goals.

3.1 Mutable by design

Asset Library must support ongoing updates to descriptive, relational, and licensing state without altering underlying immutable records.

3.2 Attributable changes

Although Asset Library is mutable, every change must remain attributable to an identified actor, with timestamp and signature.

3.3 Independent from storage

Asset Library should not depend on direct file storage semantics. Files and blobs may be referenced, but metadata and organization remain independent of how bytes are physically stored.

3.4 Independent from claims

Asset Library should coexist with immutable claim registries without duplicating their role.

3.5 Owner-controlled current state

The owner, steward, or otherwise authorized party must be able to express the currently active metadata, organizational, and licensing state for an asset.

3.6 Flexible relationship modeling

Asset Library should support hierarchical and non-hierarchical relationships alike, including folders, collections, editions, file groups, tags, and cross-references.

3.7 Licensing as mutable state

Asset Library should support active license expressions that may change over time, while allowing historical evidence of prior states to be preserved. Sales mechanics and payment-gating live in Asset Market.

3.8 Privacy-preserving

Members act under their stable Catalog.ID identifiers without disclosing real-world names. Private-by-default fields and selective disclosure are first-class concerns.

3.9 Federated

No central metadata database. Operators run independent nodes; mutable state replicates across the federation.

3.10 Human usability

Asset Library should be understandable as an interface for people, not merely as a machine index.

4. Scope

Asset Library is concerned with the mutable state surrounding assets and blobs.

Asset Library includes:

• descriptive metadata (titles, captions, dates, keywords, attributions);
• relational organization (collections, parents, members, citations, lineage);
• active licensing terms (rights expressions, audience scoping, expiration);
• publication and visibility state;
• presentation-oriented grouping;
• ownership declarations and authority structure;
• edition specifications that describe how assets are assembled into portable publications.

Asset Library does not primarily exist to:

• store immutable file bytes (that is Encrypted Filestorage);
• replace durable provenance records (that is Asset Registry);
• broker, settle, or record sales (that is Asset Market);
• function as a payment ledger or hold funds (that is Bitcash);
• replace identity verification infrastructure (that is Catalog.ID);
• guarantee one global immutable truth.

5. Core Concept

Asset Library is a federated, mutable registry of current assertions about assets and blobs.

Its function is not to erase or overwrite history, but to maintain the currently active interpretation and administrative state surrounding persistent objects. A simple way to understand the relationship is:

• Asset Registry says what was claimed.
• Encrypted Filestorage says what blob exists and where it is available.
• Asset Library says how the asset or blob is currently described, grouped, and licensed.
• Asset Market says under what terms the asset is offered for sale, and what has been agreed.

Asset Library is therefore the active control plane of the Catalog suite — the editorial and organizational layer that the other modules consult or reference.

6. Objects Managed by Asset Library

Asset Library may describe any inventory, but in the context of the Catalog suite it will mainly work with the following objects.

6.1 Assets

An asset is the fundamental unit managed by Asset Library: a logical cultural, documentary, creative, or technical object. Folders, files, file groups, and collections are all assets, distinguished by the tags attached to them and the relationships they hold, not by separate types in the data model. An asset is identified by a single AssetID (§11.2) that is stable across its lifetime and unique across the ecosystem.

Assets are ownable: every asset has an owner record (§6.7), a chain of custody, and a place in the commercial layer when offered through Asset Market. Things that are not ownable in this sense, such as authority entries describing a person, place, period, event, or topic, are not Assets. They are described separately as Lemmas (§6.11), which the Library uses as referenceable entities for Tags. The distinction is deliberate: collapsing every referenceable thing into the Asset namespace would dilute the meaning of ownership and force authority entries through the Asset Registry's per-mint economics, which is neither needed nor desirable for curated reference data.

An asset may be represented by one or more files, one or more blobs, one or more publications, or one or more editions. A single asset commonly has multiple file representations (masters, derivatives, thumbnails, language variants), possibly stored across several Encrypted Filestorage blobs with different licensing scopes. There is no enforced one-to-one relationship between assets and files.

Assets form a flat namespace with relationships expressed as tags rather than a strict tree. An asset may have multiple parents (appearing in several folders or collections at once), no parents, or a lattice of references. Whether an asset acts as "a folder that contains children" or "a file with versions" is a question of the tags present on it, not of a type column — the same asset may play either role, or both. Traversal and presentation remain rendering decisions layered above the flat model.

Any asset may also carry an article — authored prose that describes the asset and, when the asset has children, provides curated editorial framing over its inventory. The article is the asset's document face and shares the asset's AssetID; it is what Asset Library serves when the asset is accessed (§10). Internal article structure, versioning, attribution, and cross-references are specified in the Articles whitepaper.

An asset may similarly host a chat — a conversational narrative layer maintained by Chat (§15.6). Where the article is an editorially constructed, versioned narrative, the chat is a live and incremental one; both face the same evidence (the asset's files and children). Articles and chats are two mechanisms for constructing narrative around an asset's evidence; neither replaces the evidence itself, which is preserved by Encrypted Filestorage and anchored by Asset Registry. Asset Library records whether an asset exposes a chat and governs access through the license bitmap; chat content and delivery are Chat's domain.

6.2 Blobs

Immutable encrypted objects stored through Encrypted Filestorage.

Asset Library does not own blob storage, but it registers current metadata and licensing state associated with a blob.

6.3 Files

Logical files associated with assets and/or blobs.

A file may be addressed through blob membership, file number, path, digest, or asset relationship.

6.4 Articles

An article is an asset's document face: authored prose that describes the asset and, where the asset has children, frames them editorially. Any asset may carry at most one article, and that article shares the asset's AssetID. Articles are not a separate object type in Asset Library; they are a face of every asset that chooses to carry one. Detail is deferred to the Articles whitepaper and summarized at §10.

6.5 Collections and Groups

There are two distinct kinds of collection in the Library, separated by the historical archival distinction between organic provenance (the structure that came into being through the work's creation or accumulation) and artificial collection (a curator's editorial grouping made later). The distinction matters because reassigning the structural place of a creative work changes its identity, while reorganising an editorial collection does not.

6.5.1 Hard structural collections (Registry)

When the collection is part of the work itself: an encyclopedia and its volumes, an album and its original tracks, a book and its chapters, a movie and its scenes, the parent-child relationship is creative structure, not editorial choice. Page 47 of volume 16 cannot be reassigned to volume 17 without making the encyclopedia incoherent. These structural relationships live in the Asset Registry as durable signed claims (parent, derived_from, supersedes), with a single hard parent per asset, signed by the current owners of both child and parent. Once asserted, they are immutable. See §15.2 and the Asset Registry Structural Claim Addendum for the Registry-side mechanics.

6.5.2 Soft editorial collections (Library)

When the collection is a curator's editorial choice, "Books found in box 234", "the Roberto Bourgonjen collection", a thematic series, a publication edition, or a compilation album that brings together previously released tracks, the relationship is mutable, multi-parent, and subject to revision. These collections live in the Library and take two forms:

• Asset-headed collections. When the parent is itself an Asset (a physical container box that has been scanned, a registered collection asset with its own metadata and article), use Library Relations of type parent / contains (§6.10). Multi-parent allowed: a single asset may appear in several editorial collections simultaneously.
• Lemma-headed collections. When the parent is a concept (a person's name, a place, a topic, a curator's collection name), use Library Tags pointing to a Lemma (§6.9, §6.11). Browsing the Lemma's URL lists every asset tagged with it, optionally filtered by role. This subsumes the historical "virtual folder" idiom: any Lemma forms a virtual collection by virtue of being tagged on multiple assets, with no special "Collection Lemma" type required.

Ordering within an editorial collection is captured as a property of the Library Relation or Tag (position, fractional indexing), so that concurrent reorderings converge without renumbering siblings.

A single asset may belong to multiple editorial collections simultaneously without duplication. An asset-headed collection may carry its own descriptive metadata and licensing independently of its members; a Lemma-headed collection inherits its description from the Lemma.

6.5.3 Duplicate ingestion policy

When a creative work appears in multiple originating contexts, for example a song originally released on two separate albums, each album is ingested as its own Asset tree with its own structural relations in Registry. The Library may carry an editorial duplicate_of claim (§6.10) asserting the equivalence; that claim is revisable on closer examination and does not affect Registry truth. The Library does not attempt deduplication at the structural layer.

6.6 Licenses

Current active rights expressions attached to assets. A license grants a Catalog.ID-identified subject a specified set of rights on an asset, optionally with expiration and delegation. Licenses on a parent asset inherit to all descendants through the asset's parent / contains relationships, forming the primary access-control primitive. Detail in §8.

Asset Library expresses licenses as descriptive state — what rights apply, to whom, on which assets. The mechanics by which a buyer obtains a license (offers, acceptance, payment, settlement) are the domain of Asset Market; the resulting license records are written back into the Library as new mutable state. A license therefore lives in the Library regardless of whether it was issued for free, granted internally, or obtained through a Market exchange.

6.7 Owners

Ownership of an asset is recorded in a dedicated Owner record rather than as a tag. Owners hold the authority to issue licenses, edit metadata, and otherwise exercise control over the asset. An asset may have one or more active owners, each with a share that determines their weight in decisions affecting the ownership itself.

Schema

Each owner record carries:

• Asset ID — the asset being owned.
• Owner — the Catalog.ID identifier of the owner.
• Share — a non-negative integer representing the owner's weight. Shares are relative: an owner with share 3 alongside another with share 4 holds 3/7 of the asset. Adding or removing an owner does not require renormalizing the others — the total at evaluation time is the sum of all active shares.
• Outgoing signature — the prior owner's signature releasing the share. For the initial ownership at AssetID allocation, the signature comes from the purchase receipt (§11.2).
• Incoming signature — the new owner's signature accepting the responsibility.
• Timestamps, optional supersedes reference, and soft-delete fields.

Multi-owner governance

Changes to ownership itself — transferring, adding, removing, or adjusting shares — require unanimous signatures from all current owners plus the consent of the incoming party where one is named. No single owner can cut another out or dilute their share without consent.

For use cases needing lighter or more structured internal governance (foundations, estates, large co-operative holdings), an intermediate entity — a Catalog.ID group or organization — may hold the share as a single owner, with internal voting or delegation handled through the entity's own mechanisms.

Purchase-receipt root

Initial ownership is established by a signed purchase receipt issued at AssetID allocation (§11.2, §13). The purchase receipt is the root of the ownership chain; subsequent owner records reference the prior record they supersede, forming a chain that terminates at the receipt.

Owner versus steward

Ownership is distinct from stewardship. A steward manages an asset on someone else's behalf — an archive holding material the owner has entrusted to them, an agent acting for an artist. Stewardship is expressed through licenses (§6.6) granting management rights without transferring ownership; the owner remains the authority of last resort.

Relationship to Asset Market

When an asset is offered for sale through Asset Market, the Library's Owner records are what Market reads to know who is authorized to publish offers and to whom proceeds belong. Royalty splits — non-owning beneficiaries entitled to a share of revenue — are an Asset Market concern and live there; the Library expresses ownership of the asset, not the revenue distribution that may apply when sales occur.

6.8 Edition Specs

Mutable documents that describe how assets, blobs, text, metadata, and presentation rules are assembled into concrete publications or portable outputs.

An edition spec may determine:

• which assets or blobs are included;
• how they are ordered;
• which metadata fields are exposed;
• which templates, themes, or render rules apply;
• whether the result is intended for offline browsing, static hosting, or another distribution form.

Detail in §9.

6.9 Tags and Descriptors

Tags are the primary mechanism by which Asset Library expresses mutable descriptive state about assets. A tag is a signed statement by a Catalog.ID-identified author attaching a typed attribute to an asset. Authorship, keywords, dates, locations, topics, and engagement signals are all tags, differing in type and role rather than in kind. Structural links between assets (parenthood, containment, citation) are a separate record type (§6.10), because their query patterns (recursive traversal for inheritance, enumeration of children for rendering) are better served by a dedicated relation store than by a polymorphic tag table optimized for attribute search. Ownership is likewise a separate record type (§6.7), because it carries authorization semantics enforced on every read and write rather than surfaced as a descriptive claim.

Schema

Each tag carries:

• TagType: the kind of attribute (e.g. Keyword, Person, User, Place, Date, Period, Event, Topic, Access). Types are defined in a dynamic registry rather than a fixed enum; new types may be introduced without protocol changes.
• TagRole: an optional sub-classification within the type (e.g. Type=Person / Role=Author, Type=Place / Role=PlaceOfBirth, Type=Date / Role=Created). For Person and User tags the normative role vocabulary is the role list defined for Asset Registry attribution claims (PartyRoles in apps/reg/src/Registry.Contracts/PartyRoles.cs), reused verbatim so a Registry attribution and a Library Tag describe roles in identical terms. Normative role subsets for Place, Period, Event, and Topic are listed below.
• Value: the value attached to the asset. Three forms are supported:
  • a literal (string, number, parsed date or period) for descriptive claims that do not need to reference a curated entity (titles, captions, free-form keywords, plain dates);
  • a Catalog.ID identifier for Type=User tags (the value is a Catalog.ID identifier resolvable through Catalog.ID's published JWKS);
  • a Lemma reference for entity-typed tags such as Type=Person, Place, Period, Event, Topic (the value is a lem:-prefixed identifier addressing a Library Lemma; see §6.11). The Lemma carries the entity's preferred name and aliases, plus optional sameAs cross-references to external authorities.
• Author: the Catalog.ID identifier of the signer.
• Signature: a signed event, verifiable offline via Catalog.ID JWKS.
• Timestamp, optional expiry, optional supersedes reference.

External authority URIs (Wikidata, GeoNames, PeriodO, VIAF, LCSH, AAT) are not used directly as Tag values. The Library could in principle accept upstream URIs as opaque references, but this fragments the data: two operators tagging Bach independently might pick wikidata:Q1339 and viaf:32197206 for the same person, search would have to denormalize across heterogeneous URI schemes, and rendering would have to reach upstream services that may be unavailable. Instead, upstream authority data is internalized into the Library Lemma database (§6.11): users always select a Catalog Lemma, and the Lemma carries sameAs pointers to whichever upstream authorities apply.

Uniqueness is enforced on the tuple (asset, type, role, value, author). A single author cannot duplicate the same logical tag, but two different authors may independently attach the same logical tag to the same asset, each forming an independent endorsement.

Formal versus informal references to people

Two tag families express references to people:

• Type=User: the value is a Catalog.ID identifier. The tag is resolvable; a renderer may look up the current display name at Catalog.ID, so name changes or key rotations propagate automatically. A Type=User tag signed by the referenced account is a strong self-attested claim. The same tag signed by someone else is an other-attested claim about that account.
• Type=Person: the value is a Lemma reference whose Lemma represents the person (for example lem:6vhq9k for "Roberto Bourgonjen"). Used for historical, deceased, or otherwise non-Catalog.ID-account persons whose Lemma may carry sameAs pointers to external identifiers (Wikidata, VIAF). Always other-attested.

Both may coexist on a single asset. Contemporary authors with active Catalog.ID accounts are typically Type=User; historical contributors and famous figures are Type=Person.

Doxxing rule (co-implicated party). When a Type=Person tag is proposed on an asset that already carries a Type=User tag in the same role, the suggestion does not propagate through the federation without a countersignature from the named user account. A Catalog.ID account may carry a global "do not associate me with Person Lemmas" preference that operators verify before propagating. The rule is narrow on purpose: it only fires when role-on-asset overlaps; a historical Person tag on an asset with no Catalog.ID owner is unaffected.

Normative role vocabulary

For interoperability with Asset Registry and for consistency across the Catalog suite, the TagRole registry has the following normative subsets. The registry remains dynamic; operators and authorities may add roles, with these subsets as the baseline.

• Person and User: the Asset Registry PartyRoles list (Photography, Film, Music, Publishing, Visual Arts, Graphic Design, Architecture, Fashion, Games, Software, Journalism, Advertising, Academic, Production, Contract, Custodian, Dispute) is the canonical source. Library implementations validate against PartyRoles.IsValid exactly as Registry does. New roles added to PartyRoles are automatically valid in the Library.
• Place: PlaceOfBirth, PlaceOfDeath, PlaceOfActivity, PlaceOfCreation, PlaceDepicted, PlaceOfPublication, PlaceOfResidence.
• Period / Date / Event: Created, Published, Active, Depicted, Acquired, Deaccessioned.
• Topic: typically null (the value is the topic itself), with Subject, RelatedSubject, IndirectSubject reserved.

Third-party and suggested tags

Any Catalog.ID-authenticated actor may attach tags to any asset; the signer's identity is part of the tag. An operator's rendering policy determines which third-party tags are surfaced to the public; by default only tags signed by accounts with an IsHuman attestation (Catalog.ID §Validator), further filtered by the asset owner's own policy. Sybil resistance is provided by Catalog.ID's validator-attested claims; operators maintain no parallel reputation system.

Tags may also carry status=suggested to mark them as proposed contributions awaiting owner review. Suggested tags are visible only to the tag author, the asset owner, and delegates holding the corresponding management right. The owner may upgrade a suggested tag to status=approved with a signed endorsement event, which then surfaces it to public rendering. Approval is itself a signed tag event referencing the suggestion.

For licensing purposes (§8.1), only owner-signed Tags pointing to a Lemma confer membership in that Lemma's virtual collection. Third-party Tags are descriptive but do not grant license inheritance, defending against bulk-tagging attacks where an outsider could tag many assets with a Lemma and obtain bulk free access via a license issued on that Lemma.

Revocation

Tags are not deleted in place. A signer may retract a tag by publishing a signed deleted=<timestamp> event referencing it; peers in the federation converge on delete-wins semantics. A soft-deleted tag is omitted from public rendering but remains visible to its author, who may reinstate it. A tag may be marked for permanent deletion with an explicit delete_permanently flag; after a propagation window (default 30 days), all replicas purge the tag and its history.

Because tags are immutable signed events, "editing" a tag is modeled as a soft-delete of the prior tag followed by a new tag from the same signer. This simplifies federation conflict resolution (every state transition is an append) at the cost of slightly heavier rewrites for in-place corrections.

6.10 Relations

Library Relations express soft, mutable, editorial links between assets: citations, supersessions of editorial intent, soft parent/contains where the parent is itself an Asset, and any other typed connection between two AssetIDs that is curatorial rather than structural.

The distinction matters. Hard structural relationships (a page belongs to volume 16 of an encyclopedia; a track belongs to its original release album; a derivative work derives from its source) are creative-structure facts. They are part of the work's identity and live in the Asset Registry as durable signed claims (parent, derived_from, supersedes), with a single hard parent per asset, signed by both owners, immutable once made (§15.2 and the Asset Registry Structural Claim Addendum). Reassigning the structural place of a creative work would change its identity. Library Relations do not attempt to express such facts.

Library Relations are the editorial layer above creative structure: a curator's choice to put books in box 234, an article citing another asset, a compilation album referencing tracks from elsewhere, a working hypothesis that two assets are duplicates of one another. These are mutable, multi-parent, revisable, and signed without the hard constraints of Registry claims.

Library Relations are recorded in a dedicated relation store rather than in the tag model because their query patterns differ fundamentally from descriptive search. Descriptive queries over tags are wide and match-based (find all assets carrying this keyword or that date); relation queries are recursive and graph-shaped (walk ancestors for license inheritance, enumerate descendants for collection rendering). A narrow two-column schema indexed on source and target serves these walks efficiently; folding relations into a polymorphic tag table does not.

Schema

Each relation carries:

• Source AssetID and Target AssetID: the two ends of the directed link. Both must be Assets. Editorial groupings whose head is a concept rather than an Asset use Tags pointing to Lemmas (§6.9, §6.11) instead.
• Relation type: for example cites, duplicate_of, soft parent / contains. Types are defined in a dynamic registry; new relation types may be introduced without protocol changes. Hard structural types (parent in the creative-structure sense, derived_from, supersedes) are not Library Relations; they live in Registry.
• Author: the Catalog.ID identifier of the signer.
• Signature: a signed event, verifiable offline via Catalog.ID JWKS.
• Position: a fractional index for ordered relations (file groups, edition sequences, playlist positions); nullable for unordered relations.
• Status: suggested or approved, mirroring the tag model.
• Timestamp, optional expiry, optional supersedes reference, soft-delete fields.

Uniqueness is enforced on (source, target, type, author). Two authors may independently assert the same relation, each as an independent endorsement.

Standard editorial types

The dynamic Relation Type registry has the following baseline:

• parent / contains (soft): editorial parent or container relationship where both parent and child are Assets. Multi-parent allowed.
• cites: editorial citation from one asset (typically via its article face) to another asset.
• duplicate_of: editorial claim that this asset is a duplicate of another. Revisable on closer examination; carries no Registry consequence.
• endorses, recommends, and similar editorial endorsements as registered.

Directional pairs

Parenthood and similar asymmetric editorial relations are two-sided and may be recorded as two distinct relations:

• A parent relation from child X to parent Y, signed by X's owner, asserts "X claims to belong under Y."
• A contains relation from parent Y to child X, signed by Y's owner, asserts "Y claims to include X."

Both are legitimate assertions and either may exist without the other. Renderers choose how to combine them: a strict view shows only placements endorsed from both sides (intersection); a permissive view shows either side (union) with a badge indicating endorsement; a filtered view selects by trusted signers. The same pattern generalizes to any asymmetric editorial relation (citation, endorsement) without a new authorization primitive per type.

Multi-parent

An asset may hold multiple soft parent relations at once. A single asset may therefore appear in several editorial collections or folders simultaneously without duplication. License inheritance (§8.1) composes rights across all reachable ancestors by union when the relations are owner-signed; third-party relations do not confer inheritance.

Ordering

Ordered containment uses fractional indexing on the position field, so that a single insert or move updates one relation without renumbering siblings. Periodic rebalancing may be applied when index strings grow long after many successive insertions between adjacent positions.

Third-party, suggested, and revoked

Any Catalog.ID-authenticated actor may assert a relation involving any asset; the signer's identity is part of the record. The same owner-policy and IsHuman filtering that apply to third-party tags apply to relations, along with the suggested / approved review workflow. Revocation follows the same soft-delete model as tags: a signed deleted=<timestamp> event invalidates the relation, with optional permanent deletion after a propagation window.

Cycle handling

Because editorial relations can form cycles (A claims to be under B while B claims to be under A), the relation store does not reject cycles at write time. Traversal layers (license inheritance, collection rendering) guard against cycles at query time by bounding walk depth and tracking visited AssetIDs. Registry structural relations cannot form cycles because the single-hard-parent rule and the immutability of accepted claims prevent it.

6.11 Lemmas and Lemma Authorities

Tags pointing to a person, place, period, event, or topic need a stable referent so that "Bach", "Amsterdam", or "the Bronze Age" mean the same thing wherever they appear. Library systems have grappled with this problem for over a century. The traditional solution is the authority record: a curated entry, maintained by an institution (the Library of Congress, NACO, VIAF, the Getty Vocabularies, ICA's ISAAR(CPF)), that fixes a preferred form of a name with stable identifiers and cross-references. Linked-Data successors (Wikidata, GeoNames, PeriodO) extend the same idea with resolvable URIs and machine-readable cross-authority links.

Two failure modes recur in such systems. The first is fragmentation: every system that mints authority records locally drifts into duplicates, because each record is created in good faith without knowledge of the others. The second is stale upstream coupling: pointing tags directly at external authority URIs tightly binds the Library's behaviour to upstream availability, schema, and stability, which is fine for short-lived datasets but unacceptable for an archival registry expected to outlast any single upstream service.

The Library's response is to internalize authority data as Catalog Lemmas: native, signed, federated reference entries that can carry sameAs cross-references to external authorities without depending on them at query time. A Lemma is the Library's representation of a person, place, period, event, topic, or other referenceable entity. Tags reference Lemmas; Lemmas may carry sameAs pointers to Wikidata, GeoNames, VIAF, LCSH, AAT, PeriodO, or other upstreams. Users always pick a Catalog Lemma; they do not pick external URIs.

A Lemma is not an Asset. Lemmas are not ownable, not transferable, not sellable, and do not pass through the Asset Registry's per-mint economics. They are curated reference data, governed by editorial groups called Lemma Authorities, and freely importable from upstream sources.

Schema

Each Lemma carries:

• Lemma ID: a lem:-prefixed 6-character identifier from the same reduced charset used for AssetIDs, OperatorIDs, and Bitcash Wallet Codes. The namespace is separate from AssetID; tag values referencing a Lemma always carry the lem: prefix.
• Type: Person, Place, Period, Topic, Event, or any other type registered in the dynamic Lemma type registry. Operators may register types (Collection, Container, Box, Series, Genre, Movement) without protocol changes.
• Preferred name: per language, with a designated default.
• Aliases: alternative names per language.
• Disambiguating attributes: type-specific. Birth and death dates for Person Lemmas; coordinates and gazetteer references for Place Lemmas; start and end dates for Period Lemmas; etc.
• sameAs references: URIs of external authorities that describe the same entity (e.g. https://www.wikidata.org/entity/Q1339, http://viaf.org/viaf/32197206, https://sws.geonames.org/2759794/). Multiple sameAs URIs are normal; they cross-link Catalog Lemmas to upstream knowledge graphs and support multilingual label aggregation at search time.
• Authoring history: signed creation and edit events with timestamps and signing Catalog.ID identifier. No Owner record, no Market involvement, no per-mint BIT cost.

Lemma Authorities

A Lemma Authority is a Catalog.ID group that governs creates and edits to Lemmas in a domain. Multiple Authorities may exist (Geography, Music-Persons, General-Persons, Academic-Topics, Heritage-Periods); operators and consumers subscribe to whichever they trust, the same way they already filter third-party tags by signer (§6.9).

Anyone with a Catalog.ID may suggest a new Lemma or an edit to an existing one. The Authority signs approval via the existing suggested → approved workflow (§6.9). Once a Lemma has been referenced by a Tag from any account other than its creator, edits to the Lemma require Authority approval rather than just creator approval. The Authority is the editorial body that distinguishes legitimate corrections (a typo fix that preserves aliases, sameAs, and disambiguating attributes) from identity hijacks (a wholesale rename to a different entity). When a creator wants to repurpose a Lemma toward a different entity, the right move is to deprecate the existing Lemma and create a new one, leaving existing Tag references intact.

External upstreams (Wikidata, GeoNames, PeriodO, VIAF, LCSH, AAT) are themselves effectively external Lemma Authorities. Their entries are imported into the Catalog Lemma database under the governance of one or more Lemma Authorities, with sameAs URIs preserved.

Import strategy

The full Lemma database is large: Wikidata alone has on the order of one hundred million items, with active editorial churn. Realistic implementation phases the import:

1. On-demand caching. When a user references an entity that has no Catalog Lemma yet, pull from the appropriate upstream (Wikidata first, then GeoNames / VIAF / others), AI-merge with adjacent records to consolidate cross-authority duplicates, propose to the relevant Lemma Authority for review, and persist as a Catalog Lemma. The user picks Catalog Lemmas only; the database grows lazily.
2. Bulk import of the popular core. Approximately the most-referenced few million Wikidata items, all of GeoNames, all of PeriodO, imported as a one-time engineering effort. This covers the majority of real lookups with predictable cost.
3. Comprehensive coverage. Deferred until usage patterns justify it.

AI-assisted merging is feasible because Wikidata already carries cross-authority IDs (VIAF, GeoNames, LCSH, ISNI) on most items, so the bulk of the work is graph traversal rather than fuzzy matching. AI handles the long tail and ambiguous cases; the Lemma Authority approves merge proposals, with borderline cases requiring human review.

The Catalog Lemma database is not a real-time mirror. Periodic sync is sufficient. Upstream changes (splits, merges, deprecations, vandalism reverts) are reflected at sync time; Lemma Authorities adjudicate how to apply contentious upstream changes locally.

Attribution and licensing

Each Lemma surfaces the attribution required by its upstream sources. Wikidata content is CC0 (no attribution required, but credit conventionally given). GeoNames is CC-BY (attribution required). LCSH is in the public domain. AAT terms have more restrictive licensing. The Lemma's display surfaces the attribution chain; RiC export preserves it via dct:source or equivalent properties.

Search and rendering

Searching across Tags is independent of which value form a Tag carries. The search index denormalizes labels at index time: a Tag pointing to a Lemma is indexed against the Lemma's preferred name, all aliases (multilingual), and labels imported via sameAs from upstream sources; a literal-valued Tag is indexed directly. A generic search across all Tags therefore matches uniformly across literal and Lemma-referenced forms, with optional type and role filtering for narrower queries.

Re-indexing happens when a Lemma's labels change (an Authority-approved edit) or when an upstream sync brings updated labels. Neither is on the hot path.

Federation

Lemmas are federated like every other Library record class: pull-based replication, signed events, soft-delete with delete-wins semantics, propagation windows for permanent deletion. The Lemma Authority's signature is what gives a Lemma weight; an operator or consumer may filter Lemmas by trusted Authority signer the same way they filter third-party tags.

7. Metadata Domains

Asset Library supports several broad domains of mutable information.

7.1 Descriptive Metadata

Examples include:

• title;
• subtitle;
• caption;
• summary;
• description;
• language;
• creator credit;
• chronology;
• keywords;
• tags;
• notes;
• editorial commentary.

7.2 Relational Metadata

Examples include:

• asset-to-blob relationship;
• asset-to-file relationship;
• file ordering;
• membership in folders or collections;
• cross-references from articles to assets;
• edition relationships;
• parent-child structures;
• cross-reference relationships.

7.3 Licensing Metadata

Examples include:

• current license text or reference;
• commercial or non-commercial status;
• conditional or unconditional publication state;
• access restrictions;
• embargo dates;
• sublicensing permissions;
• end-user publication rights.

Sales-related state — current price points, acceptable payment rails, active offer references, inventory state, royalty splits — lives in Asset Market and references Library license state by AssetID.

7.4 Administrative Metadata

Examples include:

• current owner or steward;
• publication status;
• visibility state;
• workflow state;
• moderation state;
• verification state;
• archival priority.

7.5 Edition Metadata

Examples include:

• edition title;
• edition slug or identifier;
• included assets and blobs;
• ordering and navigation rules;
• template or theme selection;
• generated output settings;
• attribution requirements;
• output-specific license notices;
• offline or static-hosting directives.

8. Mutable Licenses

One of Asset Library's most important roles is maintaining active license state.

A blob or asset may have immutable historical records elsewhere, but the current publication position may still need to change.

Examples include:

• a work becomes publicly downloadable after an embargo period;
• a publication license is widened or narrowed prospectively;
• a file remains permanently publishable, but access to a current decryption path changes;
• a collection changes from private access to subscriber access.

Asset Library therefore treats licenses as mutable expressions of current conditions, not as replacements for historical record.

A current license entry may include:

• the licensed object;
• the licensing actor;
• the current terms or terms reference;
• territorial or audience conditions;
• whether publication is conditional or unconditional;
• time validity;
• successor and superseded license states.

When no commercial gate applies to a content item, decryption may still be possible if the owner has issued a free Encrypted Filestorage Key Grant (Encrypted Filestorage §15). Asset Library surfaces "no purchase required" state explicitly. Where a license requires payment, the gating mechanism — offer, acceptance, settlement — is operated by Asset Market; the resulting authorization is recorded back in the Library license record.

8.1 Scope and inheritance

A license is attached to a single asset (§6.1), identified by AssetID, or to a Lemma (§6.11), identified by lem:-prefix. It implicitly covers every descendant reachable through three inheritance paths, with different rules per path so the model resists abuse.

Registry structural inheritance (always). Hard structural relationships in Asset Registry (parent, derived_from, supersedes; see §15.2 and the Registry Structural Claim Addendum) compose rights for inheritance unconditionally. A license on the encyclopedia covers all volumes and pages because the structural claim is immutable, signed by both owners, and auditable. There is no opportunity for a third party to inject ancestors.

Library Relation inheritance (owner-signed only). Soft editorial relations (§6.10) of type parent / contains compose rights for inheritance only when the relation is owner-signed. Third-party Library Relations are descriptive but do not confer inheritance. A license on a curated collection asset covers the collection's editorially-included children when the inclusion is asserted by the asset owners; a stranger's claim that "this asset belongs to that collection" does not.

Lemma membership inheritance (owner-signed Tags only). A license attached to a Lemma covers every asset that carries an owner-signed Tag pointing to that Lemma. Third-party Tags pointing to a Lemma do not confer membership for licensing. A "license to all my encyclopedias" issued by owner X via a Lemma therefore covers only assets that X has signed a membership Tag on, which is necessarily X's own assets. The owner-signature requirement defends against bulk-tagging attacks where an outsider could tag many assets with a Lemma and obtain bulk free access via a license issued on that Lemma.

Inherited rights compose by union across all three paths: if any reachable ancestor (via any path) grants a right to the requesting subject, the right applies.

For licensed subjects whose access requires decryption, inheritance is realized at the key layer through Encrypted Filestorage session keys (Encrypted Filestorage §15.9): each scope is represented by a session key under which its member blob keys and child-scope session keys are wrapped, and a recipient grant on the scope's session key transitively unlocks the subtree. A single license on a collection therefore resolves to a single recipient grant on the collection's session key, regardless of how many blobs lie beneath it.

8.2 Subjects

A license subject is one of:

• a Catalog.ID identifier — grants rights to a specific member account;
• a Catalog.ID group identifier — grants rights to all members of the named group, with membership resolved at check time;
• a public sentinel — grants rights to any viewer without authentication requirements;
• the holder of an access record — grants rights to any viewer presenting a valid signed entitlement record (issued through Asset Market), used for tier-based subscriptions.

Local, site-scoped, or anonymous pubkey subjects are not supported.

8.3 Rights bitmap

Rights are encoded as independent bits rather than a level enum, permitting combinations that a single-level scheme could not express (for example, write-metadata without download, or delegate without read-raw). Typical bits include:

• READ_METADATA — read the asset's structured metadata and, if the asset carries an article, read the article (the article is the asset's extended description; see §10)
• LIST_CHILDREN — enumerate the asset's children (its inventory of sub-assets and files); independent of READ_METADATA and READ_RAW
• READ_LOWRES / READ_HIGHRES / READ_RAW
• WRITE_METADATA / WRITE_CONTENT
• DELETE
• MANAGE_LICENSES — issue licenses on this asset
• DELEGATE — re-issue one's own rights to another subject
• INCLUDE_PRIVATE — the grant extends to assets marked private; otherwise it only activates for public assets

The bitmap is open-ended; new bits may be registered without protocol changes, with unknown bits ignored by conservative consumers.

8.4 Issuance and delegation

A license is issued by signing a license event with a Catalog.ID key that holds the MANAGE_LICENSES right on the target asset — initially the owner, and subsequently any subject to whom the owner has delegated that right. Delegated licenses carry a reference to the license that authorized them, forming a delegation chain that terminates at an owner-issued root.

Delegation is bounded by the issuer's own rights: a delegate cannot grant rights they do not themselves hold. Revoking an intermediate license in the chain revokes all licenses descended from it.

8.5 Expiration and revocation

Licenses may carry an expires timestamp after which they are ignored. Revocation follows the same soft-delete model as tags (§6.9): a signed deleted=<timestamp> event from the issuer invalidates the license across the federation. A permanent-deletion flag purges the license from all replicas after a propagation window. Revocation applies prospectively to new access checks; sealed Asset Market agreements that referenced a revoked license are unaffected, since they are immutable evidence of what was sold at that time.

8.6 Public and private

Public versus private is a property of the asset, not of a license. An asset's owner tags it visibility=public or visibility=private. Public assets are readable at READ_METADATA without an explicit license; private assets require a license even for metadata. Licenses carrying INCLUDE_PRIVATE extend to both; licenses without it apply only where the asset is already public.

8.7 Separation from tags

Licenses are modeled as a dedicated record type rather than as tags. Tags are descriptive claims composable by union from many signers; licenses are authorization policy enforced on read and write, with strict issuance rules and a narrow enforcement path. Unifying the two would blur the security boundary and invite misplaced assumptions about who may issue what. Licenses share the shared asset-ID namespace, Catalog.ID subject model, and signed-event federation mechanics with tags, but their semantics remain distinct.

9. Edition Specs

Asset Library treats edition specs as first-class mutable objects.

An edition spec is not a stored blob and not an immutable claim. It is a mutable publication recipe describing how selected materials are assembled into a concrete publication output.

An edition spec may reference:

• assets (including their article faces, where present);
• blobs;
• files;
• metadata fields;
• templates or themes;
• current license expressions;
• output settings.

Edition specs belong in Asset Library because they may evolve without changing the underlying preserved materials. A publisher may revise an edition spec to:

• include newly available assets;
• exclude withdrawn items;
• reorder sections;
• correct titles or captions;
• change which metadata are exposed;
• alter theme, structure, or navigation;
• change current licensing or access conditions for the generated output.

The resulting generated publication is not the edition spec itself. The spec is the mutable instruction set. A publishing engine may resolve that spec into a concrete portable output, for example a folder containing an index.html file and related subfolders suitable for offline browsing or static web hosting.

In this way:

• Asset Library stores the Edition Spec.
• A publishing engine resolves the Edition Spec.
• The result is a concrete Edition or publication output.

This separation keeps mutable editorial intent in Asset Library while leaving the generated bytes free to be stored, served, or preserved elsewhere as needed.

9.1 Edition spec versus edition blob

The edition spec is one object; the published edition is another. The spec is mutable and lives in Asset Library; the edition is an immutable blob produced by a publishing engine from the spec at a specific moment. Once produced, the edition is an Encrypted Filestorage blob like any other: it has its own BlobID, its own ciphertext digest, its own Asset Registry registration claim, and its own licensing expression in Asset Library. Editing the spec does not alter any past edition — it revises the recipe for future editions.

This separation unifies repository storage and publication. Original files, derivatives, assembled outputs, and complete editions are all treated the same way at the storage layer: as blobs identified by digests, registered through claims, described through mutable metadata, and governed by licenses.

9.2 Publication is not the web

In a conventional model, publishing means uploading files to a website. In the Asset Library model, that is only one possible delivery mode. The defining act of publication is the creation of the edition blob itself; the delivery mode is a separate concern.

An edition blob may be:

• served from a conventional webserver after unpacking;
• mirrored in Encrypted Filestorage for long-term preservation;
• fetched directly by Catalog client software;
• browsed offline after local unpacking;
• transferred peer-to-peer as a publication object in its own right.

The web is therefore one projection of a Catalog-native publication, not the native form of publication itself.

9.3 The Catalog client as publication runtime

The Catalog client is not only a management interface. It can also serve as a runtime and browser for Catalog-native publications. A user with the client installed can request a publication, retrieve the edition blob via Encrypted Filestorage, verify and decrypt it, unpack it temporarily (for example on a RAM disk), and render the publication locally. Where the edition is gated by payment, the user obtains the necessary key through Asset Market; the Library expresses what license applies and the Market handles the exchange.

This preserves a strong separation between the immutable published blob, the mutable metadata and licensing state around it, and the runtime environment in which it is rendered.

9.4 Consequences for the architecture

Several consequences follow:

1. Published editions receive BlobIDs, ciphertext digests, and Asset Registry registration claims. They are not informal derivatives outside the normal storage and claim model.
2. Edition specs reside in Asset Library because they are mutable and may evolve over time.
3. Web publication is one optional delivery mode; the native publication artifact is the edition blob.
4. The Catalog client is both a management interface and a runtime for Catalog-native content.
5. Licensing attaches both to the edition spec (current publishing intent) and to the edition blob (the concrete published outcome); the two references may have different terms.

10. Articles

An article is the document face of an Asset Library asset: authored prose that describes the asset and, where the asset has children, provides editorial framing over its inventory. Every asset may carry at most one article, and the article's root identifier is the asset's AssetID — one identifier, one entity, two faces (document and inventory).

Articles is a self-contained module with its own whitepaper. It supports two operating modes (Articles whitepaper §4.3): a standalone local-single-author mode that does not depend on Asset Library or Catalog.ID, and a hosted mode in which articles are bound to Asset Library assets, edited by Catalog.ID identities, and federated across operators. Asset Library consumes only the hosted mode; the standalone mode is an Articles concern that Asset Library is unaware of. This section describes how an Articles-hosted article integrates with Asset Library; the Articles whitepaper covers internal structure, identifiers, history, signatures, contribution and arbitration, translations, and composition operations.

Positioning: inversion from encyclopedic systems. Asset Library reverses the relationship between article and file that systems like Wikipedia assume. The durable evidence of the asset — recorded files, timestamped blobs, captured media, preserved immutably by Encrypted Filestorage and anchored by Asset Registry — is primary. The article is commentary the host asset carries over that evidence: a narrative construction describing, contextualizing, disputing, or interpreting the files. Files are claims-of-truth (not necessarily true, but demonstrably asserted at a specific time by a specific actor); the article is one form of discussable narrative built on top of them. An asset may additionally host a chat (Chat, §15.6), a parallel conversational narrative layer alongside the article. Article and chat are two complementary mechanisms for constructing narrative around an asset's evidence; neither replaces the evidence itself.

10.1 The article as index.html

When a reader accesses an asset that carries an article, the article is what Asset Library serves. The article is the asset's landing document, analogous to index.html in a web server's directory. An asset without an article presents its children list directly, subject to its license. An asset with neither article nor children is structured metadata only.

10.2 Two faces of an asset

An asset presents two read faces, gated by distinct rights bits (§8.3):

• READ_METADATA reveals the asset's article alongside its tags, descriptors, and structural metadata. The article is the asset's extended description — there is no separate bit that reveals the article.
• LIST_CHILDREN reveals the asset's children — its inventory of sub-assets and files. This is distinct from READ_METADATA (the article face) and from READ_RAW (raw binary content such as original-resolution media); the bits carry independently.

Licensed readers may hold any combination; an unlicensed reader sees nothing. This is ordinary license configuration over the existing bitmap, not new machinery.

10.3 Curated public access

The canonical pattern for an asset with valuable children: grant READ_METADATA to the public sentinel (the article is freely readable) while restricting LIST_CHILDREN to a paid or group license (raw enumeration of the inventory requires the license, obtained through Asset Market). The article itself references a curated subset of children inline as ordinary cross-references; public readers see what the author chose to surface, while licensed readers additionally see the full list.

This pattern serves encyclopedias with a free front matter and paid entries, museums with a free introduction and a paid collection index, publishers with a free teaser and paid full catalogs — all configured from the single host asset's licenses.

10.4 Private and audience-restricted articles

An article restricted to a specific audience uses Asset Library license subjects (§8.2) — a Catalog.ID identifier, a Catalog.ID group, or the holder of an access_record issued through Asset Market. Confidential articles are encrypted at the node level; authorized readers decrypt locally using Encrypted Filestorage Key Grants, which are issued either as an owner gift or as the deliverable of an Asset Market exchange. Article digests are computed over plaintext (see Articles whitepaper §8.1), so an authorized reader verifies integrity after decryption. No article-specific confidentiality primitives are needed — the existing license + Encrypted Filestorage Key Grant machinery covers the case.

10.5 Authorship and attribution

Article authors — including AI agents acting on behalf of humans — are Catalog.ID identities recorded per node edit in the article's history, with every commit signed by the editing account's Catalog.ID signing key (see Articles whitepaper §9). An Asset Registry attribution claim may reference the host asset and one of its contributors as a party, producing an immutable timestamped record of authorship alongside the signed per-commit record in the article's own history.

Write authority on articles is a separate concern, maintained by Articles in its own editors structure (see Articles whitepaper §12). Read access on the host asset — governed by §8 — and write authority on the article — governed by the Articles editors structure — must both be satisfied for a writer to act.

10.6 Article publication

When an article is finalized for publication, the publishing pipeline resolves it into an immutable artifact — typically a PDF, an HTML page, or a bundled edition blob containing the article and its referenced media. The artifact follows the article-vs-artifact distinction familiar from edition specs (§9.1):

• The article (mutable) lives on the host asset and continues to be editable.
• The published article artifact (immutable) lives in Encrypted Filestorage with its own BlobID, ciphertext digest, and Asset Registry registration claim.
• The host asset tracks which artifacts have been produced from its article over time.

Authoring history is preserved as mutable Asset Library state; every distinct publication moment is preserved as a separate immutable Encrypted Filestorage blob.

10.7 Engagement signals

Reader engagement on articles — read events, time-on-article, endorsements, comments, inbound references from other articles — is stored as separate relationship records associated with the host asset, not embedded in the article. Engagement metrics inform editorial decisions and may be exposed to authors, but have no place in the immutable claim or storage layers.

11. Identifiers

11.1 Operator ID

4-character opaque identifier from the reduced charset shared with Asset Registry Operator IDs and Bitcash Wallet Codes.

11.2 Entity IDs

Assets — including what were previously distinguished as folders, files, file groups, and collections — share a single AssetID namespace with Asset Registry. AssetIDs are minted by Asset Registry; the same AssetID identifies an object across its Asset Library metadata, its Asset Registry claims, and its Encrypted Filestorage blob references. A member purchasing AssetIDs receives a signed purchase receipt that authorizes subsequent Asset Library metadata writes and Asset Registry claim registrations for those IDs (§13).

Articles share the host asset's AssetID: an article's root identifier is the AssetID of the asset that hosts it (§10, Articles whitepaper §6.1). Article-internal non-root nodes carry NodeIDs — 5-character identifiers from the same 31-character reduced charset used for Operator IDs and Bitcash Wallet Codes, scoped to the host AssetID's namespace (Articles whitepaper §6.2). The fully-qualified form of a non-root identifier is assetid.nodeid, e.g. qjrm4821xwpa.x7m4q. NodeIDs are allocated locally without coordination and at zero BIT cost; a non-root node that warrants its own AssetID acquires one only by being spun off into its own article (Articles whitepaper §11.2). There is no in-place promotion path between non-root and root.

Edition specs carry their own identifier space where they are not themselves assets. Blobs are identified by Encrypted Filestorage BlobIDs and referenced from Asset Library records; they do not share the AssetID namespace.

Lemmas (§6.11) carry their own identifier space, distinct from AssetID. A Lemma ID is a lem:-prefixed 6-character identifier from the same 31-character reduced charset used for Operator IDs, NodeIDs, and Bitcash Wallet Codes (e.g. lem:6vhq9k). The lem: prefix is mandatory wherever a Lemma is referenced from a tag value or external citation; the prefix carries the type, so there is no risk of confusing a Lemma reference with an AssetID or other identifier. Lemma IDs are allocated by Lemma Authorities (or by automated import from external sources, under Authority governance) and have no per-mint BIT cost.

11.3 URL Scheme

For Linked-Data interoperability and stable public citation, every entity in the Catalog suite is dereferenceable through a canonical HTTP URL. The scheme is hierarchical so that a single asset URL acts as a hub document linking to per-module slices.

Per-operator alternates: every URL is also reachable at {operatorid}.catalog.org/... for direct access bypassing the canonical resolver. See §12 for the resolution model.

11.3.1 Content negotiation

Every URL above supports content negotiation, returning the appropriate representation for the requester:

• text/html: default for browsers, human-readable view.
• application/ld+json: JSON-LD with RiC-O context (primary archival Linked-Data format).
• text/turtle: Turtle for general Linked-Data tooling.
• application/rdf+xml: RDF/XML for legacy consumers.
• application/json: raw JSON for the Catalog client and other suite-native consumers (non-RiC, fuller fidelity than the RiC-O serializations).

11.3.2 Historical views

Library and Market state is preserved with incremental commit numbers, and an exact representation of state at any past point is recoverable. Library and Market URLs accept:

• ?at=<ISO 8601 timestamp>: returns the state as of that timestamp.
• ?commit=<n>: returns the state at exact commit number n.

Registry is append-only by design: ?at filters claims to those existing at that time. Filestorage ?at returns the file list as it existed at that time.

11.3.3 Privacy at the public endpoint

Every Asset has at least a Registry claim, which is anonymous and contains no personally identifiable information. The Registry URL therefore always responds publicly. Encrypted Filestorage returns ciphertext metadata and blob references. Library is the only module with potentially private fields. The Library URL always responds; the response includes a public manifest indicating which attributes exist and which are private. Private attribute values are returned only to authenticated requesters with a license that grants READ_METADATA (and INCLUDE_PRIVATE for private assets). No 404 is returned for "private content"; the URL always exists, and unauthenticated requesters see a redacted view with private fields explicitly listed as withheld.

12. Federation

Each Operator runs its own node, accepts metadata writes from authorized members, and maintains its own current-state records. Mutable state (tags, relations, licenses, owner records, edition specs) replicates across the federation through pull-based synchronization, the same shape as Asset Registry's claim replication.

There is no global consensus and no shared sequence number. Each Operator's records form an independently verifiable signed-event log.

A local operator may manage its own mutable metadata registry while still referencing globally meaningful identities, claims, and blobs. Federation need not require one universal mutable database. Different nodes or operators may maintain their own Asset Library state, provided that:

• object references remain clear;
• actor identity remains attributable;
• conflicts are visible rather than silently flattened;
• the distinction between local current state and durable global records is preserved.

This makes Asset Library suitable both for personal archives and for broader federated publication systems.

12.1 Resolution model

The URL scheme in §11.3 raises a question that any federated archival system must answer: who owns the canonical citation URL when there is no central database? Three patterns exist in the design space.

The first is a fully decentralized model in which every operator publishes at its own host, with no canonical anchor. This is conceptually clean but produces many URLs per asset, no canonical citation form for external consumers, and broken links when individual operators go offline.

The second is a fully centralized model in which a single host owns every URL, with operators as tenants. This contradicts federation.

The Catalog suite uses the third pattern, a canonical anchor with per-operator alternates. The anchor URL catalog.org/{path} is the citation form used in publications, papers, and external references. The anchor host is a thin redirector: it returns a 302 Found to {operatorid}.catalog.org/{path} (or to an operator-owned domain), choosing an operator that holds the requested record. Each operator additionally serves at its own subdomain directly (xqr7.catalog.org/..., ab2k.catalog.org/...), so consumers may bypass the anchor for known operators.

Operator selection at the anchor:

• Default is jurisdiction-aware: requesters are redirected to an operator in their jurisdiction, since some operations involve micropayments governed by local payment regulations.
• Optionally, multiple operators may answer at the bare catalog.org host directly via GeoDNS, returning the geographically closest operator without a redirect.
• The anchor maintains a registry of which operators currently mirror each AssetID, so resolution survives individual operator outages by falling back to peers that hold federated replicas.

The anchor host carries no claim or metadata content of its own; it is a redirector backed by the federation's operator-mirror registry. The data lives at the operators.

12.2 Replication

Mutable Library state (tags, relations, licenses, owner records, edition specs, lemmas) replicates across the federation through pull-based synchronization, the same shape as Asset Registry's claim replication. Each operator's records form an independently verifiable signed-event log. There is no global consensus and no shared sequence number.

13. Ownership, Stewardship, and Authority

Asset Library distinguishes between different kinds of authority.

Examples include:

• owner;
• steward;
• curator;
• editor;
• delegated manager.

The right to update metadata does not necessarily imply the right to change licensing. The right to change licensing does not necessarily imply the right to alter ownership structure. The right to manage a collection does not necessarily imply the right to alter blob relationships.

Asset Library therefore supports fine-grained authorization roles grounded in Catalog.ID identity. Every rights-granting record — owner records (§6.7), licenses, delegated-manager assignments — names its subject by Catalog.ID identifier rather than by a local account. This keeps authority stable across key rotations (the Catalog.ID identifier does not change when its underlying keys are rotated) and consistent across operators in the federation (every operator resolves the same subject identically via the Catalog.ID JWKS).

Ownership is established by a signed purchase receipt issued at AssetID allocation time (Asset Registry §8.2). The receipt binds a payee to the purchased AssetID block; subsequent owner records and licenses on those AssetIDs verify against it. For Asset Library use, the payee is a Catalog.ID identifier — contributing metadata to Asset Library requires a Catalog.ID identity. For Asset Registry-only use cases, a purchase receipt may alternatively bind to a raw pubkey without a Catalog.ID account, preserving Asset Registry's ability to operate independently of Catalog.ID identity. Asset Library itself does not accept pubkey-only ownership; an asset surfaces in Asset Library only once its ownership resolves to one or more Catalog.ID identifiers.

An asset may have multiple concurrent owners with relative shares (§6.7). When an asset is offered for sale through Asset Market, the Library's owner records are what Market reads to determine who is authorized to publish offers and who shares in the proceeds.

Organization delegates may sign metadata updates and license issuances on behalf of organizations using their delegated keys (Catalog.ID §org-keys).

14. Change Model

Asset Library is mutable, but change is structured.

Each update records:

• object identifier;
• changed field or relation;
• actor identity (Catalog.ID);
• timestamp;
• signature;
• optional reason or change note;
• optional predecessor version reference.

This creates a change history without making Asset Library itself immutable.

Asset Library supports at least two ways of interpreting state:

14.1 Current state view

The latest accepted state for each object.

14.2 Change history view

A recoverable sequence of prior states or prior updates.

This allows ordinary use to remain simple while preserving accountability.

15. Relationship to Other Modules

15.1 Relationship to Encrypted Filestorage

Encrypted Filestorage stores immutable encrypted blobs. Asset Library does not attempt to make Encrypted Filestorage itself mutable. Instead, Asset Library references Encrypted Filestorage objects and layers mutable state above them.

Examples:

• Blob B exists in Encrypted Filestorage.
• Asset Library says Blob B is currently titled "Scanned diary, volume 2".
• Asset Library says Blob B belongs to Asset A.
• Asset Library says Blob B is currently included in Collection C.
• Asset Library says Blob B is currently licensed under License L.

Scope-based licenses in Asset Library map onto Encrypted Filestorage's session-key hierarchy (Encrypted Filestorage §15.9). A license on a collection asset resolves to a grant on that collection's Encrypted Filestorage session key; the blob keys of every member asset are wrapped under that session key, so one grant transitively unlocks the collection's contents. Joining a new blob to a licensed scope is a single Encrypted Filestorage wrap record and does not require re-issuance of any buyer's grant; the buyer's existing grant automatically covers the addition on next retrieval.

For blobs using Encrypted Filestorage's layered encryption (publisher inner + ingress outer), each layer's key material is independently grantable. A reader needs grants at all layers to obtain plaintext.

15.2 Relationship to Asset Registry

Asset Registry mints AssetIDs and records durable claims. Asset Library maintains the mutable current state attached to those AssetIDs.

Asset Library writes against an AssetID are only accepted when the AssetID is registered (Asset Registry §4.1); a purchased-but-unregistered AssetID is invisible to Asset Library. Asset Library queries Asset Registry to confirm registration status and the current owner key before accepting writes.

Asset Library does not erase or deny durable claims. It may, however, express the current preferred description, current grouping, and current active license terms.

Hard structural relationships between assets (a page belongs to volume 16 of an encyclopedia, an original track belongs to its album, a derivative work derives from its source) are expressed in Asset Registry as durable signed claims of types parent, derived_from, and supersedes. These structural claims are immutable once accepted, signed by the current owners of both child and parent at time of assertion, and follow a single-hard-parent rule for parent (each asset has at most one structural parent in the creative-structure sense). The Library reads these claims for license inheritance (§8.1) and rendering, but does not rewrite them. Soft, editorial parent or container relationships, where the parent is itself an Asset, live in Library Relations (§6.10); editorial groupings whose head is a concept rather than an Asset live in Library Tags pointing to Lemmas (§6.9, §6.11). The detailed claim schema, signature requirements, and retrospective-claim rules are documented in the Asset Registry Structural Claim Addendum.

15.3 Registry anchoring

Each Operator periodically computes a Merkle tree over its accepted metadata change events and submits the root as a registry_anchor claim to Asset Registry. This timestamps the Operator's metadata change set without exposing its content. In this way:

• Asset Registry preserves signed claims;
• Asset Library manages the present and anchors its evidence periodically.

15.4 Relationship to Catalog.ID

Catalog.ID identifies actors and verified attributes.

Asset Library relies on Catalog.ID to determine:

• who may edit metadata;
• who may register a current license state;
• who currently owns or stewards an asset;
• which verified identity attributes are associated with an administrative action.

Authentication sufficiency. For Asset Library write authorization, a valid Catalog.ID assertion is sufficient; no parallel per-asset keypair scheme is maintained. Asset Library writes are signed events carrying the author's Catalog.ID SD-JWT; operators verify them offline against Catalog.ID's published JWKS and federated key-chain history. Key rotation, recovery after loss, lockdown after compromise, and revocation are all handled by Catalog.ID's existing machinery — Asset Library does not reimplement these operations.

Asset Library therefore does not solve identity on its own. It relies on Catalog.ID for actor identity and authorization context.

15.5 Relationship to Asset Market

Asset Market handles the commercial layer above Asset Library: offers, acceptance, settlement, payment rails, deliverable taxonomy, royalty distribution, secondary markets. The boundary between Library and Market is:

• The Library expresses what an asset is, who owns it, and what licensing terms apply. Mutable state describing the asset and its current authorization graph.
• The Market expresses what an asset is offered for, who has agreed to buy it, and how proceeds are distributed. Immutable bilateral agreements between buyers and sellers, anchored to Asset Registry.

When a buyer obtains an asset through the Market, the resulting authorization (a license, an access record, a Encrypted Filestorage Key Grant) is written back into the Library as new mutable state. The Library remains the single source of truth for "what authorization currently applies"; the Market is the single source of truth for "how that authorization was obtained, by whom, and at what price."

Asset Market reads Library state extensively — owner records, license terms, asset metadata — to construct and validate offers. Asset Library does not depend on Asset Market: an archive may use the Library for purely internal description and licensing without ever publishing an offer. Asset Market is therefore a soft dependency of the Library (integrates) rather than a hard one (requires).

15.6 Relationship to Chat

Asset-hosted chats. Each asset may host a chat maintained by Chat, as a conversational narrative layer parallel to the article (§6.1, §10). Article and chat are two complementary mechanisms for constructing narrative around an asset's evidence: the article is editorially constructed and versioned; the chat is live and incremental. Asset Library records whether an asset exposes a chat and governs access through the same license bitmap that governs other faces of the asset (§8.3); chat content storage, delivery, and moderation are Chat's domain.

15.7 Relationship to Bitcash

Asset Library has no direct involvement in payment for goods. Bitcash, however, funds the operating costs of Asset Library's own infrastructure: per-write protocol fees for metadata records, relationship records, license records, and edition specs are denominated in BIT and paid through Bitcash, parallel to the protocol-fee model in Asset Registry and Encrypted Filestorage.

16. Current State versus Historical Truth

Asset Library is not the final arbiter of historical truth.

Its mutable statements are current and administrative in nature. For that reason, Asset Library's descriptive and licensing state should be understood as expressing:

• what the authorized actor currently declares;
• what the platform currently presents;
• what the current active license or organizational state is.

When there is tension between a mutable Asset Library description and an immutable Asset Registry or Encrypted Filestorage record, the distinction should remain visible rather than hidden.

Asset Library should not pretend that mutability abolishes history. Long-term evidentiary value comes from the durable record in Asset Registry and the immutable bytes in Encrypted Filestorage; Asset Library's role is to express the current preferred interpretation of those underlying records.

17. Minimal Data Model

A minimal Asset Library implementation revolves around the following record classes.

17.1 Entity Record

Represents an asset, blob, file, collection, or other managed object. Articles are not a separate entity type — an article is a face of its host asset, addressed by the asset's own identifier (§10).

Suggested fields:

• entity id;
• entity type;
• creation timestamp;
• current owner reference;
• status.

17.2 Metadata Record

Represents a mutable descriptive field.

Suggested fields:

• entity id;
• field name;
• field value;
• language if relevant;
• actor;
• timestamp;
• supersedes reference.

17.3 Tag Record

Represents a signed descriptive attribute on an asset. Structural links between assets are in the separate Relation Record (§17.5); curated reference entries (Lemmas) referenced from tags are in §17.10.

Suggested fields:

• tag id;
• asset id;
• tag type (reference to the TagType registry);
• tag role (reference to the TagRole registry, nullable; for Person and User tags the registry is the Asset Registry PartyRoles list);
• value (one of: literal string/number/timestamp/period; Catalog.ID identifier for Type=User; lem:-prefixed Lemma reference for entity-typed tags such as Person, Place, Period, Event, Topic);
• author (Catalog.ID identifier);
• status (e.g. suggested, approved);
• expires (nullable);
• signature;
• created_at timestamp;
• supersedes reference (nullable);
• deleted_at (soft-delete timestamp, nullable);
• delete_permanently flag.

Uniqueness is enforced on (asset id, tag type, tag role, value, author). Different authors may independently attach equivalent tags, each forming an independent endorsement. External authority URIs are not stored as Tag values; upstream authority data is internalized into Lemmas (§17.10) and referenced by Lemma id.

17.4 Relationship Record (legacy)

Represents membership or linkage between entities. Superseded for asset-to-asset structural links by the Relation Record (§17.5); retained for asset-to-blob and asset-to-file relationships where applicable.

17.5 Relation Record

Represents a signed editorial link between two assets (soft parent/contains, cites, duplicate_of, etc.). Hard structural relationships (creative-structure parent, derivation, supersession) are not Library Relations; they live in Asset Registry as durable claims (see §6.10, §15.2, and the Asset Registry Structural Claim Addendum).

Suggested fields:

• relation id;
• source asset id;
• target asset id;
• relation type (reference to the editorial Relation Type registry; e.g. parent, contains, cites, duplicate_of);
• author (Catalog.ID identifier);
• status (e.g. suggested, approved);
• position (fractional index for ordered relations, nullable);
• expires (nullable);
• signature;
• created_at timestamp;
• supersedes reference (nullable);
• deleted_at (soft-delete timestamp, nullable);
• delete_permanently flag.

Uniqueness is enforced on (source asset id, target asset id, relation type, author). Dedicated indexes on source asset id and target asset id support the recursive walks used for license inheritance and collection rendering. License inheritance through a Library Relation requires the relation to be owner-signed (§8.1).

17.6 Owner Record

Represents a current ownership share of an asset.

Suggested fields:

• owner record id;
• asset id;
• owner (Catalog.ID identifier);
• share (non-negative integer; evaluated relative to the sum of active shares);
• outgoing signature (prior owner releasing the share, or purchase-receipt signature for initial ownership);
• incoming signature (new owner accepting the responsibility);
• created_at timestamp;
• supersedes reference (nullable);
• deleted_at (soft-delete timestamp, nullable);
• delete_permanently flag.

Changes to the set of owner records for an asset require unanimous signatures from all current owners plus the consent of any incoming party.

17.7 License Record

Represents current active licensing state.

Suggested fields:

• license id;
• asset id (single reference; no separate folder/file/filegroup columns);
• subject (Catalog.ID identifier, group identifier, or public sentinel);
• rights bitmap;
• expires (nullable);
• delegated_from (reference to the parent license in the delegation chain, nullable);
• issuer (Catalog.ID identifier of the signer);
• issued_at timestamp;
• signature;
• supersedes reference (nullable);
• deleted_at (soft-delete timestamp, nullable);
• delete_permanently flag (triggers hard deletion after the propagation window).

17.8 Edition Spec Record

Represents a mutable publication recipe.

Suggested fields:

• edition spec id;
• owning actor or steward;
• included object references;
• structural rules;
• template or theme selection;
• output directives;
• active license references;
• actor;
• timestamp;
• supersedes reference.

17.9 Change Event

Represents an administrative mutation.

Suggested fields:

• event id;
• affected object;
• actor;
• event type;
• timestamp;
• signature;
• optional reason.

17.10 Lemma Record

Represents a curated reference entry for a person, place, period, event, topic, or other typed entity referenced from Tags (§6.11). Lemmas are not Assets; they have no Owner Record, do not pass through Asset Registry, and carry no per-mint cost.

Suggested fields:

• lemma id (lem:-prefixed 6-character identifier from the reduced charset);
• type (Person, Place, Period, Topic, Event, or any type registered in the dynamic Lemma type registry);
• preferred name (per-language, with a designated default);
• aliases (per-language list);
• disambiguating attributes (type-specific: birth/death dates for Person; coordinates and gazetteer hierarchy for Place; start/end for Period; etc.);
• sameAs (list of external authority URIs and other Lemma references: https://www.wikidata.org/entity/Q1339, http://viaf.org/viaf/32197206, https://sws.geonames.org/2759794/, etc.);
• attribution metadata (source upstreams and their licensing requirements: CC0, CC-BY, public domain, etc.);
• author (Catalog.ID identifier or group; the signing Lemma Authority);
• signature;
• created_at timestamp;
• supersedes reference (nullable);
• deleted_at (soft-delete timestamp, nullable);
• delete_permanently flag.

Uniqueness within a Lemma Authority's domain is editorial: the Authority deduplicates and merges entries during creation and on import from upstream authorities. Distinct Authorities may independently maintain Lemmas for the same entity; cross-Authority equivalence is expressed as sameAs links.

Edits to a Lemma that has been referenced by a Tag from any non-creator account require Lemma Authority approval, not just creator approval (§6.11). Drastic identity changes are handled by deprecating the existing Lemma and creating a new one rather than rewriting in place.

18. Example Use Cases

18.1 Archival description

A scanned letter is already preserved in Encrypted Filestorage and claimed in Asset Registry. Asset Library adds a title, date estimate, tags, language, and collection membership.

18.2 Licensing update

A blob remains durably stored and publishable, but the active end-user license changes from subscriber-only access to public access. Asset Library updates the active licensing state without changing the blob itself.

18.3 Editorial correction

An incorrect attribution is corrected. The current description changes, but prior state remains visible in change history if desired.

18.4 Reorganization

A set of files is moved from one collection to another. Encrypted Filestorage blobs remain unchanged; only Asset Library relationships are updated.

18.5 Ownership transfer

An asset is sold privately (off-market) from one Catalog.ID member to another. A new Owner record is signed by both parties and supersedes the previous one. License records, tags, and relations remain unchanged.

18.6 Edition publishing

A publisher updates an edition spec in Asset Library to include a new set of assets, adjust ordering, and change the currently active license notices. A publishing engine then resolves that spec into a portable static output.

18.7 Triage of unclassified assets

A photographer uploads 500 photos from a shoot. Asset Registry mints AssetIDs and registers them. Asset Library presents the new assets as "unclassified" — registered but lacking tags, descriptions, or parent collections. The photographer applies a subject tag to the batch, creates a parent collection, drags the photos under it, and writes a brief article describing the project.

19. Privacy and Legal Position

Because Asset Library manages mutable metadata, ownership declarations, and rights statements, it may process personal data, editorial assertions, and authority claims.

Asset Library should therefore be designed with:

• attribution of changes;
• selective disclosure;
• role-based permissions;
• change history;
• clear separation between public and private fields;
• compatibility with applicable data-protection requirements.

Right to erasure. Erasure operates by the same de-identification model as Asset Registry §7.3: pubkey-to-person mapping is destroyed in Catalog.ID; Library records that referenced the username persist but reference a dead identifier.

Asset Library should not expose more identity data than necessary to express and administer current state.

20. Trust Model

• Editor signature layer — every metadata change carries the editor's Catalog.ID signature, verifiable offline against Catalog.ID's published JWKS.
• Owner signature layer — owner record changes require unanimous signatures from all current owners.
• Operator layer — Operator signs each received event, recording reception and validation.
• Federation layer — peer Operators replicate and verify metadata change events.
• Asset Registry anchor layer — periodic Merkle anchoring of metadata change sets to Asset Registry for external timestamping.

21. Implementation Direction

A practical initial implementation of Asset Library may begin as:

• a mutable database of entities, relations, metadata fields, licenses, owner records, and edition specs;
• actor attribution through Catalog.ID;
• signatures on every change;
• periodic anchoring of summaries into Asset Registry for evidentiary purposes;
• Encrypted Filestorage references where relevant.

Asset Library should remain implementation-neutral at the whitepaper level. Its essence lies in maintaining mutable description and organization above immutable storage and provenance — cleanly separated from sales, payment rails, and immutable agreement records (which are Asset Market's domain).

22. Design Principles

1. Mutable description and licensing. The descriptive and licensing state of any asset is editable by authorized actors.
2. Library is the complete collection. Owned items and items from others alike. The published Catalog (via the publisher module) is what you publish from the Library.
3. Federated, not centralized. No global mutable database; no shared consensus; pull-based replication.
4. Catalog.ID-rooted authorization. All write authority resolves through Catalog.ID identity; no parallel keypair schemes.
5. Asset Registry-anchored timestamping. Long-term evidentiary anchoring of Merkle roots via Asset Registry registry-anchor claims.
6. Same identifier patterns as the rest of the ecosystem.
7. Privacy-preserving by default. Members act under stable Catalog.ID identifiers; selective disclosure for metadata.
8. Composable. Works with or without Asset Market — an archive may use the Library purely for description and never publish an offer.
9. Sales out of scope. Offers, acceptances, settlements, payment rails, royalty distribution all live in Asset Market. The Library expresses what is described, licensed, and owned; the Market expresses what is sold.

23. Conclusion

Asset Library is the descriptive and organizational core of the Catalog suite.

It exists because real archives and publications require a living layer above immutable claims and immutable stored bytes — a layer in which titles change, descriptions evolve, groups are reorganized, active licenses shift. Asset Library provides the place where those changes can be expressed responsibly, attributable to identified actors, without sacrificing the evidentiary value of durable claims or the stability of immutable storage.

In this architecture:

• Catalog.ID identifies actors;
• Asset Registry preserves durable claims and mints AssetIDs;
• Encrypted Filestorage preserves immutable encrypted blobs;
• Asset Market brokers offers and records bilateral agreements;
• Bitcash meters and settles value;
• Chat carries messages;
• Asset Library expresses the mutable present.

Asset Library is therefore not merely a database of metadata. It is the complete personal collection — the editorial layer in which preserved material becomes understandable, navigable, and manageable over time. It is what you organize from, what you publish from, and what you license from. Sales happen in another module; description, organization, and authority live here.

24. Open Questions

The following questions remain open for later drafts:

• Should Asset Library itself support periodic signed state snapshots, beyond Merkle anchoring of metadata changes?
• Which mutable fields should be public by default, and which private?
• How should competing current-state claims from different authorized actors be represented?
• Should current license records be plain text, structured templates, or references to external legal documents?
• To what degree should Asset Library metadata changes be anchored periodically into Asset Registry?
• How should Asset Library represent derived works, versions, and editorial editions?
• What is the relationship between Asset Library and any future client-side local inventory replicas?
• What is the precise read-protocol Asset Market uses to query Library state at offer-construction time, and how is it rate-limited?