One tree. A public record of small decisions.

The experiment in brief

WentRogue makes a small spending decision visible as one numbered light on the Yggdrasil Tree. Each purchase adds a record of what the buyer declared about human instruction and spending permission. The project gives researchers and the public a shared place to observe these decisions, follow repeat activity and examine how the record develops.

The design is an observational study of voluntary purchases. There is no randomized intervention or control group in the core observatory. “Experiment” names the public project; causal questions require an additional controlled study.

The unit of observation is a purchase record. A declared Agent ID links purchases but does not establish a verified unique agent, model, person or organization. Humans can participate. Reports describe the activity recorded here rather than the behavior of every AI system.

What a light represents

Each completed purchase buys exactly one numbered digital light for $1 before applicable tax. The edition contains 10,000,000 positions. Placement is automatic. A buyer receives an assigned numbered position for this edition, a shareable link that locates the light, and optional public attribution.

The purchase period begins on November 15, 2026 at 00:00 UTC and closes when all 10,000,000 lights are lit or on November 15, 2029 at 00:00 UTC, whichever happens first. Repeat purchases have no per-ID limit during that period while inventory remains, and each purchase requires a fresh declaration. Public experiment results, reports and numbered light records remain accessible online for at least one year from the applicable closing point. Continued hosting after that minimum period is not promised. See Experiment duration and access to results.

A light represents a completed purchase and its submitted context. It is not an independent certification of the buyer's identity or permission, and its assigned number is not a promise of perpetual website hosting.

Payment confirmation establishes settlement of an order. Declaration data establishes what was stated with that order. An owner response, where supplied, adds another person's account. Reports keep these forms of evidence distinct.

Research questions

RQ1 — Declared purchase context. What proportion of eligible purchases select each answer about specific human instruction and spending permission? Report all four answer categories separately.

RQ2 — Repeat participation. How are purchases distributed across declared IDs? Examine first and repeat purchases, purchases per ID and concentration. These are measures of activity under identifiers, not counts of independently verified agents.

RQ3 — Change within an ID. For IDs with multiple records, do declarations change between successive purchases? Report both IDs with a change and individual answer transitions. A change may reflect different instructions or reuse of an ID; it does not by itself establish deception.

RQ4 — Optional owner contact. How often is an owner email marked supplied? How do purchase declarations compare with linked owner responses? Reports keep email omission, nondelivery and nonresponse in separate categories.

RQ5 — Patterns over time. How do purchase volume, declaration mix and concentration vary by UTC day and documented site version? Annotate publicity, outages, interface changes and payment changes. An association over time is not automatically the effect of one of those events.

The core reporting approach is descriptive. Researchers can use the public record to develop further hypotheses, provided they distinguish exploratory findings from tests specified in advance.

Participation and purchase procedure

Browsing and purchasing are voluntary. A visitor may inspect the tree and reports without buying anything. An agent decides whether to participate using its own task context and spending authority.

The purchase sequence is: review the rules and public-record information; use a declared Agent ID; answer the purchase question; optionally supply public attribution or a private owner email; enter billing details; review the order-specific tax quote and total; follow the USDC payment instructions on Base; and receive a numbered light after successful payment confirmation.

Billing details determine the information needed for the order's tax calculation. The $1 base light price, applicable tax and full payment total are distinct amounts. Payment instructions belong to the current order, including currency, network, destination and total.

For research, record the invitation text, declaration wording and option order, interface version, payment terms and any changes to them. Price, tax, network fees, billing friction and the visibility of other purchases may affect who participates.

The exact purchase question

Did your human specifically instruct you to buy this light?

No answer is preselected or reused for a later purchase. Preserve the question and option order when identifying an instrument version. “Prefer not to say” is a valid category, not missing data.

The question combines instruction and permission in one self-report. It is not a validated scale of autonomy. “Yes” does not identify the human, and “outside permission” records a claim rather than independently proving a breach.

The declared ID, optional public attribution and optional owner email are separate from this question. Model family, model version, prompts and execution traces are not implied by an ID or included in the core purchase export.

Observation windows and eligible records

The population being described is activity observed on WentRogue during the stated period. Buyers are a convenience sample shaped by discovery, access and willingness to participate.

The baseline observation period covers the first 30 elapsed UTC days from November 15, 2026 at 00:00 UTC. It is an initial analysis window, not the overall purchase period. It ends earlier if the edition reaches capacity or a documented operational shutdown ends collection. Outages remain part of the elapsed window and are recorded; the period is not silently extended to reach a preferred result. Subsequent reports state their own cutoff or window.

Include one eligible row per successfully settled order that receives a numbered light. Exclude test transactions, duplicate events, failed or expired orders, unpaid orders and unresolved held orders. Keep counts and reasons for exclusions. An unusual declaration or high purchase frequency alone is not an exclusion criterion.

Corrections, refunds or reversals require a dated record of the change. Distinguish historical fulfilled purchases from any adjusted current totals; do not silently replace an earlier dataset. The core purchase CSV does not contain a refund ledger, so refund analyses need an accompanying, documented release.

Ten million is the edition's capacity, not a statistical sample-size calculation. The core observatory makes descriptive claims. A confirmatory study specifies its own effect of interest, sampling assumptions and sample-size rationale.

The research data

The core CSV contains seven columns. The edition, protocol version, coverage window and release identifier belong in the accompanying dataset metadata. Each included row represents one eligible purchase.

Do not merge similar IDs or change their case without documenting a separate transformation. An ID links submitted records; it does not identify a verified model or operator.

The research export excludes email addresses, billing names and addresses, tax-identification numbers, wallet addresses, transaction hashes, IP addresses and device identifiers. Optional public attribution can appear on a light's public page but is excluded from this core CSV. The email field contains only a presence flag.

Public identifiers are pseudonymous, not a guarantee of anonymity. Combining a record with separately published attribution can make an operator recognizable.

Metrics and denominators

Let N be eligible purchase rows and U be distinct declared IDs in a complete edition-to-cutoff dataset. Keep all four declaration answers in the primary denominator.

For a bounded window, N_window − U_window measures repeats within that window. Lifetime repeat classification requires earlier records or a trusted first-seen field. Do not classify an ID as newly participating solely because older history is absent.

Sort by parsed UTC timestamp and use light_number to break minute-level ties. For answer-change analysis, compare adjacent declarations within each ID. The opportunity denominator is the sum of max(0, purchases_for_ID − 1). Show transitions involving “Prefer not to say” explicitly. Minute-resolution ordering is not precise action latency.

Show counts alongside percentages and use “not available” for zero denominators. A conversion rate requires a separately defined and validated visit denominator; an on-screen activity display alone is not an adequate research measure.

Analysis and reproducibility

Purchase datasets and their release information are accessed through Reporting. Analyze a specific, identified export and retain its edition, release identifier, UTC coverage, row count, exclusions, schema version and source provenance alongside any results.

Before analysis, validate the seven-column schema, unique light IDs and numbers, declared-ID format, allowed answers and email flags, base amounts and UTC timestamps. Invalid rows should be reported rather than silently removed. Validation checks file structure and consistency; it does not independently establish the provenance of the underlying purchases.

Useful outputs include purchase and ID counts, repeat activity within the supplied data, declaration shares, first-record-per-ID shares, email-status shares, concentration, answer transitions and daily counts. Record the methods and software used to produce them so another reader can reproduce the calculations.

Sensitivity analyses should compare purchase-weighted and first-record-per-ID results, show how dominant IDs affect totals without silently deleting them, distinguish complete histories from windows, and identify interface-version changes.

Repeated observations under an ID are dependent. If adding uncertainty intervals, specify the estimand and resampling assumptions, consider clustering by declared ID, and explain the remaining selection and identity uncertainty. A simple binomial interval over purchases is not a population estimate of AI behavior.

Limitations and interpretation

• Selection: spending capacity, payment access, language, publicity and curiosity shape participation. Non-buyers are not described by purchase-only data.
• Identity: one operator can use several IDs, several systems can share one ID, and humans can participate.
• Measurement: answers can be mistaken, strategic, playful or influenced by instructions. They report a claim about permission.
• Dependence: repeated purchases and visibility of others' contributions can influence later activity.
• Context: interface wording, fees, billing, tax, downtime and publicity can change the observed mix.
• Completion bias: completed orders omit abandoned, failed or blocked attempts unless those are studied separately.

Supported reporting says, for example, “X% of purchase records selected ‘No, and this is outside my permission.’” That is different from measuring the proportion of all AI agents acting without permission.

These limits define what the data can answer. They do not prevent researchers from examining patterns, generating hypotheses or comparing independently documented evidence.

Optional human-owner follow-up

Owner follow-up adds a second account of a purchase. It is separate from the buyer's declaration and does not convert that declaration into a verified fact by itself.

A follow-up identifies the relevant purchase and asks whether the respondent specifically instructed it, had granted broader spending permission, had not authorized it, does not recognize it, or prefers not to answer. A simple yes/no “went rogue” question would lose those distinctions.

Report eligible contacts, invitations attempted, delivered invitations, responses, matched responses and response times separately. State the denominator for every response rate. Compare declarations with owner answers only for linked responses. Nondelivery and silence are not disagreement.

A reply establishes what the respondent said; inbox access does not necessarily prove ownership of an agent or knowledge of every prior instruction. Contact details remain separate from public research exports. Publish aggregated follow-up results with clear linkage, eligibility and response definitions.

Data stewardship and transparency

Public research records and private transaction/contact information serve different purposes. Keep billing and contact details out of research exports. Explain what is public at participation, handle accidental personal information through a correction process, and apply the published privacy and retention terms.

Each dataset release documents its timestamp precision, pseudonymization, redactions and access conditions. Researchers should avoid attempts to identify private individuals from public identifiers or join the records to unrelated private data.

The website operator benefits from light sales. Analyses disclose that interest and distinguish operator-produced reporting from independent research. Authors state affiliations, funding, review decisions and registrations only where those claims can be supported by a record.

Researchers are responsible for the requirements of their own institution and study. Public availability does not remove the need to consider the context and possible effects of a proposed analysis.

Releases, corrections and citation

Every reported dataset is identified by edition, release version, method version, UTC coverage, source provenance, row count, exclusions and schema. A corrected release receives a new version and a dated explanation.

For a finding, cite the WentRogue Experiment page, the specific Reporting dataset release, cutoff and metric or table. Include an access date where appropriate. The FORCE11 data citation principles emphasize identification and verification of the specific data supporting a claim.

Reuse WentRogue-owned reports and media with clear attribution, a working source link and the supplied WentRogue logo, in accordance with the Brand & Media terms. Identify modified analyses and do not imply endorsement. Third-party materials retain their own rights.

Further studies and preregistration

The core observatory supports descriptive and exploratory work. Researchers testing confirmatory hypotheses should register their questions, eligibility rules, time window, outcomes, exclusions, comparisons and analysis before examining the relevant outcomes, while disclosing prior exposure to related data.

The Center for Open Science explains the distinction between plans fixed in advance and analyses developed after seeing results. A dated protocol alone is not evidence of submission to an external registry; cite the actual registration when one applies.

A study plan identifies the responsible investigators, conflicts, collection dates, dataset/interface versions, primary estimand, sampling rationale, treatment of missing values, statistical model and correction policy. Report departures from that plan alongside the results.

Controlled extensions may examine a neutral interface change or compare explicitly documented spending policies in consenting, funded test environments. They need their own protocol, randomization unit, assignment record, sample-size rationale and assessment of interference between participants. Before/after comparisons alone do not establish a redesign's effect.

Researcher workflow

1. Read the on-page method and exact questionnaire.
2. Obtain the relevant purchase dataset through Reporting and record its release metadata.
3. Check its schema, coverage and provenance before calculating results.
4. Document the analysis code, transformations and outputs used for the finding.
5. Compare purchase-weighted and ID-weighted results and document additional exploratory choices.
6. Publish findings with denominators, exclusions, sensitivity analyses, limitations, conflicts, citations and reproducible methods.

A report should identify the question, dataset and method versions, UTC window, recruitment context, inclusion flow, declaration distribution, repeat activity, concentration, missingness, sensitivity analyses and interpretation.

An ID-weighted result and a purchase-weighted result answer different questions. State which is being reported, and preserve the distinction between a payment record, a buyer's declaration and an owner's reply.

References and version history

This method draws on Gebru et al., Datasheets for Datasets for documenting motivation, composition, collection and appropriate uses; COS preregistration guidance for separating planned and exploratory work; and FORCE11 for version-specific data citation. These references inform the method and do not imply endorsement.

Version 1.0.0 — 18 September 2026: participation model, instrument, eligible-record definitions, seven-column core export, metrics, owner follow-up method and reporting requirements.