SIE.12:5 - Archetypal Grounding
SIE.12:5.1 - Equipment Classes Shared by Three Organizations
Two manufacturers and a service partner exchange service observations using a shared equipment-classification module. Each manufacturer also has local classes needed for its own products.
| Arrangement | Concrete use |
|---|---|
| Shared core | Describes the equipment categories needed to interpret the service observations. |
| Local modules | Retain product-specific distinctions and identify their relation to the shared core. |
| Correspondences | State the qualified relations between local and shared classes; different meanings remain visible. |
| Content decision | The agreed maintainers decide changes to the shared module within its stated scope. |
| Release decision | The participant authorized to release the module publishes an identified edition and its dependency conditions. |
| Contact | A reachable participant receives questions, communicates decisions, and helps route disputes. |
| Source authority | Each manufacturer retains the authority for its product descriptions and issued source claims. |
A participant proposes changing a shared class from “equipment with a replaceable drive” to “equipment serviced through a replaceable drive module.” The second definition changes the classification criterion. Existing service queries can depend on the first meaning.
For this constructed agreement, the maintainers retain the earlier class and introduce a distinct class for the new criterion. The illustrative identifier equip:DriveReplaceable continues to mean “equipment with a replaceable drive”; equip:DriveModuleServiceable means “equipment serviced through a replaceable drive module.” The second module edition contains both definitions and leaves the earlier edition accessible. It asserts no equivalence between the classes.
The manufacturers’ qualified product descriptions supply these discriminating cases:
| Equipment | Earlier class | New class |
|---|---|---|
| X: its drive can be replaced as a separate part; it has no replaceable drive service module. | Included: the drive is replaceable. | Excluded: module replacement is not its service arrangement. |
| Y: its drive can be replaced separately, and the supported service arrangement also provides a replaceable drive module. | Included. | Included under the module-service criterion. |
SIE.11 follows the changed classification need to the actual queries. Two consumer outcomes complete the illustrative transition:
- The service partner changes its receiving question to module-replacement planning. It adopts
equip:DriveModuleServiceable, updates the relevant correspondence and query, and verifies that Y is included and X excluded. The receiving owner accepts that scoped result; SIE.10 validates its integration premises. - Manufacturer A retains its spare-drive query against
equip:DriveReplaceable. Its required meaning and the qualified X/Y results remain unchanged, so it retains matching evidence for that use. Adopting the new class is not a prerequisite for continuing this query.
The participant authorized to release the module publishes the identified edition with those definitions, dependency conditions, and migration information. Contact supplies the notice; the content decision, product-source claims, and receiving decisions keep the separate remits shown above. The two completed consumer results do not establish migration by every other user. If the two manufacturers require incompatible local criteria, the commons can retain scoped local modules and their qualified correspondences. No broader equivalence is asserted merely to make the shared diagram simpler.
SIE.12:5.2 - A Sufficient Interface Agreement
Two providers agree to expose separately attributed on hand and available to promise values. They have no additional users maintaining a shared module.
Their agreement identifies the meanings, source owners, interface responsibilities, and change conditions. SIE.3 and SIE.9 can supply the model and interface results. Those results complete the current need. A commons arrangement becomes useful if independently maintained shared modules and their users create a further maintenance problem.
SIE.12:5.3 - Urgent Semantic Correction
A shared mapping incorrectly interprets a quantity’s unit, and a supported interface can return a wrong answer. The authorized maintainer corrects or withdraws the affected mapping according to the community’s rules, identifies the affected edition, and notifies its consumers. The notice explains the correction and the supported continuation.
The completed action is an urgent qualified correction with notification. Earlier users’ unresolved reliance remains visible for SIE.11; the action cannot establish that every consumer has already migrated.