Paper Walkthrough — FACET: Grounding Instruction, Environment, Solution and Verifier in One Executable State

A terminal task is a four-part bundle: instruction, environment, reference solution, verifier. FACET builds and runs the environment first, then uses that realized state as shared ground for every other artifact. From 71K agent skills it produces 6,078 validated tasks, and 1.2K successful trajectories lift Qwen3.5 at 4B, 9B and 27B alike.

FACET: Preserving Source Intent and Executable State in Terminal Task Synthesis

An analogy: building one driving-test course

To teach an agent how to work in a terminal, you need practice problems. But a practice problem here is not a piece of prose. The paper frames each terminal task as a bundle of an instruction, an initialized environment, a reference solution, and an executable verifier — and notes that if these are generated from inconsistent assumptions, the result is a task that is either unsolvable or incorrectly evaluated (§1).

Think of a driving-test course. There is the instruction ("navigate the S-curve, then parallel park"), the course itself with its cones and painted lines (the initial environment), the demonstration lap an instructor actually drives (the reference solution), and the sensors that measure whether you clipped the wheel stop (the verifier). Break any one of the four and the whole thing collapses. If no S-curve is painted, the instruction is unexecutable. If the sensors watch a kerb that does not exist, a perfect lap still fails. Worse, the four are coupled: adjust the course slightly and both the demonstration and the scoring rules have to move with it.

FACET (Fine-grained Agentic Construction of Executable Tasks) is a framework for mass-producing that four-part bundle without internal contradictions. It comes from a group at USTC, Shanghai AI Laboratory and Fudan University, released in August 2026.

What actually breaks: information decay and artifact drift

The paper separates the failure modes of multi-stage synthesis into two (§1).

The first is that source information is easily lost. The original material encodes capabilities, dependencies, intermediate states, input–output contracts and procedural constraints — yet each successive generation stage compresses all of that toward a short task description, so the synthesized task preserves only a fraction of the structure and complexity that was available.

The second is that task artifacts drift apart. An instruction may refer to a file that was never realized, a solution may assume a different schema or dependency, a verifier may test a state the task cannot even reach. Passing textual specifications between stages helps, the paper says, but it "does not ensure that all artifacts are grounded in the same realized execution state" (§1). Those two problems are the target.

The raw material: recovering scenarios from 71K skills

FACET starts from existing agent skill packages. Skills are collected from OpenClaw, ClawHub and GitHub, and anything unsafe, dependent on private resources, unreadable, non-actionable or duplicated is discarded, leaving 71,341 valid skills (§2.2, Appendix A.1). They fall into five top-level families and 34 fine-grained categories — 24.42% multimedia/creation/publishing, 21.28% AI/agents/tools, 21.11% software/systems/security, and so on.

Here is where it gets interesting. Rather than translating one skill into one task, an extraction agent proposes scenario hypotheses for each skill: in what setting might this be used, what is the user's goal, what should the initial and desired final states look like. Those hypotheses are embedded and used to retrieve similar hypotheses from other skills, which is how candidate skill combinations are discovered (§2.2). Related hypotheses are grouped into scenario–skill candidates $p_c=(c, X_c)$, and a model-based judge keeps only those whose skills are relevant, complementary, non-redundant and executable as a terminal workflow.

The mechanism: build the environment first, then ground everything in it

The paper's central claim is about the order in which artifacts are produced, and what they are grounded in. First, the notation. A synthesized task bundle is written (§2.1):

where $\mathcal{I}$ is the user instruction, $\mathcal{E}$ the environment specification, $\mathcal{S}$ the reference solution, $\mathcal{V}$ the executable verifier, and $\mathcal{M}$ the runtime metadata. In words, the line says that a task here is not a piece of prose but a five-part bundle — the request, the world it runs in, a worked answer, the machine that checks that answer, and the settings needed to run any of it. Writing the five side by side is itself the argument: none of them may be authored in isolation. Write $e_0$ for the state after initializing the environment and $e_T$ for the state after running the reference solution ($\bot$ if it fails). A task is accepted when:

Read aloud: (1) the environment builds, and (2) the verifier does not pass on the untouched initial state, and (3) the reference solution runs to completion, and (4) the verifier passes on the resulting state. All four must hold. In words: $\land$ is "and", $\neg$ is "not", and the whole line says the verifier must fail before the work is done and pass after it. Condition (2) is the quiet hero — without it your dataset fills up with tasks that are already "solved" before the agent does anything.

On top of that, FACET builds and runs the environment before writing the task (§2.4). The environment agent first emits a manifest listing the required directories, files, services and dependencies with their expected properties, then materializes it inside a restricted base image. It may fetch public resources and reshape them, or generate text and binary assets procedurally — but retrieved resources are localized into the build context, so the finished environment is self-contained and needs no network at evaluation time. To avoid thin, template-like fixtures, the agent may also expand and perturb the data while preserving schema and task semantics: extra records, metadata fields, distractor entries, cross-file relations.

If the build or the initialization check fails, the failure trace goes back to the environment agent for at most three repair iterations. Crucially, repair is conditioned on the reconstructed specification as well as the trace — otherwise the agent takes the shortcut of deleting the requirement instead of fixing the build (§2.4).

Once the environment stands up, its realized state is exposed as a shared grounding interface. Instruction, solution and verifier are generated in that order, each with read access to the same container state. The reference solution is then actually executed so the resulting final state can be observed, and only then is the verifier written. Verifiers check behaviour and state rather than exact command sequences, so alternative correct solutions still pass. And if a repair changed a filename, path, port, package version, schema or fixture, every downstream generator sees the updated state — which is what stops the three artifacts from being written against different implicit versions of the same environment (§2.4).