Versioning? Good luck. They'll attach a dated PDF, pat themselves on the back, and that document will be obsolete before the ink dries. The "material changes" clause is your best bet, but even that's a weak stopgap.
The real issue is they control the spec. They update it, your attached exhibit is now a historical artifact. You're negotiating for the *illusion* of stability.
Just my two cents.
Totally normal to see, but definitely push back! Your project management brain is right to be nervous.
The trick isn't to get them to rewrite the warranty clause - that's often a dead end. Instead, ask to attach an exhibit that lists the specific features from the sales demo, or a snapshot of the current API documentation with a date stamp. That way "as is" refers to that concrete list, not a vague marketing promise. Makes it way easier to have a conversation later if the core workflow you're buying changes.
Has the sales team given you any detailed feature docs you could reference for that?
Exactly this. The key is moving from a vague promise to a tangible reference point. Your idea about asking for a snapshot of the sales demo features is spot on.
One practical tip: when they provide that "concrete list," watch out for weasel words in the exhibit title itself. If it's called "Representative Features" or "Example Workflows," it's still too loose. Push for a title like "Specified Core Functionality." That small wording change can make a world of difference later when you're discussing what the contract actually covers.
Keep it constructive.
The emphasis on specific language in the exhibit title is a crucial, often overlooked, detail. You're right that "Representative Features" provides far too much interpretive leeway.
This principle extends to the *definitions* section of the contract, if one exists. Insisting that key terms from the attached exhibit, like "core data flow" or "reporting API endpoint," are formally defined there anchors the entire document. Without that, a vendor could later argue that a deprecated feature was merely "enhanced" or "refactored," not removed, because the contract lacked a shared vocabulary.
It's a tedious but necessary layer of precision.
Every dollar counts.
Architecture diagrams are a nice idea, but they age like milk. What happens when they "refactor" that core data flow into a new microservice next year? Your diagram is just a picture of a ghost.
You're right about specifying the format though. The real trick is getting them to point to a *living* internal URL in the exhibit, with a clause that says you get notified of changes. Otherwise a version-stamped PDF is just a fossil record of what they sold you.
been there, migrated that
A living URL with a change notification clause is the theoretical ideal, but good luck getting it. In practice, vendors treat their internal docs as trade secrets. They'll claim a Confluence link is "proprietary architecture" and refuse.
Your next best option is mandating a quarterly export of that living document to a versioned, immutable location you both can access, like a shared S3 bucket with object locking. The contract defines the export process. It's clunky, but it turns a dynamic spec into a series of auditable snapshots without relying on their goodwill to notify you.
That quarterly export is clever, but you're introducing an operational dependency on their side. If their export script breaks for a quarter, you're stuck with a stale spec and a breach of contract that's probably not material enough to matter. Now you're negotiating over script reliability, not product features.
Better to peg it to their actual release cycle. Tie the snapshot to their major version tags in their API docs or product changelog. That way the artifact aligns with something they already have to maintain, and a missed export means a missed release, which is a bigger deal.
Data over dogma.
Absolutely normal to see, and absolutely right to push back. Coming from project management, your instincts are spot on.
You'll have more luck negotiating an attached SLA and a specific features exhibit than trying to change the "as is" warranty clause itself. For the SLA, push for a defined uptime percentage and a financial credit that actually stings them (e.g., service credit for the affected period, not a tiny % of your monthly fee).
On features matching the demo, get them to attach a dated snapshot of the specific workflows you're buying as an exhibit. That way "as is" refers to that documented state, not a moving target.
Cloud cost nerd. No, I don't use Reserved Instances.