“Which option is best for long-term scalability?”

That question lands in your sales channel every week. And every week, the rule-based configurator either freezes or punts: it can validate, but it won’t advise. The quote ends up needing a call with product, another with service, and a quiet spreadsheet to reconcile trade-offs.

We’ve trained our CPQ to say what’s allowed. We haven’t taught it what we believe.

From Claude’s Constitution to CPQ Principles

On the Hard Fork podcast, Anthropic’s Amanda Askell described why Claude is guided by a constitution: not just rules, but values. The idea is simple and powerful - rules alone don’t generalize to messy, human situations. Values do.

That lands directly in CPQ. Traditional product configurators are binary: if X then not Y. That’s essential for correctness. But it’s not enough for judgment. When a buyer asks which option they should choose, you don’t need more rules - you need principles that express your sales ethos.

In CPQ terms, think of two layers:

  • Validation layer - your constraint engine (Tacton CPQ and other systems that only uses symbolic logic for configuration) ensures what you sell can be built and priced.
  • Advisory layer - your “constitution” that scores valid options against values you care about: long-term scalability, serviceability, lead time risk, standardization, lifecycle cost, sustainability, customer fit.

The validation layer keeps you safe. The advisory layer makes you useful.

“A configurator without principles is a traffic light with no map.”

This isn’t about witty answers or brand tone. It’s about encoding how your best experts think when two valid options exist and the customer needs guidance. Rules tell you what you can do. Principles help you decide what you should do.

Principles That Travel Well in CPQ

You don’t need 29,000 words. Start with five to seven short principles that explain your judgment when choices are valid but different. Keep them testable and explainable.

  • Prioritize the customer’s future success. Prefer options that scale across sites and phases, even if capex is slightly higher. Example: choose the drive platform with a published expansion path to 3x throughput.
  • Bias to standardization. If a standard module meets need within 10% of performance, recommend it over a custom variant. Example: choose stock frame height with spacer kit over bespoke frame if load targets are met.
  • Optimize for lifecycle value, not just purchase price. Consider energy, maintenance intervals, spares availability. Example: show total cost over 5 years alongside list price.
  • Reduce delivery risk. Favor configurations with shorter and more predictable lead times. Example: score options higher if they avoid scarce components or tooling changes.
  • Prefer explainable choices. If two options score similarly, recommend the one you can explain with fewer assumptions. Example: tie-break in favor of simpler control architecture when performance is comparable.

Make each principle concrete with a rule-of-thumb and a test case. You’re building habits, not slogans.

“If you can’t explain why it’s best, it isn’t a recommendation - it’s a guess.”

A quick anti-pattern to name internally: Persona paint. That’s when a team adds a chatty tone and a friendly avatar, but the underlying decisions are unchanged. The bot still can’t weigh trade-offs. It still can’t defend a choice. Adoption doesn’t move.

By contrast, a principle-led bot can say: “Option B is better for multi-site rollout. It adds 4% to capex but cuts your 5-year service cost by 12% and ships three weeks sooner. Standard modules keep spares common across plants.” That’s the voice of your best solution engineer - embedded.

Designing Guardrails Without Killing Judgment

So how do you wire this into a system buyers and sellers will trust?

1) Keep the solver sacred. Don’t muddy constraint logic with advisory logic. Your validation rules ensure buildability, safety, and pricing correctness. They are binary and testable.

2) Build a scoring layer for trade-offs. For each principle, define signals you can compute at quote time: module maturity, % standard content, lead-time class, installed base commonality, total cost drivers. Combine them into a simple score per option. Start crude. Improve through use.

3) Make every recommendation explain itself. When the bot suggests Option B, show the rationale in plain language and include the numbers behind it. Keep a “Why this?” link at every decision point.

4) Add hard constraints for your red lines. Like Anthropic’s hard no-go areas, keep a small set of absolute guardrails: no unfunded customizations, no variants beyond tested ranges, no offers outside service coverage. If the bot is “convinced” to cross a red line, treat it as a jailbreak - block and explain.

5) Treat principles as tests, not slogans. For each principle, write scenario tests that prove the bot behaves as intended. Example: “Customer will add two lines next year” should push the recommendation toward scalable powertrain. Run these tests in CI for your advisory layer.

6) Govern like a product, not a project. Give one owner the pen for principles and scoring. Meet weekly. Review real quotes. Amend one principle at a time. Publish change notes. Small, visible changes beat quarterly overhauls.

7) Respect pricing realities. Your pricing engine can continue to do what it does best: discount guidance, price waterfalls, pocket price analytics. Let the advisory layer feed pricing with a reasoned recommendation and the factors that matter to margin over time.

“Each extra rule is a future maintenance bill. Principles pay compounding interest.”

When you design it this way, the system becomes an enabler, not the hero. The solver keeps everyone safe. The advisory layer makes good judgment repeatable. AI can then help with interaction speed, document generation, and surfacing rationale - but it leans on the explicit logic you’ve defined.

And yes, AI can sit in the loop. Use it to translate principle scores into clear language, suggest clarifying questions, or draft a customer-facing rationale. But keep the scoring functions explicit and testable. Fluent assistance with ungrounded logic is just a nicer way to be wrong.

Who benefits? The teams that sell complex, configurable products at scale. They get fewer expert escalations, faster proposals, and better conversations. Who drifts? The teams that respond to edge cases by adding more rules and hoping adoption follows. It won’t.

“The first answer wins attention. The best explained answer wins trust.”

Practical steps for this quarter

  • Codify seven principles that reflect your sales ethos. Write one sentence each. Attach one test scenario each. Publish them.
  • Prototype a scoring layer for two product families. Use spreadsheet math first. Move it into your CPQ once it works.
  • Ship explainability with every recommendation: the comparison, the tie-breakers, and the numbers.

One more thing I’ve learned the hard way: don’t wait for perfect data. Start with the signals you have. Expose the logic. Iterate with real deals. Prices, lead times, and product ranges will change; your principles should survive that change because they describe how you think, not what you sell this quarter.

A configurator built on values doesn’t replace product expertise - it scales it. And that’s the job.

The quiet test is simple: when a buyer asks, “What should we choose?”, does your system have an answer it can defend?