A model can take part in a price without owning it. Our method: map the live logic, write the bounds first, run the model in shadow, and switch one decision class at a time.
A pricing flow is a poor place for improvisation. In our view, the rule that decides what a customer pays was often written years ago, by people who have left. Putting a model into that flow is an engineering problem with a governance problem attached.
This is how we do it, step by step, with who decides at each stage and what we refuse to do. One clarification first. In our practice, the AI can set a price, but only within bounds that people on your side define, and it has to say why. It never sets its own limits.
Step 1: We start with the decision, not the model
The first conversation is with our founder, not a sales team. It lasts thirty minutes. We ask what you are building, where it is failing, who decides, and what the system must never do. If the question is technical, an engineer joins.
If you prefer to write first, Start a Project asks six questions. Two of them matter most for pricing: what a bad deploy costs you, and what we should absolutely not touch. We reply within two working days, with questions of our own.
Who decides: you do. You name the decision and the things that are off limits.
What we refuse: we do not take projects we cannot deliver properly. If we are not the right fit, we say so.
Step 2: We map the logic as it actually runs
We call this logic archaeology, and it takes two weeks. We map the decision as it runs today: the code, the spreadsheets, the exceptions, and the person who overrides it on Fridays.
That last item is the one that matters. We do not start from the documented rule alone. We read what runs.
The output is a decision map. Most clients tell us it is worth the engagement on its own.
Who decides: your people tell us what the exceptions are and why they exist. We write them down and ask what we missed.
What we refuse: we do not start from the requirements document alone. We read what runs.
Step 3: We write the bounds before we choose a model
This is the step that answers the title. Before any model is selected, we define three lists:
- what the AI may decide alone,
- what it must escalate to a human,
- what it may never do.
We also define how every decision is logged. For a price, the bounds are the policy: the limits within which a number is acceptable, and the conditions under which a human has to look. The model works inside that frame. It does not draw the frame.
The result is a governance document that a regulator, auditor, or board can read. We write it for that reader, not for the project team.
Who decides: your business owns the bounds. We draft, challenge, and make them precise enough to be enforced in code. We recommend that someone with authority over pricing signs them off, because someone has to own them.
What we refuse: we do not let a model set a price outside the bounds, and we do not let a model change the bounds. We also do not deploy AI into a decision where a named human cannot remain accountable.
Step 4: We choose the model for the decision
The right model for a decision is often not the largest one. We pick on the job: what the decision needs, what it costs per call, how fast it must answer.
Where the decision depends on your own data, we build retrieval over that data. We build evaluation suites from your historical decisions, so the question "is it any good?" has an answer in your own numbers rather than a vendor's.
Who decides: we recommend the model and show the evaluation. You see the results on your own history before anything touches a live price.
What we refuse: we do not choose a model first and look for a place to put it. We do not accept a demo as evidence.
Step 5: We build it into the live system like any other service
The AI component goes into the existing flow with the same rigor as any other production service: typed interfaces, cost ceilings, latency budgets, and rollback.
Typed interfaces mean the model's output is a structured value the surrounding system can check against the bounds, not free text someone has to interpret. Cost ceilings are enforced at the component level, so a pricing component cannot quietly become an expensive one. Rollback means the previous logic is still there to return to.
Every AI deployment we ship has audit logging and rollback. That is a standard, not an option, and it applies to a pricing component the same as to any other.
Who decides: we engineer it. Your engineers review the interfaces and the limits, because they will operate it afterward.
What we refuse: we do not ship a component we cannot explain, audit, or reverse.
Step 6: We run it in shadow, then switch one decision class at a time
The current logic stays in charge. The AI component runs beside it in shadow mode, producing the decision it would have made, with its reasoning, while the existing logic still decides. We compare the two until the numbers agree.
Only then does the AI take over, and only one decision class at a time. Human review rates decrease as confidence is earned. They do not drop on a calendar date.
We do this for every decision class before switch-over. Our position: a class where the two disagree stays where it is until we understand why.
Who decides: the agreement threshold is a joint decision, and the switch is yours. We recommend it. We do not make it for you.
What we refuse: we do not cut over everything at once, and we do not remove human review on a schedule.
What you hold at the end
- A decision map of the pricing logic as it exists.
- A governance document a regulator, auditor, or board can read.
- The AI component in production, with monitoring, cost controls, and explainability built in.
- An evaluation harness your team can run after every model update.
- Engineers on your side trained to operate and extend it.
The harness matters more than it looks. A model will change, and when it does, your team can re-run the evaluation against your own historical decisions instead of trusting that nothing moved.
What is not fixed
We have not described a timeline for the whole pricing engagement here, because the pages that define our method fix only some of it. Logic archaeology takes two weeks. Everything after depends on how many decision classes there are and how many exceptions sit inside them. We would rather tell you that than invent a schedule.
Bring us one pricing decision your business makes badly and answer the six questions on Start a Project, including what a bad deploy costs you. We reply within two working days, with questions of our own. The AI Business Logic Implementation service page sets out the same method.
This article was drafted by SKYLOGIQ's editorial pipeline from the firm's own pages and checked by an AI fact-checking editor, with a human review queue for anything the editor refuses. How the Briefing is made