The version behind
a digital entitlement.

A digital entitlement can remain in the same account while the thing it refers to changes underneath it. Before asking whether a permission is scarce or transferable, establish which version of the object and which version of the promise the holder actually received.

Imagine a design business buying a limited entitlement to run a particular engineering model. It validates a workflow against release A, records the outputs and trains its staff. Months later, the provider replaces the file at the familiar download address with release B. The account still displays the same product name and allowance. The new model produces a different result.

This is a hypothetical example, not a report about a named supplier. Nobody needs to have copied the entitlement or exceeded its allowance for a dispute to arise. The customer and provider may simply be referring to different objects when they say that the purchase remains available.

The Digital Scarcity programme distinguishes information, access and effective control. Earlier articles examined repeated redemption and excess issuance. Version identity adds another question: what stays attached to an entitlement as files, services and terms evolve? Public specifications for content naming and software provenance help make the technical part precise. The commercial interpretation still needs to be stated separately.

1. A product name is not an object

A catalogue name can identify a family of releases. A web address can identify a location from which different releases are served over time. An account entry can identify a customer's relationship with a supplier. None of these necessarily fixes the bytes, behaviour or conditions relevant to a particular purchase.

For the design business, I would separate the purchased permission from the object to which it applies. Does the purchase cover release A only? Does it include future releases? Does the supplier promise continued access to A, or only to a maintained successor? Does use of a successor consume the same allowance? Those are different products, even if the interface displays one familiar label.

The distinction does not require an opinion about which product is best. A customer may prefer automatic improvements. Another may need a stable version for a validated process. A supplier may be unwilling to maintain old releases indefinitely. The problem begins when those different expectations remain hidden inside the same description.

A limited entitlement is economically clearer when its object, permitted action, quantity and update rule are specified together. Scarcity in the quantity field cannot compensate for ambiguity in the object field.

2. What a hash can establish

RFC 6920, Naming Things with Hashes, specifies ways to identify digital objects using hash outputs. Its security discussion is carefully bounded: the check connects a name to the retrieved bytes, and the integrity of that connection depends on the integrity of the original name. Creating such a name requires no secret. It does not establish that the person presenting it owns the referenced material. The document also warns that a hash does not protect the material's confidentiality.

Applied to our example, a trusted purchase record could identify the expected model package by an algorithm and digest, rather than only by its download address. A later retrieval could be checked against that reference, subject to the chosen hash function’s security assumptions. The same bytes could be obtained from another location without changing their identity. Different bytes should not silently pass as the referenced package merely because they arrive from the expected server.

This is an application of content integrity, not a complete entitlement system. A matching digest does not establish the customer's current permission, the supplier's authority to grant it, the quality of the model or the availability of its dependencies. It identifies one part of the object that those other claims concern.

The source of the reference matters. Downloading a replacement package and a replacement digest from the same untrusted response does not independently establish that either matches the purchase. The customer needs a retained reference whose connection to the transaction can itself be checked.

3. Fix the representation before comparing it

A permission record may be structured data rather than a single opaque file. Two JSON documents can carry the same intended fields while differing in whitespace or object-property order. Hashing their raw bytes then compares their serialisations, not merely the fields a reader considers equivalent.

RFC 8785 describes the JSON Canonicalization Scheme, an Informational specification rather than an Internet Standards Track specification. It defines constrained input and deterministic serialisation, including recursive sorting of object properties while preserving array order. It excludes duplicate property names and preserves Unicode string data without applying Unicode normalisation.

The lesson for the proposed entitlement record is to specify the representation, not to claim that every digital agreement must use this scheme. A record should identify which fields are covered, how they are encoded and how a verifier handles unsupported values. It should also say whether the object being identified is the original document or a canonical representation derived from it.

Canonicalisation does not settle meaning. Two parties can reproduce the same digest while disagreeing about what “one use” permits. Conversely, two differently encoded descriptions may express an equivalent commercial arrangement without being the same signed or hashed object. A system should not switch between those notions of equality when convenient.

I would therefore version the field definitions alongside the record format. A unit called “run” needs an interpretation: one submission, one completed computation, a stated amount of processing, or something else. Precise bytes are useful only when the parties also understand the promise those bytes express.

4. The package is not the whole service

Release A may depend on a runtime, configuration, external data or a remote service. Preserving its main file does not necessarily preserve its behaviour. The scope of the purchased object must follow the dependencies that matter to the promised result.

The SLSA 1.2 build-provenance specification provides a useful distinction. It describes an attestation linking artifacts to the build platform and build definition that produced them. Its model identifies the builder's trust boundary, external parameters and resolved dependencies. That evidence can support checking whether an artifact was produced as expected. It is not a declaration that the software is correct or that every commercial claim about it is true.

For our design business, a possible record would connect the model package to its declared runtime and relevant settings. Where the service uses changing external data, the supplier should distinguish a reproducible historical calculation from a calculation against whatever data are current when the request runs. The customer may want either. They are not interchangeable guarantees.

This proposed application does not make build provenance a proof of service delivery. A record describing how a package was produced is different from evidence that the customer's request used that package. The execution record would need to identify the relevant version and configuration, subject to the service's stated trust and observation limits.

The objective is not to collect every available technical detail. It is to identify the dependencies that can change the performance being purchased, then make the evidence proportionate to that promise.

5. Updates change the bargain

An update can improve a product and still impose costs on a particular customer. New behaviour may require revalidation, retraining or changes to an established workflow. Retaining an older release can avoid some of those costs while creating others, including maintenance and security exposure.

These are possible consequences to measure, not findings about the hypothetical model market. They explain why a technically newer object is not automatically an economically equivalent replacement.

I would compare three clearly stated arrangements. A fixed-version entitlement covers a specified release under stated support conditions. A subscription covers an evolving service under a stated change policy. An upgrade entitlement permits a move to a successor, with an explicit rule about whether access to the predecessor remains. The price and duties can differ across all three.

A transfer between customers introduces a further choice. Does the recipient acquire the predecessor's fixed version, the latest version, or a choice within the original product terms? Does an unused upgrade option move with the entitlement? A transfer record that changes only the holder's name can leave those questions unanswered.

This is a proposed commercial taxonomy, not a legal determination about existing licences. Its value is to prevent the engineering record from silently choosing a different bargain. A system can record the selected arrangement and enforce defined access conditions; the authority to make or alter that arrangement must be established separately.

6. Preserve the claim, not merely a moving link

A purchase record that points to “current terms” creates an evidentiary problem if that address later serves a different text. The customer needs a way to identify the terms associated with the purchase, as well as any subsequent change and the basis on which it applies.

For the proposed service, I would retain the original version reference, the relevant terms, the entitlement's identifier and the later authorised transitions. A replacement should not erase the earlier account. An amendment should identify what changed rather than require a future investigator to reconstruct it from a current web page.

Retention also has a boundary. Publicly exposing customer-specific records can reveal commercial activity. A provider can retain evidence privately and give the customer an appropriate copy without publishing every relationship. The evidence design should disclose no more information than the intended check requires.

Nor is a retained hash a storage service. If nobody can supply the referenced bytes, the customer may know which object is missing without being able to use it. Availability, retention periods and the permitted sources of a replacement copy belong in the service design. Integrity and availability should be evaluated separately.

7. Test substitution, not just copying

A useful evaluation would compare the proposed version-bound arrangement with an ordinary account system that retains purchase records and release history. Both should offer the same commercial terms. The question is whether the additional structure improves identification and dispute resolution enough to justify its cost.

I would test a changed file at an unchanged address, a package with a matching name but a different digest, an unchanged package with altered configuration, a revised terms page, and a permitted upgrade followed by a transfer. Include missing dependencies and an unavailable historical release. Each case needs a declared expected result before the test begins.

The measurements should include incorrect substitutions accepted, legitimate requests refused, time to identify the governing version, recovery of historical evidence, information disclosed and administrative cost. A successful hash comparison is one observation within that evaluation, not its conclusion.

The central question is what the holder can reliably demand of the system. A scarce permission to an unspecified, changing object is a weakly described product. A precise reference does not supply all the missing authority or performance, but it prevents those questions from being obscured by a familiar filename.

Digital scarcity becomes easier to examine when the promise survives changes in its presentation. Identify the version, state the update rule, retain the evidence and test the permitted transitions. Then the parties can discuss what was bought and what changed without first having to guess which object the record meant.