Data is not behavior

1048. Lesson identity

Module

3.4 — Declarative data

Lesson

Data is not behavior

Academic type

Concept

Lesson format

Mixed

Order

Lesson 1 in the module

Estimated time

30–40 minutes, including practice

This lesson establishes the boundary between declarative configuration and executable rules. You will classify examples as data, behavior, or state, then identify who owns each item and where its meaning should be validated.

1049. Learning objective

After this lesson, you can classify a game value or rule as data, behavior, or state and justify its owner and semantic validation boundary.

1050. Why it matters

Generated code can place adjustable numbers, executable decisions, and temporary runtime facts in the same structure. This makes responsibilities difficult to inspect. A configuration edit can unexpectedly affect an algorithm, while mutable state can be mistaken for permanent content.

Declarative data is useful only when the system defines what each value means, who owns its schema, and which values are acceptable. Clear classification helps you review generated implementations and detect accidental coupling.

1051. Prior knowledge

You should be able to identify direct dependencies and events, distinguish an owned operation from a broadcast fact, and explain why uncontrolled event communication creates an unclear network of interactions. These ideas were introduced in 3.3 L2 — Avoid event soup. You should also be comfortable reading simple fields, tables, and conditional rules.

1052. Core concept

Data describes choices or parameters; behavior makes or carries out decisions; state records what is true now.

Declarative data is a description consumed by a system without replacing the algorithm that interprets it. Examples include an item's purchase cost, a weapon's configured maximum range, or a configured reuse duration. Such values still require a defined schema and meaningful limits.

Behavior is executable logic: conditions, calculations, transitions, procedures, and side effects. “If the target is outside the configured range, reject the action” is behavior. The range used by that rule can be data, but the comparison and rejection are behavior.

State is information that changes while the game runs. Current health, whether the dialogue interface is currently open, and the remaining reuse time are state. A designer may configure maximum health or reuse duration, but the current values belong to a runtime owner.

Classification depends on role and context, not syntax. A number in a file is not automatically configuration, and a number in code is not automatically behavior.

A code-owned data distinction

An implementation constant is not a fourth target classification. It is a code-owned value under the broader data/value classification. For example, MAX_SERIALIZED_ITEMS = 256 may express an implementation contract rather than a designer-authored tuning choice. The constant remains a value; the code that compares a count against it performs behavior.

A field can also hide executable instructions. If a system evaluates onUse = "applyDamage(); startTimer();", the text is stored as data but used as behavior. The storage format does not make the responsibility declarative.

1053. Mental model: Describe–Decide–Record

Use this classification test:

1. If a content author changes a value without intending to alter the interpreting algorithm, classify it as configuration data.
2. If code owns a fixed parameter required by an implementation contract, classify it as a code-owned data value, often called an implementation constant.
3. If an item expresses a decision, transition, calculation, procedure, or side effect, classify it as behavior.
4. If a value changes during play to represent the current situation, classify it as state.
5. If context is missing, state the assumption before classifying. More than one answer may be defensible under different ownership assumptions.
6. If one field has several roles at once, split it into separate data, behavior, and state representations.

Validation belongs at the boundary where a responsibility enters its owner. A configuration loader validates authored values, an operation owner protects behavioral rules, and a runtime owner preserves state invariants.

1054. Concrete example

Consider a consumable item with a configured three-second reuse delay:

Designer-authored item data:
  reuseDurationSeconds = 3.0

Behavior owned by the item-use system:
  when Use is requested:
    if reuseRemainingSeconds > 0, reject the request
    otherwise apply the effect and start the timer

Per-instance runtime state:
  reuseRemainingSeconds = 1.7

The duration is data because it describes adjustable content. Its schema should reject values outside the documented range. The request check, effect application, and timer update are behavior owned by the item-use system. The remaining duration is state because it records the current condition of one runtime instance.

Placing a mutable canUse field in shared item configuration would mix configuration with state. Several item instances could then share a temporary flag, or a session-specific fact could be persisted as permanent content.

1055. Common mistakes

One mistake is treating everything in a data file as declarative. A mutable currentHealth field belongs to runtime state even if it was serialized, while a script expression stored in a string remains executable behavior if the system evaluates it.

Another mistake is checking only syntax. A value can be numeric but semantically invalid. Examples include a negative cost, a probability outside the documented range, or a reuse duration that violates the system contract. Validation must check meaning, references, ranges, and cross-field rules where applicable.

A third mistake is classifying an ambiguous field without describing its context. dialogueOpen = true could be a configured initial value or the dialogue system's current state. Ownership and lifecycle determine the answer.

1056. Guided practice

Classify each contextualized item as data, behavior, or state. Then name its likely owner and one semantic validation concern.

1. A designer-authored carry-capacity setting: maximumCarryWeight = 30.
2. The inventory instance's current measured load: currentCarryWeight = 18.
3. The pickup system's executable rule: if currentCarryWeight + itemWeight > maximumCarryWeight, reject pickup.
4. The dialogue runtime's current interface flag: dialogueOpen = true.
5. A content-authored reward table: rewardTable = [{ item: "medkit", chance: 0.25 }].
6. The pickup operation: “When a pickup is accepted, add the item to inventory and emit PickupAccepted.”

For item 5, also decide whether probabilities must total exactly 1.0, may total less than 1.0 with an implicit “nothing” result, or require another documented rule. There is no universal choice; the reward-table schema must state and enforce its contract.

Suggested classifications:

• 1 — Data: owned by the carry-capacity configuration schema; validate that it is finite, non-negative, and within the documented design range.
• 2 — State: owned by the inventory runtime; validate that it remains consistent with the inventory contents and does not become negative.
• 3 — Behavior: owned by the pickup or inventory operation; verify the comparison rule and ensure rejection does not apply acceptance side effects.
• 4 — State: owned by the dialogue runtime; ensure transitions update it through the responsible interface controller.
• 5 — Data: owned by the reward-table schema; validate item references, probability bounds, and the documented total rule.
• 6 — Behavior: owned by the pickup operation; preserve the ordering and contract of inventory mutation and event emission.

If item 1 instead meant a hard implementation limit, it would still be a data value, but its owner would be the code module rather than the content schema. If item 4 meant a configured initial interface condition, it would be configuration data. State your assumption whenever context does not establish the lifecycle.

1057. Practical assessment

Complete the linked practical assessment. You will classify one configured value, one executable rule, and one runtime value. For each, you must state the owner and a semantic validation concern. This checks reasoning that the recognition quiz cannot assess by itself.

1058. Evidence of learning

Your classification is supported when you can explain:

• what the item represents in its stated context;
• why it is data, behavior, or state;
• which schema, system, module, or runtime entity owns it;
• which semantic condition must be checked at that owner's boundary.

When context is incomplete, identify the missing assumption rather than presenting an unconditional classification.

1059. Key ideas

• Data describes values; behavior executes decisions and effects; state records current runtime facts.
• An implementation constant is a code-owned data value, not a fourth peer classification.
• Context, ownership, and lifecycle determine classification—not file format or syntax.
• Validation must check semantic constraints, not only types.
• Keep configuration separate from per-instance mutable state.
• Keep executable decisions in the system that owns the operation.

1060. Next lesson

Next, continue to 3.4 L2 — Make a tunable rule declarative, where you will represent an adjustable rule as explicit data with a defined schema and validation boundary.

1061. Knowledge check