But the number of outlandish requests in business logic is countless.

Like... In most accounting things, once end-dated and confirmed, a record should cascade that end-date to children and should not be able to repeat the process... Unless you have some data-cleaning validation bypass. Then you can repeat the process as much as you like. And maybe not cascade to children.

There are more exceptions, than there are rules, the moment you get any international pipeline involved.

▲

ssl-3 2 hours ago | parent [-]

So, in human interaction: When the business logic goes wrong because it was described with a lack of specificity, then: Who gets blamed for this?

	▲	shakna 23 minutes ago \| parent \| next [-]
		I wasn't specific, because I'd rather not piss of my employer. But anyone who works in a similar space will recognise the pattern. It's not underspecified. More... Overspecified. Because it needs to be. But AI will assume that "impossible" things never happen, and choose a happy path guaranteed to result in failure. You have to build for bad data. Comes with any business of age. Comes with international transactions. Comes with human mistakes that just build up over the decades. The apparent current state of a thing, is not representative of its history, and what it may or may not contain. And so you have nonsensical rules, that are aimed at catching the bad data, so you have a chance to transform it into good data when it gets used, without needing to mine the entire petabytes of historical data you have sitting around in advance.
	▲	necovek an hour ago \| parent \| prev [-]
		Depends on what was missing. If we used MacOS throughout the org, and we asked a SW dev team to build inventory tracking software without specifying the OS, I'd squarely put the blame on SW team for building it for Linux or Windows. (Yes, it should be a blameless culture, but if an obvious assumption like this is broken, someone is intentionally messing with you most likely) There exists an expected level of context knowledge that is frequently underspecified.