Model Elements

This page provides a complete reference of all elements that can be created in a CaseTalk information model.

Overview

A CaseTalk information model is built from a set of typed elements. Following the FCO-IM methodology, a model captures communication about data — it records what is administered in a business domain, not a direct representation of the real world. The central element is the fact type; object types and roles emerge from it.

Element	Category	Purpose
Fact Type	Core type	The primary building block; a typed set of roles
Object Type	Core type	A named set of roles; identifies what is being administered; referred to by another role in a Fact Type or Object Type.
Role	Structural	A typed position within a fact type
Label Type	Core type	A data value type
Fact Expression	Verbalization	Full natural language sentence verbalising a fact type
Object Expression	Verbalization	Phrase expressing how an object type is referred to in speech
Expression Parts	Verbalization	Text segments and role player positions that compose an expression
Population	Data	Example instances that populate the fact types
Namespace	Provenance	The originating IG file of a model element
Concept	Documentation	Abstract definition or glossary term
Container	Organisation	Groups related model elements together
Template	Organisation	Applies shared facts to all object types inside it (like a stereotype or interface)
Rule	Governance	Business rule derived from the model
Transaction	Process	Business event or transaction structure
Temporal	Data	Marks an object type as time-variant: valid time, transaction time, decision time, or any custom timeline
Paragraph	Documentation	Descriptive text section within the model
UC	Constraint	Ensures unique combinations of role values
TC	Constraint	Requires all instances to participate in a fact
CC	Constraint	Specifies how many times a value may occur
SC	Constraint	Requires one role population to be a subset of another
VC	Constraint	Restricts the allowed values for a role
State	Constraint	Models lifecycle states and transitions as a state machine

Fact Type

A fact type is the primary building block of a CaseTalk information model. It holds one or more roles. Every fact that a business domain administers is expressed as an instance of a fact type.

Examples: Person 123 was born on Date 1-1-2020, Employee 987 works for Company FastCo, Order 20219876 contains Product A67

Fact types can be binary (two roles), unary (one role), or n-ary (three or more roles). They are expressed in natural language through expressions, and their instances are recorded as population.

In FCO-IM, the fact type is primary — object types and label types derive their meaning from the roles they play in fact types.

Object Type

In FCO-IM, an object type is a named set of roles. It does not directly represent a real-world thing — it identifies what is being administered in a business domain. An object type groups the roles that belong to the same subject of administration.

Examples: Person, Company, Invoice, Product

The name of an object type reflects the data administration perspective: a Person object type does not model a physical person, but rather the set of facts that a business records about persons. What makes something an object type is that it participates in multiple fact types through its roles, and those roles collectively define its meaning.

Object types are shown as named shapes in the diagram and can be arranged in subtype hierarchies to express specialisation.

Every object type is identified through one or more uniqueness constraints that define its reference scheme.

Role

A role is a typed position within a fact type. It is the point of attachment between a fact/object type and the object type or label type that fills that position. Roles define who or what participates in a fact, and in what capacity.

Example: In Employee works for Company, the fact type has two roles:

works for — played by Employee
employs — played by Company

Roles can be named to make the participation explicit. They are also the attachment points for uniqueness constraints, total constraints, cardinality constraints, and value constraints.

Label Type

A label type (also called a value type) represents a data value, referred by a role in an object type or fact type. Label types hold concrete values such as names, codes, numbers, and dates.

Examples: PersonName, PostalCode, Amount, DateOfBirth

Label types are not independently stored or administered — they exist only in relation to the object types they label or describe. A label type participates in a fact type alongside the object type, and the fact type is what gives the label its meaning in context.

Fact Expression

A fact expression is a full natural language sentence that verbalises a fact type in a specific language. It describes the fact as a complete statement, with each role player referenced at its position in the sentence.

Example: "<Person> was born on <BirthDate>"

Each fact type should have at least one fact expression so the model can be communicated to non-technical stakeholders. Expressions can be created in multiple languages (locales) within the same model, supporting multilingual models.

A fact expression is made up of expression parts — alternating text segments and role player references. When the expression is read in context, each role player reference is replaced with the object expression of the object type that fills that role.

Object Expression

An object expression is the phrase that expresses how we talk about a specific object type in speech or writing. It defines the natural language form used to refer to an instance of that type.

Example: For the object type Person, the object expression might be "the person known as <PersonName>" or simply "<PersonName>".

Every role played by an object type in a fact type provides an expression substitution point. When a fact expression is read or generated, each role player position is replaced by the object expression of the object type that plays that role. This produces a fully natural, context-sensitive sentence.

Example of substitution:

Fact expression: "<Person> was born on <BirthDate>"
Object expression for Person: "the person <PersonName>"
Substituted result: "the person <PersonName> was born on <BirthDate>"

This substitution mechanism makes it possible to read any fact in the context of how each participating type is naturally named and described in the domain.

Expression Parts

Expression parts are the individual segments that compose either a fact expression or an object expression. An expression alternates between text fragments and role player references.

Example: In the expression "<Person> was born on <BirthDate>", the parts are:

Role player: Person
Text: " was born on "
Role player: BirthDate

Expression parts can be edited individually in the Expression Editor, allowing precise control over wording and role player placement.

Population

Population is the set of example instances (tuples) that fill a fact type. Each row of population is a concrete fact: an actual combination of values that satisfies the fact type's roles.

Example: For the fact type Person was born on Date, population rows might be:

Alice — 1985-03-12
Bob — 1990-07-24

Population serves several purposes in CaseTalk:

It validates the model against real business data
It drives the Population Editor and example-based verification
It is used to check constraints against concrete instances
It supports communication with domain experts through tangible examples

Population can be entered manually in the Population Editor, imported from external sources, or generated from connected databases.

Namespace

Every model element carries a namespace that identifies its originating IG file. When a project combines multiple IG files, elements from different files coexist in the same model view. The namespace records which IG file each element was defined in.

Namespaces allow the same type name to exist in more than one IG file without conflict, and they make it possible to trace any element back to its source. In the Expression Viewer the Namespaces panel shows all contributing IG files and filters the vocabulary by origin.

A namespace is not created manually — it is assigned automatically when an element is defined in an IG file.

Concept

A concept is an abstract definition or glossary entry that documents a term or idea relevant to the domain. Unlike object types, concepts do not participate in fact types — they serve as reference documentation.

Examples: Business Rule, Customer Segment, Service Level Agreement

Concepts can be linked to other elements in the model and are included in generated documentation and business glossaries.

Container

A container groups related model elements together into a logical namespace or folder. Containers help organise large models by clustering types, fact types, and constraints that belong to the same subject area.

Containers can hold object types, fact types, label types, and other elements. They are shown as a bounded region in the diagram. Roles pointing into a container indicate that a type outside the container participates in facts inside it.

Template

A template is a special container element that defines shared facts and properties to be applied uniformly to all object types placed inside it. It is comparable to a UML stereotype, an interface, or a mixin.

A template holds object types together with fact types whose roles are played by the template itself. Because the template acts as the role player, every object type added to the template automatically inherits those facts — without each type needing its own explicit connection.

Example: A template called Auditable could define the facts:

<Auditable> was created on <CreationDate>
<Auditable> was last modified by <UserName>

Any object type (Invoice, Contract, Employee) placed inside the Auditable template automatically participates in those facts, gaining creation and modification tracking without further modelling effort.

This mechanism keeps the model compact and consistent when multiple types share a common structure.

Rule

A rule is a business rule associated with the model. Rules capture governance requirements, derivation logic, or policies that apply to the domain but are not directly expressible as structural constraints.

Examples: A customer may not place an order if their account balance is overdue, An employee may manage at most one department

Rules are documented in natural language and linked to the relevant model elements.

Transaction

A transaction (business transaction) is a structure that groups fact types belonging to the same business event or operation. Transactions define which facts must be recorded together when a real-world event occurs.

Examples: Place Order, Register Customer, Process Payment

Transactions provide the basis for generating data entry screens, API operations, and event-driven integrations.

Temporal

A temporal marker flags an object type as time-variant, meaning its fact instances carry a time interval in addition to their content. CaseTalk supports three built-in timeline axes:

Valid time - when the fact was true in the real world (effective period)
Transaction time - when the fact was recorded in the system (audit trail)
Decision time - when the decision about the fact was made (advanced compliance)

An object type can use one or more axes simultaneously (bi-temporal, tri-temporal). The topology is set in the OTFT editor. Once set, the Source Mapping panel shows a ~Timelines virtual folder with the physical column slots for each active timeline.

Timeline sets - including custom names for ETL columns like LOAD_DTS and IS_CURRENT - are configured in Tools > Environment > Timelines.

Paragraph

A paragraph is a documentation section that can be attached to any part of the model. Paragraphs hold free-form descriptive text and support structured documentation of complex topics.

Paragraphs are included in generated reports and can be formatted using standard text conventions. They provide the narrative context for formal model structures.

Uniqueness Constraint (UC)

A uniqueness constraint (UC) specifies that a particular role, or combination of roles, may contain each value combination at most once. It is the primary mechanism for defining how instances are uniquely identified.

Single-role UC: Each Person has at most one BirthDate

Spanning UC: The combination of FirstName and LastName is unique per Company

When a uniqueness constraint is designated as the primary identification constraint, it defines the reference scheme for the object type.

See also: Constraints

Total Constraint (TC)

A total constraint (TC), also known as a mandatory role constraint, requires that every instance of an object type must participate in at least one instance of the constrained fact type. It makes the role obligatory.

Example: Each Person must have a LastName

Total constraints can also be set as exclusive (XOR), meaning each instance must participate in exactly one of a set of roles.

See also: Constraints

Cardinality Constraint (CC)

A cardinality constraint (CC) generalises the uniqueness constraint by specifying a minimum and maximum number of times a value may appear in a role. Where a UC implies a maximum of one, a CC allows explicit min and max counts.

Form	Min	Max	Meaning
At most N	0	N	Each value may occur at most N times
At least N	N	—	Each value must occur at least N times
Exactly N	N	N	Each value must occur exactly N times
Range	N	M	Each value must occur between N and M times

Example: Each Committee must have between 3 and 7 members

See also: Constraints

Subset Constraint (SC)

A subset constraint (SC) specifies that the population (set of values) of one role must be contained within the population of another role. It expresses a set-inclusion relationship between two fact types.

Example: Every Person who manages a Department must also be an Employee of that Department

Subset constraints are drawn as an arrow from the subset role to the superset role.

See also: Constraints

Value Constraint (VC)

A value constraint (VC) restricts the set of allowed values for a role or label type to a predefined enumerated list.

Example: Status must be one of: Active, Inactive, Suspended

Value constraints can be applied at the role level (restricting values in a specific context) or at the label type level (applying globally to all uses of that type).

See also: Constraints

State

A state is a specialised form of value constraint in which the allowed values are arranged as a state machine. Each value represents a lifecycle state, and the constraint defines which transitions between states are permitted.

Example:

States: Draft → Submitted → Approved → Completed
A more complex machine may include branching, rejection paths, and loops

States are visualised as a state diagram, making lifecycle rules explicit and easy to communicate to stakeholders. The state constraint is attached to the relevant label type or role, and CaseTalk renders the permitted transitions as a directed graph.

State machines are useful for modelling order lifecycles, document approval workflows, task statuses, and any domain concept with a defined progression of stages.

See also: Constraints