Change management

Change Management

1. Unchangeable idea identifiers

Gellish supports the management of change process on the lowest level of expressions of ideas by binary relations. Each idea is represented by a unique idea identifier (UID). An idea is only known in a Gellish environment when its idea UID is allocated. If there is no idea UID then we cannot say anything about it. A UID may not change and there may not be two different UIDs that represent the same idea. Furthermore, an idea UID may not be reused to denote another idea.

2. Deletion of ideas

An idea is something that is or might be or might have been the case. If it is no longer the case, then it should get the status ‘deleted’ or ‘history’ or ‘replaced’. The expression of the idea and its UID do not need to be physically removed from the database, because usually it is valuable to retain the historical knowledge about its earlier existence of ideas. So the status ‘deleted’ or ‘history’ or ‘replaced’ means that its validity is terminated, which implies that its contextual fact ‘date of end of validity’ should be set.

3. Replacement of ideas

An idea can also be replaced by another idea. This may be used to indicate that a situation has been changed into another situation. Then the idea get the status ‘replaced’, whereas the UID of the successor idea by which it is replaced shall be recorded in another contextual fact, called ‘replaced by’.

4. Changes to expressions of ideas

Although an idea may not change, the expression of an idea may change and the contextual facts about the idea may also change. For example, names may be improved, a textual description may be improved, the status may change (e.g. from ‘proposed’ to ‘accepted’). Such allowed changes shall be accompanied by a registration of the author of the latest change and the date of the latest change. Implementations of Gellish may decide to archive the old state of the idea to trace its improvement history.

5. Fixed creator and creation date

When an idea is created it should be accompanied by a registration of its creation date and of the person who is responsible for the creation of the idea. The name of the originator and the creation date shall never be changed. It is also recommended to record a reference to a source or another reference document, person or organization that can be consulted for additional information.

6. Measured data

Measured data, such as measured temperatures may change over time, so that they often have very limited validity periods. Their creation ‘date’ is the ‘moment in time’ at which their validity period starts and the ‘date of latest change’ is the ‘moment in time’ at which the validity period terminates (the two moments in time may be equal). The status of a measured value which validity period ended should be ‘history’. This method also supports the registration of average values over periods in time. Note that the moment in time is recorded conform the ISO 8601 (2022) standard ( This enables to register a moment in time to an accuracy that is above any current measurement accuracy.

7. Version and succession relations

Another mechanism to manage change is through ordinary Gellish relations between objects. Especially the <is a next version of> relation, the <is a successor of> relation and their inverse expressions (previous and predecessor).

8. Termination of existence of objects

The existence (the ‘life’) of an object terminates when its definition idea (typically expressing its classification) is deleted, which means that that idea gets the status ‘deleted’ or ‘history’ or ‘replaced’ or is physically removed. Such a deletion implies that all the ideas about the object should also be deleted. Special attention should be given to various kinds of kinds of relations. For example, occurrences in which a deleted object is involved, because depending on the kind of involvement in the occurrence the occurrence itself might continue to exist or not. Some deletions should normally be propagated, such as the deletion of parts when an assembly is deleted. The deletion of parts should be confirmed before actually being executed. If a collection is deleted it should be verified whether the other elements in the collection should also be deleted or not.

Return to Start