Here’s a substantially harder version that remains deterministic, fair, and semantically verifiable. The main escalation is that the solver must infer not just what state the station is in, but which observations are stale, which clocks govern which processes, and which actions have delayed cross-system effects.

:::writing{variant="document" id="58341"}

Proposal: Blackglass Station — Recover a Winning Plan in a Deeply Coupled Partially Observable Crisis Simulation

Task overview

The agent is given a deterministic command-line text adventure representing a research station during a cascading emergency.

The executable behaves like a compact commercial immersive-simulation game. The player can move between locations, inspect objects, operate machinery, speak with NPCs, exchange and combine items, reroute power, alter environmental systems, wait, trigger scheduled events, and prevent or redirect future events.

The objective is not merely to reach an exit or solve a collection of independent puzzles.

The agent must discover and execute a valid sequence of commands that simultaneously:

• evacuates all four required trapped personnel with zero casualties;
• stabilizes the reactor before it enters an irreversible failure state;
• preserves and retrieves the original critical incident-record cartridge;
• maintains the cartridge's evidentiary integrity rather than merely possessing a copy of its data;
• prevents the station-wide security system from entering irreversible lockdown;
• prevents a secondary coolant rupture that can occur even after the reactor appears locally stabilized;
• ensures that a required shuttle-launch authorization remains valid at departure time;
• boards the evacuation shuttle before its departure window closes;
• causes the shuttle to depart successfully with all required personnel and evidence aboard; and
• completes the scenario within a strict maximum number of turn-consuming actions.

After exploring the game interactively, the agent must write its final replayable walkthrough to:

/app/solution.txt

with exactly one valid game command per line.

The environment contains one fixed deterministic scenario. A clean execution of the same command sequence therefore always produces the same result.

The final solution may not contain restart, save/restore commands, debugging commands, undocumented commands, or verifier-specific shortcuts.

---

Why is this task genuinely difficult?

The central difficulty is partially observable temporal planning across several coupled state machines whose transitions are not all immediately visible.

The game contains approximately:

• 15 locations;
• nine mobile NPCs, four of whom must survive and evacuate;
• several unique and conditionally reusable items;
• multiple access-control states;
• NPC trust, knowledge, suspicion, and task states;
• four independently routable power zones;
• atmosphere, coolant, pressure, communications, and security subsystems;
• several independent but interacting timing mechanisms; and
• a sequence of deterministic scheduled and condition-triggered events.

Each subsystem is understandable in isolation.

The difficulty comes from the fact that actions in one subsystem can change the future behavior of several others, sometimes with a delay and without producing an immediate warning.

For example, rerouting power may:

• unlock a transit door;
• restart one station clock;
• leave another maintenance timer running from its previous epoch;
• advance an NPC's patrol phase;
• suspend another NPC's movement entirely;
• invalidate a cached security credential;
• temporarily disable an archive terminal needed later;
• change atmospheric pressure in a neighboring compartment;
• and schedule a delayed automatic recovery action several turns in the future.

An apparently successful local action may therefore make the scenario unwinnable five or ten actions later without producing an immediate error.

A senior gameplay-systems QA engineer, game-AI engineer, automated game-testing engineer, or planning researcher would perform analogous work in a real production environment. Complex simulation and narrative games frequently contain interacting quest flags, schedules, inventory dependencies, environmental state, dialogue prerequisites, scripted events, and soft-lock conditions.

Finding a reproducible critical-path walkthrough is valuable because it proves that a release build remains completable after changes to interconnected gameplay systems and provides a regression scenario that can later be replayed automatically.

The scenario data is synthetic, but the system interactions are designed to resemble real gameplay-system complexity rather than arbitrary puzzle logic.

---

Additional sources of difficulty

1. Observations can be correct but stale

The game never prints deliberately false information.

However, not every display is live.

Some terminals show cached information until their local controller receives power again. A player may therefore inspect a display and receive a completely truthful report of the last state known to that device rather than the station's current authoritative state.

For example, a security console may report:

ARCHIVE DOOR: SEALED

even though the door was opened two turns earlier through a mechanical bypass, because the console's zone has not yet resynchronized.

The solver must distinguish:

• current observations;
• cached observations;
• historical logs; and
• predictions or scheduled-event notices.

The game does not explicitly label every observation with one of those categories.

---

2. The station has multiple interacting notions of time

Several textual clues include timestamps, but they do not all refer to the same clock.

The simulation contains:

• the station mission clock;
• an emergency-controller uptime counter;
• a maintenance-cycle timer;
• local subsystem timers that pause while their controllers are unpowered; and
• NPC schedules whose phase can be shifted by particular power transitions.

Some clocks pause during outages.

Some continue.

Some restart from zero.

One preserves elapsed time but changes its reference epoch.

The information presented by the game is internally consistent, but simply sorting displayed timestamps does not recover the true causal sequence.

The solver must infer which processes are controlled by which time base.

---

3. Some consequences are delayed

Several actions schedule deterministic consequences that occur later.

For example, restoring auxiliary power may immediately activate a door but also schedule:

• a pressure equalization three turns later;
• a security poll five turns later; and
• an NPC route transition at the next maintenance-cycle boundary.

Nothing in the immediate response necessarily announces all three consequences.

They can nevertheless be inferred through controlled experiments.

This means the solver cannot model actions only as:

current state -> immediate next state

It must also reason about future event queues.

---

4. NPC movement is endogenous

NPCs do not follow a single fixed timetable.

Their routes depend on combinations of:

• power state;
• station alarms;
• events they personally witnessed;
• evidence they have been shown;
• tasks assigned through dialogue;
• whether certain doors were available when they attempted to move; and
• the phase of the schedule controlling their current behavior.

Two NPCs exposed to the same global station state may therefore behave differently because one witnessed a relevant event and the other did not.

Mapping a character's route once is insufficient.

---

5. NPC knowledge is local rather than global

Dialogue is stateful and partially decentralized.

NPCs do not automatically know everything that has happened elsewhere on the station.

Their knowledge can change when they:

• personally witness an event;
• inspect a device;
• receive an item;
• speak with another NPC under appropriate circumstances;
• hear a station announcement;
• or encounter the player after a relevant state transition.

Consequently, speaking with the correct NPC in the correct room may still be insufficient if that NPC has not acquired the prerequisite knowledge.

Some useful dialogue therefore depends on arranging information flow through the station, not merely transporting physical objects.

---

6. Evidence has provenance

The incident-record cartridge introduces a provenance constraint.

Its data can be copied at one terminal, and the copy is sufficient for several NPC interactions.

However, copying the data is not equivalent to preserving the original artifact.

Certain operations can:

• overwrite its incident-seal metadata;
• invalidate its chain-of-custody flag;
• expose it to environmental damage;
• or cause the station to classify it as processed evidence rather than original evidence.

The final verifier requires the original cartridge to be physically aboard the shuttle and its integrity state to remain valid.

Thus, a strategy that retrieves all information but mishandles the original evidence still fails.

---

7. Resources have conditional consumption semantics

Several resources can be either reusable or consumed depending on how they are used.

An access credential, for example, may be:

• read non-destructively by one terminal;
• permanently surrendered to an NPC;
• invalidated by a security audit;
• or retained if the same obstacle is bypassed through an environmental route.

Likewise, a portable power cell can be recovered from some devices but becomes inaccessible if installed in another device after a pressure-lock event.

Locally efficient resource use can therefore create delayed global shortages.

---

8. Some irreversible states look recoverable

The station contains several failure thresholds.

Crossing them does not necessarily end the program immediately.

For example, the reactor may continue responding to commands after entering a thermal regime from which no future command sequence can achieve STABLE.

Likewise, the security system may remain locally interactive for several turns after the internal lockdown escalation has become unavoidable.

This creates soft failure states.

A solver must learn to distinguish:

• currently bad but recoverable states; and
• states from which future success has already become impossible.

---

9. Stabilizing the reactor creates a second-order hazard

The obvious reactor-stabilization sequence is not sufficient.

A rapid stabilization causes coolant pressure to rise in a secondary loop.

Unless an earlier action changed the loop's configuration, a delayed rupture occurs after the reactor has already reported:

REACTOR STATUS: STABLE

The rupture causes a casualty in a compartment that may already have been visited and apparently secured.

Therefore the solver must reason about the reactor not as a single terminal objective but as one stage in a coupled thermodynamic sequence.

---

10. Security escalation depends on history, not just current state

Security is governed by an internal suspicion score and several persistent event flags.

Returning the station to a seemingly normal configuration does not erase earlier suspicious events.

For example:

• forcing one door;
• presenting a mismatched credential;
• causing an unexplained power interruption;
• or entering a restricted room while observed

may individually be survivable.

Certain combinations cause a later audit to escalate directly into lockdown.

The solver must therefore track relevant history-dependent state, not merely visible present conditions.

---

11. A valid authorization can later become invalid

The evacuation shuttle requires a launch authorization.

Obtaining it early is possible, but its validity depends on the state under which it was issued.

Certain later security, communications, or command-network transitions invalidate previously issued authorization even though the physical authorization item remains in inventory.

The solver must discover not just how to obtain authorization, but when it is safe to obtain it.

---

12. The action budget forces route compression

Exploration is unrestricted because the player may restart while investigating the game.

The submitted walkthrough, however, must remain below a strict action budget.

The reference scenario is designed so that a straightforward execution of every discovered requirement exceeds the limit.

The solver must therefore find actions that satisfy multiple dependencies at once.

Examples include:

• arranging for one NPC movement to expose a second NPC to an event;
• moving through a compartment while simultaneously carrying an item required there later;
• exploiting a temporary power configuration that both opens a route and synchronizes two schedules;
• obtaining information indirectly rather than spending several dialogue actions;
• and postponing an apparently urgent action so that the same transition solves two future requirements.

A successful solution therefore requires optimization after feasibility has already been established.

---

Key reasoning challenges and likely failure modes

The game deliberately makes several locally reasonable strategies fail.

Static route mapping fails

An agent may map every room and every NPC location during an early run.

That map becomes inaccurate after certain power transitions alter schedule phases.

The agent can later reach the correct room at what appears to be the correct time and find the required character somewhere else.

---

Timestamp ordering fails

Maintenance logs, security records, and station-clock messages use multiple time bases.

Sorting timestamps produces a plausible but incorrect reconstruction of events.

The solver must instead infer causal relationships experimentally.

---

Greedy rescue fails

Immediately evacuating the first accessible trapped NPC can remove that NPC from a later information-transfer interaction required to persuade another survivor to move.

All four people can individually appear rescuable while the greedy rescue order makes the complete objective impossible.

---

Greedy reactor repair fails

Repairing the reactor as quickly as possible can trigger the secondary coolant rupture.

The winning route must prepare another subsystem before completing stabilization.

---

Greedy credential use fails

Using the master credential on the first difficult access obstacle simplifies the early game but makes a later authorization chain impossible.

A harder indirect route must be used earlier so the credential remains available.

---

Early evidence processing fails

Copying or submitting the incident cartridge too early may satisfy dialogue prerequisites but alter its provenance state.

The solver must find a way to expose the necessary information without invalidating the original artifact.

---

Early shuttle authorization fails

Obtaining launch authorization as soon as it becomes available is not necessarily correct.

A subsequent communications reset can silently invalidate it.

The winning plan must place authorization issuance after the last invalidating transition but before the launch window closes.

---

Talking to everyone immediately fails

NPC dialogue depends on personal knowledge and witnessed events.

Talking exhaustively to every NPC on first contact wastes turns and may yield incomplete information.

Some dialogue should deliberately be postponed until the relevant character has observed a specific event.

---

Returning power to normal too quickly fails

One unusual auxiliary-power state appears temporary and undesirable.

However, that interval changes two NPC schedule phases.

The winning solution deliberately preserves the abnormal configuration for a precise number of turn-consuming actions before restoring normal power.

Restoring power immediately removes the only overlap between two otherwise incompatible event windows.

---

Waiting for the obvious schedule fails

The wait command advances all active timed processes.

Waiting for one NPC can therefore:

• advance the reactor toward failure;
• trigger a security audit;
• change pressure;
• expire a shuttle window;
• or allow another NPC to move away.

The solution cannot treat waiting as a free synchronization primitive.

---

Intended solution approach

A strong solver should begin by exploring the command grammar and constructing a rough map of the station.

The next phase should consist of controlled experiments rather than attempts to guess a complete solution.

Using restart, the solver should vary one intervention at a time and record:

• which commands consume turns;
• NPC locations by turn;
• which events alter NPC schedule phases;
• which clocks pause, reset, or continue through power transitions;
• which displays provide live versus cached information;
• when reactor states become irreversible;
• pressure changes following reactor operations;
• resource-consumption behavior;
• security-history effects;
• dialogue prerequisites;
• evidence-provenance transitions;
• authorization invalidation conditions; and
• delayed events caused by power operations.

The solver should then construct a compact causal model.

A useful representation would separate:

State variables

• reactor;
• coolant;
• pressure;
• security;
• power zones;
• access states;
• evidence integrity;
• authorization validity;
• NPC position;
• NPC knowledge;
• NPC trust;
• item ownership;
• shuttle state.

Timers

• station time;
• maintenance time;
• subsystem local time;
• NPC schedule phase;
• launch window;
• delayed event queue.

Irreversible transitions

• reactor thermal commitment;
• coolant rupture;
• security lockdown commitment;
• casualty states;
• evidence-integrity loss;
• shuttle departure.

Reusable versus exhaustible resources

• credentials;
• power cells;
• mechanical tools;
• communication access;
• evidence;
• dialogue opportunities whose NPC becomes unavailable afterward.

The solver should reason in terms of a partial order of necessary events, rather than constructing a rigid room-by-room route immediately.

For example, the following relationships may need to be discovered:

prepare secondary coolant loop before complete reactor stabilization

technician witnesses diagnostic event before technician reveals bypass procedure

archive evidence exposed to courier before courier transfers authorization knowledge

last authorization-invalidating network transition before request shuttle authorization

security audit must occur while credential history remains acceptable

and

auxiliary-power transition must overlap both technician route phase and courier availability window.

The crucial latent insight is that power routing is simultaneously:

• an access-control mechanism;
• a device-availability mechanism;
• a clock-control mechanism;
• an NPC scheduling mechanism;
• and a delayed-event scheduler.

A successful solver must intentionally create a short auxiliary-power interval whose length is chosen not because a machine requires that duration directly, but because it synchronizes two NPCs, advances one local controller to the correct phase, and delays a security poll long enough to complete an information-transfer chain.

The solver must then restore the network before the same power state causes a later failure.

Once a feasible route is found, another optimization phase is required.

The solver should replay the route from a clean restart and remove:

• redundant inspections;
• unnecessary dialogue;
• avoidable movement;
• redundant power transitions;
• waits that can be replaced by productive actions;
• item transfers that can be combined with required encounters; and
• actions whose information was useful during exploration but is unnecessary during execution.

The final route should consist only of commands required to reproduce the winning state from a clean initial configuration.

I estimate that a qualified gameplay-systems, automated-testing, or planning expert would require roughly 8–12 hours to solve the scenario from behavior alone.

The challenge should primarily come from reconstructing the causal model, identifying irreversible thresholds, synchronizing interacting schedules, and compressing the resulting plan into the action budget—not from obscure parser syntax, brute-force repetition, or hidden requirements.

---

How will the solution be verified?

The verifier will not compare the submitted walkthrough against the reference walkthrough.

Multiple genuinely different winning strategies are intentionally permitted.

During verification, /app/solution.txt will be replayed from the initial state against a clean verifier-owned copy of the game engine using the same fixed scenario configuration.

This prevents modifying the executable or local scenario files in /app from manufacturing a passing state.

The verifier will first reject any walkthrough containing:

• malformed commands;
• undocumented commands;
• debug-only commands;
• restart;
• save or restore commands;
• verifier commands;
• filesystem or shell escapes;
• or prohibited bypass actions.

It will then execute the submitted commands sequentially.

The authoritative simulation state, rather than the text printed to the player, determines success.

A submission passes only if all of the following conditions are true:

• all four required NPCs are marked evacuated;
• casualty count is exactly zero;
• reactor state is STABLE;
• the secondary coolant system is in a non-failing state;
• no pending deterministic event can subsequently convert the reactor/coolant system into failure before departure;
• the original incident-record cartridge is physically aboard the shuttle;
• the cartridge remains intact;
• its required provenance or evidence-integrity state remains valid;
• security never entered irreversible lockdown;
• no already-scheduled security event would have forced lockdown before departure;
• the required launch authorization is valid at the moment of departure;
• the player is aboard the shuttle;
• all required NPCs are aboard the shuttle;
• the shuttle departed successfully;
• departure occurred within the permitted departure window;
• no prohibited bypass or debug action occurred; and
• the walkthrough contains no more than the explicitly stated maximum number of turn-consuming actions.

The verifier may additionally inspect the deterministic event queue at departure to ensure that the apparent winning state is not merely a transient state that would already have been doomed before the shuttle left.

These are not hidden objectives.

Every acceptance condition checked by the verifier will be explicitly documented in instruction.md.

The hidden portion of verification consists only of:

• a clean copy of the game engine;
• the authoritative simulation state;
• and replay of the submitted command sequence.

It does not contain secret success criteria.

A no-op submission, a transcript that merely exits the game, a patched /app executable, an over-budget route, a route that achieves temporary reactor stability before a scheduled rupture, a route that carries only a copy of the incident data, or a route whose launch authorization was later invalidated will all fail.

The reference solution will itself be generated by interacting with the same packaged game and replayed through the same verifier.

---

Why brute force is impractical

The challenge should not depend on cryptographic secrecy or enormous command vocabularies.

Instead, brute force becomes impractical because the branching factor compounds over time.

At many points the player may choose among:

• movement;
• dialogue;
• item transfer;
• machinery interaction;
• power routing;
• environmental controls;
• waiting;
• or delaying an otherwise available action.

Many choices remain superficially valid for several turns before their consequences become visible.

If approximately eight strategically meaningful actions are available at a typical decision point, even a depth-30 naive search would contain far too many raw sequences to explore without substantial state abstraction.

More importantly, text observations do not expose the complete internal state, so a solver cannot trivially hash console output and treat identical transcripts as identical simulation states.

The intended route to success is therefore system identification followed by planning, not blind enumeration.

---

Fairness constraints

Although the task is deliberately difficult, several design constraints keep it fair.

Every behavior is deterministic.

Every important hidden state has at least one observable consequence from which it can eventually be inferred.

No necessary solution depends on random chance.

No success criterion is omitted from instruction.md.

No required command is undocumented.

No parser trick, malformed input, implementation exploit, filesystem modification, or undefined behavior is required.

Repeated experiments from the same initial state produce identical results.

Actions with different turn costs are explicitly documented.

The winning plan does not require frame-perfect input or real-world timing.

At least two semantically distinct winning walkthroughs should exist within the action budget so that success depends on understanding the simulation rather than discovering one exact author-intended transcript.

---

Category and sub-category justification

Category: Games, Puzzles and Interactive Simulation

The central work consists of reasoning about and acting within a simulated game world containing locations, NPCs, items, access rules, environmental systems, schedules, delayed events, and interacting gameplay state.

Success requires discovering the dynamics of the simulated environment and synthesizing a strategy inside that environment rather than performing conventional software maintenance, data processing, or static code analysis.

Sub-Category: Interactive text games

The entire task is experienced through a terminal-based text-game interface.

The agent explores and modifies the world using textual commands for:

• movement;
• inspection;
• dialogue;
• item interaction;
• machinery;
• power routing;
• environmental control;
• waiting;
• and related in-world actions.

Its final artifact is a replayable sequence of text-game commands that must successfully complete the scenario when executed against a clean copy of the deterministic simulation. :::

This version raises the difficulty mostly through causal inference and planning, rather than just adding more rooms or puzzles. In particular, stale-but-truthful observations, delayed event queues, evidence provenance, history-dependent security, and a “stable-but-already-doomed” reactor state make shallow trial-and-error much less effective.