Docs · Get started
How P34 decides
What the model does with your request, in plain terms — and what it does not do.
The question it answers
Given the options in front of you right now, which should you take, at what size, and what profit should you expect from the set? A menu of candidate deals goes in; a sized plan comes out. P34 does not chat, write or search — your code or your agent does that. It supplies the economic decision.
Menus, history and the task
A request carries three things, and one paragraph:
| Part | What it is |
|---|---|
The task (menu = 0, T = 0) | Every option open to you now — one row per (deal, quantity). This is what P34 decides. |
Historical menus (T < 0) | The options you faced at past decision moments, including the ones nobody took, with the outcome where it is known. |
| Sales | The money tape: what the taken options actually sold for, and when. |
| Business description | How your unit economics work — fees, holding costs, write-offs — in plain words. |
P34 is pre-trained, so the history does not teach it markets from scratch. It calibrates the model to your market before it answers.
Why the deals you did not take matter
History is biased: outcomes exist only for the options a business chose, and those were never chosen at random. A model trained on them alone looks excellent in a backtest and then over-buys on the full menu it was never forced to refuse. P34 is trained on the whole menu, taken and untaken — so the service refuses a history in which every option has an outcome.
| Naive profit regressor | P34 | |
|---|---|---|
| Trains on | the deals that were taken | the whole menu, including declined options |
| Backtest | excellent (0.9266 AUC) | honest |
| Full future menu | −$417.4k realized | +$2,250 on $4,146 deployed |
| “Do nothing” | not in its vocabulary | a first-class output |
A synthetic market with known ground truth: a demonstration of the mechanism, not evidence of live-market profitability. Methodology in Research and the technical report.
Refusals are the product
Most rows of a result come back with qty = 0. That is the model working: in the markets P34 is built for, most candidate deals should be turned down, and finding the few worth taking among thousands is the hard part.
Grounding: your economics, compiled
By default a fit starts by grounding: P34 turns your business description into code that replays your history through your actual fees and costs, so every historical option gets the profit it would have earned. It takes minutes and is metered. When the next fit sends the same description and the same data schema, the compiled code is reused.
A plan, not a list of scores
P34 sizes the options jointly and calibrates the predicted profit as a sum over the plan (predicted_profit_sum). confidence_correction moves the selection toward fewer, surer picks or toward more of them, and each result includes a sweep showing what other settings would have selected.
Lifecycle of a request
POST /fit → {"session_id": "…", "status": "grounding"} seconds
GET /result/{id} grounding → queued → processing → done | failed minutesWhen P34 is the right tool
| Good fit | Not a fit |
|---|---|
| Menu-shaped decisions: many (item, quantity) options per decision moment | A handful of options you could score by hand |
| Hundreds to thousands of candidate deals per menu | Decisions needed in under a second |
| History, including the options with no outcome — or a research-built one | Trading regulated securities, derivatives or prediction markets |
| A measurable economic outcome: profit, margin, recovery | Signals or a dashboard instead of an executable plan |