Actions Science — The Right to Act

Make the action the unit of governance. Start with one AI-assisted deployment.

Preparing the walkthrough…

An action is born scoped

The walkthrough showed one governed action. This map shows how its authority, decision, enforcement and evidence remain connected. One consequential action travels through five stages. Existing controls govern their parts. Actions Science makes them meet at the action. Root Zero Vault binds the right, the decision and the evidence.

DEED

Who has the right?

GATE

May this action happen?

CHAIN

Can someone else check it?

These are responsibility mappings across the action journey, not isolated components that operate at only one stage. CHAIN is cross-cutting: evidence begins before execution and continues through later change.

This is a design map: it shows how one action's authority, decision, enforcement and evidence stay connected. It describes the intended structure and the tests that judge it — it is not evidence that any deployment has passed them.

Three aligned responsibilities: existing systems and controls · governed action · retained evidence

Define

AI, data and software

Model, data and code checks

CHAIN · action identity

Pin exact build 1.1

Bind its content identity, Production target, parameters and attempt.

Chain evidence

Action identity, build identity, target and inputs.

Establish authority

People and access

Owners, roles and approvals

DEED · resolve the right

Establish the legitimate right

The engineer holds Test authority. Production requires the owner’s approval for exact build 1.1. Test authority cannot authorize Production.

Chain evidence

Authority, delegation, owner approval and applicable policy version.

Decide

Policy engines

Agreed deployment rules

GATE · permit or refuse

Decide before the effect

Refuse Production under Test-only authority. Permit the Test deployment. After owner approval, permit only exact build 1.1 for Production. Refuse build 1.2.

Chain evidence

Bound permission or refusal, the exact reason, and artifact and target binding.

REFUSEno covered effectPermit build 1.1 → continue

Enforce

Deployment gateway

Production and target controls

GATE · check at Production

Enforce at the target

Check the permission at Production. Verify build identity, target, expiry and permitted use. Refuse build 1.2 when the permission covers build 1.1.

Chain evidence

Observed result, target-side refusal, and success, failure or unknown.

MISMATCHno covered effectBuild 1.1 valid → release

Recheck

Audit and archives

Independent reviewer

CHAIN · recompute offline

Recompute offline

Recompute the authorization decision offline using retained evidence, authenticated history and independently established trust inputs — without releasing the software again.

Chain evidence

Decision, authority history, policy history, observed outcome or unknown, the later build 1.2 request, and relevant revocations and changes.

Permission does not prove that the effect occurred. Record the observed result. Preserve uncertainty as “unknown.”

A failed mediation check restricts the affected route.

The action path

Permission meets the destination

Production checks whether permission covers the exact build.

Target enforcement sequence

Gate decides on exact build 1.1 and Production.
Permission binds the build, target and limits.
Production validates the permission.
Build 1.1 may proceed.
Build 1.2 is refused — different bytes, not covered.
The observed result or refusal is retained.

Independent review after the action

The gateway can stop. The evidence remains.

Before the effect

Build 1.1, authority, policy, permission or refusal.

At Production

Success, failure, refusal or unknown.

Through later change

Build 1.2, revocations and relevant history.

Independent reviewer

Recomputes the authorization decision offline, without the original gateway’s live operation.

Portable evidence

Bound records and their history.

Established trust inputs remain independent of the evidence package itself. The package does not establish its own trust merely by carrying its own key.

Two ways to connect the existing stack

Actions Science defines what must be true. It applies the same method and tests to either implementation.

Root Zero Vault (RSBIS)

A structural implementation. Deed, Gate and Chain bind authority, decision, enforcement and evidence to the action across the integrated controls.

A complete alternative construction

Mature components assembled with their own binding architecture across the entire tested action path. It must satisfy the same requirements to qualify.

Ordinary identity, policy, workflow and logging products do not automatically satisfy the complete method. Qualification depends on the whole path.

The method around it

Six views of the whole journey

The six Actions Science pillars — views across the complete journey, not six extra runtime steps.

Semantics

What exactly changes?

Authority

Who may authorize it, under which limits?

Execution

Where is permission enforced before the effect?

Evidence

What can another person verify?

Continuity

What happens during failure, delay or change?

Assurance

How strong is the finding, and what challenges it?

Each pillar applies across the action stages.

Requirements that become reusable

The intended operating model for classes of actions.

01 · ACTION CLASS

Shared requirements and challenge sets

Example: controlled room-finding production release.

02 · DEPLOYMENT BINDING

Named owners, Test, Production, credentials and routes

Confirm the actual controls and boundaries.

03 · EACH ACTION

Current facts, exact artifact and its own permission

Build 1.2 does not inherit build 1.1’s authorization.

Relevant changes reopen the affected requirements and tests.

The Actions Science working cycle

The engineering and assurance cycle — not six additional runtime services.

1 · Define

Name the exact effect and declared surface.

2 · Hypothesize

State what must hold and how to disprove it.

3 · Prepare

Assign owners. Gather the needed evidence.

4 · Challenge

Try bypass, substitution, replay and change.

5 · Judge

Record supported claims, gaps and contradictions.

6 · Improve

Fix the mechanism. Refine requirements.

Define → Hypothesize → Prepare → Challenge → Judge → Improve.

Six distillation tests of the complete action path

The tests cross all six pillars and assess the integrated action path.

TEST 1

Pre-action decision + rejection

Decide before the effect. Refuse unauthorized actions and retain the refusal.

TEST 2

Historical policy + authority

Recover the rules and legitimate authority that applied at the time.

TEST 3

Decision-bound execution

Approval for build 1.1 cannot authorize build 1.2, another target or a replay.

TEST 4

Mediation assurance

Test every declared route to the effect. Contradictions restrict affected operation.

TEST 5

Operator-independent replay

Recompute the decision offline using retained evidence and established trust inputs.

TEST 6

End-to-end semantic coherence

Keep identity, authority, policy, permission, effect and verification tied to the same event.

Root Zero Vault, RSBIS, the demonstration and any deployment do not automatically pass every test.

Scope: This is a design map of the declared action routes and established trust inputs. It is not evidence that a deployment has passed every test.

Your next step

Choose one action your team needs to trust.

You have seen the action operated, the missed handoff, and the complete structure. Now take the same method to one action of your own — a bounded 30-minute exercise. No account, no purchase, no Root Zero Vault adoption required.

↓ Take this to your team ↓ 12-slide briefing (PDF)

The kit includes the action worksheet in PDF and editable Word, plus the briefing to introduce it to others.

The map shows the structure. The Essay explains why governing the action, rather than only the model, becomes a distinct discipline.