Verified execution

A decision proves an action was allowed. It does not prove it worked.

That gap is where most real damage lives: the deploy that was permitted and half failed, the migration that was approved and left the schema in a state nobody described.

const outcome = await memnox.guardVerified(
  { action: 'code.modify', target: 'src/payment/checkout.ts' },
  {
    preconditions: [{ description: 'branch is clean', check: () => isClean() }],
    execute: () => applyPatch(),
    postconditions: [{ description: 'tests pass', check: () => runTests() }],
    rollback: { description: 'revert commit', execute: () => revert() },
  },
);

The four outcomes

`outcome.status`

succeeded

Preconditions held, the work ran, postconditions held

precondition_failed

Nothing ran. The world was not in the state assumed

execution_failed

The work itself threw

postcondition_failed

The work ran and left something wrong, rollback fired

Every one of them is reported to POST /v1/actions/outcome and audited.

Rollback, and the case that opens an incident

A failed postcondition triggers the rollback. If the rollback also fails, the event is audited as critical and opens an unrecovered_execution incident.

That is the most serious thing this product reports, and it is worth being precise about why: it is the state where nobody knows what state the system is in. Not "something broke", "something broke and the undo broke too."

Why unreported outcomes escalate

The verification guard escalates the next action from an agent that never reported the outcome of its last allowed one.

The reasoning is simple: an agent that does not tell you whether its last change worked is an agent you know less about with every step it takes. Escalating costs a human a moment; not escalating costs you the whole trail.

bash

memnox serve --verification-guard

Writing good conditions

Preconditions describe the world you are assuming, not the work you are about to do. Branch is clean. Migration N-1 has run. The feature flag is off.

Postconditions describe the observable result, not the mechanism. Tests pass. The endpoint answers 200. Row count is unchanged.

A postcondition that only asserts "the function returned" verifies nothing, execution_failed already covered that.

Reporting an outcome directly

If you are not using the SDK wrapper, report it yourself. The actionId is the one the runtime returned when it allowed the action:

bash

curl -X POST http://127.0.0.1:7466/v1/actions/outcome \
  -H "Authorization: Bearer $MEMNOX_AGENT_TOKEN" \
  -H "content-type: application/json" \
  -d '{"actionId":"act_8812","status":"succeeded","detail":"3 files changed, tests green"}'

An action whose outcome is never reported escalates the agent's next one, so this call is not optional bookkeeping.

Guards

The other escalators, and what each one catches.

Incidents

What happens after an unrecovered execution.