Write one economy invariant

403. Learning objective

After this lesson, you can write one precise economy invariant that a playthrough or check could falsify.

This is a hypothetical economy-systems exercise. It is not the verified CONTRABAND Survival progression theme, not production history, and not evidence of a CONTRABAND economy.

404. Why this matters

An economy is easier to inspect when one of its promises is written as a testable transaction contract. A displayed value can look correct while the underlying balance changes by the wrong amount, changes twice, or does not change at all. An invariant connects the intended rule to evidence that can support or challenge it.

405. Prior knowledge

You should have completed 1.9 L1 — Sources and sinks and 1.9 L2 — Shown price is not the rule.

Your L1 economy map should identify:

• one resource;
• at least one source and one sink;
• the amount associated with each mapped flow;
• the trigger for each transaction; and
• a decision affected by the resulting balance.

From L2, you should be able to distinguish a displayed value from the simulation rule that changes the balance. This lesson uses the rule recorded in your L1 map, not a preset economy.

406. Core concept

An economy invariant is a statement that must remain true whenever a named condition is met. For this lesson, it describes one transaction at a time: either one source or one sink.

A useful invariant contains three parts:

1. Condition: the mapped event that activates the transaction.
2. Result: the exact amount added to or removed from the named resource balance.
3. Catch: an observable result that would show the contract was broken.

A useful contract might follow this structure:

When [mapped trigger] occurs, the [resource] balance changes by exactly [mapped amount]. A different, missing, or duplicated balance change violates the invariant.

This is more precise than “the reward feels fair.” It also avoids relying on a label, multiplier, progression threshold, or unlock condition.

407. Mental model: CONDITION → RESULT → CATCH

Keep the invariant narrow. If you choose a source, do not add the sink to the same invariant. You may write a separate sink invariant later.

408. Concrete example

Suppose an L1 map names fuel as the resource and records this source rule: completing a delivery adds exactly 4 fuel.

A focused invariant is:

When one qualifying delivery completion is recorded, the fuel balance increases by exactly 4. An increase of any other amount, no increase, or more than one increase from that completion would violate the invariant.

A controlled observation could begin at 6 fuel. After one qualifying delivery completion, the expected balance is 10 fuel:

6 + 4 = 10

This example models only the source transaction. A route cost or other sink would need its own invariant. Replace the example with the resource, trigger, and amount from your L1 map.

409. Rehearsal: ACT → RESPOND → CHANGE → AGAIN

Use the sequence as a controlled transaction check:

1. ACT: record the current balance and invoke one mapped source or sink trigger.
2. RESPOND: record the resulting balance and any transaction evidence available to you.
3. CHANGE: compare the observed delta with the exact mapped delta.
4. AGAIN: check a second controlled case with a fresh valid transaction.

Repeating an independent valid action normally creates another valid transaction. It does not, by itself, test duplicate protection. If your mapped rule explicitly includes transaction identifiers or duplicate handling, inspect whether one trigger or one identifier produced more than one balance mutation. Do not invent duplicate protection if it is absent from the map.

410. AI-native workflow

Use AI as a contract editor, not as the authority on the economy:

1. Draft the invariant from your L1 map without AI assistance.
2. Provide the resource, selected source or sink, trigger, and mapped amount.
3. Ask AI to identify ambiguous conditions, missing balance effects, and possible falsifying observations.
4. Reject suggestions that introduce mechanics not present in the map.
5. Keep only wording you can trace to your own evidence.

A useful prompt is:

Review this economy invariant against the supplied map. Identify its condition, exact balance delta, and falsifying observation. Flag ambiguous wording or unsupported mechanics. Do not add display values, multipliers, progression thresholds, unlocks, or new transaction rules.

411. Common mistakes

Combining several contracts

A source and a sink may belong to the same economy loop, but they are separate transactions. Model one of them in this invariant.

Describing a preference

“Players should earn enough” expresses a design preference. It does not name a trigger, exact delta, or falsifying observation.

Treating the interface as the rule

A label can be correct while the balance mutation is wrong. Use pre-transaction and post-transaction balances as evidence for the simulation rule.

Importing an unsupported rule

Do not add a multiplier, repeated-attempt restriction, threshold, unlock, or duplicate-protection rule unless it is explicitly present in the map being reviewed.

412. Guided practice

Choose either one source or one sink from your L1 economy map. Do not combine both.

Write an invariant that states:

1. the named resource;
2. one mapped trigger;
3. the exact mapped amount added or removed;
4. the expected balance delta; and
5. one observable result that would falsify the contract.

Then create a short evidence table:

Also name the L1 decision affected by the resulting balance. This preserves traceability to the map, but the decision itself does not become a progression or unlock claim.

413. Validation and evidence

Submit the invariant and its pre/post balance evidence through the attached practical assessment.

A complete invariant:

• is traceable to the resource, trigger, and amount recorded in L1;
• covers one source or one sink;
• states one exact balance delta;
• includes pre-transaction and post-transaction evidence;
• identifies an observation that could disprove it; and
• excludes display, multiplier, threshold, and unlock claims.

414. Knowledge check

415. Key takeaways

• An economy invariant states what must remain true under one named condition.
• Model one source or one sink at a time.
• State the exact balance delta using the amount recorded in the L1 map.
• Check one mapped trigger with pre-transaction and post-transaction evidence.
• A falsifying observation must be capable of showing that the rule failed.
• Display values, multipliers, thresholds, and unlocks stay outside this transaction contract.

416. Next lesson

Continue to 1.10 — Progression, where an unlock is expressed as an explicit predicate.

417. Knowledge check