RevenuePilotby Foxes TechnologyMost pricing tools ask you to trust the automation on day one. RevenuePilot starts read-only and moves a workspace up the ladder only when evidence, approvals and connector certification support the next stage.
Every workspace starts at the bottom. Moving up is a decision supported by recorded evidence, not a setting that can be flipped on the first afternoon.
The workspace reads. Products, options, departures, bookings, cancellations, costs and commissions are reconciled from the connected source, and data-quality gaps are surfaced rather than filled in. Nothing is written anywhere.
The engine produces real recommendations against real data and records them with their receipts. Nothing reaches a price. This is the stage that accumulates the evidence a later decision to execute has to rest on.
Recommendations become actionable, and a person approves each one. Guardrails are re-checked at execution time, the write is version-fenced and read back, and the outcome is sealed into a receipt.
Approved decision types run inside the same guardrails without a per-change approval. It requires connector certification, completed qualification and explicit approvals, stays bounded by the same caps, and remains reversible.
The requirements are the same for every workspace, and elapsed-time requirements cannot be compressed by generating more activity.
| Stage | What runs | Required to advance |
|---|---|---|
| Observe | Reconciliation and data-health reporting | A reconciled source with mappings reviewed |
| Shadow | Recommendations recorded, never applied | 14 consecutive shadow days and at least 20 eligible recommendations |
| Assist | Per-change operator approval before execution | Owner-approved costs and mappings, plus a certified connector |
| Autopilot | Approved decision types inside the same guardrails | A restricted one-tour canary with signed acceptance |
Qualification exists so the first real write is boring. Each requirement below removes a specific way an automated pricing rollout goes wrong.
The clock runs on calendar days against live data, so the record covers real demand patterns rather than a burst of generated activity. Fixture-generated dates do not count toward it.
Automated pricing on unverified economics is how a system optimizes revenue while eroding contribution. The variable costs and product mappings behind the decisions must be approved by the workspace owner before execution is considered.
The first live writes are confined to a single approved tour under the full guardrail set, with verification after every change. The canary is accepted, extended or rolled back on the evidence it produces.
The interesting question about an automation system is not how it runs. It is what happens the moment you want it to stop.
Five roles, allow-listed permissions, and a TOTP step-up in front of high-impact actions. Hiding a control in the interface is not treated as authorization.
| Role | Typical scope | Step-up on high-impact actions |
|---|---|---|
| Owner | Workspace lifecycle, billing, exports, execution controls | TOTP required |
| Admin | Configuration, connectors, team and policy settings | TOTP required |
| Revenue manager | Reviews and acts on the decision queue | TOTP required |
| Analyst | Reads decisions, evidence and reporting | Not applicable |
| Viewer | Read-only visibility | Not applicable |
These are configuration, not model behavior, and they are evaluated again at execution rather than only when the recommendation was produced.
A minimum confidence of 85 and a maximum movement of 5% per change. A proposal that breaks either constraint is rejected rather than clipped and shipped.
At least 24 hours before the same product can change again, and at most 10 writes per day. Bounded exposure matters more than reaction speed.
Your absolute commercial corridor is enforced before a proposal is made and again before it is applied, so no path exists to a price outside it.
The write is fenced against the version it was calculated from, and refuses to overwrite a price that changed underneath it.
The applied value is confirmed against both the machine read and the public quote. A mismatch triggers version-fenced rollback.
Every write is keyed so a retry cannot apply the same change twice, and each attempt produces a downloadable receipt attributable to an actor.
Yes. Shadow is a legitimate long-term operating mode. The recommendations, receipts and evidence trail are the same ones execution would use, so a workspace can run the review discipline without ever enabling a write.
No. External price writes are disabled by default and live price execution is currently disabled globally. Autopilot requires connector certification, completed qualification and explicit approvals, and it stays inside the same guardrails when it does run.
Dual kill switches disable execution, and rollback remains available even when normal writes are switched off, so an already-applied change can still be verified or reversed. A failed rollback locks organization writes instead of proceeding.
No. Revenue Copilot is advisory. It cannot create an executable signal, change a guardrail or trigger a write, and it has no route to alter the automation stage or any approval.
Observe and Shadow require no price writes at all, and they produce the evidence any later decision about automation should be based on.