A capsule registry starts with versioning, rights, and withdrawal

The first problem is an update

Imagine a fictional team reusing a capsule that summarizes permit obligations for a construction project. The author discovers that one cited exemption has expired and publishes a corrected version. A colleague still has the earlier artifact attached to a briefing. What should the system tell them, and what should remain reproducible about the original work?

That question is more useful to us than whether a capsule should be sold in a marketplace. The proposed registry would need stable artifact identities, version relationships, access rules, and a channel for corrections. It should let a team discover relevant material without confusing popularity, a publisher’s reputation, and a review decision about one particular version.

Borrow the mechanics, keep the claims narrow

OCI content descriptors identify referenced content using a media type, byte size, and digest. A consumer can retrieve the content and independently verify the digest. This is a useful pattern for checking that the received bytes match the requested artifact. It says nothing about whether a permit interpretation inside the artifact is right. [1]

npm provenance provides a second useful distinction. Its documentation describes attestations that link a package to its source and build process, and explicitly warns that provenance does not guarantee the absence of malicious code. For a knowledge artifact, the parallel is straightforward: knowing which process produced it does not establish that its claims are supported or its advice appropriate. [2]

Hugging Face model cards provide a precedent for documenting intended uses, limitations, training information, and evaluation results alongside an artifact. A capsule listing should offer similarly practical information: the question it addresses, source coverage, jurisdiction or domain, maintenance responsibility, permitted uses, and known limitations. A complete-looking card is documentation to inspect, not a seal of approval. [3]

An artifact can be immutable while its status changes

Our design would keep a published version’s identity stable while allowing a separate status record to say that it has been superseded, withdrawn, or flagged for review. The earlier permit capsule should remain identifiable in a historical briefing. A new use should show the correction and ask whether the task needs the current version. Silently replacing bytes at the same immutable identifier would undermine both behaviors.

DCAT 3, the W3C vocabulary for data catalogs, includes versioning relationships and checksum support for distributions. It is a useful reference for describing related releases and discovery metadata. A TACITUS implementation would still need policies for status updates, permissions, offline use, and consumer notifications. We do not claim DCAT conformance from borrowing those ideas. [4]

Withdrawal is especially awkward when documents have already been downloaded. A registry can stop serving material and publish a withdrawal notice, but it cannot guarantee that every offline copy disappears. A consumer also needs to distinguish withdrawal for a factual correction from withdrawal because redistribution rights changed. Those events have different implications for an existing assessment.

A small institutional library is a better first test

We would first test the lifecycle with a bounded library: a few capsule versions, known users, explicit permissions, and deliberately introduced corrections. The sequence would publish a version, attach it to a task in PRAXIS, revise a source, issue a replacement, and inspect what the original user sees. DIALECTICA would need to preserve the relevant identities and review records throughout that sequence.

Failure cases should include a digest mismatch, an unsupported schema version, a revoked source permission, an unavailable registry, and conflicting status information. Offline behavior must be defined: for example, a consumer might permit reading a cached artifact while prominently displaying that current withdrawal status could not be checked. The acceptable rule depends on the task; it should not be hidden in a generic success indicator.

These tests would not establish a business model. They would establish whether distributing context preserves enough information for responsible reuse. Curation, contribution terms, support, and commercial arrangements remain separate design and operating questions.

Review the upkeep before adopting the pack

The demonstration collection exposes task fit, jurisdiction, language, source coverage, author assertions, review limits, lineage, rights questions and refresh triggers. Prepare review pack creates a local buyer summary; it does not transact or transmit anything. The plausible next stages are private reuse, controlled handover and a small manually reviewed expert collection.

A seller cannot relicense a publisher’s corpus or a former client’s evidence. Pinned tasks must not silently adopt an update. Withdrawal may stop future hosted access where enforcement exists, but cannot promise remote deletion of exported copies. Quality, buyer fit, maintenance effort and willingness to pay still need measurement. [5]