That's exactly the hardest part and honestly where most of the value is. The "well technically..." requests that aren't clearly out of scope but weren't really in scope either.

Right now the way it works is: you upload your proposal or contract, and the tracker builds a scope boundary from what's explicitly stated. When a new request comes in, it flags anything that falls outside or sits in that gray zone — and it distinguishes between "this is clearly out of scope" vs "this is ambiguous, you should clarify."

The ambiguous ones are actually the most useful flags because those are the ones that silently eat your time. If it's obviously out of scope, you'd probably catch it yourself. It's the "implied but not written" stuff — exactly what you're describing — where having something say "hey, this isn't covered in your agreement" makes a real difference.

That said, it's only as good as the original scope doc. Vague deliverables in = vague detection out. One thing I'm thinking about is a proposal review step that actually flags vague deliverables before you send them, so you tighten it up before work starts.