> ## 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. # Adding World Data > Give the agent files, a repository or simulated services to work in, while keeping the answers private. By the end of this page your task exposes the inputs you intend, keeps its scoring data private, and validates cleanly. You need a task folder from [Initialize Task](/tasks/initialize). World data is optional: a task whose inputs fit in `workspace/` needs nothing on this page beyond the first section. ## Files the agent can read Anything under `workspace/` is visible to the agent and counts as task input. For `expense-audit` that means the claims export and the policy document. Files the agent creates in the workspace during a run are its output, so you do not need to declare output filenames. Keep the answer key out of this folder; it belongs in the task package's private data. Workbooks are ordinary files here, up to 25 MiB each, ten per task and 100 MiB in total. Save a recalculated copy if your verifier reads cached formula values. ## A repository to change For `repo-python` and `repo-node` starters, author the checkout under `assets_src/repo/` and bundle it whenever it changes: ```bash theme={null} droyd task bundle --json ``` Bundling builds the repository asset and pins its base commit. The agent receives the checkout at `repo/`; hidden tests run against a fresh copy with the agent's changes applied. Give the repository a realistic history and a starting state that does not already pass the checks. Node dependencies are installed offline, so keep `package.json` and `package-lock.json` in the repository and vendor anything that needs a build step. ## Simulated services A task can declare simulated GitHub, Linear and Slack services. The agent uses the same tool calls it would against the real products: it can read issues, files, tickets and channels, 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 for the verifier. No real account is connected; the services are clones seeded from your fixtures. Generate a fixture, then replace the generated records with your task's world: ```bash theme={null} droyd task seed slack --json droyd task seed lint --json ``` Each fixture separates `public` records, which the agent sees through the service, from `private` state that only the verifier reads. For `expense-audit`, the finance lead's Slack reminder about the policy is public; the list of claims she expects to be flagged is private. A schema check cannot see an answer pasted into a message body, so read your own fixtures for leaks. Order matters. Records are replayed in the order you list them, one minute apart, so put issues in ascending number order and conversations in chronological order. ## Keep people consistent The registry in `seeds/world.json` names the people and organizations in your world. Give each real person one handle and use the same display name and email in every service so the linter can connect them: ```bash theme={null} droyd task world set-persona susan --name "Susan Vega" --email susan@acme.test --role "VP Finance" droyd task world set-org acme --name "Acme Corp" droyd task world validate --json ``` The registry does not duplicate channels, tickets or messages; those stay in their service fixtures. ## Grade the resulting world For service tasks, the verifier can inspect the final state of each service and the recorded calls. Prefer final state for ordinary success, such as the Slack message existing in the right channel or the Linear issue being closed, and use the recorded calls only when the exact action or its order matters. The platform verifies that the recording is authentic; only your verifier decides whether the outcome is right. ## Validate ```bash theme={null} droyd task seed lint --json droyd task world validate --json droyd task validate --json droyd task push -m "Add Slack world" --json ``` **Success:** validation passes, a debug run shows the agent reading the intended inputs, and the trajectory contains no private data. ## Next steps * [Submitting Tasks](/tasks/submitting) explains what happens once the task is ready. * Run `droyd task seed --help` and `droyd task world --help` for fixture and registry options. **In active development** Task authoring is in active development. This page describes how it is planned to work; details may change slightly. Service seeds must follow the pinned `*.tools.v1.json` schemas; unknown public fields, including private-looking ones such as `expectations`, are admission errors. Seed files are capped at 2 MiB; use repository assets for repository content. Slack writes are gated by channel `members` when the list is non-empty, so include `viewer_id`. The simulated GitHub `create_pull_request` records head, base and diff only; use a repository asset when the agent must edit or test code. World calls have a 30-second default deadline capped at 60 seconds, and a timeout does not mean a mutation can be retried safely. Use the `droyd_competitions.vf_adapter.world_queries` helpers (`final_state`, `service_events`, `precedes`) in the private verifier.