Category Archives: Best Practices

Jeez. How do I select a vendor NOT likely to screw me over?

i.e. The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part IV)

We know what you’re thinking.

After reading your three-part exposé (group) on the most important clause in your (Procure) Tech (SaaS) contract, I’m pretty sure I’m going to be screwed to some extent on a significant number of my SaaS contracts. How can I minimize the chances of this happening?

Do your diligence and limit your pool to vendors with the right vendor profile.

This means you have to go beyond a deep analysis of:

  • the product, and does it do what you need
  • the platform, and will it support growth
  • the services capability, and can they implement and integrate the system without resorting to third parties
  • the consulting/training capability, and can they provide basic help when you need it

which is where most people stop. And then you have to go beyond Legal and Risk Management’s staples of

  • legal status
  • financial stability
  • legal jeopardy
  • brand sentiment

because that’s not enough either! All that does is tell you the likelihood of being screwed over today, it does nothing to tell you the likelihood of being screwed in the next 6 months, 18 months, or 3 (to 5) years, which will be typical contract duration for a SaaS app of moderate complexity and significant importance.

So how do you figure that out? Well, there’s no golden rule or single predictor guaranteed to always work, as anything can happen to the best and worst of companies over time, but there is one highly correlated factor to SaaS company success you need to compute because, when it’s low, chances of crisis (that lead to your company getting screwed) are high.

What is that factor?

Relative Corporate Debt*

In a (PE/VC/etc.) investor funded company, where msi = “months since investment”, this is defined as:


1.4^((60-msi)/12) * revenue
————————————
investment valuation

In a private company, this is defined as:


annual revenue
———————
annual operating cost
 

If this is less than 1, you’re taking a risk!

In the second case, for a private company that isn’t yet profitable, unless you can plot a trend line over the past year and a half on a quarterly basis that sees the vendor reaching profitability within a year and a half, you’re taking a big risk as loans and founder savings tend to only take a company so far. (And if the ratio is greater than 1, the company is stable and has a good chance of staying that way if it has a solid solution that improves annually.)

In the first case of an investor funded company, you need to understand that a provider that just raised 7, 10, 15X its current annual revenue is not a guaranteed winner. In fact, it’s not even guaranteed to be stable in the long term! One needs to remember that most investors expect a return within 5 years, and many of the bigger firms will expect a return within 3 years (and will slash operating expenses, i.e. headcount, to get it, especially if they bought it to flip it to a bigger investor down the line). This means that the investors who invested amounts at these ridiculous valuations are hoping it’s the next unicorn and expecting exponential growth.

But exponential growth is very hard to obtain!

First of all, exponential growth either requires creating a whole new market, which takes time, or displacing a lot of established competitors, which also takes time … especially if the majority of customers are still locked into those competitors for years. In the first case, it also requires businesses creating whole new budgets and then taking money away from other functions, which takes time. Plus, in both cases, it requires the company to create a broad and deep platform capable of displacing mature providers who might have spent a decade or more on their products, and that also takes time. Just like 9 women cannot have a baby in 1 month, there is a limit as to how fast even the best teams can create broad and deep software that is better than the last generation, scalable, secure, and reliable. (Given that [almost] half [or more] of AI code has been found to contain [significant] security flaws in multiple studies, AI code is not going to accelerate development as much as the AI players want you to believe. Sometimes it slows things down!)

Moreover, even once the market is ready (as a result of existing contracts expiring, millions of dollars spent on marketing to normalize the new player, millions more on development that might be enough to displace customers where the existing solution was bloatware), there is not only the resistance to change to overcome, but the reality that a provider can only take on so many customers so fast and support them adequately.

Despite what the investors want to believe, and what the C-Suite might promise, most back-office installs aren’t just “flipping a switch” and require a lot of time and effort by the provider to load data, integrate with the key back-end systems, configure the systems to the client’s needs, train the client’s personnel, monitor the system and usage during the first few months to make sure everything goes according to plan, etc. That means a provider can only handle so many new customers a month. Moreover, you can’t just add people at will to handle support needs because those support people will need to be trained and that will also require time from existing personnel, which will then have less time to support the clients.

The harsh reality is that, in IT and SaaS, most companies CANNOT grow at more than 40% year-over-year and maintain aggressive platform growth and leading customer support. Any growth beyond that leads to development slowdowns, significant interruptions (to complete failures) in customer support, and other missteps.

Doing the MATH, this means that a company can’t realistically grow more than 5X in 5 years without making some sacrifices along the way, which, in IT/SaaS, typically means SACRIFICING YOU! And that’s what the formula captures! Realistic growth expectations against current revenue and whether it will hit investor expectations in time!

So this means that if the provider accepts funding at a valuation that is significantly more than 5X, their chances of meeting the investor expectations are not good (unless, of course, they significantly raise prices on the renewal, which will also screw you), and that means your chances of great support will steadily decrease as time goes on and your chances of being one of the customers that eventually gets screwed (even if there was no ill intent or false promises when they signed you) increases.

Moreover, if the provider accepts funding at a valuation of more than 7X, their chances of meeting the investor expectations are really (really) bad. If they can more-or-less double functionality and increase the average annual sale price by about 50% within a year or so, then they can make 7X, but beyond that, there’s usually no way to make the math work in a manner that can be expected to satisfy the investors!

So do the math first. If the investment multiple is too high, or the company too far from profitability, it doesn’t matter how good it, or the solution, looks. If you want stability in your purchase, you need to walk away. If the situation changes in a couple of years, there’s no reason you can’t look at them again if the provider you go with ends up not doing everything you wanted. After all, if you ensured the contract had the IT’S MY DATA clause, and tested it rather promptly after implementation, nothing stops you from switching.

And this clearly demonstrates yet again why the IT’S MY DATA clause is the most important clause and any vendor who can’t, or won’t, guarantee full access to all of your data all of the time is not one you should go with.

Furthermore, and this is the kicker, chances are good that any vendor who is confident not only in their solution but in their ability to keep improving their solution will happily guarantee this. And who’d you rather? A vendor that feels the need to lock you in to a proprietary solution that holds your data hostage in order to keep you as a customer or a vendor that is so confident you’ll stay with their solution after mastering it that they give you the access codes to their competitor’s suite? I know who I’d rather!

* (which is not the same as relative debt in estate law by the way!)

The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part III)

In Part I we told you that

  • while you might think there is no single most important clause as there are a lot of important clauses, especially if you ask around,
  • liability or penalty clauses are quite important, or that
  • termination matters

the reality is that

  • there is a most important clause, and it’s not what you think,
  • liability is worthless if collecting costs more than you get, and
  • you can’t terminate if you don’t have another choice!

We also told you that, after signing the contract, there is a good chance you will be screwed to some extent, whether or not the provider intends it. Between:

  • psychopathic salespeople who will promise anything to sign the deal (and off to their next job before the reckoning comes),
  • investor owners that are going to limit/cut support when unreachable sales targets are not hit, forcing the C-Suite to pick and choose who to screw over,
  • the fact that your vendor will likely be acquired (because if it’s not, it’s likely to go out of business since there are almost 10 times the number of vendors we need in ProcureTech), and
  • the fact that a struggling vendor with the best of intentions will take on too much and be forced to leave some customers high and dry

the chances are, like it or NOT, that you are going to be screwed. (And possibly doomed and entombed by the proprietary software using proprietary data formats that you probably shouldn’t have bought.)

This means there is one clause that overrules them all:

IT’S MY DATA … AND I CAN, AND WILL, GET IT ANYTIME I WANT IT!

Then we made it clear in Part II that while you might think it’s your data, you’ll think again when something happens 6 to 18 months down the road and you need to get it out. Chances are that, unless the developers give you a full database dump (in an underlying schema you have no documentation for, using encryption you have to acquire third party software for), you will be limited to exporting a few reports, and small transaction or record sets at a time. (Unless, of course, you include a clause mandating this, test it after all of your data has been imported and you have run a few events/processed a few thousand transactions to augment it, and penalty and termination clauses with damages and real teeth if this critical requirement is violated.)

But what we didn’t make clear is:

YOUR DATA IS MORE THAN JUST YOUR DATA

It’s also your configuration!

–> Who is using the software and what access rights they have.

–> What processes and workflows they are using.

–> And, most importantly, how those processes are configured!

Now, we’ll be brutally honest here and say that while you can’t expect to be able to import these settings into the next app you get for the same purpose, because every app is slightly different with slightly different configuration capabilities, workflow, etc.

It is very likely this is the only documentation you have of:

  • who is allowed to use the software and what they are permitted to do
  • what processes and workflows you are following
  • what approval processes you are using and who is actually approving
  • and so on.

In other words, it is very likely that the ONLY documentation you have on your processes and practices is in the tools you are using, and, more specifically, in the configurations. Thus it’s absolutely essential you be able to export those as well. Even though you will have to manually recreate them when you switch platforms, it is still better to have documentation on what you were doing, and who was doing it, than none at all. Plus, you can then analyze your processes and find opportunities for improvement with these records!

So make sure that when you select an app you can get your data, and we mean all of your data, at any time before you sign on the bottom line. That way, no matter what happens, you’ll never really be screwed.

The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part II)

In Part I we told you that

  • while you might think there is no single most important clause as there are a lot of important clauses, especially if you ask around,
  • liability or penalty clauses are quite important, or that
  • termination matters

the reality is that

  • there is a most important clause, and it’s not what you think,
  • liability is worthless if collecting costs more than you get, and
  • you can’t terminate if you don’t have another choice!

But this isn’t the worst of it! The worst of it is that, after signing the contract, there is a good chance you will be screwed to some extent, whether or not the provider intends it. Between:

  • psychopathic salespeople who will promise anything to sign the deal (and off to their next job before the reckoning comes),
  • investor owners that are going to limit/cut support when unreachable sales targets are not hit, forcing the C-Suite to pick and choose who to screw over,
  • the fact that your vendor will likely be acquired (because if it’s not, it’s likely to go out of business), and
  • a struggling vendor with the best of intentions will take on too much and be forced to leave some customers high and dry

the chances are that you are going to be screwed.

This means there is one clause that overrules them all:

IT’S MY DATA … AND I CAN, AND WILL, GET IT ANYTIME I WANT IT!

You might think it’s your data, and you might think you can get it anytime you want it as there will be clauses around data protection, privacy, security, etc. as well as acknowledgements that you own your data, it will be kept separate from competitors, and the provider will not use it except to serve you, which may include using limited anonymized portions of it in community data.

And you might think you can get your data anytime you want it because they will guarantee up time, allow you to export transactions and reports, and so on.

But ask yourself this. Of the hundreds (and possibly beyond a thousand) of SaaS applications your organization currently uses, and has used throughout your career there, how many could you, self-serve, do a complete export of all of your data on-demand? And by all of your data, I mean all of your data. Not just reports or summaries or core record subsets. When sourcing, all suppliers and all related 360-data — all risk scores, compliance certificates, performance KPIs, related transactions, related bids, related events, product catalogues, tooling data, etc. In Procurement, all documents related to a transaction — not just the invoice but the purchase order, acknowledgement, goods receipt, credit note, etc.

When we say all of your data, we mean ALL of your data. Chances are, you can’t get it self-serve from your SaaS Application. You might not even be able to get all of your data with help from the the provider’s services personnel. For some applications, the only chance is if the developer does a, relatively undocumented, database export. And good luck with that!

This means three things.

  1. If the provider says that have no way for you to get all of your data at any time, you should not consider them.
  2. You must have a clause that:
    • allows you to export all of your data self-serve at any time (although it’s reasonable for the provider to charge a fee if we’re talking many GBs or TBs and you decide to export all of it on a regular basis, but you should be able to do this, depending on the data velocity and volume, at least once a quarter, month, or week, for free) in a standardized format; in addition, you must also include a modified
    • penalty clause with a significant penalty if you cannot do so by whatever date the baseline implementation is supposed to be completed; a (modified)
    • termination clause if the provider is unable to correct this by a certain time, and a (modified)
    • liability clause for the damages incurred as you will have to find another solution and will have lost time and money on implementing the providers solution.
  3. You must test the ability as soon as the initial import of all of your data is complete, and again in a few weeks once you create a whole lot of new data in the system (updated profiles, end-to-end sourcing events, thousands of new transactions with associated documents, etc.). We realize this will take a lot of time, but much less than trying to figure out what to do six to eighteen months down the road when the vendor fails (you) and you’re left high and dry.

That way, if the provider

  • fails to complete the implementation and required integrations in a reasonable time (and you’re unable to adopt the system),
  • sells you something they don’t have and may not have within the timeframe of the initial agreement,
  • gets acquired by a larger vendor with no intent to support the solution longer than they feel it will take for their forced migration to a higher-priced solution you don’t want, or
  • serves you a notice that it is winding down operations

you can keep going. As long as you can export all of your data in a standard, documented, format, you know that there are a dozen (if not dozens of) providers who will happily convert it to to their format (for free) for your business. Just be sure they will also agree to the same IT’S MY DATA … AND I CAN, AND WILL, GET IT ANYTIME I WANT IT! before selecting them!

The reality of the situation is that there is no unique capability in business data processing that can’t be, and isn’t, more-or-less replicated by dozens of other solutions. Sure they have different UIs, add or subtract process steps, and use different data storage formats, but universal business processes are universal, there are dozens of ways to do them, and get around the software patents supposedly protecting them (which should be banned in the US, as they are in the EU). The next solution might not be as custom fit as the one you are forced to abandon, but it will work (as long as you have unhindered access to 100% of your data). That’s the point.

As long as you can always get your data, you’re never completely screwed. (And once you’ve switched, if the losses are still significant, then, if the C-Suite wants to pursue, you can let the lawyers have their day. You won’t be held ransom by a vendor holding your data hostage.)

The MOST Important Clause in Your (Procure) Tech (SaaS) Contract (Part I)

While you might think there is no one most important clause as there are a lot of important clauses, especially if you ask around.

  • In Procurement, you will want implementation in the promised timeframe
  • Finance will want holdbacks and penalties if functionality is not delivered or timeframes are not met
  • Risk Management will want clauses around cyber-security and privacy
  • Legal will be very concerned about governing venue, liability, and standard termination clauses,
  • etc.

And those are all important, but the reality is:

  • regardless of what’s in the contract, the solution will be implemented when it gets implemented, and delays will be blamed on your IT team, partners, etc. especially if it is their fault
  • you have to prove it was the vendors fault to get any penalties enforced, and that will be very hard indeed
  • good clauses alone are not enough if a cyber-breach or data-breach happens, your customers will still be coming after you
  • the legal venue usually isn’t that important, the only time liability typically comes into play is if customer data is fraudulently accessed as a result of the provider’s failure in security or there is a massive prolonged system failure, and, no matter how bad the performance, the contract won’t be terminated unless there is outright fraud because the organization still needs a system
  • etc.

which means that, while important, unless there was outright fraudulent representation (or serious negligent misrepresentation) in the signing of the contract, none of these clauses really matter as they aren’t protecting you nearly as much as you think they are since any damages you would be awarded in court would be limited to fees paid, which could be dwarfed by the legal fees and mounting losses while you waited months or years for the situation to be resolved!

Moreover, when you consider that the average company is not a Fortune 500, and no longer has (multi-)million budgets for SaaS, that means that most of your purchases are going to be in the (low) six figure range. This means that the vendor knows that the cost of any legal action that would arise plus the losses that would be incurred by the organization that takes action will dwarf the fees paid, and that means that the likelihood of any action coming the vendor’s way is minimal. (Plus, after all of the glowing recommendations you gave the vendor to the C-Suite upon selection, to their customers in the all-expenses paid customer event at the fancy resort destination that was offered to you as a big new name customer, and to new potential customers in reference calls when you were still enthralled by the shiny screen, they know you won’t want to come forward and admit how wrong you were.)

This means that a good portion of you will be screwed to some extent. Let’s consider the reality.

  • Once FinTech, and then ProcureTech, became hot, you had all of the top performing sales people from across enterprise tech move in — and not all of them are altruistic; in fact, some of them are as psychopathic as they come and will promise anything to get the deal signed, even if they know the vendor organization CAN NOT deliver
  • Many providers have been capitalized at multiples of 7, 10, 15, or more by VC and PE firms looking for the next unicorn and are under pressure to reach ridiculous, and wholly unrealistic, sales targets and will effectively over promise to get sales and then underdeliver when the investors don’t allow them to hire enough support personnel due to not hitting sales targets
  • There are over 700 providers in a space that offers less than 10 core modules. That’s almost 10 times the number of providers that are needed. Most will not make/retain profitability and, thus, most will not survive. Some will go under, others will be acquired in fire sales or discount sell offs by investors who cut their losses before they lose it all. Even if your vendor gets acquired, chances are the acquirer will gut it and support levels will significantly decrease (and new development come to a standstill).
  • If the vendor needs the sale to get the bank loan, keep their jobs, make payroll, even the best providers will assume they can figure it out later with money in the bank, but this won’t always happen, especially if they are behind on promises to other customers.

In other words, even if the sales person and the provider had no will intent, you are still likely to get screwed.

This means that the most important clause in the contract is …

Finally A Good Webinar on Gen-AI in ProcureTech …

… from SAP?!?

Yes, the doctor is surprised! In ProcureTech, SAP is not known for being on the leading edge. It’s latest Ariba refresh is 3 to 6 years late. (Had it been released in 2019, before the intake and orchestration players started hitting the scene and siphoning off SAP customers with their ease of use and ability to integrate into the back-end for data storage, it would have been revolutionary. Had it been released in 2022 before these players really started to grow beyond the early adopters, it would have been leading. Now, no matter how good it is, SAP Ariba is going to be playing catch up in the market for the next two years! This is because it’s been fightiong to not only keep its current customers, but grow when it now has suites, I2O [Intake-to-Orchestrate] Providers, and mini-suites in the upper mid-market all chomping at its customer base!)

Most players in ProcureTech jumping on the Gen-AI Hype Train are just repeating the lies, damn lies, and Gen-AI bullcr@p that the big providers (Open AI, Google, DeepSeek, etc.) are trying to shove down our collective throats, especially since these ProcureTech players don’t have real AI experts in house to know what’s real and what’s not. Given that SAP Procurement is not a big AI player, one would expect that, despite their best efforts, they might be inclined to take provider and partner messaging and run with it. But they didn’t.

In fact, they went one step further and engaged Pierre Mitchell of Spend Matters (A Hackett Group Company) in their webinar (now on demand) who is one of the few analysts in our space more-or-less getting it right (and trying to piece together a plan for companies to successfully identify, analyze, and implement AI in their ProcureTech operations). (Now, the doctor doesn’t entirely agree with all of his architecture or all of his viewpoints, but the effort and accuracy of Pierre’s work is leagues beyond anything else he’s seen in our space, and if you’re careful and follow his models and advice properly, low risk. Moreover, you’re starting from sanity if you follow his guidance! More than can be said for the majority of AI approaches out there.)

When it was said that that architecting the solution and the area around [the] business data cloud and managing data and data models is really important because AI has shown that, hey, we have all this amazingly powerful data that’s out there, but we got to tap it and we got to make it more structured and we have to make it useful and that the data quality around data coming out of those models right now needs to be limited to co-pilots and chatbots because we’re not ready to turn the keys over to the LLMs and that they have to be wrapped into deterministic tooling they are not only making clear the limitations of the LLM technology but making clear they understand those limitations and that they have to do more than just plug in an LLM to deliver dependable, reliable value to their customers.

When even the leading LLM, ChatGPT, generates responses with incorrect information 52% of the time, that tells you just how unreliable LLM technology is! Moreover, it’s not going to get any better considering that OpenAI (and its peers) literally downloaded the entire internet (including illegally using all of the copyright data that had been digitized to date [until the Big Beautiful Bill that restricted Federal AI Regulation for 10 years was past, retroactively making their IP theft legal]) to train their models and the vast majority of data produced since then (which now accounts for half of the internet) is AI slop. (This means that you can only expect performance to get worse, and not better!) This means that you can’t rely on LLMs for anything critical or meaningful.

However, if you go back to the basics and focus on what LLMS are good for, namely:

  • large document search and summarization and
  • natural language processing and translation to machine friendly formats

then you realize these models can be trained with high accuracy to parse natural language requests and return machine friendly program calls that execute reliable deterministic code and then parse the programmatic strings returned and convert them to natural language responses. If you then use LLMs only as an access layer, and take the time to build up the cross-platform data integration, models, and insights a user will need in federated cubes and knowledge libraries, you can provide real value to a customer using traditional, dependable, analytics, optimization, and Machine Learning (ML) in an interface that doesn’t require a PhD to use it!

This is what they did, as they explained in their example of what should be done when your CFO asks for a breakdown of your laptop and keyboard spend to potentially identify opportunities to consolidate vendors. Traditionally, this request might take your business analyst days to compile across multiple systems stakeholders and spreadsheets but if you have SAP spend control tower with AI, they unify data across multiple sources in the platform for you. Whether your purchases are coming through existing contracts, P cards expense reports, or any other channel they federate the data by apply[ing] intelligent classifications to automatically categorize your purchases with standard UNSPSC codes to ensure that items like your Dell XPS 15 and your MacBook Pro 16 are both properly classified as laptops, despite the different naming conventions. Moreover, since they have also integrated with Dun & BradStreet, you can easily consolidate your suppliers. So rather than it looking like you’re purchasing items from three different subsidiaries, your purchases will align to the same parent company. This says they are using traditional categorizations, rules, and machine learning on the backend to build one integrated cube with summary reports, and all the LLM has to do is create an English summary, to which you can attach the supporting system generated reports.

Moreover, this also says that if you need to source 500 laptops and 500 [external] keyboards with the goal of cut[ing] current costs from what you’ve been paying by 15% it can automatically identify the target prices, identify the suppliers/distributors who have been giving you the best prices, automatically run predictive analytics to estimate the quotes you would get from awarding all of the business to one supplier (who would then be inclined to give better price breaks), and if none of those looked like they’d generate the reduction, access its anonymized community data, identify other suppliers/distributors supplying the same laptops you typically buy, compute their average price reduction over the past three months, and identify those that should be invited to an RFX or Auction to increase competition and the chances of you achieving the target price reduction while informing you of the price reduction it predicts (which might only be 10%, or 5%, if you are already getting better than average market pricing). And it will do all of this with a few clicks. You’ll simply tell the system what your demand is and what your goal is and all of these computations will be run, supplier and event (type) recommendations generated, and it will be one click to kick off the sourcing event.

Moreover, when the webinar said that if you think about this area around workflow and process orchestration, there’s no reason why you can’t take pieces of that, like on the endpoints, around intake or invoices or whatever and use AI there and bake it in a controlled way
into your processes
. Because that’s they key. Taking one tactically oriented process, that consumes too much manual intervention, at a time and using advanced tech (which need not be AI, by the way, modern Adaptive RPA [ARPA] is often more than enough) to improve it. Then, over time, stringing these together to automate more complex processes where you can gate them to ensure exceptional situations aren’t automated without over guidance. One little win at a time. And after a year it cumulatively adds up to one big win. (Versus going for a big-bang project, which always ends in a big-bang that blows a whole in your operation that you might not be able to recover from.)

The only bad part of this webinar was slide 24, Spend Matters recommendation #1: “Aggressively Implement GenAI”!

Given that Gen-AI is typically interpreted as “LLM”, as per above, this is the last AI tech you should aggressively implement given its unreliability for anything but natural language translation and search and summarization. Moreover, any tech that is highly dynamic and emerging should be implemented with care.

What the recommendation should be is aggressively implement AI because now that we have the computational power and data that we didn’t have two decades (or so) ago, which was the last time AI was really hot, tried and true (dependable) machine learning and AI is now practical and powerful!

Now, in his LinkedIn post, Pierre asked what we’d like to see next in terms of research/coverage (regardless of venue). So I’m going to answer that:

Gen-AI LLM-Free AI Transformation!

Because you don’t need LLMs to achieve all of the value we need out of AI in ProcureTech and, to be honest, any back office tech. As I have been saying recently, everything I penned in the classic Spend Matters series on AI in Procurement (Sourcing, Supplier Management) today, tomorrow, and the day after in the last decade … including the day after, was possible when I penned the series. It just wasn’t a reality because there were few AI experts in our space, data was lacking, and the blood, sweat and tears required to make it happen was significant. We didn’t have readily available stacks, frameworks and models for the machine learning, predictive analytics, and semantic processing required to make it happen. Vendors would have had to build the majority of this themselves, which would have been as much (or more) work than building their core offering. But it was possible. And with all the modern tech at our disposal, now it’s not only possible, but doable. There is zero need to embed an untested unreliable LLM in an end-user product to provide all of the advantages AI can offer. (Or, if you don’t have the time to master traditional semantic tech for NLP, zero need to use an LLM for anything more than NLP.)

So, I’d like to see this architecture and explanation of how providers can roll out safe AI and how buying organizations can use it without fear of being another failure or economic disaster when it screws up, goes rogue, and orders 100,000 units of the wrong product!