A mission is a set of predicates

714. Lesson identity

Module

2.7 — Missions

Lesson

A mission is a set of predicates

Academic type

Concept

Schema type

text

Order

1 in the module

Estimated time

30–40 minutes, including practice

715. Learning objective

After this lesson, you can write a mission contract that expresses objectives as observable predicates, names an authoritative evidence source for each predicate, and defines the condition that permits completion.

716. Why this matters

A mission objective such as “help the contact” is readable but not executable. A game system needs a testable condition that can be evaluated from known state. If the condition is vague, completion may occur too early, too late, or from the wrong event. A precise mission contract also gives AI a bounded implementation target: it can inspect the predicates and evidence sources instead of guessing what “done” means.

717. Prior knowledge

You should already be able to distinguish economy-owned state from a transaction result, and you should understand why a crafting transaction must validate all requirements before changing state. An earlier foundation, 2.5 L3 — Crafting is a transaction, not a second economy, provides the relevant distinction: a mission may observe the result of an authoritative transaction, but it should not silently become a second owner of economy state. This lesson uses those transaction and ownership distinctions to specify mission evidence; it does not require later mission-sequencing or cross-system coordination concepts.

718. Core concept

A mission is not primarily a sequence of dialogue lines or map markers. It is a contract over game state.

A predicate is a condition that evaluates to true or false from observable state. A mission contract combines predicates into a completion rule and identifies where the evidence comes from.

For each objective, specify:

1. Predicate: What condition must be true?
2. Evidence source: Which system owns or reports the state that proves the condition?
3. Completion authority: Which system is allowed to accept the mission as complete?
4. Timing: When is the predicate evaluated or re-evaluated?
5. Failure or invalidation rule: If relevant, what makes the objective impossible or no longer valid?

The mission system can coordinate these checks, but it should not invent facts that belong to another system. For example, an inventory system can prove that an item exists in the player inventory. A mission system can use that fact to evaluate an objective. It should not maintain an unrelated duplicate count and treat that copy as authoritative. A mission record may record that an acquisition predicate was observed or that mission progress was made; it does not duplicate ownership of the item or become the owner of inventory quantities.

719. Mental model

Use the predicate contract for every mission objective:

The authority boundary is the key distinction:

Authoritative system state
        ↓ evidence
Mission predicate evaluation
        ↓ all required predicates true
Mission completion authority
        ↓
Completion event and presentation

A marker, dialogue line, animation, or reward presentation is evidence of feedback—not proof by itself. Presentation may communicate a state change, but it must not be the only source of truth.

720. Concrete example

Consider the objective: “Recover the ledger and bring it to the archivist.”

A weak implementation might complete the mission when the player enters the archivist's area. That location event does not prove that the player recovered the correct ledger or delivered it.

A stronger contract separates the required facts and makes the delivery precondition explicit:

The mission completion rule is:

ledgerRecovered
AND ledgerAvailableForDeliveryAtDeliveryStart
AND deliveryAccepted(ledgerId, archivistId)

ledgerAvailableForDeliveryAtDeliveryStart is a temporal predicate: the ledger must be available when the delivery is attempted. The accepted delivery result is the authoritative evidence that the available, correct ledger was actually transferred to the archivist. After a successful delivery, the ledger may no longer be in the player's inventory, so the mission must not re-check current possession as a continuing completion condition. If the mission stores that the ledger was recovered, that record is mission progress only; it does not duplicate the inventory system's ownership record or item count.

Entering the area can present an interaction prompt, but it cannot complete the mission without an accepted delivery. If the delivery transaction rejects the ledger, the mission remains incomplete and the rejection can be presented to the player.

721. Common mistake

The common mistake is treating a player action or presentation event as completion evidence. “The player clicked the dialogue option” is an event. It is not automatically proof that the required transaction succeeded. Likewise, “the objective marker disappeared” is a presentation change, not an authoritative mission state.

Another mistake is listing a predicate in the contract but leaving it out of the completion rule. Every required predicate must either appear in the rule or be explicitly defined as a precondition subsumed by an authoritative predicate such as an accepted delivery result. Broad labels such as missionFeelsComplete hide missing evidence. Name the concrete state and the system that owns it. A mission progress record can refer to an inventory-owned fact without becoming a second inventory authority.

722. Guided practice

Write a mission contract for this objective:

“Prepare a repair kit and deliver it to the mechanic.”

Use the following constraints:

• The repair kit must be produced by an accepted crafting transaction.
• The kit must be available for delivery when the delivery transaction begins.
• The mechanic must accept the correct kit through an accepted delivery interaction.
• The mission system may decide completion, but it does not own crafting or inventory quantities.

Complete this table:

Then make one deliberate decision: require all three predicates, or explicitly subsume the availability predicate into an accepted delivery result that verifies the correct kit was available at delivery start. State your choice, explain why, and identify what evidence prevents the mission from fabricating completion. Your final rule must make the availability requirement visible either as its own temporal predicate or as a documented precondition of the authoritative delivery predicate. If you mention a mission progress record, distinguish it from the crafting or inventory systems that own the underlying state.

723. Validation / evidence

Your contract is valid when another developer can answer all of these questions without asking you to interpret the objective:

• What exact boolean conditions must be true?
• Which system is authoritative for each condition?
• Can the mission complete if crafting is rejected?
• Can the mission complete if the kit is unavailable when delivery begins?
• Can the mission complete if the wrong item is delivered?
• At what event or state transition are the predicates evaluated?
• Which system is allowed to change the mission to complete?
• If availability is not a separate completion term, where is it explicitly subsumed by the accepted delivery predicate?
• Does any mission record merely record progress, rather than duplicate item ownership or inventory quantity?

A strong submission contains at least three explicit predicates for this exercise—or two predicates plus a precise statement that the availability precondition is subsumed by the accepted delivery predicate. It names an evidence source for every required condition, expresses completion as a rule over those conditions, and does not use a marker, dialogue choice, or reward presentation as sole proof. Any mission record is described as progress or observed evidence, not as a duplicate owner of the item.

724. Key takeaways

• Express every mission objective as observable predicates.
• Use evidence from the system that owns the relevant state or transaction result.
• Keep temporal requirements, such as availability at delivery, visible in the contract.
• Let the mission system evaluate evidence and own mission status without duplicating inventory or economy authority.

725. Next lesson

Next: 2.7 L2 — Coordinate objectives across systems. That lesson applies mission predicates when objectives depend on more than one authoritative system. It is the second and final lesson in Module 2.7; after it, continue to Module 2.8 — Interactive narrative.

726. Knowledge check