Coordinate objectives across systems

727. Lesson identity

Module

2.7 — Missions

Lesson

Coordinate objectives across systems

Academic type

Integration

Schema type

practical

Order

2 of the module

Estimated time

35–45 minutes, including practice

This lesson introduces event contracts as the bridge between mission predicates and authoritative systems. The mission system observes facts produced by combat, inventory, alarm, and faction systems; it does not rewrite their state.

728. Learning objective

After this lesson, you can draw a dependency map that sequences mission objectives across system events, identifies interruption and reversal paths, and marks optional objectives without assigning mission ownership to unrelated systems.

729. Why this matters

A mission rarely advances because one system owns every relevant fact. Combat may report that a target was defeated, inventory may report that an item was deposited, and a faction system may report a reputation change. The mission system coordinates these facts while preserving each system's authority.

Clear contracts also give AI a bounded analysis target. It can help identify ambiguous predicates, missing failure cases, or unlabeled dependencies, but it cannot decide which system is authoritative for the designer.

730. Prior knowledge

You should be able to:

• Define a mission objective as observable predicates with evidence sources.
• Distinguish mission evaluation from the systems that own combat, inventory, alarm, and faction state.

The previous lesson, A mission is a set of predicates, provides the foundation for choosing evidence instead of relying on a vague flag such as missionFeelsComplete. This lesson introduces the event-contract vocabulary used to connect those predicates to cross-system evidence.

731. Core concept

A mission coordinates systems through events and predicates, not through direct ownership of their state.

An event contract answers five questions:

1. What happened? Use a stable event name such as target_defeated or item_deposited.
2. Who is authoritative? Identify the producer that owns the fact.
3. What evidence is carried? Include only the payload needed to evaluate objectives, such as target_id, item_id, location_id, or mission_context_id.
4. When can the mission consume it? State whether the event can arrive before, during, or after the objective is active.
5. What happens if the fact changes or is invalidated? Define interruption, reversal, or re-evaluation behavior.

The mission system may record mission progress derived from these events. It must not directly set an enemy's health, add an item to inventory, change alarm state, or alter faction reputation merely to make an objective pass.

Optional objectives require the same contract discipline. An optional objective can contribute a branch, reward, score, or later predicate without blocking the required completion path. Labeling an objective optional is a mission rule; it is not permission to weaken an authority boundary.

732. Mental model

Use the chain producer → event or query contract → mission predicate → objective state.

For sequencing, represent each objective as a node and each required event or query as an edge. Add explicit paths for:

• Interruption: a condition temporarily suspends progress or changes the active objective.
• Reversal: later authoritative evidence invalidates previously recorded progress.
• Refusal: another system authoritatively denies a requested transition.
• Optional branch: a path that may change an outcome but does not block required completion.

A visual diagram is not required. You may submit an equivalent node-and-edge table with these columns:

The diagram and table formats represent the same relationships. If a dependency crosses a system boundary without an event or query contract, the design is incomplete.

733. Concrete example

Consider a mission with these objectives:

1. Required: Find the sealed case.
2. Required: Deposit the case at the safehouse.
3. Optional: Complete the deposit without damaging the case.
4. Required: Report the result to the mission contact.

A dependency map could read:

inventory: item_acquired(case_7)
              |
              v
       [case acquired]
              |
              v
inventory: item_deposited(case_7, safehouse)
              |
              v
      [deposit complete] ---------> [report result]
              |
              +----> [optional: case condition intact]
                         |
                         v
                  [optional outcome branch]

The same structure can be recorded in a node-and-edge table instead of inspected visually. The optional condition does not block the report objective and must not become a hidden prerequisite. If the safehouse becomes unavailable before the report, an authoritative world-state or faction event may interrupt the mission and require a new destination.

If inventory later emits an authoritative reversal such as item_deposit_invalidated(case_7, safehouse), the mission contract must specify whether the deposit becomes incomplete, enters a failed state, or awaits compensating evidence. The mission observes and evaluates the result; it does not manufacture it.

734. Common mistake

The most common mistake is treating a mission event as a command to another system. For example, a mission handler may receive deposit_requested and then directly add the case to inventory or mark a faction relationship as changed. That transfers ownership to the mission and makes failure, replay, and reversal difficult to reason about.

A mission should consume an authoritative result such as item_deposited, not pretend that a request is already a result. If a command is necessary, model it as a separate request with a clear owner and wait for the owning system's success, refusal, or failure evidence.

735. Guided practice

Create a dependency map for this mission brief:

Recover a ledger from a guarded location. The ledger must be placed in the archive. If the player destroys the guard captain, the archive contact refuses the handoff. If the player retrieves the ledger without triggering an alarm, the mission may award an optional clean-recovery outcome. The player can be interrupted before the handoff if the archive becomes inaccessible. The mission must not own combat, inventory, alarm, or faction state.

You may use a node-and-edge diagram or the equivalent table described above.

Complete these steps:

1. Write the required and optional objectives as predicates with evidence sources.
2. Name at least four events or queries and identify their authoritative producers.
3. Represent the normal sequence from recovery to handoff.
4. Add an interruption path for an inaccessible archive.
5. Add the guard-captain refusal path: if combat authoritatively reports that the guard captain was destroyed, the faction or archive-contact system must provide the refusal result, and the handoff objective must remain incomplete.
6. Add a reversal or invalidation path for a previously accepted ledger placement.
7. Mark the clean-recovery branch as optional and state exactly what it can change without blocking required completion. The absence of an alarm event is not durable evidence by itself: identify an evaluation boundary and require an authoritative alarm-system query or summary event confirming zero alarms for the relevant mission context.
8. Inspect every cross-system dependency. Replace any direct state mutation with an event, a query, or an explicitly named request/result pair.

Make one design decision about a pre-activation or out-of-order event: state what happens if ledger_retrieved arrives before its objective becomes active. Choose one of these policies:

• Retain the evidence until the objective can evaluate it.
• Query the authoritative producer's current state when the objective activates.
• Reject the event with a documented reason.

Explain why the selected policy fits the evidence lifetime and replay behavior.

736. Validation and evidence

Your map or table is sufficient when it contains:

• A labeled producer for every fact used by a mission predicate.
• A distinct event or query contract for every cross-system transition.
• Required and optional predicates with their evidence sources.
• A normal objective sequence with required predicates in order.
• An interruption path that does not silently complete the mission.
• A guard-captain refusal path showing that the handoff remains incomplete after the authoritative refusal result.
• A reversal or invalidation path explaining what happens to recorded progress.
• An optional branch that cannot block the required path.
• An authoritative alarm query or summary event evaluated at a defined boundary for the clean-recovery condition.
• No mission-owned mutation of combat, inventory, alarm, or faction state.
• A documented policy for a pre-activation or out-of-order ledger_retrieved event.

Read the dependency model once as a replay. Remove one required event and confirm that the dependent objective cannot complete. Then apply the interruption, refusal, and reversal paths and verify that every resulting state has an authoritative explanation.

Submit this work as the practical assessment attached to the lesson.

737. Key takeaways

• Missions coordinate authoritative facts; they do not own every system involved in an objective.
• Event contracts need a producer, meaningful evidence, timing assumptions, and invalidation behavior.
• A pre-activation or out-of-order event needs an explicit retention, query, or rejection policy.
• Interruption, refusal, and reversal paths must be designed explicitly.
• Optional objectives can change outcomes without blocking required completion.
• The absence of an event is not durable proof unless an authoritative contract establishes that fact at a defined evaluation boundary.

738. Next lesson

Next: 2.8 — Interactive narrative. Bring forward the event names, authority boundaries, guard-captain refusal path, optional branch, and interruption and reversal decisions documented here. These become inputs to narrative-state design; they do not transfer ownership of mission, combat, inventory, alarm, or faction state.

739. Knowledge check