Green · worked pricing study

Find a defensible meal-box price.

This tutorial makes every input visible: the product respondents see, the people represented by the EDSL agents, the generated questions, the execution boundary, and the calculation behind the recommendation.

We will measure stated purchase intent for a weekly meal box at $20, $30, $40, and $50. Every respondent answers at every price. Green records the definition and builds native EDSL objects; EDSL or Humanize administers the reviewed survey.

1. Start with the decision

green init --type gabor-granger \
  --description "Pricing a weekly meal subscription for two-person households"
green next

{
  "phase": "definition-empty",
  "action": {
    "command": "green product describe product --description 'Product being priced'"
  }
}

The project description is study context. It is persisted and included in the generated question text; it is not a hidden prompt supplied later.

2. Say exactly what the product is

green product describe weekly_box \
  --description "A box delivered weekly with ingredients and recipes for three dinners, serving two people" \
  --unit USD

green price-point add 20 30 40 50
green product show
green price-point list
green validate

{
  "product": {
    "name": "weekly_box",
    "description": "A box delivered weekly with ingredients and recipes for three dinners, serving two people",
    "unit": "USD"
  },
  "price_points": [20.0, 30.0, 40.0, 50.0],
  "valid": true
}

The stable ID is weekly_box. Green renders it as “weekly box,” adds the full description and study context, and formats prices as dollars. The description is part of every fielded question.

3. Define respondents—Green does not invent them

An AgentList is an explicit sample definition. green agent add creates each record; field build merely translates those records into EDSL Agent objects. No demographic distribution, persona, or sample size is inferred.

green agent-list create panel

green agent add panel --id budget_parent \
  --persona "Budget-conscious parent comparing meal kits with grocery shopping" \
  --trait household=family --trait price_sensitivity=high

green agent add panel --id busy_couple \
  --persona "Dual-income couple paying for convenience on weeknights" \
  --trait household=couple --trait price_sensitivity=medium

green agent add panel --id experienced_user \
  --persona "Current meal-kit subscriber familiar with delivery quality and portions" \
  --trait meal_kit_experience=current

green agent add panel --id convenience_seeker \
  --persona "Time-constrained professional who rarely plans dinners in advance" \
  --trait convenience_orientation=high

green agent-list show panel

Agent(
  name="budget_parent",
  traits={
    "persona": "Budget-conscious parent comparing meal kits with grocery shopping",
    "household": "family",
    "price_sensitivity": "high",
    "green_respondent_id": "budget_parent"
  }
)

Four agents are useful for inspecting mechanics, not for making a market claim. A production synthetic study needs a justified sampling frame and substantially more respondents. A human study can use the same Survey without treating these personas as its sample.

4. Build native, inspectable EDSL packages

green field build --job-name pricing --agent-list panel

./survey.ep             # four QuestionMultipleChoice objects
./agent_list.ep         # the four explicit agents above
./jobs.ep               # Survey × AgentList
./question-map.json     # question IDs → numeric prices
./humanize-schema.json
./manifest.json         # hashes and exact handoff commands

These are git-backed EDSL objects, not generated Python. The Jobs package contains the Survey and AgentList but no answers and no secretly selected model.

field build writes public artifacts to the current directory by default and returns every exact path. To isolate them deliberately, pass an explicit directory such as --output-dir fielding/pricing; Green never invents a green_jobs/ location.

5. Inspect what will actually be asked

ep inspect jobs.ep
ep inspect agent_list.ep
ep surveys questions survey.ep

ep inspect jobs.ep
  length: 4 · question_count: 4 · agent_count: 4 · model_count: 0
  question_names: purchase_at_1 … purchase_at_4

ep inspect agent_list.ep
  agent_count: 4
  trait_keys: persona, household, price_sensitivity,
              meal_kit_experience, convenience_orientation
  sample: budget_parent, experienced_user, busy_couple

ep surveys questions survey.ep
  purchase_at_1 · multiple_choice
    Product: weekly box
    Description: A box delivered weekly with ingredients and recipes
                 for three dinners, serving two people
    Study context: Pricing a weekly meal subscription for two-person households

    Would you buy this product at a price of $20?
    Options: Yes, No

  purchase_at_2 … $30
  purchase_at_3 … $40
  purchase_at_4 … $50

This is the review point for product wording, price units, agents, and question count. If any of it is wrong, edit Green state and rebuild; do not compensate with an unrecorded execution-time prompt.

6. Calculate the fielding burden before execution

ep jobs cost jobs.ep --model gpt-5.4-mini
green plan field --job-name pricing

respondents          4
questions each       4
external model calls 16
requires approval    true
output               results.ep

7. Choose one administration path

For an approved synthetic-agent run:

# Only after explicit approval
ep run jobs.ep --model gpt-5.4-mini \
  --output results.ep

For human respondents, preview and create a Humanize survey from the same reviewed package:

ep humanize preview --survey survey.ep

ep humanize create --survey survey.ep \
  --schema humanize-schema.json \
  --name "Weekly meal-box pricing"

Synthetic path: EDSL models answer as the four explicit agents.
Humanize path:   Humans answer the same Survey in a web interface.
Common contract: Results are returned as results.ep and normalized by Green.

8. Import the returned Results package

green data import-edsl results.ep \
  --job-name pricing --name field_run_1
green data quality field_run_1

respondent_id,price,purchase
budget_parent,20,true
budget_parent,30,true
budget_parent,40,false
budget_parent,50,false

question-map.json converts purchase_at_1 back to numeric price 20. Agent names become respondent IDs, while personas and traits remain available as provenance.

9. Reproduce the analysis with observed example data

The repository includes a small observed-format fixture so the analysis can run without making model calls. These six IDs are not claimed to be the four illustrative agents above.

green data import-gg examples/gabor-granger/responses.csv --name meal_prices
green data quality meal_prices
green report gabor-granger meal_prices --threshold 0.5

price  n  raw intent  monotone intent  revenue index
$20    6    100.0%        100.0%          20.0
$30    6     83.3%         83.3%          25.0
$40    6     50.0%         50.0%          20.0
$50    6      0.0%          0.0%           0.0

Monotone intent is the cumulative minimum as price rises, preventing an upward demand step from driving the recommendation. The revenue index is price × monotone purchase intent; without population weights, costs, and calibration, it is a comparative screening measure rather than a revenue forecast.

10. Preserve the decision artifact

green report save --name pricing_decision \
  --kind gabor-granger --input meal_prices
green report list
green validate --require-report gabor-granger

Highest price at or above 50% intent  $40
Revenue-index maximum                 $30
Monotonicity violations                 0

Saved files:
  data.json    exact calculation and provenance
  report.md    readable table
  plot.svg     purchase-intent curve
  report.html  standalone decision report

The two prices answer different questions. $40 is the highest tested price retaining half the sample; $30 maximizes the simple revenue index. Neither should be generalized beyond the represented sample without uncertainty analysis and external validation.

The explicit data flow

product describe ─┐
price-point add ──┼─→ Green state ─→ survey.ep ─┐
agent add ────────┘                 agent_list.ep ├─→ jobs.ep
                                                   │
                         reviewed model run ────────┤
                         or Humanize fielding ──────┘
                                                   ↓
                                               results.ep
                                                   ↓
                                import → quality → curve → saved report

There is no hidden persona synthesis or execution-time product prompt. If an input is not visible in Green state, ep inspect, or ep surveys questions, it is not part of the administered study.