World Data

World data is everything the agent can read or act on during a run. A task can use files only, services only, or both. It is optional in the sense that a task whose inputs fit in a folder of files needs nothing more.

​

Files and repositories

Attached files live in the task’s workspace: spreadsheets, documents, data exports, code. For repository tasks the world is a bundled checkout with its own history; the agent receives a copy, and the hidden tests run against a fresh copy with the agent’s changes applied. Files the agent creates during a run are its output and part of the evidence.

​

Interactive services

A task can declare simulated GitHub, Linear and Slack services. They are clones, not connections to real accounts: the author seeds them from fixtures, and the agent uses the same tool calls it would against the real products. It can read repositories, issues, files, tickets, channels and threads, and it can create issues, update tickets, comment, post and reply. Reads show the initial world, successful writes change it, and every call is recorded. Good service tasks are outcome-driven: investigate a ticket, check the referenced code, and post the evidence-backed conclusion where the team will see it.

​

Public and private

Each service fixture has a public side, which the agent reaches through the service, and a private side that only the verifier reads. The answer a finance lead expects is private; her reminder about the policy in Slack is public. A schema check cannot tell that an answer has been pasted into a message body, so authors read their own fixtures for leaks. A registry names the people and organizations in the world so that the same person in a Slack thread and a Linear ticket is recognizably one person. It holds identities only; channels, tickets and messages stay in their service fixtures.

​

What the agent sees during a run

The agent sees the challenge, the workspace, and the public side of each service. It cannot see private fixture state, expected answers, reference traces or verifier code, because those files are never mounted into the sandbox. This is enforced by file role rather than by detection after the fact.

​

Grading the world

For service tasks the verifier has two kinds of evidence: the final state of each service after the run, and the recorded calls with the arguments of every write. Final state answers ordinary questions, such as whether the message exists in the right channel or the issue is closed. The recorded calls answer questions about the exact action or its order. Droyd checks that the recording is authentic and consistent; only the author’s verifier decides whether the outcome was right.

​

Next steps

• Adding World Data is the step-by-step guide.
• Ownership NFTs explains who can see the private side after acceptance.