> ## Documentation Index
> Fetch the complete documentation index at: https://docs.droyd.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# World Data

> Files, repositories and simulated services an agent can work with, and how the private side of a task stays private.

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](/tasks/world-data) is the step-by-step guide.
* [Ownership NFTs](/core-concepts/tasks/ownership-nfts) explains who can see the private side after acceptance.

<Note>
  **In active development**

  Task authoring is in active development. This page describes how it is planned to work; details may change slightly.
</Note>