If it helps you out personally, it may be nice to impose a translation filter between the rest of the world and yourself here?
These other folks say “know” when they mean “have confidence in” and they are looking for you to similarly say “know” meaning that. Your internal meaning of knowledge can be much stronger, but they are just asking for you to give your reasons why you think that would be the case. You can feel free to hedge as well.
“I think we can resolve all of these things if we just make a UserInteractions table on our end, rather than proxying all of this to the upstream API. We will still proxy the interactions, but our source of truth can be our table.”
“How do you know that will work?”
“Well, it involves taking on some risks, like when they update things and never tell our source of truth about them, then our two systems are out-of-sync. I think that probably the problem of synchronizing our table with their system is simpler and more tractable than getting their system to behave in a normal way where we don't get successful responses until we're sure that the interaction has happened. It would be different if everything was changing every second of course, but that isn’t what we’ve been seeing happen on our staging server. The rest of it is not too bad, there are three API endpoints which generate these UserInteractions and they all touch it but rewriting them can’t be more than a day’s work, so the only hard problem is populating this UserInteractions table in the first place, but that’s not an ongoing risk, just a one-time cost for a developer to pay. That’s why I’m confident that this is a good choice moving forward.”
“How do you know that interaction times won’t suffer?”
“Well, I cannot say 100% for sure but usually requests over the local network to the local database are going to be faster than general network requests, unless things are really unusually smooth between the two. But at our present number of users and our projected go-live numbers, I have seen MySQL setups handle that with no problem and if it is a problem then we’ll have to face that scaling difficulty either way, as MySQL is not just used for these UserInteractions but also for X, Y, and Z.”
You see? I don’t need to claim absolute knowledge here, I just need to express:
1. There is some sort of cost-benefit analysis of trade-offs happening here,
2. someone has done this analysis, and,
3. more info can become available and I can be held accountable for this trade-off if this choice later becomes problematic.
It’s sort of a part of negotiation rather than part of technical responsibility. If you can appeal to an outside authority (“The OWASP security guidelines clearly state...”) or at least an unbiased one (“I ran this by Susan, who is a developer at our contractor that we work with, and she agreed it was worth a shot and gave me some good feedback about a potential pitfall that I should avoid...”) or otherwise communicate that some sort of expertise has peeked in to a problem, then people feel naturally more confident and trusting about it. If you don’t do that then it starts to sound more like “we should do this because I say so” even when the problem is legitimate and painful.
I guess I’m saying, think of yourself as a doctor talking to a patient about an upcoming surgery. They are right to have nebulous general concerns and they talk in funny ways that technically do not have much scientific value, but it is important to reassure them when needed, provide them options when needed, and just trust that if they lose trust of you and want to get second opinions, they are acting in good faith and have every right to be concerned about these things that are probably innocuous but have a tiny probability to kill them.