Checks and undo

Every action is checked twice and ships with its undo

Before it acts, org.run checks the action against your rules, in numbers and in words, and shows you exactly what will happen. After it acts, it checks that it worked. If something is wrong, the compensating action is already prepared.

How it works

Check, preview, act, check again

  1. 01

    It checks the rules first

    Before anything runs, the action is tested against your rules. Math checks like a refund under $500 or a discount of at most 10%, and language checks like the tone matches the account or no promise outside policy.

  2. 02

    It shows you the exact thing

    For anything one-way, a payment, a send or a deploy, you see the exact email, the exact refund or the exact code diff before it leaves. Not a summary. The thing itself.

  3. 03

    It checks the result

    After acting it goes back and looks. Did the invoice actually send? Did the error rate drop after the rollback? A passed check closes the run. A failed one is never assumed away.

  4. 04

    It undoes when it has to

    Every action is planned with its compensating action: roll back the deploy, void the credit note, recall the email. If a check fails after the fact, the undo runs and you hear about it.

Two kinds of check

Rules in numbers, and rules in words

Some of your rules are arithmetic. Most of them are judgment. Both run on every action, before and after.

Math checks

Amount under $500. Discount at most 10%. Credit never above the invoice total. Delivery date inside the SLA. Hard limits, tested exactly, with no room for interpretation.

Language checks

Tone matches how you talk to this customer. No promise the policy does not back. No commitment to a date engineering has not agreed. The judgment calls, written in plain language and checked the same way every time.

Off your plate

Stop checking the work twice yourself

You still set the rules. You stop re-reading every output to make sure they were followed, and stop cleaning up when they were not.

  • Re-reading every draft before it goes out
  • Doing the refund math a second time in your head
  • Checking the next morning whether the email actually sent
  • Cleaning up by hand after a wrong send
  • Writing the apology for a promise nobody approved
  • Watching the error rate yourself after a rollback
  • Finding out weeks later that a rule change broke something
  • Keeping a list of what to undo if this goes wrong

Built so acting is safe

What stands between a plan and a mistake

Math checks

Hard limits tested exactly before the action runs: the $500 refund line, the 10% discount cap, the credit that can never exceed the invoice.

Language checks

Rules of judgment, written in plain language: the tone fits the account, nothing is promised outside policy. Checked on every draft, every time.

Preview before anything one-way

The exact email, refund or code diff, shown at the approval step. What you approve is what goes out, word for word.

Checks after acting

It confirms the result in the system itself. The invoice shows as sent. The error rate came down. If not, the run does not close, and it tells you.

Compensating actions

Every action is planned with its way back: a rollback, a void, a recall. Undo is a step it already knows, not a cleanup you have to invent.

Replay tests

Past cases are kept as tests. When a model or a rule changes, they are re-run first, so a change that would have handled last month differently is caught before it goes live.

Questions about checks and undo

Twice. Before the action, against your rules, so a bad action never starts. After the action, against the system it touched, so a failed one is caught rather than assumed. One-way actions also stop for a person in between, with a preview.

Anything you can write down. Numbers: amount under $500, discount at most 10%, delivery inside the SLA. Language: tone matches the account, no promise outside policy, no date engineering has not agreed. You write them in plain language and org.run applies them the same way every time.

It runs the compensating action planned alongside the original: roll back the deploy, void the credit note, recall the email, reverse the record change. Some actions cannot be fully taken back, like an email that has already been read. Those are tagged one-way and wait for a person before they happen.

A past case kept as a test. Before a model update or a rule change goes live, org.run re-runs those cases and compares the outcome with what happened and was approved before. A change that would quietly decide differently is flagged to you first.

The run does not close. org.run tells you what failed, with the evidence, and either retries, runs the undo or waits for you, depending on your rules for that kind of action. Nothing is marked done until the check passes.

Early access

Let it act, and let it prove it worked

Set the rules once. Every action is checked against them, before and after, with a way back ready.

Scoped, auditable and reversible from day one. Your data stays yours.