Instruments, Materials, and Observations

Seven things that look like one

When a farm manager says "probe 17", they may mean any of seven things, and an identity architecture has to know which. The device is the physical object with a manufacturer's serial number. The device model is the product line it belongs to, shared by thousands of identical probes. The deployment is the fact that this device sat at this depth in this field during this period. A calibration is an event that changed how the device's raw signal is converted into a value. An observation is a single recorded result. A derived dataset is a curated collection of observations, published by someone for some purpose. And a claim built on that dataset — the field was drier than usual — is an assertion by a party with its own authority.

Only some of these deserve their own RID, and which ones is a granularity decision for the parties concerned. The device clearly does: it has a continuing existence that outlasts any deployment. A published dataset does too, because people cite it and it has revisions. A deployment or a calibration may be best kept as a record about the device inside the space that manages it, or, where it needs its own lifecycle, permissions, or provenance, it may be named; Document 08 makes a relationship with such needs eligible for its own RID (§7.4). The device model is a classification, not an individual, and is better treated as descriptive metadata than as the identity of any particular probe.

The diagram's arrows are hypothetical assertions, not registered predicates. What matters is their direction. Observations point at the device that produced them and at the place they describe; the dataset points at its observations; the claim points at the dataset. Nothing points the other way into the device's identity. That is why the device can change — be recalibrated, moved, repaired — without any of the records about its past becoming false.

Soil Probe 17, from installation to retirement

The cooperative installs the probe in North Field in spring 2031. The Valley Soil Observatory, which publishes the region's soil data and owns the calibration protocol, registers the probe as an instrument. In the scenario its RID is 451.EPT1QX0PDW4YF6KG (Soil Probe 17), and it has a structured name, rrn:451:cedarvalley:us-ca:soil:instrument/soil-probe-17, registered by the fictional Cedar Valley Network authority. The space segment of that name records the naming context under which the name was registered. It does not say where the probe is, who owns it, or which field it measures; those are facts that change. Nor does the kind settle what the probe is semantically: Document 08 registers instrument as a naming kind without publishing a definition, and the RSM model's rsm:Instrument names a broader family of legal, financial, policy, technical, measurement, or representational constructs. Whether a physical sensor is best described by that class or as a capability-bearing rsm:Facility is an open modelling question (SPEC-10), and this Journal uses instrument in its plain sense.

In June the observatory notices drift and recalibrates the probe. The calibration is recorded as an event with a date, a method, an actor, and the readings it affects. Readings before and after keep their original values and their own provenance; the observatory's corrected dataset is a new revision of the dataset, not a rewrite of history. In September the cooperative moves the probe to another field. Its RID is unchanged, because it is the same device. Its deployment record changes, and from that day its readings are about a different place. A query that asks "what did Soil Probe 17 measure in North Field?" now has a precise answer: the readings produced while the North Field deployment was in effect.

Now suppose that in 2033 the probe fails. A new probe of the same model goes into the same hole, and someone paints "17" on its stake. This is the moment a single shared identifier would do the most damage, because the new device would silently inherit the old one's history. Here it is a new device and receives a new RID. The old probe's identity is retired (governance could instead record it as superseded, with the new probe as successor). A retired RID is never freed for reuse, so every 2031 reading continues to point at the device that actually produced it.

Repair is harder than replacement. If the probe's sensing element is swapped but its housing, electronics, and serial number remain, is it the same device? Most operators would say yes; a metrologist might say that the instrument relevant to measurement has changed. Document 08 does not answer this, and this Journal does not either. It is a continuity question that the observatory's governance should answer in writing, so that every space applies the same rule (SPEC-04). The Fieldnote A sensor is not its reading works through the case in more detail.

Integrity is not identity

Sensor data is often protected with checksums or signatures so that tampering can be detected. That protection answers a different question from identity. A digest proves that a particular sequence of bytes has not changed since it was signed; an RID says which referent those bytes are about. Document 08 keeps them apart explicitly: an optional content digest identifies the exact bytes of a representation and is stored separately from the RID, and changing the bytes of a document may change its digest while preserving the RID of the continuing document (§9.3).

For the seasonal dataset, that means the observatory can publish a corrected revision with a new digest while the dataset keeps its RID, and a researcher who cited the earlier revision can still obtain it by revision selection. For the probe, it means a signed feed of readings is trustworthy only if it also names, by RID, the device and the place it concerns. A perfectly signed reading attributed to the wrong probe is still wrong. The Seednote on instruments and observations summarizes the distinction.

Harvest Lot A, and the gap in the registry

Materials introduce a problem instruments rarely have: they divide and combine. Harvest Lot A is grain harvested from North Field in 2032 and stored in the cooperative's grain store. In the scenario it has the RID 451.K9PSWTQ7MSXE7VN6 (Harvest Lot A). It has no RRN, and the reason is instructive. The minimum naming profile of Document 08 has no kind for materials. The RSM model can describe the lot as rsm:Material, but that semantic class is not a registered naming kind, and an RRN using an invented material kind would be rejected at authoritative registration. How materials, communities, living systems, and digital agents are named is an open registry question (SPEC-03).

The RID is unaffected by the gap, because an RID encodes no kind at all. The lot can be identified, referenced, and resolved while the question of how to give it a structured name waits for the registry's stewards. That is the opacity of the RID doing exactly its job: a classification problem in the naming layer does not block identity.

Custody is the next lesson. The lot moves from the cooperative's grain store to a trucking company to a regional buyer. Each transfer is a relationship or record — this party held the lot from this date, under this contract — kept by the space that is responsible for it, with its source and authority. None of it is written into the RID. The lot remains the same lot as it changes hands, as Document 08 allows any resource to change administrative authority or legal ownership without changing its RID (§9.4).

Then, in 2033, the lot is divided for two buyers, and one buyer blends its share with grain from elsewhere. The dashed arrows mark the place where a convention would be tempting and wrong. It is easy to keep calling one half "Harvest Lot A" and treat the other as a fragment, or to let both halves inherit the original RID. Either choice silently decides an identity question: are the two parts continuations of the original lot, new referents derived from it, or something else? The answer may legitimately differ by commodity, by contract, and by regulation. What RSM ID requires is that the decision be made under a documented rule, recorded with provenance, and applied consistently — not improvised by whichever system processes the split first (SPEC-04).

One reasonable rule, offered here only as an illustration, is that each physically distinct part becomes a new referent with its own RID, related to the original by a recorded derived from relationship, while the original lot's identity is retired or superseded once nothing of it remains undivided. Another rule might treat a small sample withdrawn for testing as leaving the lot's identity intact. Both are governance choices; neither is a property of RIDs.

The Grower Support Agent: identity, operator, keys, delegation

The cooperative runs a software agent that drafts irrigation schedules from soil readings and weather forecasts. In the scenario it is the Grower Support Agent, 451.69XF2T1ZM7SBCK1V (Grower Support Agent). Like the lot, it has no RRN: rsm:DigitalAgent has no registered naming kind (SPEC-03). It has an identity because people and systems need to refer to it precisely — to record which agent drafted which schedule, and under whose authority it acted.

Four facts about the agent must not be merged. Its identity says which agent. Its operator is the party responsible for running it, here the cooperative, which may change if the cooperative contracts the service out. Its keys are credentials it uses to authenticate, which are rotated regularly and may be revoked. Its delegation is the authority it has been granted to act — to propose schedules, but not to change water allocations. A new key does not make a new agent; a new operator does not make a new agent; a revoked delegation does not end the agent's identity. Each is a separate, dated record with its own authority.

The agent's RID therefore never authenticates anything. An irrigation controller that receives a schedule must check the agent's credentials and its current delegation, not merely the identifier it presents. And an agent that later turns out to be a different program wearing the same display name is exactly the impersonation case Document 08 warns against.

What these cases teach

Instruments, materials, and agents share a pattern. Each has a referent that persists through ordinary change: the probe through calibration and redeployment, the lot through custody, the agent through new keys and operators. Each produces or attracts records that are not the referent: readings, calibration events, custody transfers, delegations. And each meets, sooner or later, a change that genuinely tests continuity: a replaced probe, a divided lot, a rewritten agent. RSM ID's contribution is not to answer the last question by fiat but to make sure that the first two never get confused with it.

For practitioners, the habits are concrete. Give the device its own identity and never reuse it, even when a replacement wears the same label. Record deployments and calibrations as dated records related to the device, and make every observation name the device and the place. Treat custody as a chain of relationships, not an attribute of the material. Write down, before the first split, the rule that decides whether divided material is new. Keep agent identity, operator, keys, and delegation in separate records. And when the registry lacks a naming kind for something you need to identify, use its RID and wait for the kind registry rather than inventing a name that would be rejected.

The next step in the Cedar Valley story is to follow what these observations become: evidence for claims about an outcome. The identity of a formation picks up the readings of Soil Probe 17 where this Journal leaves them, and the Viewgraph From instrument to outcome draws the chain from sensor to assessment. For the claim side of that chain, see Claim and evidence and An outcome is not a claim.