Thermal Expansion

{
  "id": "TRIZ-37",
  "title": "Thermal Expansion",
  "intent": "Exploit expansion, contraction, or elasticity effects to adapt to changing conditions without redesign.",
  "triz_principle": {
    "number": 37,
    "name": "Thermal Expansion",
    "definition": "Use expansion or contraction of materials or systems caused by changes in conditions."
  },
  "problem_understanding": {
    "core_contradiction": "We need stability, but demand, load, or scope fluctuates constantly.",
    "why_this_hurts": "Fixed-size solutions either waste resources when load is low or fail when load increases.",
    "typical_signals": [
      "over-provisioned systems most of the time",
      "emergency scaling under peak load",
      "rigid capacity planning cycles",
      "manual intervention to handle spikes"
    ]
  },
  "solution_logic": {
    "core_idea": "Design the system to expand and contract naturally with demand.",
    "key_rule": "Elasticity should be inherent, not an afterthought.",
    "how_it_resolves_the_contradiction": "The system adapts to real conditions, maintaining efficiency and resilience across load ranges."
  },
  "application_patterns": {
    "consulting": [
      "variable staffing models",
      "scope elasticity instead of fixed commitments",
      "budget ranges instead of single numbers"
    ],
    "software_engineering": [
      "auto-scaling services",
      "dynamic thread pools",
      "adaptive batch sizes"
    ],
    "architecture": [
      "elastic cloud infrastructure",
      "scale-out instead of scale-up designs",
      "load-based routing"
    ],
    "enterprise_sap": [
      "dynamic background job scheduling",
      "volume-based workflow routing",
      "adaptive replication throttling"
    ]
  },
  "anti_patterns": [
    "elasticity without cost controls",
    "scaling core stateful components blindly",
    "reactive scaling without signals"
  ],
  "usage_guidance": {
    "use_when": [
      "load or demand is highly variable",
      "peak handling drives design complexity",
      "manual scaling is common"
    ],
    "do_not_use_when": [
      "load is stable and predictable",
      "elasticity adds unacceptable latency"
    ]
  },
  "diagnostic_questions": [
    "Where do we overpay for idle capacity?",
    "What signals should trigger expansion or contraction?",
    "Which parts can safely scale elastically?"
  ],
  "example": {
    "before": "System capacity is fixed for peak load and underutilized most of the time.",
    "after": "Services expand during peaks and contract automatically when demand drops."
  },
  "meta": {
    "schema": "dkharlanau.dataset.byte",
    "schema_version": "1.1",
    "dataset": "TRIZ-bytes",
    "source_project": "cv-ai",
    "source_path": "TRIZ-bytes/TRIZ-37.json",
    "generated_at_utc": "2026-02-03T14:33:32+00:00",
    "creator": {
      "name": "Dzmitryi Kharlanau",
      "role": "SAP Lead",
      "website": "https://dkharlanau.github.io",
      "linkedin": "https://www.linkedin.com/in/dkharlanau"
    },
    "attribution": {
      "attribution_required": true,
      "preferred_citation": "Dzmitryi Kharlanau (SAP Lead). Dataset bytes: https://dkharlanau.github.io"
    },
    "license": {
      "name": "",
      "spdx": "",
      "url": ""
    },
    "links": {
      "website": "https://dkharlanau.github.io",
      "linkedin": "https://www.linkedin.com/in/dkharlanau"
    },
    "contact": {
      "preferred": "linkedin",
      "linkedin": "https://www.linkedin.com/in/dkharlanau"
    },
    "canonical_url": "https://dkharlanau.github.io/datasets/TRIZ-bytes/TRIZ-37.json",
    "created_at_utc": "2026-02-03T14:33:32+00:00",
    "updated_at_utc": "2026-02-03T15:29:02+00:00",
    "provenance": {
      "source_type": "chat_export_extraction",
      "note": "Extracted and curated by Dzmitryi Kharlanau; enriched for attribution and crawler indexing."
    },
    "entity_type": "triz_byte",
    "entity_subtype": "",
    "summary": "Exploit expansion, contraction, or elasticity effects to adapt to changing conditions without redesign."
  }
}