We're debating the next feature for StateGuard. Would you trust this?
Over the past few weeks, we've been building StateGuard, an open-source runtime reliability SDK for AI applications.
The goal isn't to improve model quality. It's to keep AI workflows running when something around the model changes unexpectedly - schema drift, provider response changes, tool output mismatches, validation errors, missing fields, and similar runtime failures.
Instead of the application crashing because one component changed, StateGuard attempts to repair the mismatch and continue the workflow safely.
One capability we're considering next is Semantic Repair.
For example:
A provider returns "done" instead of "completed"
A tool renames "assistant_message" to "assistant"
Two APIs use different field names for the same concept
Equivalent values are represented differently across providers
Instead of failing, StateGuard would recognize that the intent is equivalent, normalize the payload, and continue execution.
The question is:
Would you actually trust something like this in production?
Or would you rather these cases fail loudly so you can fix them yourself?
We're trying to build the roadmap around real developer feedback, so I'd genuinely love to know:
Where would you draw the line between "safe automatic repair" and "developer intervention required"?
Have you run into failures like these yourself?
Is there another runtime failure you'd solve before semantic repair?
The trust question seems more important than whether Semantic Repair is technically possible.
From the developers using or evaluating StateGuard so far, have you seen anything in their actual behavior that tells you how much repair authority they're comfortable giving the system automatically?