Docs · Build
Prepare your data
A request is two tables and a paragraph. Get these right and the rest is plumbing.
The request at a glance
Two tables and a paragraph. Rows travel as JSON records (as below) or base64 Parquet.
{
"menus": [
{"key": "A001", "menu": 0, "T": 0, "unit_cost": 15.5, "unit_price": 32.5, "qty": 1, "rank": 812},
{"key": "A001", "menu": 0, "T": 0, "unit_cost": 15.5, "unit_price": 32.5, "qty": 2, "rank": 812},
{"key": "B417", "menu": 112, "T": -12, "unit_cost": 9.1, "unit_price": 21.0, "qty": 4, "rank": 455, "profit": 18.4}
],
"sales": [
{"key": "B417", "T": -11, "qty": 3, "price": 21.0},
{"key": "B417", "T": -9, "qty": 1, "price": 18.0}
],
"market_type": {},
"business_description": "Small wholesale reseller buying supplier lots weekly. Net profit = sale price - purchase cost - 15% marketplace fee - $2.10 fulfilment per unit - $0.04 per unit per week of storage; unsold units are written off at week 12. Columns: rank = marketplace sales rank at offer time."
}Menus: every option, taken or not
One row per (key, quantity option) per decision moment. If you could have ordered 1, 2 or 5 units of an offer, that is three rows — the model chooses at most one of them.
| Column | Required | Meaning |
|---|---|---|
key | yes | Your id for the deal: SKU, lot, listing, load. Returned as-is. |
menu | yes | 0 = today's task. Any other id = one past decision moment. |
T | yes | 0 = now; negative = the past (weeks, days — any consistent unit). |
unit_cost, unit_price | yes | What a unit costs you and what it sells for. |
qty | yes | The order size this row offers. |
| features | strongly advised | Anything you would glance at before deciding: rank, velocity, margin, grade. More useful features, better plans. |
profit | history only | The realized profit where you know it. Blank on every T = 0 row — P34 never sees your future. |
historically_chosen | optional | 1 on the option your business actually took, when you have that record. |
Sales: the money tape
What the taken options actually sold for — real money, not list prices. P34 replays it through your economics to value the history.
| Column | Required | Meaning |
|---|---|---|
key | yes | Matches a key in the historical menus. |
T | yes | When the sale happened, on the same axis. Never after now. |
qty | yes | Units sold. |
price | send it | The realized price per unit. |
unit_holding_cost, unit_fee | optional | Storage per unit, and a per-position charge on ordered units. |
The business description
Under the default grounding this paragraph is executable input: it is compiled into the economics that value your history. Write:
- what the business does and how one deal makes or loses money;
- every fee and cost, as formulas — approximations are fine to start;
- the profit window and the write-off rule (when unsold stock is written off, and at what value);
- what each of your feature columns means.
Send it with each request, or save it once in the console's business profile and omit the field. Keep it word-for-word stable while your economics are unchanged: repeat fits then reuse the compiled code.
Checklist before an actual fit
- Today's menu carries the market's full flow of candidates — hundreds at least.
- History includes options with no known outcome; the service refuses a history where every option has one.
- Every T = 0 row has a blank
profit; every sale is dated at or before now. - At most 100,000 menu rows in total; trim whole old menus, never rows inside one.
/validatepasses and an input test ("mock": true) completes.
No history yet?
A history assembled from market research — past offers and what similar items sold for — is a first-class input. Start shallow, not narrow: fewer feature columns and a shorter history, but always the full current menu. Grow the data where accuracy pays for the compute.
Samples
p34-sample-request-v1.json (generated; for validation and input tests) · CSV, Excel and JSON samples with per-column notes.
Data format, rule by rule · Skill: prepare inputs · Skill: business economics