DJ backend architecture

What's built (October 14)

DJ runs end to end on an isolated test system, with test cards and test sellers. Nothing is merged yet: it is a stack of draft pull requests (the work). It ships dark, to staff, over the air: no native change and no Face ID. The design further down is the original architecture; where it differs from this section, this section is what was built.

One card per plan. A plan bought in one purchase posts one receipt in the thread. A plan bought in parts posts nothing per part: its own card fills in place (“2 of 6 bought”), and each part is a row in the plan's activity, with its seller and a link to the order.

Sheets open complete. The approval sheet arrives with the draft: the show's art with ticket type, date and venue, the terms as rows, and one consent line. Approve works as soon as the box is ticked.

No backward compatibility. Nothing has shipped, so the DJ pull requests carry no compatibility code and no compatibility migrations. The server and the app deploy together, and the first merge is the first contract.

The capability layer. DJ reads the person's whole account (wallets on every platform, each listing's delivery state, each sale's next step) and the catalog (artists, venues, events, search), and answers with composed cards: artist and venue cards with one hero, details behind folds, and names that open CrowdVolt's pages.

Delivery in CrowdVolt's words. An order or a sale is one card: CrowdVolt's own status badge, one line on what is happening, the steps folded under it, and one button only when a step is the person's to do. An order or sale waiting on them takes the dock with that step. Each plan has its own page: the terms, what DJ bought or sold, and the activity, with the orders one tap down.

Evaluation results stay in the repository.

• The agent reads and drafts, never acts. A tool loop on one strong model every turn looks up the market and the user's own plans, answers questions, finds events, and drafts several plans at once. No tool can approve, charge, list or raise a limit, and every number it says has to come from a tool. It uses the kit, gives evidence-backed recommendations and distinguishes observed facts from inference. It never guarantees future prices.
• Approval is the only authority. An immutable consent row is hashed to the exact terms and text the user saw. The person ticks one consent line on a sheet the server rendered. The engine re-checks the consent in the same transaction that moves money.
• React after commit, never inside it. The 23 places that already feed the autopricer also emit a DJ signal, coalesced to each listing's latest state. A matcher per event picks it up. Target: listing to charge in under 5 s at p95; the budget below adds to 4.1 s.
• Buying waits smartly. DJ buys when a listing beats the expected cost of waiting, and that bar rises to the max as the deadline nears. Plans run until carting closes, past doors.
• No second path to money. DJ buys through calc_buy, cart_buy_order and buy_approved, the chain checkout uses, with an off-session charge on the card pinned at approval.
• Selling extends the autopricer. It adds two goals and pools DJ sellers so they never undercut each other. It matches the lowest early, leads by $1 in the last 6 h, anchors on recent sales when there's little to match, and sells to an offer within $1 or one that crosses.
• Ships dark. A kill switch row starts off. Breakers trip it on their own. Two weeks of shadow mode run before any real charge.

Four boundaries

Each layer can do one kind of thing. Nothing below a line can widen what the line above allowed.

What the evals changed

Backtests on past events, agent evals and a market simulation changed these decisions. Where they disagree with the first version of this design, the evals win, and the rest of this page already reflects them.

The system

Plan states

Every plan is one row with a state, a version and a revision. Pausing everything and the kill switch are not states. The API returns a computed effective_state, and the executor checks all three.

Approve: the only way authority is created

Buying: listing to charge in under 5 seconds

The hero case: Four Tet, Sat Oct 10. Max $80 each, all in. A $73 listing ($76 all in) appears Thu 11:48 PM. It beats the expected cost of waiting, so DJ buys it 3 seconds later.

When DJ buys: smart waiting

• Fitting the max isn't enough. DJ estimates how often listings arrive and at what prices from the event's last 24 h. It buys when a listing beats the expected cost of waiting for a better one.
• The bar rises to the max. As the deadline nears there's less time left to wait, so the bar climbs until anything under the max qualifies. The aim is the same chance of getting tickets at a lower price.
• Plans run until carting closes. A buy plan's deadline is doors_close_time, past doors, because people keep buying after doors open.
• Speed still matters. People cart a good listing soon after it appears, so the race is won at cart time. That's why the target is under 5 s from commit.

Latency budget, p95 from commit

• Fairness. First approved, first served. queue_at only moves when a version raises the max or the quantity. Public bids fill inside the seller's own calc_sell, so they win ties by construction.
• Fair share with people. While DJ's share of an event's waiting demand is low, there's no hold-off. Once DJ holds more than about a quarter of it, brand-new listings wait 30 to 60 s before DJ can take them, so people buying by hand still get a turn.
• Retries. Stripe timeouts retry twice with the same key. Anything stuck past 30 s goes to the reconciler, which gets the original intent back by key and finishes or releases. buy_approved is already idempotent on the intent.
• Bank checks. The app confirms the intent with the user present, then calls auth_complete. Doing it in that order avoids buy_approved cancelling intents that still need action (ms:3117).
• Exemptions. DJ carts skip the cart-hogger policy. The bank check at approval satisfies the forced check over $250 (sus_buyer_service.py:32).

Selling: a pool, not a race

The hero case: Jamie xx, Fri Oct 9. Listed at $110, 11th of 11. DJ moves it to $98, 1st of 11, which earns $93. The minimum is $80 earned, which means listing at $85.

Inside the spread

The seller wants to earn at least $80, which means listing at $85. The best offer is $78 and the lowest other listing is $90. Nothing can trade yet, because $78 earns $74.

• Early, match $90. Far from doors, DJ ties the lowest other listing instead of undercutting it, which keeps the seller's margin.
• In the last 6 h, lead by $1 at $89. That's when buyers arrive, so first in line is worth a dollar. It earns $84. Plans keep leading after doors, until carting closes.
• Keep $85 private. It's the floor, not the price.
• Anchor when there's little to match. With fewer than 3 other listings live, DJ prices at the median of the last 20 sales, capped at the lowest other listing. From 3 h after doors, it takes the best offer at or above the floor. Without an anchor, a book of mostly DJ sellers has nothing to price against.
• Take an offer within $1. Leading at $89, an offer at $88 earns $83, above the minimum, so it sells. An offer that crosses DJ's next price sells too. An offer is a committed buyer, which makes the sale faster and surer.
• Pull the other side up. The $78 bidders get the existing new-supply message that a listing is at $89. A DJ buyer whose max covers it gets it in seconds. That's how a spread becomes a trade.
• At last call, when carting closes, an offer of $85 or more sells. A lower one asks the seller: "An offer at $82 earns you $77, $3 under your minimum. Take it?" No offer ends the plan.

How often the price moves

Matching the lowest raises the price when cheaper listings sell and cuts it when a new one appears, so a listing can bounce up and down. Moves get a budget that loosens toward doors, and raises have to wait.

A raise is at most 10% a move. The wait runs from when the cheaper competition disappears. If a cheaper listing appears during it, there's no raise, which is what stops the bouncing. A buyer who arrives during the wait pays the current price.

• Selling to an offer. Within $1 of DJ's price, or crossing it. Lock the bid NOWAIT, re-check status, price, quantity and a capturable intent, then call calc_sell(use_bid_uqid=B) by name. Without the name it fills the cheapest qualifying bid (ms:4259). This ships after the core pricer.
• Last call is when carting closes, doors_close_time, unless the plan's own deadline is earlier. The heads-up goes out 30 min before.
• Ties. calc_buy breaks ties by created_at (ms:1570). Add ask.queue_at and sort by price then queue_at, there and on the event page.
• Scope today. The pricer only runs for house inventory: Drew's Hub, groups of up to 20, a DICE adapter. Consumer owners and other providers get added here.

Recommending limits

recommend_limits is engine code. The agent calls it and puts the answer into words. It never picks a number itself.

Market information: what DJ tells people

People ask "is this a good price", "where should I list", "will it drop". Answers should help a trade happen without teaching everyone to wait out the market, handing competitors CrowdVolt's data, or exposing anyone's limits. The tools enforce it. None returns per-sale rows or anyone's limits, so no card can show them.

• Share what helps a trade happen. Tell a seller exactly where to be first in line: "$98 puts you first. $110 is 11th of 11." Tell a buyer their own plan's odds, as facts. No event-wide forecasts like "prices usually fall into doors", because advice everyone follows stops trades.
• Never reveal private limits. No DJ maxes, minimums, or the shape of waiting DJ demand. A seller can see "About 10 buyers are watching", a rounded count, never at what prices.
• Round, range and lag. "About 20 listed", "Sold today: 30+". Exact counts and sale-by-sale history stay internal.
• Personal, never a dataset. Stats come as answers to one person's plan in the thread, never through an open market-data API. The market tools share the 20 messages per 5 min budget, so scraping the book through DJ is slow and useless.
• Where the lowest has been, instead of a verdict. Each recent day's low to high, like Weather's 10-day rows, plus the plan's odds as facts, and DJ catches the dip. Verdicts like Low or Typical didn't predict whether a better price came later.
• Measure, and pull what hurts. Each new kind of answer ships behind a flag with a holdout. If it lowers sell-through, pushes purchases into the last hour, or raises lowball maxes, it's turned off.

The agent: a tool loop that can't move money

GPT-6 Luna on the Responses API, built on the ops_copilot loop. It can look things up, answer questions, find events and handle several asks in one turn. The safety line isn't "no tools". It's that no tool can approve, charge, list or raise a limit.

Cards: designed first, composed as the fallback

Answer small, reveal on tap. The message gives the answer with enough detail to make the decision. The card holds only what you act on: one row with the price and a short note, and one or two buttons. History and options open inside the card on tap. Every common question has a designed card; the agent composes from the same kit only when none fits.

• Numbers are references. A series block binds to a series a tool returned, so the agent chooses what to show but can't supply data. The server writes the notes, pill hints and button labels.
• Two buttons at most, from a whitelist. Open checkout, draft a plan from a recommend_limits option, open the edit sheet, open an event. None of them moves money.
• Chips are prompts. Tapping one posts its text as the person's message. Anything that goes somewhere is a button or a tappable row for a typed entity, and the app routes it. No free-form links.
• Checked before sending. Known blocks only, five at most, references that resolve with the right type. A failing card gets one regenerate with the errors, then the designed card for its intent. The message itself is guided by the prompt, never gated for style; only its numbers are checked.
• Old app versions. The client sends its kit version. A block it doesn't know falls back to the text answer and the nearest older block.

Suggestions

A suggestion is DJ starting the conversation: a plan the user didn't ask for, built from something they did on purpose. "Four Tet dropped to $78. It's in your Likes. Want me to get 2 under $80?". Reasons come only from Likes, alerts, orders and offers, never views or searches, and never with a date.

• The cap adapts. It starts at 1 a day and 3 a week. Two accepted suggestions add one a week, up to 5. Two ignored in a row pause them for 14 days. Three "Not now" on an artist mutes it.
• Why cap at all. Every unasked message spends trust. A user who mutes DJ also loses the messages they asked for. And CrowdVolt's other marketing shares the budget, through MarketingFrequencyService.
• Score is weight × fillable × 2^(−age_h / 12). The suggested price is always the user's own number (their alert or offer) or the current lowest.
• No double sends. DJ registers as an OfferProvider, so a suggestion or plan holds back the generic offer-rescue and new-supply sends for 72 h.
• Wallets only with the opt-in asked once, after the wallet-link copy and privacy policy say so.

Discovery: what should I do tonight

DJ can also find events. "Something melodic tonight under $60", "what's good this weekend", "I liked Four Tet, what else". It rides on the recs stack py-mkt already has. Buying and selling mostly move existing demand around, so discovery is where new demand comes from, in nights people wouldn't have found otherwise.

• Reasons only from explicit actions. Never from views or searches, and nothing guessed about the person.
• Wallet history stays out of discovery's reasons and ranking until resold events are stripped from it and product and legal sign off on consent.
• Measured from day one. Every pick is logged with stable item ids through tap and purchase, and judged against the "More for you" blend and plain popularity. The offline test asks discover as a real past buyer, at a time before their purchase, and checks whether the event they bought lands in the top 5.

Data

All tables live in tktx.*, with prefixed uqid keys, money in *_cents, and _history tables. Append-only tables reject UPDATE and DELETE with a trigger.

API and realtime

Every lookup is scoped WHERE uqid = ? AND user_uqid = ?. A mismatch is a 404. Behind the backend flag dj-agent.

Live Activities: only for deadlines

A plan can run for days, and a Live Activity is capped at 8 h and meant for something with a clear end. So the Dynamic Island shows DJ in four moments, one activity at a time, most urgent first.

• Nothing spends from the island. Buttons are crowdvolt:// deep links into the edit sheet or checkout. No App Intents touch money.
• Native side. An ActivityKit widget target via expo-widgets. Countdowns use a system timer, so they tick without pushes.
• Server side. Expo push can't send Live Activity pushes, so py-mkt sends straight to APNs. It keeps each activity's push token and a push-to-start token, because moments 2 and 3 open while the app is closed. Older iOS gets the normal push instead.
• Only real changes update it. The lowest crosses a band, first place changes, the best offer changes, or there's a result. Low priority unless there's a countdown the user must act on.
• One switch in DJ settings, on by default for people with push on. Android gets an ongoing notification for bank checks only.

Guardrails

A kill switch, per-person and per-event spending limits, price-impact pauses and circuit breakers guard every automated buy and sale. The exact thresholds stay in the repository.

Fix first

Backend issues found while mapping DJ are tracked in the repository.

Build order

One team, about 10 weeks to beta and 12 through it. Each phase has an exit test, and nothing charges a card until shadow mode passes.

Still open

1. The visible offer under the max. Off by default. Where it sits: recent fills, or a percentage under the max.
2. DJ buyer with DJ seller. Crossing them at a price inside both limits needs consent wording on both sides and a legal read.
3. Spend caps above, to confirm with risk.
4. Executor placement. If the worker hop blows the 950 ms headroom, run the executor inside the matcher.
5. Suggestion cap. The starting numbers are guesses. Tune them against a holdout.

Settled since the first version: selling to an offer within $1 of DJ's price (Sep 28), no hold-off on new listings until DJ holds about a quarter of an event's waiting demand (Sep 28), one sheet per side (Sep 29), a visible DJ offer charged off-session when a seller accepts it, with no hold (Sep 29), pricing above the seller's own price only as a lift shown on the approval, never after it (Sep 29), and what happens at doors: bids are cancelled when doors open, so the seller chooses between keeping the listing up until last call (the default) or taking the best offer just before doors (Sep 29).