Effects: what actually gets authorized

You cannot reliably authorize a sentence. "Clean up the old build files" can mean very different things on two machines. SensCheck authorizes a canonical effect: a small, typed, versioned record.

{
  "schemaVersion": "1.0",
  "effectId": "eff_8f2c…",
  "principal": { "id": "coding-agent", "type": "agent" },
  "action": { "verb": "DEPLOY", "resource": "production:api" },
  "parameters": { "version": "2.3.1", "region": "eu-west-1" },
  "risk": "HIGH",
  "proposedAt": "2026-10-02T12:00:00.000Z",
  "metadata": {}
}

Strict by design

Missing or malformed fields are not guessed. Unknown top-level fields are rejected. An unknown risk level is rejected. The result is FAIL_CLOSED with reason INVALID_EFFECT. metadata is informational only and never influences a decision.

The digest: approval that cannot drift

SensCheck hashes the material fields (principal, action, parameters, risk) into a digest. Approvals, and optionally authority, are bound to that digest.

Say a human approves "deploy version 2.3.1". If the agent then asks to deploy 9.9.9, the digest differs, there is no approval on file, and the result is REQUIRE_APPROVAL again. Changing an authorized effect always means asking again.

The copy that runs

Once validated, the effect is deep-copied and frozen. The function that finally runs receives that frozen copy, so mutating your original object after the check cannot change what executes.

Choosing verb, resource and risk

← All lessons