DETERMA.systems
עברית

Runtime Execution Authority

AI can act. DETERMA decides whether it may act now.

DETERMA is an external execution authority layer. It checks whether the exact action an AI is about to perform is still covered by its approval, its scope and the current state — before it changes a real system.

Let AI work. Keep authority with you.

Evaluate PR Authority ContinuitySee the authority boundary

01

Proposal

02

DETERMA — Execution Authority

03

State change / external effect

The authority gap

Capability is not authority.

Models and agents keep getting more capable. The unresolved question is not whether an action can be performed, but whether it may be performed right now, by this executor, under this approval, against this state.

Capability is not authority.

An agent that can call the tool has not been authorised to use it for this action.

Identity is not authority.

A valid token proves who is calling. It does not prove that this particular effect is permitted.

Approval is an event. Authority must still be valid now.

An approval given ten minutes ago can be stale: scope drifted, the state moved, or the release was already consumed.

The authority moment

One moment decides everything: the instant before the effect.

Pick a scenario and see what an external execution authority evaluates at that instant. Every scenario below is a simulation of the evaluation model, not a record of a customer deployment.

Scenario

Agent opens a pull request that matches the approved intent and scope.

SIMULATION / EVALUATION SCENARIO

Inputs evaluated

Intent
Open a pull request that patches the dependency version in one service.
Scope
One repository, one manifest file, no workflow files.
Approval
Exact-action approval, single-use, not yet consumed.
Current State
Base head unchanged since the approval was captured.
Policy
Software change policy v0 — pull request only, no direct write to default branch.
Executor / Tool
Constrained GitHub adapter, pull-request scope only.

Decision

ALLOW

Allowed — exact action still covered.

  • Requested action matches the approved action byte-for-byte.
  • Base state matches the state the approval was bound to.
  • Execution release is fresh and single-use.

Reasoned receipt

intent=matched
scope=within-bounds
approval=exact-action, unconsumed
state=unchanged
policy=satisfied
executor=constrained, in-scope

Simulated evaluation. Verdicts are deterministic illustrations of the authority model, not measurements of a production system.

What DETERMA checks before execution

Six checks, evaluated at execution time.

Not a score, not a heuristic. Each check is evaluated against the exact action that is about to run.

01

Intent

Is this the action that was actually proposed and understood?

02

Scope

Does the requested effect stay inside the bounds that were reviewed?

03

Approval

Is there an approval that covers this exact action, unconsumed?

04

Current State

Does the system still look like the state the approval was bound to?

05

Policy

Do the rules that govern this class of effect still permit it now?

06

Executor / Tool

Is this executor allowed to perform this action, in this scope?

Why existing controls are not enough

Each layer answers a different question.

These layers are necessary and DETERMA assumes they exist. None of them decide whether a specific action may take effect right now.

Identity proves who.

DETERMA validates what may happen now.

Sandboxing controls where.

DETERMA controls authority.

Orchestration keeps work moving.

DETERMA decides whether it may continue.

Observability explains what happened.

DETERMA can block before the side effect.

Category-level comparison. DETERMA sits beside these layers, not against any vendor.

Use cases

One current wedge. Several evaluation tracks.

The first proof surface is deliberately narrow. Everything else is presented as a Design Partner evaluation track, not availability.

Current — first evaluation wedge

GitHub / software change

Open PR Authority Continuity: one historical or sanitized pull request where approval existed, then the world changed before merge. Evaluated against intent, scope, approval, current state, policy and executor before anything is applied.

See all use cases

Design Partner evaluation tracks

MCP / tool calls

Authority evaluation for agent tool invocations.

Evaluation Track — not a production availability claim.

Cloud operations

Bounded parameter changes with state revalidation.

Evaluation Track — not a production availability claim.

CRM / revenue operations

Allowlisted field writes with readback.

Evaluation Track — not a production availability claim.

ITSM / operations

Status transitions gated on evidence.

Evaluation Track — not a production availability claim.

Finance / payments

Draft preparation with single-use releases.

Evaluation Track — not a production availability claim.

Procurement

Bounded record actions with exact-action approval.

Evaluation Track — not a production availability claim.

Administrative workflows

Repetitive state changes under defined authority.

Evaluation Track — not a production availability claim.

These tracks describe evaluation scope with a design partner. They are not statements of availability and imply no named vendor integration.

First product / first proof

GitHub Authority Check.

Open PR Authority Continuity: a governed evaluation of one historical or sanitized pull request where approval existed and the world changed before merge. The starting path is read-only or sanitized replay by default — no production credentials, no write access, no production mutation.

The first evaluation checks for three drift classes: Target/Base Drift, Approver Authority Drift, and Policy/Ruleset Drift. GitHub is the first wedge, not the boundary of the platform.

  • No autonomous merge.
  • No permanent model credentials.
  • No success claim before verification.
  • Read-only by default during assessment.
See the GitHub evaluation

Governed lifecycle

AI may propose. Authority decides. Constrained executors mutate. Evidence proves.

Evidence and validation are not authority.

  1. 01

    Proposal

  2. 02

    Validation

  3. 03

    WAITING_APPROVAL

  4. 04

    Human approval context

  5. 05

    Exact scope binding

  6. 06

    State Witness where required

  7. 07

    Fresh single-use Execution Release

  8. 08

    Constrained Executor

  9. 09

    Append-only audit

  10. 10

    Post-execution verification

See the authority boundary

Evidence, not claims

Three levels of proof, stated separately.

We separate what the mechanism demonstrates from what has been implemented and from what a market has validated. The three are never blended.

Mechanism proof

Available

The authority model itself: exact-action binding, state revalidation, single-use release, fail-closed behaviour on ambiguity, drift or replay.

Verified implementation slice

PROVISIONAL — internal only

Internal evaluation of a narrow software-change slice. Internal findings only; not customer validation and not a production capability.

Market proof

Not claimed

Shown only when real, linked customer evidence exists. Nothing is presented here until then.

We do not display customer logos, deployment counts, savings figures or risk-reduction percentages. Where evidence does not exist, the section stays empty.

See the evidence model

Design partner path

Four steps. Enforcement only under a separate approval.

Each step is bounded, reversible and evidence-producing. Nothing escalates automatically.

  1. 01

    01 · Read-only assessment

    Metadata-first review of an existing workflow. No writes.

  2. 02

    02 · Historical replay / shadow mode

    Replay past actions, or observe live proposals without effect.

  3. 03

    03 · Bounded evaluation

    A defined scope, a defined executor, a defined set of actions.

  4. 04

    04 · Enforcement

    Only with a separate, explicit approval. Never a default.

What this does not require

  • No production credentials by default.
  • No write access during assessment.
  • No secrets handed over.
  • A defined workflow, agreed in advance.
  • An evidence report at the end.
See the design partner path

Business outcomes

What teams are trying to change.

Qualitative outcomes only. We publish no ROI figures, no savings estimates and no quantified risk reduction.

  • Less manual coordination around bounded approvals and revalidation.
  • Fewer broad standing permissions held by agents and automation.
  • Less ambiguity and less after-the-fact reconciliation.
  • Traceable evidence from intent through to outcome.
  • More autonomy for AI inside defined authority boundaries.

These are the outcomes an evaluation is designed to test, not results we claim on your behalf.

Why this is hard to copy

Five properties, stated plainly.

Authority continuity

Authority is carried from proposal to effect, not re-guessed at the end.

Exact-action binding

Approval attaches to one action, not to a role or a session.

Single-use release

A release authorises one execution and cannot be replayed.

Verified effect

The effect is read back and compared against what was authorised.

Evidence lineage

Intent, approval, state and outcome remain linked as one record.

Next step

Which action would you want AI to be able to perform safely?

Tell us the workflow and the action. We will tell you whether a bounded evaluation makes sense — and what evidence it would produce.

Step 1 of 2 — 01 · Contact

  1. 01 · Contact
  2. 02 · Qualification
This request starts with a fit check for the Open PR Authority Continuity evaluation. The assessment path remains metadata-first by default.