+4E

The Four-Fold Harmony: Experience, Examples, Exercises, Experiments

The Semantic-Ex Method helps discover constraints by putting abstract semantics (meaning) into practice through four approaches. The “Ex” that accompanies meaning represents methods for transforming meaning into executable constraints.

  • Experience: Living the meaning through realistic scenarios
  • Examples: Seeing concrete instances of semantic concepts
  • Exercises: Practicing constraint discovery hands-on
  • Experiments: Testing and validating constraint hypotheses

This natural progression from semantic meaning to practical constraints creates a unified methodology for evidence-based system design. These four steps form a framework for safely and reliably transitioning from meaning to constraints. Rather than the traditional linear flow of “requirements → immediate constraints,” this process features a spiral approach involving continuous interaction with reality.

The Problem with Abstract-First Design

The Typical Flawed Approach

Abstract requirements → Arbitrary constraints → Implementation → "Why doesn't this work?"

Example of Abstract-First Failure:

{
  "$comment": "Abstract constraint definition",
  "productName": {
    "type": "string",
    "maxLength": 255
  }
}

Reality Check: Where did 255 come from? Database limitation? Random number? Convention? This constraint isn’t grounded in experience.

The Hidden Costs

  • Unusable interfaces: Constraints that break UX
  • Arbitrary limitations: Rules without actual justification
  • Continuous fixes: “Why did we limit this to 50 characters again?”
  • Stakeholder conflicts: “We need longer descriptions!”

Phase 1: Experience - Semantic Experience “Know the Reality”

Foundation: From Meaning to Reality

The first phase focuses on experiencing what semantic concepts actually mean. Rather than starting with abstract definitions, we explore how they manifest as concrete expressions in the real world.

{
  "$comment": "ALPS Semantic Descriptor - Starting Point",
  "id": "productName", 
  "type": "semantic",
  "def": "https://schema.org/name",
  "title": "Product Name",
  "doc": "Commercial name of the product as known to customers"
}

Learning Product Names Through Experience

Instead of immediately defining constraints, we experience what real-world product names look like:

// Semantic-driven experience generation
const realWorldProductNames = [
  "iPhone 15 Pro Max",                    // Tech: short, model-focused
  "Sony WH-1000XM5 Wireless Noise Cancelling Headphones",  // Electronics: detailed features
  "The Complete Works of Shakespeare (Leather-Bound Collector's Edition)",  // Books: elaborate descriptions
  "Portable Solar Panel Charger for Outdoor Adventures and Emergency Power",  // Outdoor gear: benefit-focused
  "Premium Organic Extra Virgin Cold-Pressed Olive Oil from Ancient Sicilian Groves",  // Gourmet: origin and quality focused
  "LEGO Creator Expert Big Ben 10253 Building Kit (4,163 Pieces)",  // Toys: specifications and piece count
  "Patagonia Men's Better Sweater 1/4-Zip Fleece Jacket - Navy Blue - Size L"  // Apparel: full specifications
];

Insights from Experience

By deeply experiencing this data, we discover patterns:

  • Length variety: From 15 to over 85 characters
  • Information density: Some pack technical specs, others focus on benefits
  • Character usage: Letters, numbers, spaces, hyphens, parentheses, commas
  • Context dependency: Same product, different names in different contexts

Key insight here: Constraints emerge from experiencing reality, not from assumptions.

Phase 2: Examples - Semantic Examples “See the Reality”

From Experience to Concrete Instances

Phase 2 transforms experiential understanding into concrete, testable examples that reveal the true nature of constraints.

Example-Driven Constraint Discovery

// Real-world examples that test assumptions
const constraintTestingExamples = {
  "edge_cases": [
    "iPad",  // Minimum viable length
    "Microsoft Surface Pro 9 for Business (Windows 11 Pro, Intel Core i7, 16GB RAM, 512GB SSD, Platinum)",  // Maximum realistic length
    "ACME Widget™ (Model #X-2023) - Professional Grade",  // Special characters
    "Toshiba Dynabook T75/PW PT75PWP-SJA Laptop PC",  // International characters
  ],
  "ui_breaking_examples": [
    "This product name is intentionally too long for most UI layouts and will cause truncation issues in mobile views",
    "Product\\nWith\\nLine\\nBreaks",
    "Product<script>alert('xss')</script>Name",
  ],
  "business_valid_examples": [
    "Apple MacBook Pro 16-inch (M3 Max, 2023)",
    "Samsung 65-inch 4K QLED Smart TV",
    "Nike Air Jordan 1 Retro High OG - Chicago (2015)"
  ]
};

Example-Based Validation

{
  "$comment": "Constraints emerging from example analysis",
  "productName": {
    "type": "string",
    "minLength": 4,
    "maxLength": 120,
    "pattern": "^[\\p{L}\\p{N}\\p{P}\\p{S}\\s]+$",
    "not": {
      "pattern": "[<>{}\"'`]"
    },
    "description": "Product name that works in all UI contexts and supports global markets",
    "examples": {
      "min_valid": "iPad",
      "max_realistic": "Microsoft Surface Pro 9 for Business (Windows 11 Pro, Intel Core i7, 16GB RAM, 512GB SSD, Platinum)",
      "international": "Toshiba Dynabook T75/PW PT75PWP-SJA Laptop PC"
    }
  }
}

Example-Driven Benefits:

  • Concrete validation: Every rule has specific examples
  • Edge case coverage: Real-world exceptions guide design
  • International support: Examples reveal localization needs
  • Security awareness: Attack patterns become visible

Phase 3: Exercises - Semantic Exercises “Practice Discovery”

Hands-On Constraint Validation

Phase 3 involves actively exercising constraint definitions through systematic testing and refinement.

Exercise 1: Constraint Testing Workshop

// Hands-on constraint validation exercise
class ProductNameConstraintExercise
{
    public function exerciseConstraintValidation(): void
    {
        $validator = new JsonSchemaValidator();
        $schema = $this->loadSchema('product-name.json');
        
        // Exercise A: Valid cases should pass
        $validCases = [
            "iPhone 15 Pro",
            "Samsung Galaxy S24 Ultra 5G",
            "Sony WH-1000XM5 Headphones",  // Japanese products
            "Café Bustelo Espresso Blend", 
        ];
        
        foreach ($validCases as $case) {
            assert($validator->validate(['name' => $case], $schema));
        }
        
        // Exercise B: Invalid cases should fail appropriately
        $invalidCases = [
            "",                           // Empty
            "X",                         // Too short
            str_repeat("Long", 50),      // Too long
            "Product<script>hack</script>", // XSS attempt
        ];
        
        foreach ($invalidCases as $case) {
            assert(!$validator->validate(['name' => $case], $schema));
        }
    }
}

Exercise 2: Real-World Integration Practice

// UI constraint exercise - See how constraints actually work
class ProductNameInputExercise {
  createConstraintAwareInput() {
    return `
      <input 
        type="text" 
        name="productName"
        minlength="4"
        maxlength="120"
        pattern="[^<>{}\"'\\`]+"
        placeholder="Enter product name (4-120 characters)"
        oninput="this.setCustomValidity('')"
        oninvalid="this.setCustomValidity('Product name must be 4-120 characters and cannot contain HTML')"
      />
    `;
  }
  
  // Exercise: Test with example data
  async testConstraintInUI() {
    const testCases = window.semanticExExamples.productNames;
    
    for (const testCase of testCases) {
      const isValid = this.validateProductName(testCase);
      console.log(`"${testCase}" -> ${isValid ? 'Valid' : 'Invalid'}`);
    }
  }
}

Exercise Benefits:

  • Practical validation: Constraints fit real implementations
  • Iterative improvement: Learning through practice
  • Team alignment: Common understanding through hands-on work
  • Confidence building: Constraints proven through exercises

Phase 4: Experiments - Semantic Experiments “Test Hypotheses”

Scientific Validation of Constraints

Phase 4 treats constraint definitions as hypotheses to be rigorously tested through controlled experiments.

Experiment 1: Performance Impact Analysis

// Controlled experiment: Validation performance
class ConstraintPerformanceExperiment
{
    public function experimentValidationPerformance(): array
    {
        $datasets = [
            'small' => array_fill(0, 1000, 'iPhone 15 Pro'),
            'large' => array_fill(0, 1000, str_repeat('Large Product Name ', 8)),
            'mixed' => $this->generateMixedDataset(1000)
        ];
        
        $results = [];
        
        foreach ($datasets as $type => $data) {
            $startTime = microtime(true);
            
            foreach ($data as $productName) {
                $this->validateProductName($productName);
            }
            
            $endTime = microtime(true);
            $results[$type] = $endTime - $startTime;
        }
        
        return $results;
        // Hypothesis: Our constraints should validate 1000 items in under 10ms
    }
}

Experiment 2: User Experience Impact Study

// A/B testing experiment on constraint impact on UX
class ConstraintUXExperiment {
  async runConstraintImpactExperiment() {
    const variants = {
      'no_constraints': {
        validation: () => true,
        description: 'No validation - anything goes'
      },
      'loose_constraints': {
        validation: (name) => name.length > 0 && name.length < 200,
        description: 'Minimal validation - length only'
      },
      'semantic_ex_constraints': {
        validation: this.semanticExValidation,
        description: 'Full Semantic-Ex Method constraints'
      }
    };
    
    // Hypothesis: Semantic-Ex constraints have:
    // - Higher completion rates (clearer expectations)
    // - Lower error rates (better guidance)
    // - Higher satisfaction (frustration-free experience)
    // - Fewer support tickets (self-explanatory validation)
    
    return this.runExperiment(variants);
  }
}

Experiment Benefits:

  • Data-driven decisions: Constraints based on evidence, not opinions
  • Continuous improvement: Regular hypothesis testing drives evolution
  • Risk mitigation: Discover issues in controlled environments
  • Stakeholder confidence: Decisions backed by experimental proof

The Semantic-Ex Method in Practice

Case Study: E-commerce Product System

Traditional Abstract Approach

{
  "product": {
    "name": {"type": "string", "maxLength": 50},
    "description": {"type": "string", "maxLength": 200},
    "price": {"type": "number", "minimum": 0}
  }
}

Problems Discovered:

  • Product names truncated: “Apple MacBook Pro 16-in…”
  • Descriptions too short for detailed products
  • Price range ignores currency formatting issues

Applying the Semantic-Ex Method

Phase 1: Semantics

{
  "alps": {
    "descriptor": [
      {"id": "productName", "def": "https://schema.org/name"},
      {"id": "productDescription", "def": "https://schema.org/description"},
      {"id": "price", "def": "https://schema.org/price"}
    ]
  }
}

Phase 2: Experience Generated 1000+ realistic products:

  • Electronics with model numbers
  • Books with long subtitles
  • Luxury items with elaborate descriptions
  • International products with various currencies

Phase 3: Constraints

{
  "$comment": "Experience-based constraints from 1000+ product analysis",
  "product": {
    "name": {
      "type": "string", 
      "minLength": 5,
      "maxLength": 120,
      "description": "Accommodates real product names",
      "examples": ["iPhone 15 Pro Max", "The Lord of the Rings: The Fellowship of the Ring"]
    },
    "description": {
      "type": "string",
      "minLength": 20,
      "maxLength": 2000,
      "description": "Based on actual product descriptions",
      "examples": ["High-performance laptop with M3 chip..."]
    },
    "price": {
      "type": "object",
      "description": "Compound type discovered through experience",
      "properties": {
        "amount": {"type": "number", "minimum": 0.01},
        "currency": {"type": "string", "enum": ["USD", "EUR", "JPY"]},
        "display": {
          "type": "string",
          "description": "For formatted display like '¥1,299'"
        }
      }
    }
  }
}

Semantic-Ex vs Traditional Approaches

Aspect Abstract-First Semantic-Ex Method
Starting Point Arbitrary rules Semantic meaning
Validation Hope-based Empirical evidence
Flexibility Rigid, brittle Adapts to reality
Stakeholder Buy-in “Why this limit?” “We tested this”
Maintainability Constant fixes Stable, evidence-based
User Experience Often misaligned Naturally optimized

Benefits of the Semantic-Ex Method

1. Evidence-Based Constraints

Every constraint has a documented reason based on actual usage.

{
  "userBio": {
    "maxLength": 160,
    "description": "Twitter-style bio that fits in profile cards",
    "reason": "Testing showed longer bios break mobile layouts"
  }
}

2. Stakeholder Trust

Business stakeholders see why constraints exist through prototypes.

Before: “Why can’t product names be longer?” After: “Oh, I see it breaks the layout. 120 characters makes sense.”

3. Future-Proof Design

Constraints based on semantic meaning are more adaptable than arbitrary technical limitations.

4. AI-Ready

Clear semantics → Rich training data → Better AI assistance.

// AI can generate better constraints from rich semantic context
const constraintPrompt = `
Based on the semantic definition of "product name" as a 
commercial identifier displayed in search results, shopping carts, 
and product catalogs, generate appropriate validation constraints.
`;

Implementation Strategy

Step 1: Semantic Modeling

Define what things mean, not how to implement them.

{
  "customerReview": {
    "type": "semantic",
    "def": "https://schema.org/Review",
    "doc": "Customer feedback about product experience and quality"
  }
}

Step 2: Experience Generation

Create realistic, diverse scenarios.

// Generate reviews of various lengths and styles
const reviews = [
  "Great product!",  // Short and sweet
  "I've been using this for 6 months and it's completely transformed my workflow. The quality is exceptional, customer service was responsive, and it integrates perfectly with my existing tools. Highly recommend for professionals.",  // Detailed experience
  "It's okay. Works as expected but nothing special. Probably wouldn't buy again but not bad enough to return."  // Mixed/negative
];

Step 3: Constraint Discovery

Let reality guide the rules.

{
  "customerReview": {
    "type": "string",
    "minLength": 10,
    "maxLength": 2000,
    "pattern": "^[^<>{}]+$",
    "description": "Customer review that provides meaningful feedback",
    "constraints": {
      "minLength_reason": "Filters out meaningless 'Great!' reviews",
      "maxLength_reason": "Accommodates detailed experiences", 
      "pattern_reason": "Prevents HTML injection"
    }
  }
}

The Semantic-Ex Mindset Shift

From Questions Like:

  • “What’s a reasonable character limit?”
  • “How long should descriptions be?”
  • “What validation rules should we add?”

To Questions Like:

  • “What does this represent in the real world?”
  • “How do people actually use this?”
  • “What breaks when we test with realistic data?”

Conclusion: Grounding Design in Reality

The Semantic-Ex Method transforms software design from assumption-driven to evidence-driven.

By starting with semantic meaning, experiencing realistic scenarios, and discovering constraints through observation, we create systems that naturally fit how they’re actually used.

The meaning we’ve deepened here isn’t just abstract definitions—it’s based on real user experiences. This enables stakeholders to deeply understand the system’s meaning and achieve mutual understanding. AI can leverage this semantic context to suggest better constraints, while developers can build better systems with fewer assumptions.

AI is an expert at meaning and language (it’s an LLM after all!). It can generate vast numbers of Examples from Semantics (meaning), and from Examples beyond our imagination, new constraint emergences may arise. When constraints that were traditionally decided by intuition or experience emerge from iterations of experience, examples, exercises, and experiments, they will surely become better constraints. These constraints will create common understanding among stakeholders, reduce developer burden, and provide natural experiences for users. Not to mention their role as a common language with AI.