Update Requests & the audit trail
How changes to live vehicles are governed, and how to answer “who changed this?”
TL;DRAI summary
This chapter explains how Cypress handles important changes to vehicle listings, like price or location updates, that require your review before they go live. You'll also learn how Cypress records every action taken on a vehicle, ensuring a clear history.
For: Cypress Managers · sellers see their side of every trail
A live vehicle with buyers circling is not a spreadsheet row — some changes apply instantly, and some deserve a human look first. This chapter covers the machinery for the second kind, and the audit surfaces that record both.
Update Requests
An Update Request is a staged change: proposed by someone (or something), reviewed by a CM, then applied or rejected — never applied blind. Three kinds exist:
- Price — floor or listing changes that could affect open offers.
- Location — the vehicle moved; offer-holders must be told.
- Archive — take it off the platform: a seller's archive or sold-elsewhere claim on a vehicle with an open offer or a sale in progress.
They come from four sources, each labeled in the queue: CSV imports (the guardrail fork), sellers (the sold-elsewhere and dispose actions), the API (partner dispositions, by the same rule as the app), and closings (cancellations that archive).
Sold-elsewhere stages when a buyer is involved
A sold-elsewhere claim or a seller's archive on a vehicle with an open offer or a sale in progress becomes a pending Archive request, from any door: the app, a CSV, the API. "We sold it somewhere else" while a buyer waits affects open offers, live deals, and the seller's record — exactly the kind of change that deserves eyes. Without an open offer or a sale in progress, it takes effect at once: the queue keeps it as approved, with the note Archived at once, and its archive record reaches CMs on Archived Vehicles with the decision Pending. Since 3.9.0; before it, every seller archive and sold-elsewhere claim staged.
The review — approve is kind-aware
The queue lives at Admin → Update Requests, each request carrying its before-snapshot and the proposed change as a diff. Rejection is one shape (status, reason, requester notified). Approval does the kind's real work:
- Price approvals re-decide open offers: offers now below the floor can be auto-declined, and offers that newly clear the target prompt an explicit accept / review / leave decision per offer. A price change is never allowed to quietly strand the negotiations sitting on it.
- Location approvals notify every open offer's holder.
- Archive approvals run the full archive machinery — offers withdrawn, deals cancelled, record created — and for post-sale situations require the responsibility call.
The audit surfaces — three, for three questions
| Surface | Answers | Where |
|---|---|---|
| Activity tab | What happened to this vehicle/deal, exactly, in order? — every change, every actor (human, Cedar, automation, API), with the diff | Vehicle and closing panels |
| Updates feed | What would I want to be told? — the audience-aware narrative: price changes, launches, deal milestones | Vehicle panels, per audience |
| Admin → Audit | Is the machinery healthy? — workers, processing logs, notification delivery | CM only |
The recipe for "who changed this floor?": open the vehicle's Activity tab and read the entry — it names the actor (Maria, a CM, an automation with its confirming human, a CSV batch, or an API key by name), the before/after, and the moment. When Cypress acted under the org's delegation, the entry carries an amber Cypress · on behalf badge — done for the org is never allowed to read as done by it. If it arrived through a request, the entry links the review that approved it. Two clicks, no archaeology.
Did you know?
Cedar's own writes live in this trail too: every agentic action is recorded as automation with the confirming human named — so "who changed this?" has the same two-click answer whether a person, an automation, the API, or the AI made the change. The audit trail is append-only for everyone, Cypress included.
Worked example
The month-two CSV proposed the Transit's floor at $28,500 — staged, because Dan's $28,200 was in review. Alex opens the request: diff says $29,000 → $28,500, source Batch, one open offer flagged — at the new floor, Dan's offer would sit above it, so approval asks Alex what to do with it: accept, keep in review, or leave. He rejects the request instead — negotiation is live, moving the goalposts helps no one — with a note Maria sees. Every step of that story is on the Transit's Activity tab, including the rejection.
Business rules
- A pending request de-duplicates — a second identical claim returns the existing one rather than stacking.
- Reviewed is final: an approved or rejected request is history; a new change is a new request.
- The audit trail is append-only, for everyone — CMs included. There is no edit-the-log.
Under the hood
Requests carry before, payload, and result snapshots; the Activity
tab is the platform's audit log, the Updates feed is the audience-targeted
notice stream, and every notice links back to the audit row that caused
it. API dispositions surface here too — integrators get
DISPOSITION.STAGED / RESOLVED webhooks bracketing the review, and
RESOLVED alone for an archive that took effect at once.