There's an entire semi-formal language on promises, called promise theory. This includes promises autonomous agents (humans, back when this was conceived) make for other autonomous agents. Promise Theory was the basis for CFEngine, which spawned Puppet and Chef, but it's applicability is much broader. The kind of promises examined within this article can be described and analyzed by promise theory.

The central insight is understanding that promises are not obligations, and why and how that matters. From there, interesting things can be analyzed -- using types and contracts in a development team, unit tests, integration tests, specs, user interface and user experience, compliance, signaling, APIs, etc.

I think it is particularly useful now in the age of LLMs, agenic AIs, and autonomous robots that have to navigate spaces shared with humans.

https://markburgess.org/promises.html

> When publishing software, you make a promise to your users.

Just to add on to that. Beyond a promise, it's a contract, and someone has to be responsible and accountable for it.

Like when you're walking or driving and see a traffic light... you don't stop to wonder if there's a race condition or if another signal is out of sync. You trust it and act.

Unfortunately, it feels like in software today, promises are made... but rarely kept. And worse, most people just seem to accept that. If traffic lights were broken, we'd just need to upgrade to the next version right?

I disagree. A lot of open source software literally come with "it's what it is" clause in the license, meaning that the maintainer has ZERO responsibility towards you, the user. No promises were made, you take it as is or leave it. Just because the dev generously decided to open source the code doesn't give you, the user, any "rights" to inundate the dev with issues.

`software can be anything in imagination, but must be something in reality.` - I like that. I should stick it on my wall.

Only async software.