Custom Verbs – Sys2DSL

While AGISystem2 provides a rich set of built-in relations, you can define custom verbs tailored to your domain. Custom relations become first-class citizens of the conceptual space – they receive their own permutation encoding and can be used identically to built-in relations.

Basic Syntax: DEFINE_RELATION

Use the DEFINE_RELATION command to create a new verb:

@relDef DEFINE_RELATION name [properties...]

Parameters

Parameter	Type	Description
`name`	Required	The relation name (ALL_CAPS convention)
`symmetric`	Optional flag	If present, A REL B implies B REL A
`transitive`	Optional flag	If present, A REL B and B REL C implies A REL C
`inverse=NAME`	Optional	Names the inverse relation

Examples

Simple Relation

# Define a temperature relation
@r1 DEFINE_RELATION BOILS_AT

# Use it
@f1 ASSERT Water BOILS_AT Celsius100
@f2 ASSERT Alcohol BOILS_AT Celsius78

Relation with Inverse

# Define a bidirectional relation pair
@r1 DEFINE_RELATION TEACHES inverse=TAUGHT_BY
@r2 DEFINE_RELATION TAUGHT_BY inverse=TEACHES

# Now both work
@f1 ASSERT Alice TEACHES Math
@f2 ASSERT Math TAUGHT_BY Alice  # Equivalent

Symmetric Relation

# Define a symmetric relation (both directions are identical)
@r1 DEFINE_RELATION COLLABORATES_WITH symmetric

# One assertion implies both
@f1 ASSERT Alice COLLABORATES_WITH Bob
# Automatically: Bob COLLABORATES_WITH Alice

Transitive Relation

# Define a transitive relation
@r1 DEFINE_RELATION ANCESTOR_OF transitive

# Chain inference
@f1 ASSERT Adam ANCESTOR_OF Seth
@f2 ASSERT Seth ANCESTOR_OF Enos

# Query works via transitivity
@q1 ASK Adam ANCESTOR_OF Enos  # TRUE

Combined Properties

# Symmetric AND transitive (equivalence relation)
@r1 DEFINE_RELATION SAME_GROUP_AS symmetric transitive

# If A=B and B=C, then A=C, and all combinations
@f1 ASSERT Alice SAME_GROUP_AS Bob
@f2 ASSERT Bob SAME_GROUP_AS Carol

@q1 ASK Carol SAME_GROUP_AS Alice  # TRUE

The Geometric Model: Values as Separate Concepts

Critical principle: In AGISystem2, every entity is a point (or region) in conceptual space. This means values must be separate concepts, not embedded in relation arguments.

❌ WRONG: Compressed Syntax

# This is FORBIDDEN - property=value compresses multiple points
@f ASSERT Water HAS_PROPERTY boiling_point=100

This syntax hides three separate points:

Water – a concept point
boiling_point – another concept point
100 (or Celsius100) – yet another concept point

✓ CORRECT: Decomposed Relations

Pattern A: Direct Relation with Value Concept

# Define a specific relation for the property
@r1 DEFINE_RELATION BOILS_AT inverse=BOILING_POINT_OF

# The value is a first-class concept
@f1 ASSERT Celsius100 IS_A temperature
@f2 ASSERT Celsius100 IS_A high_temperature

# Now use the direct relation
@f3 ASSERT Water BOILS_AT Celsius100

Pattern B: Property Chain

# Explicit chain of relations
@f1 ASSERT Water HAS_PROPERTY boiling_point
@f2 ASSERT WaterBoilingPoint HAS_VALUE Celsius100
@f3 ASSERT WaterBoilingPoint PROPERTY_OF Water

Pattern C: Reified Fact

# Create a fact node for complex properties
@fact DEFINE_CONCEPT WaterBoilingFact
@f1 ASSERT WaterBoilingFact SUBJECT Water
@f2 ASSERT WaterBoilingFact PROPERTY boiling_point
@f3 ASSERT WaterBoilingFact VALUE Celsius100
@f4 ASSERT WaterBoilingFact CONDITION SeaLevelPressure

Domain-Specific Relation Sets

Temperature Domain

# Define temperature relations
@r1 DEFINE_RELATION BOILS_AT inverse=BOILING_POINT_OF
@r2 DEFINE_RELATION FREEZES_AT inverse=FREEZING_POINT_OF
@r3 DEFINE_RELATION MELTS_AT inverse=MELTING_POINT_OF

# Define value concepts
@v1 ASSERT Celsius0 IS_A temperature
@v2 ASSERT Celsius100 IS_A temperature
@v3 ASSERT Celsius0 IS_A freezing_temperature
@v4 ASSERT Celsius100 IS_A boiling_temperature

# Use relations
@f1 ASSERT Water BOILS_AT Celsius100
@f2 ASSERT Water FREEZES_AT Celsius0
@f3 ASSERT Iron MELTS_AT Celsius1538

Employment Domain

# Define employment relations
@r1 DEFINE_RELATION WORKS_AT inverse=EMPLOYS
@r2 DEFINE_RELATION MANAGES inverse=MANAGED_BY
@r3 DEFINE_RELATION REPORTS_TO inverse=HAS_REPORT transitive

# Use them
@f1 ASSERT Alice WORKS_AT TechCorp
@f2 ASSERT Bob MANAGES Engineering
@f3 ASSERT Charlie REPORTS_TO Bob
@f4 ASSERT Bob REPORTS_TO Alice

# Transitive query
@q1 ASK Charlie REPORTS_TO Alice  # TRUE

Medical Domain

# Define medical relations
@r1 DEFINE_RELATION TREATS inverse=TREATED_BY
@r2 DEFINE_RELATION SYMPTOM_OF inverse=HAS_SYMPTOM
@r3 DEFINE_RELATION CONTRAINDICATED_WITH symmetric

# Use them
@f1 ASSERT Aspirin TREATS Headache
@f2 ASSERT Fever SYMPTOM_OF Infection
@f3 ASSERT DrugA CONTRAINDICATED_WITH DrugB

Querying Custom Relations

Custom relations work with all query commands:

# Direct query
@q1 ASK Water BOILS_AT Celsius100

# Pattern matching
@temps FACTS_MATCHING ? BOILS_AT ?
@waterFacts FACTS_MATCHING Water ? ?

# With masks
@mask MASK_DIMS temperature
@q2 ASK_MASKED $mask Water FREEZES_AT Celsius0

Relation Introspection

Query information about relations:

# Get relation properties
@info GET_RELATION_INFO BOILS_AT
# Returns: { name: "BOILS_AT", inverse: "BOILING_POINT_OF", symmetric: false, transitive: false }

# List all registered relations
@rels LIST_RELATIONS
# Returns: ["IS_A", "PART_OF", "BOILS_AT", ...]

Best Practices

Naming Conventions

Use ALL_CAPS for relation names: BOILS_AT, TEACHES
Use verb phrases: WORKS_AT not WORKPLACE
Name inverses consistently: TEACHES / TAUGHT_BY

Value Concepts

Create explicit concepts for values: Celsius100, Kilogram50
Place values in hierarchies: Celsius100 IS_A high_temperature
Never embed values in tokens: temp=100 is forbidden

Relation Design

Define inverses for bidirectional navigation
Use transitive sparingly – it increases inference complexity
Group domain relations in theory files for reuse

Technical References

DS(/theory/dsl_engine.js) – DEFINE_RELATION implementation
DS(/core/relation_permuter.js) – Permutation generation
DS(/theory/Sys2DSL_geometric_model) – Why property=value is forbidden
Built-in Relations – Reference for standard relations

Defining Custom Relations (Verbs)