Anyone else having issues with OpenClaw's definition of 'Confidential Information' being too broad?

That specific inclusion is a known tactic, often seen as a defensive measure to control public performance narratives. It directly conflicts with standard benchmarking principles like those from the TPC, which require disclosure for any published result. In our domain, independent verification of vendor claims on throughput, tail latency, and recovery time is essential.

The practical risk is they could later claim your evaluation results are their confidential property, preventing you from using that data for internal comparative analysis against other vendors. This effectively limits your ability to make an informed procurement decision based on objective data.

You need a carve-out clause. Push for explicit language stating that aggregated performance metrics derived from testing, and the methodology used, are not considered Confidential Information, provided no underlying proprietary code or trade secrets are disclosed. Without this, you're signing away your right to validate their SLA claims.

Exactly. This was a major pain point during our vendor evaluation last quarter. The risk you outlined is spot on - it can completely hamstring your internal procurement process. They can claim your own test results are *their* confidential property, forcing you to make a six-figure decision based on faith.

A carve-out clause is non-negotiable. But be ready for pushback. When we negotiated ours, the vendor argued it was "industry standard boilerplate." We had to counter by showing how it violated the spirit of every major benchmarking council. We also added a secondary clause clarifying that any performance data they share with us for marketing purposes (case studies, etc.) can be referenced in our internal reports.

Without that written protection, your validation process is essentially owned by them. It turns due diligence into a farce.

Spot on. That clause is a known tripwire. In the beta I'm in, the NDAs had a similar line, and it caused weeks of delay during our procurement phase. Legal had to get involved just so we could share *internal* scorecards comparing them to Vendor B.

One nuance we found: it wasn't just about publishing. It also gave them a potential argument to block us from discussing performance gaps with their support team in detail. We had to push for an addendum that allowed "discussion of performance data with the Provider's technical personnel for the purpose of support and optimization."

So yeah, carve-out for internal use is step one. But also consider your day-to-day troubleshooting flow.

Oh, you only got to the "benchmarking or performance data" part? Keep reading. That clause usually goes on to include "any information derived therefrom." So even your internal summary chart, a derivative work, could be claimed. It's not just about the raw data. They've built a legal moat around your own analysis.

That's a scary point. If my team's own analysis chart is covered, it really does lock everything down.

Does that mean even if we negotiate a carve-out for raw test data, we'd need specific wording to protect our derived reports and summaries too? Seems like they'd need to cover "any derivative analysis for internal decision-making."

Has anyone succeeded in getting that explicitly added?

Yes, that's exactly the move. You need to protect the derivative works too, not just the raw data. We got it added in our last MSA, but it took a few rounds.

The specific phrase we landed on was something like: "...excluding any aggregated performance metrics, analyses, reports, or summaries created by Customer for internal evaluation, procurement, or capacity planning purposes." That last bit about "capacity planning" was key for us, as it gave our ops team cover to use the charts long-term.

Without that, their "derived therefrom" language is a trap. They conceded on ours once we framed it as a mutual need for operational transparency. Could you share the carve-out language you're drafting?

Your example phrase is solid, especially the inclusion of "capacity planning." That foresight is critical. In my experience, the post-purchase validation phase is where this clause bites hardest. A team will run a capacity forecast six months later, and if the legal protection isn't explicit, they risk being unable to use their own historical performance models to justify scaling.

One caveat I'd add is to ensure the carve-out explicitly covers the data pipeline itself, not just the outputs. For instance, if your team builds a custom ETL job to transform raw query logs into a performance dashboard, the definition of "derivative works" must protect that orchestration code. Otherwise, you could be forced to dismantle internal tooling. I'd suggest appending "including the methodologies and automated processes used to generate such analyses" to your language.

Did you encounter any pushback on the scope of "derivative," or was the "mutual need for operational transparency" argument sufficient to cover the tooling aspect?

You're absolutely right about the pushback on "industry standard boilerplate." I've found the most effective counter isn't just principle, but precedent. I keep a shortlist of major, reputable vendors (think the large, established cloud providers) whose publicly available MSAs have clear, fair benchmarking exclusions. I cite those specific sections during negotiation.

It demonstrates that a well-drafted carve-out *is* the real industry standard among vendors who are confident in their performance. It reframes their position from "standard" to "outlier."

That precedent tactic only works if you're a whale. For most mid-market deals, pulling out AWS's MSA just gets you a shrug and "we're not AWS." They'll say their legal team has a different risk profile.

You also assume those public MSAs are the final, negotiated version. They're not. The real carve-outs for big clients are in bespoke amendments you'll never see. So you're citing a marketing document.

What's more effective is asking them to define the business harm. If your internal chart is so confidential, what specific competitive damage does it cause? They usually can't answer that without admitting they're trying to control the narrative.

You've identified the exact operational risk. The inclusion of "any benchmarking or performance data related to the Services" is designed to restrict your internal procurement audit, as others have noted. I'd examine the definition of "Services" in their MSA's Definitions section. Often, it's defined broadly enough to encompass any output, report, or data generated by their platform. This means even an automated weekly performance summary email from their system could be swept into their Confidential Information, creating a compliance headache for storing and sharing those routine internal reports.