Done means done. Satin confirms every change with the app before saying so.
In development. Action Broker passes tests against stand-ins; live Jira tests next.
WEB-1 · Website
Design support flow
- 1Resolve
- 2Check
- 3Execute
- 4Read back
- 5Report
- 6Audit
The cases match the acceptance tests every change must pass.
Six steps, every time. Each change is a small transaction run by the Action Broker. “Done” comes last.
- 1
Resolve
Find the exact entity. Ask when two things match.
- 2
Check
Confirm the person is allowed, and apply risk policy.
- 3
Execute
Call the application’s own API, never the page.
- 4
Read back
Fetch the entity again and compare.
- 5
Report
Say exactly what happened, or offer the native path.
- 6
Audit
Write a minimal event, with no content.
Verified: the read-back matches, so the person sees “Done”.
Safe failure: nothing false is claimed, and a link to the original app is offered.
Correctness rules
Small rules that stop big mistakes. Each one is written down, and each one has a test.
The risk is quiet errors: the wrong task, the wrong day, an overwrite. The Action Broker is built to make them impossible, or at least loud.
- Identifiers are never invented. If two things match, Satin asks.
- Last-updated is checked before writing; conflicts are shown, not overwritten.
- Double clicks write once; timeouts are read back, not resent.
- Undoing layout is separate from undoing data changes.
“Set due date to today”
Your time zone, from your Interface DNA
In Kolkata it is 01:30 on Sat 24 Oct
due_date: "2026-10-24""2026-10-23"A date with no time, for a date-only field. Acceptance test AT-01 checks 20:00 UTC on 23 October in Kolkata and Los Angeles.
Safe failure
When it can’t, it says so. Plainly, and with a next step.
A safe failure is a proper result, not an error screen. Satin claims nothing false and changes nothing it shouldn’t. A busy or unavailable app never becomes a false “Done”.
- Every failure gives a plain reason and a next step.
- A link to the same task in the original app.
- A conflict shows what changed, and writes nothing.
When a change can’t be made
Design support flow · WEB-1
You can’t edit this task
Your role in this workspace can view it but not change it. Nothing was changed.
result: safe_failure · reason: permission_denied
- Nothing false was claimed
- Nothing unintended changed
- A way to the original app
Audit
A record of what happened. And nothing you wrote.
Every action, finished or not, writes an audit event: action, task identifier, workspace and result. It stays on your device, or in the product’s own log with the SDK.
{}entity_id
The app’s own identifier for the task. An identifier, never content.
- steps in every change
- 6steps in every changeResolve, check, execute, read back, report, audit
- for a verified change, at the 75th percentile
- ≤ 2 sfor a verified change, at the 75th percentileDesign target
- writes to the wrong workspace
- 0writes to the wrong workspaceChecked on every read-back, and tested
- acceptance cases written
- 38acceptance cases writtenAcross 13 tests; 36 run today
Questions, answered plainly.
After the change, Satin asks the app’s own API for the task again. Only if the value it returns matches what you asked for does Satin say “Done”.