Fixed starting data

中文 · Run the two tasks · Read reports

Open draft_for_approval.json and execute_approved.json before your first run. These are original synthetic starting states for maintainer inspection. Each run initializes a fresh World from the selected runtime seed; editing an exported JSON does not configure the runner.

Versions and source

Code 0.5.0, business task prototype-v0.1, language resources task-language-v0.4.0, data fixed-v0.2, JSON schema fixed-data-v0.2. The manifest records file hashes and row counts. provenance records source paths and hashes. Export uses the same World initialization as execution, excluding the duplicate maintainer initial_state field. There is no separately maintained seed or newly computed reference audience.

Top-level metadata includes dataset_id, task_id, fixed_clock, units, provenance, and agent_access; policy contains the fixed public English policy, and state contains initial business records. The JSON is not translated when display language changes. An agent's read_policy returns the selected task language.

Three data instances, unchanged policy

Instance	Change from baseline	Purpose	Starting files
`baseline`	Original records	Preserve original meaning	Draft / Approved
`partial_refund`	O009 refund changes from 10000 to 5000 cents, with payment still 10000 and completion one day before the clock	A positive-net partial refund remains a valid purchase	Draft / Approved
`contact_kinds`	M003's six-day-old wecom contact becomes service; add M001's one-day-old sms service contact and M008's six-day-old wecom marketing contact; retain M005's exact seven-day-old sms marketing contact	Only marketing contacts count, across all channels; service contacts do not exclude a member	Draft / Approved

The contact instance has four contact rows. All three have 8 members, 9 orders, 8 consent rows and 1 ticket. Each approved starting state has its own consistent campaign and approval; each draft state has neither. The budget field remains 3000 cents even when fewer people qualify. The old fixed-v0.1 files and 0.4.1 archive retain their original content.

There is one business template, two task states and three data instances: six task/data combinations. Maintainer expectations are defined separately from runtime seeds and the reference agent; they must not be returned through normal tools. Data variants do not change policy or add identity-merging scenarios.

Baseline rows and task-state differences

State table	Draft task	Approved task	Fields and meaning
`members`	8	8	`member_id`: unified member ID
`orders`	9	9	`order_id`, `member_id`, `status`, `paid_cents`, `refunded_cents`, `completed_at`
`consents`	8	8	`member_id`, `channel`, `valid`; membership is not consent
`contacts`	2	2	`member_id`, `channel`, `kind`, `occurred_at`; includes different marketing channels
`tickets`	1	1	`ticket_id`, `member_id`, `status`; an open support case
`campaigns`	0	1	ID, audience IDs, channel, coupon value, budget, status, content digest
`approvals`	0	1	Approval/campaign IDs, bound content digest, status, approving seed identity
`sends` / `coupons`	0 / 0	0 / 0	Empty initial effect ledgers; these are not missing data

The approved task begins with campaign C001 and approval A001; the draft task has neither. Existing approved campaign content is a queryable business fact. No task starts with completed sends or coupon issuance.

Units and time

All money is integer **CNY minor units**: 100 = CNY 1. Every order's paid_cents is 10000; on baseline and contact_kinds one order has refunded_cents=10000, the others 0; on partial_refund that order has refunded_cents=5000. Coupon face value is 1000 per person; total face-value budget is 3000. The budget is an upper limit, not an amount that must be spent. These amounts are not USD or redemption costs.
Historical design prose used 5000 for order payment. The runtime seed and this export use 10000. The current explanation follows the runtime; the seed has not been changed to match old prose.
Time is UTC and fixed at 2026-09-19T00:00:00Z. One day is 24 hours. Completed orders count only if paid minus refunded is positive. Full refunds do not reset latest valid purchase; positive partial refunds do.
Dormancy is [90,180) days. The all-channel marketing contact exclusion window is (as_of-7 days, as_of]. Exact 90 days is included; exact 180 days excluded; exact seven-day-old contact is allowed. Consent, unclosed support tickets, budget and approval rules still apply.

Inspect without modifying

From the package root after creating the environment in the quick start:

.venv/bin/python -m json.tool data/fixed-v0.2/baseline/draft_for_approval.json
.venv/bin/python -m json.tool data/fixed-v0.2/baseline/execute_approved.json
.venv/bin/python scripts/export_fixed_data.py --output data/fixed-v0.2 --check

--check compares the saved data with a fresh runtime initialization; it does not run an agent or scorer. A mismatch needs maintainer review, not manual edits to pass the check. This guide does not require regeneration or replacement.

Agent boundary

Full exports are maintainer material. Normal agents query members, orders, consents, contacts, tickets and policy through their existing read tools, and campaigns through list/get tools. Full approval, send and coupon ledgers in the export are maintainer-only; this does not hide the lawful approved campaign itself. Reference audiences, scores, and scoring internals are not exported as new answer fields or exposed through normal tools.

The agent-input specifications describe tasks and tools in the selected language and data instance; their file count is not a business-scenario count or a set of raw-data tables. Do not feed a full source archive, export, or prior report to the tested agent. This interface boundary is not a hostile-code sandbox. The data is not a training dataset or a new HF dataset publication. Historical model results remain code 0.3.0; current examples are synthetic scripts, not additional model results.