How things instantiate types

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.


This paper explores how we describe things – past, present or future.

People talk of abstract types and concrete instances; this paper discusses curious things such as concrete types and abstract instances.

People say the map is not the territory; this paper discusses when the map does become the territory!


Bear in mind. 1

How do we know if a thing instantiates a type?. 2

Descriptions as type elaborations. 3

More about types and instances. 4

Even more about types and instances. 5

Questions and answers. 6

Fuzziness and change. 9

When a map becomes part of the territory. 10



We do not naturally communicate using language that a logical positivist philosopher would approve.

But somehow, we do manage to describe things as instances of types well enough to be understood, most of the time.


The sentences we form are packed with descriptive types, both explicit and implicit.

“Last Friday, Jane Jones, a 33 year old woman doctor, gave birth to twins in the same hospital where she works.”

Particular things include last Friday, Jane Jones and the hospital where she works.

General types (explicit and implicit) include “date”, “named person”, “age”, “woman”, “doctor”, “mother”, “birth event” “location” and “employment”.

Jane Jones embodies or exhibits several types at once; but she lives outside this description, and is more than instances of these types.


This table illustrates how things instantiate types used to describe them.

This type

with this property type

is instantiated by this thing

with this property instance


Height in metres

John Smith








Jane Jones

80 London road


Hours available each day

CRM system



Natural language is imprecise.

It is often ambiguous because the names of properties (aka concepts or qualities) may be interpreted as types and/or instances,

You might say Jane Jones has the properties "name", “age”, "employer" of the type “employee”.

Strictly, you ought to say the person embodies the property types of the named type.

A person embodies property types in property instances such as the attribute values  “Jane Jones”, "33 years " and "Hospital X”.


Bear in mind there are behavioural types as well as structural ones

The dynamic systems of interest in this work comprise both structural elements and behavioural elements.

There are not only component types and instances, but also process types and instances.

Descriptions as type elaborations

A description conveys the properties of a thing

A description corresponds to a type elaboration, and anything so described may be called an instance of that type.


A type describes properties found in real or envisaged things

A type name is not enough, you need a type elaboration.

Why “type elaboration”? Because “type definition” is misleading.

A type elaboration defines not the type, it defines properties a thing needs to become an instance.

To describe or define the type itself, you need a more generic type.


This thing

Is a instances of the type named

Which is described in this type elaboration

A person working for an employer


An employment of a person by an employer

Bilbo or Frodo


A humanoid, smaller than and with bigger feet than a human

A classical symphony score

The classical symphony form

A musical score in four movements of different styles

Beethoven’s 9th symphony

Beethoven symphony

A classical symphony written by Beethoven

A performance of Beethoven’s symphony

Beethoven symphony performance

A performance of a Beethoven symphony



An execution of a behaviour or sequence of instructions


A type elaboration defines an instance of the named type, with reference to other types.

A type elaboration is a description of a thing that may rightly be called an instance of the type (using the type name).


A type is a type, regardless of its form, be it in the mind, on paper, carved in stone, whatever.

A type becomes meaningful when it is exercised to classify something as an instance, or produce an instance.

Note that the classification or production of an instance may be imperfect; there is fuzziness here.


In thought and discussion, I confuse instances and things, and I guess you do too.

We find it convenient to label an instance of the employee type using a person’s name.

A thing (a person) can embody a named type (employee), while being much more than that.

How do we know if a thing instantiates a type?

A thing instantiates a type named A when the thing embodies or exhibits all (or perhaps most) of the property types set out in the elaboration of A.


The rose bush in my garden instantiates the type named “rose” because it embodies and exhibits the property types (thorny, flowering, bush) of the type “rose”.

Mars instantiates the type named “planet” because it embodies and exhibits the property types (a massive body, over a defined size, orbits a sun) of type “planet”.


And we have two ways to determine whether a thing instantiates a type or not.

·         ask a judge or jury to examine a thing or a description, and give us a verdict

·         devise test cases with predicted results, and compare those predicted results against the results of running the tests.


It is important to understand that (outside of software engineering) the notion of instantiation can be fuzzy.

It helps to understand the reasons for fuzziness and how to resolve it.


There are two reasons for fuzziness

·         A type may have optional properties (cake: a sweet food item, baked, and sometimes iced or decorated).

·         A thing may not have all properties (my rose bush has only two thorns, fails to flower this year?)


So how to resolve fuzziness?

The psychologist's concept of a Just Noticeable Difference (JND) might be useful to a judge, jury or tester.

You may have to decide which stakeholders are most important to the decision, then understand which properties those stakeholders value most.

Fuzziness may be resolved in different directions at different times and for different stakeholders.


A reader asks:


Q) If, without knowing your recipe, I bake a cake identical to ones your recipe yields, is that cake an instance of the same type?

A) Yes. The cake type (a structural output type) and the recipe (a behavioural process type) are separable.

A baker who does not know the recipe can produce an instance of the same cake type.

The baker might do this either by accidentally following the same recipe, or by instantiating a somewhat (not entirely) different recipe.

To decide whether a slightly different cake is an instance of the same type, you have the two ways above.


Q) If I don’t follow the recipe exactly, is my performance still an instantiation of the recipe (process type)?

A) The truth is fuzzy; and the instantiations of a type are fuzzy.

You may conclude it best to say you followed the same recipe, or followed a different recipe.

The answer depends on how strictly you or your audience judges a thing against the type, using one of the two ways above.

More about types and instances

Descriptions are types

To typify is to describe; to describe is to typify.

As soon as you have described one thing, other things of that type may be envisaged.

(Unless you name or otherwise identify one particular thing in time and space.)

Instances can be concrete or abstract

A concrete thing can be seen as an instance. E.g. Mars can be seen as an instance of the type “planet”, “rocky body”, or “three-dimensional body”.

An abstract thing can be seen as an instance. E.g. a heroic act might be seen as an instance of the type “heroism”, or “medal winning act”.

Some things are types

Some things are not the products of actors (a rock, cloud, bush or tree), and cannot be regarded as types

Some things are descriptions produced by actors (a map, symphony score, dictionary definition or Java program,) and can be regarded as types.

Types are the products of actors

You might possibly regard your genome as a type, but let us put that aside for now.

For our purposes here, types are the products of actors.

With no actors, there is no abstraction, no conceptualisation and no types.

Types exists as things

Types are recorded in one or more models, be they mental, documented or some other form of model.

For our purposes here, if there is no type if there is no record of the type.

However, the same type can be newly conceived many times, especially if it is a widely useful type.

Simple types (number, word, person) have been conceived in countless minds.

Complex types (an algorithm) are often the product of one mind, or a small group of collaborators, and less likely to be reinvented.

Types, models and descriptions

The terms “model”, “type” and “description” can all be used with the much same meaning in two premises below.

A model is a model, regardless of its form, be it in the mind, on paper, carved in stone, whatever.

A model becomes meaningful when it is exercised by some kind of interpretation process.

Even more about types and instances

Abstract instances

It may appear perverse: not only do types exist, but instances can be abstract.


Instances can be past, present, future or fictional

There is no rule that says an instance must be concrete; it may be imaginary.

E.g. instances of a building or system described by an architect but not yet built.

E.g. instances of Greek God (Zeus, Hera, Poseidon, Demeter, Ares, Athena, Apollo, Artemis…)

E.g. instances of the type Hobbit in book “Lord of the Rings”.


Instances can be real, yet still abstract

There can be many instances of any behaviour, action or process type.

You can observe the effects of an instance, but cannot touch or hold the instance.

E.g. instances of a Beethoven symphony performance.

E.g. instance of the type “heroism”.

Instantiation of types by things

Things existed long before any types were created by living actors.

The thing now called Venus existed for millennia before somebody defined the type called “planet”.

The thing now called the solar system existed before anybody considered it to be an instance of the type named “system”.

A thing can exist without ever being typified or described.

But the moment a type is conceived, things (past, present, future or fictional) may be seen as instances of that type.


A thing can instantiate a type

An instance is the instantiation of a type - by a thing that embodies the properties described by/in the type.

This instance

embodies the type named



A rose bush


An employee



A thing can be more than an instance of a type

A thing that embodies a type can have many more observable properties than listed in the type elaboration.

E.g. A person acting as an employee has many more observable properties than are associated with their employee role.


A thing can instantiate several types

E.g. a person is an instance of employee, mother, footballer.

E.g. a wine bottle is an instance of container, glass object and labelled object.


Go ahead, try to imagine a thing that is an instance of one and only type!

E.g. Is a god in Greek mythology nothing but an instance of the type Greek God?

It is also an instance of other types (character in literature, object of study in a degree course at Oxford university).

Is an employee database record nothing more than instance of the employee database record type?

It is also an instance of other types (e.g. entry in cache of a data server X).


A thing can instantiate one type several times over.

E.g. One person, playing the same role for different employers, can embody the employee type several times.

The relation between things and descriptions


Type names are a short hand for a more elaborate description

Venus is thing with several names. E.g. Venus, morning star and evening star.

Is Venus really a star? Surely it is better described as a planet?

A type name is not enough, you need a type elaboration.

Only when the type elaboration is agreed can you be sure the type name is used accurately.

(It is a problem that one type of number is defined in different ways in the Java and C++ languages.)


There is a many-to-many relation between things and descriptions

One type can have many instances; one thing can be several instances (of several types).

E.g. The one type called star has many instances.

E.g. The one thing called Venus is several instances

·         an instance of the type called planet (aka star)

·         an instance of a light source sometimes bright in the morning sky or evening sky

·         an instance of other types: roundish thing, thing named after mythological figure etc.

Questions and answers

Does a type depend on the existence of an instance?

No. A type is a concept that exists when it is conceived and/or recorded in a mental or documented model.

A type (e.g. “flying elephant”) can exist without ever being instantiated.

You can write a musical score that is never performed, or a program that is never executed.

Does the existence of an instance depend on the existence of a corresponding type?

Yes. A thing cannot be an instance of a type if there is no type that describes properties of the thing.

A thing cannot be the subject of a model if there is no model (mental, documented or other) that represents properties of the thing.

For a thing to be an instance, there must be a recorded or recoverable type that describes properties of the thing.

Can a thing exist without being an instance of a type?

No simple answer to this. It depends what you mean by a “thing” and ”exist”.

Looking back in time, you might say a thing can exist before any actor observed it or described it

It seems reasonable to say

·         biological entities existed before being typified (unless you say their genomes were their types).

·         other natural things (e.g. the planets) existed before they were typified.

·         a thing becomes an instance the moment an actor creates a type that satisfactorily describes it (though “satisfactorily” may be a human judgement).


A natural thing need not be an instance of a type

A natural thing is a product of natural evolution (rather than a product of actors).

For example, a thing you call a rock, bush or tree is a side effect of the ever unfolding process that is the universe.

You perceive it to be an instance of a type whose name you know (rock, bush or tree).

But types are concepts invented, by actors, to classify things in terms of features they share.

If all mental and documented models were destroyed, then the things would still exist, but they could not called be instances of types.


A man-made thing is often an instance of a type

We might make a thing directly, perhaps with some trial and error, with no predefined model.

But the manufacture of a designed thing usually follows the existence of the type

Especially the manufacture of a complex man-made product, such as a violin, a house or a motor car.

We probably start with a model (mental or documented) that typifies the features we expect to find in the built thing.

And once the thing is built, observers will naturally classify it as an instance of one or more types they have in mind.

It embodies the properties of the named type; its property instances conform to the property types in the type elaboration.

However, the thing can continue to exist if the descriptive type is destroyed, or even human kind became extinct.


Some man-made things must be an instance of a type

A designed activity system cannot repeat its behaviour without a descriptive type.

For a symphony to be performed, there must be a description that elaborates the properties of the symphony as a type.

For a software program to be performed, there must be source code or other record that elaborates the properties of the program as a type.

For a regular business process to be performed, it must be described in a mental or documented model of the process type.


These things are instances that exemplify or manifest types in predefined documented models.

Musical scores and source code define an instance’s features in excruciating detail - by itemising elementary performable process steps.

If the process steps of the type are never performed, then the type never realised as an instance.


Provided at least one record of a process type exists, then instances (performances) of the process are possible.

What if all records of the process type (all mental and documented models) were destroyed?

Then there can be no more performances of that symphony, executions of that program, continuance of the regular business operation.


Can a thing be a type and an instance?

Yes. Any description can be both an instance and a type.

E.g. A map’s key is a type: describes features observable in that map, and others of its type.

It is also an instance of “map key” as described in a cartography manual.


E.g. A musical score is a type: describes features observable in all performances (instances) of that music.

It is also an instance of the musical score type, as defined in a guide to writing music.

Are there behavioural types and instances?

Of course there are; this table lists several examples


A thing of this type

is an informational resource that encodes in a

all the instructions actor(s) need to

Cake recipe

natural language

bake a cake

Symphony score

music notation

perform a symphony

Business procedure

natural language

perform a business process

Computer program

programming language

execute the algorithms of a program


DNA macromolecule

assemble, maintain, and reproduce a living organism


Note the thing is itself a type that defines an instance of behaviour (rather than a structure).


A thing of this type is itself a type

that defines an instance of this behaviour

by which actor(s) of this type

produce a structure of this type

Cake recipe




Symphony score

Performance of music

Member of orchestra

Memory of performance

Business procedure

Performance of business process

Employee in organisation unit

Business output or product

Computer program

Execution of algorithms

Environment in computer

Data structure



Cell in organ in body

Body of living organism


And surely there is a sense in which the resource (recipe, score, program) defines not only an instance of behaviour, but also an instance of the structure produced (memory, food item, data structure)?

Fuzziness and change


Instances can be fuzzy

There are types – such as number and post code – to which we expect all instances will conform exactly.

However, it is possible that no circle is perfectly drawn and no music performance ever conforms exactly to a given musical score.

In other words a type can be loosely instantiated, and our notion of an instance is rather fuzzy.


Types can be fuzzy

A type may be modified (a musical score may be altered for a smaller orchestra) while we continue to use the same type name.

Which is to say, our notion of a type is also rather fuzzy.


Concreteness is an experience

Our mental models of the universe derive from observing and envisaging realities.

Observation gives us the false impression that the things we see are concrete and persistent.

Even the most concrete things are (at the atomic level) almost entirely empty space.

What we observe of them is behaviour; it is the forces/processes of physics at work.


All things pass

Thing come and go, and in the end, nothing persists

Apparently persistent things are only the transient side effects of the ever-unfolding process that is the universe.

Systems are transient islands of stability we carve out of that ever-unfolding process.

A system theory has to recognise that the definitions of any type in the system may change from one system generation to the next.

When a map becomes part of the territory


There is a many-to-many relation between maps and territories

A map may describe an imaginary territory.

A map usually records, in a documented model, some properties that are observable in one real-world territory

A map may be generalised (e.g. a housing estate plan) to describe several real-world territories.


A territory on the earth’s surface may exist without a map (a thing may exist without any description of its properties).

A territory may be described by only one map.

A territory may be described by many different maps (each a view that shows different properties).

A territory can be mapped also in many mental models – which are usually less accurate and more fragile than documented models.


A description is a thing in its own right

Any description can be both:

·         a type (a map to which a territory conforms)

·         an instance of a type (in the territory of map making).


A map is description, but also a concrete reality in the territory of cartography.

It is described in a legend or key, which lists properties shared by all instances of the same map type.


Also: e.g.

·         A musical score is a type (to which a performance conforms) and an instance of the musical score type (in the territory of musicology).

·         A software application is a type (to which its execution conforms) and an instance of the application type (in the territory of software development)

·         An architecture definition document is a type (to which a system conforms) and an instance of a document type (in the territory of an architecture framework)

·         A model is a type (to which a subject conforms), and an instance of a generic model kind (in the territory of a modelling language)

·         A “view” is both a type (to which operational system elements conform) and an instance of what is described in a generic “viewpoint” (in the language of ISO 42010).


At composition-time, a musical score includes both:

·         instructions to be followed in a performance and

·         specifications of instruments and performers needed for performance.

It is taken for granted that the orchestra will have a platform and seats to sit on.


At composition-time, a deployable software application includes both:

·         instructions to be executed in processes and

·         specifications of services to be provided by related application components.

·         specifications of “platform services” to be provided by “infrastructure” technology components.


At run-time, both operational systems above include

·         the instructions to be followed in processes,

·         performances of the specified processes and the

·         concrete resources need for performance, including a platform of some kind.


And thus, the map becomes part of the territory.



Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0       07/06/2016 16:49

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see



Incoherent left overs - for review and possible deletion in the future

The design-time map may be seen as part map and part territory

A purposeful man-made activity system exists in both design-time and run-time forms.

The design-time musical score describes musical activities and roles; it does not describe how to manufacture instruments or musicians.

But it does enable people to work out what “platform” components must be bought or hired and deployed to perform the music.


Similarly, the design-time source code of an application describes data processing activities and component roles; it does not describe how to make computing hardware and networks.

But the system description does specify services required of run-time “platform” components.

So, it enables people to work out what components must be bought or hired and deployed to perform the activities, to process the data.

One purpose of a higher-level system description is to specify required platform components, before the lower level design is complete.


What about a passive system - a collection of interrelated elements that do not perform activities?

Consider a passive structure like a Greek temple, the Dewey Decimal Classification system, or a map.

These structures are accessed and used by people (at run-time) to perform whatever they want to do.

Here however, the system describer’s job falls short of buying, hiring or deploying people to do anything with the system description.