Why Hypergraphs?

Most graph databases and modeling tools are built on simple graphs — nodes connected by edges, where each edge links exactly two nodes. This works fine for binary relationships, but conceptual modeling demands more.

In FCO-IM, a fact type like "Person works at Company in Role" is a ternary relationship — it connects three object types simultaneously. Splitting this into binary pairs (Person-Company, Person-Role, Company-Role) destroys the original semantics. The fact is atomic: all three participants are bound together in a single assertion.

This is where hypergraphs come in. A hyperedge can connect any number of nodes — two, three, or more — preserving the N-ary nature of fact types exactly as they are verbalized and modeled.

How FCO-IM Works: From Verbalizations to Types

FCO-IM is a verbalization-first method. The modeler starts at M0 — concrete example sentences from the business domain:

"Alice works at Acme as Engineer"
"Alice has name 'Alice'"
"Acme is active"

From these verbalizations, the modeler distills the M1 schema: identifying object types (Person, Company, Role), label types (Name), and fact types (Employment, HasName, IsActive) with their roles. The structure is not designed top-down — it emerges bottom-up from real communication.

In CaseTalk's current implementation, this entire workflow — verbalizations, type distillation, constraints, populations — operates within the tool's built-in M2. The concepts of FactType, ObjectType, LabelType, and Role are hardcoded in the application. The user models at M1 and populates at M0, but M2 is fixed by the tool.

The Domain Model as Hypergraph

The domain model in FCO-IM is organized in three meta-levels, each forming its own hypergraph:

M2 — The Meta-Model defines the modeling language itself. A FactType contains Roles, and Roles are played by an ObjectType or a LabelType. The key recursion: an ObjectType is a FactType — it is an objectified (nested) fact, which again contains roles. This self-referential structure is what gives FCO-IM its expressive power. In CaseTalk today, this level is fixed — it is the engine of the tool itself.

M1 — The Conceptual Model is where domain modeling happens. This is what the modeler distills from verbalizations. Fact types are hyperedges connecting object types:

• A ternary fact type like Employment connects Person, Company, and Role through a single hyperedge (green).
• A binary fact type like HasName connects Person and Name — this degenerates to a regular graph edge (red).
• A unary fact type like IsActive attaches to a single node as a property (purple).

M0 — The Population is where it all starts. The concrete verbalizations and example data that the modeler enters. Each fact instance (e.g., "Alice works at Acme as Engineer") is a hyperedge instance connecting concrete values. In FCO-IM, M0 is not just "test data" — it is the primary input from which the model is derived.

The dashed blue arrows show instantiation between levels: every M1 type is an instance of an M2 meta-concept, and every M0 fact is an instance of an M1 type.

Custom Attributes as a Parallel Hypergraph

Custom attributes — such as security_level, source_system, or domain_owner — are not mere annotations sitting outside the model. They form their own parallel meta-stack with M2, M1, and M0 levels, connected to the domain model through bridges.

M2 — Custom Attr Meta-Model defines what a custom attribute definition is: a meta fact type that targets domain meta-types (ObjectType, FactType) and has a value domain.

M1 — Custom Attr Definitions are the actual attribute definitions. Each one is a binary hyperedge connecting a domain type to a value domain:

• security_level applies to Person with range {public, confidential}
• source_system applies to the Employment fact type with range String
• domain_owner applies to Person with range String

M0 — Custom Attr Values are the concrete assignments. Each value is a hyperedge instance that connects an attribute definition, a domain type, and a value:

• attr #1 assigns "public" to security_level of Person
• attr #2 assigns "HR system" to source_system of Employment
• attr #3 assigns "HR dept" to domain_owner of Person

The fact that attr #2 targets a fact type — not just an object type — demonstrates the power of this approach. Custom attribute values can annotate any element in the domain model, including relationships themselves.

Looking Ahead: CaseTalk v15 — Breaking the M2 Ceiling

In the current version of CaseTalk, some meta-level concerns — like custom attribute definitions — are managed through dedicated UI: hardcoded editors and dialogs. This works, but it means these concepts live outside the regular modeling workflow. The tool's M2 is a closed system: you can model within it, but you cannot model it. Custom attributes are just one example of this limitation. Subtype derivation rules, constraint metadata, and other structural concerns are similarly locked into application code.

This creates an asymmetry. At M0 and M1, the modeler works with verbalizations, populations, constraints, and all the expressiveness of FCO-IM. But at M2, everything is frozen in specialized dialogs.

CaseTalk v15 breaks this mold entirely — not just for custom attributes, but for meta-modeling as a whole.

Verbalizations at M2

The breakthrough is allowing regular FCO-IM verbalizations at M2. Instead of flat key-value pairs in a custom editor, the modeler can write:

"Object type 'Person' has custom attribute 'security_level' set to 'confidential'"

This is a full FCO-IM expression at M2. Notice what happens: 'Person' is an object type name living at M1 in the domain model. But in this M2 verbalization, that same 'Person' appears as a populated value — M1 type names become M0 population for M2 expressions. This is the cross-level bridge in action.

But this goes far beyond custom attributes. The rather flat attribute definitions are just one use case. Once M2 is open for verbalization, any meta-level concern can hook into a rich information model — with fact types, constraints, derivation rules, and well-formedness checks — all guarded by CaseTalk with the same rigor it applies to domain models.

Subtype Derivation at M2

Consider subtype derivation. In the domain model, Book is a subtype of Article. At M0, we might verbalize:

"Article 123 is a Book."

This sentence mixes M0 and M1 in an M2 expression: "Article 123" is an M0 instance, "Book" is an M1 type name, and the derivation rule ("is a") operates at M2. CaseTalk v15 can now safeguard these tuples — validating that Article 123 satisfies the subtype constraints, that Book is indeed a subtype of Article, and that the derivation is consistent with the model's rules.

Today, subtype derivation is handled by internal logic. In v15, it becomes a verbalizable, constrainable, extensible part of the model.

The General Pattern

• Every meta-level follows the same pattern. Verbalizing facts at M1 draws population from M0 — concrete instances like "Alice" and "Acme". Verbalizing facts at M2 draws population from the names defined at M1 — "Person", "Employment", "security_level". Verbalizing at M3 would draw from M2 names — "ObjectType", "FactType", "CustomAttrDef". Each level's type names become the next level's population values.
• M2 expressions can mix M0 and M1 references. A single verbalization like "Article 123 is a Book" combines an instance identifier (M0), a type name (M1), and a derivation rule (M2). CaseTalk v15 manages these cross-level references explicitly.
• M2 and M3 become modeling layers, not hidden system internals. The meta-model is open for inspection, extension, and verbalization through the same familiar interface used for domain modeling.
• Constraints apply across levels. The full power of FCO-IM constraints — uniqueness, mandatory roles, subset, equality, exclusion — becomes available at M2, guarding meta-level facts with the same precision as domain-level facts.

This unification — treating everything from data instances to subtype derivations to meta-model extensions as verbalizable facts in a layered hypergraph — is what makes FCO-IM uniquely powerful for conceptual modeling. CaseTalk v15 is where the tool finally matches the full ambition of the method.