Play Now
All patch notes

Patch Notes B0.053 - Key Fields, Procedures, File Tree

Thanks to everyone who joined the town halls! It was really great to chat with folks live and get a bunch of questions answered. I can't recap the full sessions here, but here are some key points:

  • We mainly support three audiences: casual players, world builders and power users.
    • Casual players want to pick some content and play. They don't want to fiddle with tuning instructions or get into the weeds. They want a fun, immersive game, and they generally want the AI to run faster.
    • World builders mostly build for casual players, and care about tuning their games for that experience.
    • Power users build complex systems and games, often for themselves. They care less about efficiency or turn speed and more about the GM handling their complex systems.
  • Harness 2 has been great for casual players and world builders, but hasn't performed as well for power users. We're addressing that in future updates, this one included. Part of the reason is that we designed Harness 2 to be efficient with context. The more unnecessary context in the context window, the more expensive turns get, which is bad for everyone! So the name of the game is getting the right context to the GM at the right time. We may have overcorrected a bit, so we're adding context management features to help you do exactly that.
  • Until we feel Harness 2 can support the more complex worlds power users expect, we're extending Harness 1 support. There's no specific timeline yet, but we'll give you a heads-up once we think Harness 2 has reached that bar.

All that said, we have some great updates coming for Harness 2. Today's update introduces a few new concepts.

Tool pruning

This has been part of Harness 2 from the start, but now is a good time to explain it.

Tool pruning saves context. During a turn, the GM may research and read files. Most of the time, what it gets back only matters in that moment: it uses it to write the turn. When the turn ends, we remove those research and read results from the context window. The current turn had the full detail, and future turns aren't bloated by it.

That keeps the context efficient, but it hurt when some of that content needed to stick around. If you felt the GM wasn't reading your character sheets, that's likely why: it read the sheet once, the result was pruned, and it didn't read the file again on later turns.

The features below, key fields and procedures, solve that problem.

File tree in context, plus read() and list()

When we shipped Harness 2, the GM got most of its information through the research() tool. research() and read() can both return information from files, but they work differently:

  • research() is for when the GM doesn't know where, or whether, some information exists. It asks a question, and the research tool finds the answer.
  • read() is for when the GM knows which file it wants, and which fields of it.

Harness 2 now also keeps your file tree in context: your folders and how many files each holds. The GM knows what kinds of files your game has, can use list() to see the files in a folder or of a type, and can then read() them.

One read is capped at 12,000 characters. Images and embedded data are left out, and a really big file is read in parts, so one huge file can't flood the GM's context.

Both read and research results are pruned when the turn ends, with two exceptions:

  • Key fields stay. Whatever key fields a read returned stay in context on later turns; the rest of the read is pruned (more below).
  • A file read again stays. If the GM reads the same file and the same fields again on a later turn, after the first read was pruned, that read stays whole until the game's memory is next compacted. The GM clearly needs it, so it won't keep re-reading it.

The GM can also see this coming: every read and research result now tells it whether it will be pruned. When it will, the GM is reminded to jot down anything it'll need later in a hidden note (more below).

Key fields

Key fields are a new setting on file types. They tell the GM which fields matter enough to keep in context. When the GM reads a file, its key fields stay in context instead of being pruned.

When research() looks into a file that has key fields, its key fields come back with the answer, even if the question didn't ask for them, and they stay too.

Some fields are key by default: a file's description and fields named like a look (appearance, looks, physical description, hair, eyes, height). So the GM already remembers what your characters look like once it has read them.

To mark a field as key, just ask Orbit to mark certain fields on a file type as key fields, “Orbit please mark backstory as a key field to the character sheets". go to your workspace's File Types tab, open a file type's Schema tab, click a field and turn on Key field. You can also turn the default off for a field the same way. Orbit can set key fields for you too.

Don’t overuse key fields. You only want to designate a handful of key fields that tell the GM the most important information to keep narration immersive. For characters, you should make any fields related to who they are, what they look like, and what they sound like. The GM will look up other details when it needs to. In a very mechanical system, a few stats the GM uses constantly (like D&D's ability scores) are good key fields. Long fields like inventories and spell lists are better left unmarked: the GM reads them when a turn needs them, and keeping them every turn would cost context on every turn.

New instruction type: Procedure

Without pinned and partial files in Harness 2, many complex games had no room for their longer encounter or bookkeeping rules.

Procedures are a new type of instruction, and should feel similar to how files with partial context visibility used to. A procedure can be up to 10,000 characters, much longer than always-on and situational instructions, and a game can have up to 25, including Craft's own four (travel, fights, trackers and hidden things).

The GM always has a list of your procedures in context, by name and when to use each, and reads one when its moment comes. Each procedure has a Pruned setting:

  • After use: the procedure is pruned when the turn ends. Use this for procedures that only matter in the moment, like creating a character or resolving one combat action. We recommend After use for most procedures, since it saves the most context.
  • On compaction: the procedure stays in context until the game's memory is next compacted. Use this for something that runs over several turns, like a whole fight or a long negotiation.

So what's the difference between procedures and situational instructions? Situational instructions are short reminders (up to 1,000 characters) that we hand the GM whenever their trigger fires. Procedures are listed by name in the GM's context, and the GM chooses to read one when it decides it's relevant.

Procedures are great for longer instructions that run as a workflow or take the GM several steps: resolving combat turns, creating new characters, running a complex scene.

We've moved Craft's own rules for travel, fights, trackers and hidden things into procedures as well. That cut the GM's system prompt by about a quarter, and the GM reads those rules in full when the moment comes.

Hidden notes

The GM now keeps notes to itself inside its replies: things the player shouldn't see in the story yet, like a secret, an NPC's real plan or a ruling it will use again. It also uses them to hold on to something it looked up before that lookup is pruned. Notes stay in the GM's context until the game's memory is compacted, and the important ones carry over into the game's memory. They're out of the story, but you can read them with the Hidden notes button under a reply.

What does this mean for me?

  • If you had longer instructions that lost their home, make them procedures.
  • If you felt the GM wasn't using fields you care about, make those fields key, but keep it to the few that matter most.
  • Overall, the GM should read your files and instructions better than before.

Advice for World Builders on Harness 2

To get the most out of Harness 2, I recommend starting small. Create a blank project of a small scale, and test things out in a game.

You can add a procedure, or a situational instruction, and then run a turn. You can inspect the turn to see what the GM researched, read, or updated. This way you can see how your instructions affect the GM's behavior. Once you understand that, you should be off to the races!

The CLI and Orbit have also both been updated - just paste this prompt: “Can you take a look at my instructions? See if any instructions should be moved into procedures. If the old v1 instruction files still exist in this project, look at those to understand the original intent and create procedures from those as well. Make sure we do not have any conflicting instructions"

Other changes

  • Changes in the Appearance tab now show in the preview first: Apply saves them, and Discard drops them.
  • Added Gemini 4 Argon (half price at launch), Kimi K3.1 Pro, Muse Wonder and GPT-6.1 Terra to the model picker.
  • Retired MiMo V2.5 and MiMo V2.5 Pro; saved picks moved to MiMo V2.6. Kimi K3 moved to legacy now that Kimi K3.1 Pro is here.
  • Every model priced at or above Gemini 3.8 Flash now has the Expensive tag and asks before you switch to it.
  • Your text and image models now show as one row each in Player Preferences, and Change opens the full list.
  • The GM no longer makes a second character when it writes someone's name with or without their title (Sir Alaric Rochefort and Alaric Rochefort).
  • Fixed an issue where the auto review process would incorrectly prohibit a small number of worlds from being published. If you were an affected creator, you should be able to republish your world now.

What's next?

We still have plenty of work to do on Harness 2. In the next few updates we’re going to be focusing on the following:

  • Improve the GM’s ability to update files, instructions, and other state accurately
  • Give Orbit more visibility into H2 games
  • Give world builders more debugging tools