StableMindMachine Authority
Sign inStart with ActionGate

Changed Beneficiary · Interactive synthetic story

Identity stayed valid.
Authority did not.

A payment agent is authorized to pay an approved supplier. The agent is still authenticated. Its service credential still exists. The amount is still inside policy. Then the beneficiary account changes. That single fact changes the authority question.

Synthetic scenario: every organization, supplier, account, payment, decision, permit, credential, intervention, and proof state below is fictional. The story runs entirely in your browser and creates no payment or machine authority.

PAYMENT REQUEST / SYNTHETIC$428,000 USD
APPROVED DESTINATIONSUPPLIER_42 / ••7744
CHANGED DESTINATIONSUPPLIER_42 / ••9138
Agent identityVALID
CredentialAVAILABLE
AmountIN RANGE
BeneficiaryCHANGED
ACTIONGATEFRESH HUMAN AUTHORITY REQUIRED

One mutation. Six control moments.

Follow the request from green lights to a broken authority chain.

Use the controls to compare the original approved beneficiary with a changed destination. The decision is deterministic and browser-local. The point is not that every beneficiary change must always be denied; the point is that a destination mutation cannot inherit authority merely because surrounding controls remain green.

1 / 6
01 / IDENTITYVALID

The agent proves who it is.

Enterprise identity resolves the workload and authenticated principal. That matters, but identity does not answer whether this machine may send this payment to this destination.

IdentityVALID
DelegationVALID
CredentialAVAILABLE
Destination••7744
AUTHORITY STATENOT YET DECIDED

Identity is an input to authority, never a substitute for it.

browser_local=true · network_calls=0 · payment_effects=0 · authority_effects=0

The trap

Most surrounding signals can stay green while the decisive fact turns red.

01

Identity remains valid

The payment agent can still authenticate successfully. Authentication answers who the machine is, not whether a newly changed beneficiary lies inside delegated authority.

02

The credential still exists

A payment API token or vault secret may still be technically retrievable. StableMind treats capability as downstream of authority, so the credential is withheld when permit eligibility disappears.

03

The amount can remain ordinary

$428,000 may fit every familiar amount threshold. Destination continuity is a separate consequential dimension; one green limit cannot cancel a changed target.

04

The supplier name can stay familiar

A recognizable supplier label does not prove the receiving account is the authorized destination. The authority object must bind the consequential target precisely enough to detect the mutation.

The machine-authority response

The changed beneficiary is not “fraud detected.” It is authority no longer established.

StableMind does not need to claim the new account is malicious. It only needs to recognize that the known delegation no longer proves permission for the changed destination. That distinction makes the control explainable and fail-closed without pretending certainty about intent.

01

Semantic request

Normalize the consequential action: send $428,000 USD from the governed account to the exact beneficiary destination associated with SUPPLIER_42.

02

Authority lineage

Resolve who delegated payment power, the permitted supplier and destination, limits, approvals, validity window, and inherited constraints.

03

Target continuity

Compare the requested destination with the destination bound into the current authority context. A material mismatch prevents silent inheritance.

04

ActionGate decision

With the original destination, a narrow Action Permit may be eligible. With the changed destination, fresh human authority is required before a permit can exist.

05

Capability withholding

Execution Fabric does not release a JIT payment credential merely because one exists in a vault. Capability follows the current Action Permit.

06

Evidence afterward

If no execution occurs, Evidence records the governed decision path. A synthetic story is not external Proof of Consequence, settlement evidence, or customer production proof.

Identity ≠ authority

The changed-beneficiary problem reveals the missing layer between access and consequence.

QuestionOriginal beneficiaryChanged beneficiary
Is the agent authenticated?YESYES
Does a technical credential exist?YESYES
Is the amount inside the synthetic limit?YESYES
Does current authority cover the exact destination?YESNO
May a current Action Permit exist?ELIGIBLENO
What happens next?BOUNDED EXECUTION PATHFRESH HUMAN AUTHORITY

Why this scenario matters

Beneficiary changes are a clean test of whether an enterprise governs access or governs power.

01

The mutation is semantically small

To an integration, the change can look like one field in a payment payload. To the enterprise, that field determines where money leaves the organization. Machine Authority Infrastructure treats semantic consequence, not payload size, as the control boundary.

02

Traditional controls can remain truthful

The identity system is not wrong when it says the agent authenticated. The vault is not wrong when it says a credential exists. The payment policy is not wrong when it says the amount is below a threshold. Those systems answer narrower questions. StableMind exists because none of those answers establishes delegated permission for the changed destination.

03

Risk prediction is not required

A machine-authority decision can be conservative without claiming omniscience. StableMind can require fresh human authority because the consequential target changed, even when it has no basis to call the account suspicious, compromised, or fraudulent. The control remains explainable because it rests on authority discontinuity rather than a hidden suspicion score.

04

The same pattern travels beyond payments

The underlying control problem appears whenever the target of an action changes: a new production cluster, a different SaaS tenant, a changed contractual counterparty, a new data destination, or a substituted recipient. The exact policy differs, but the invariant survives: old authority must not silently expand to a materially different consequential target.

Constitutional boundaries

What this story deliberately does not claim.

01

No fraud verdict

A changed beneficiary can be legitimate. StableMind's public story does not label a person, account, supplier, or transaction fraudulent; it shows that authority must be re-established for the changed consequential target.

02

No payment execution

The page never calls a payment rail, bank, processor, ERP, vault, or customer system. The fictional accounts exist only in browser state.

03

No real Action Permit

“Eligible” is a teaching state. Only governed ActionGate infrastructure operating over real validated authority can issue a real permit.

04

No customer proof

The scenario does not establish a named customer, blocked loss, prevented fraud, live production action, external Proof of Consequence, recognized revenue, or realized customer value.

05

No credential authority

A usable secret, token, or payment capability remains insufficient. StableMind's architecture requires the authorization boundary before technical capability is materialized.

06

No interface override

A user clicking a story control cannot grant authority. Website sessions, marketing entitlements, signup state, and browser interactions create zero downstream machine power.

Evaluator questions

Questions this one payment mutation should force an enterprise to ask.

Why is IAM not enough for a changed beneficiary?
IAM can authenticate the machine or user. The changed-beneficiary question is whether the current delegation authorizes this exact consequential destination now. Those are different control questions.
Why not rely on the payment provider's fraud model?
Fraud scoring and machine authority solve different problems. A risk model may estimate suspiciousness; authority determines whether valid delegated permission exists. StableMind can fail closed without claiming a fraud diagnosis.
Could ActionGate simply deny every beneficiary change?
The public story uses HUMAN_AUTHORITY because a changed target can be legitimate but needs fresh authority. An enterprise policy may be stricter, but the key invariant is that old authority cannot silently expand to a new destination.
What happens to credentials?
Execution Fabric releases technical capability only after an exact current Action Permit exists. If authority is missing or requires a human, the JIT credential remains withheld.
Where does Consequence Capital fit?
Consequence capacity can remain a separate precondition for payment authority. Sufficient reserve never repairs a destination mismatch, just as a matching destination never waives a required reserve.
Is this Proof of Consequence?
No. This browser story is synthetic. Proof of Consequence requires independently attributable postcondition evidence after an actual governed execution, and even favorable proof does not create authority.

Public Truth boundary

A compelling story is still not production evidence.

SIO12 is an architecture-and-product education surface with a browser-local synthetic payment narrative. StableMind.io does not use this interaction to imply customer deployment, a prevented loss, a production payment, financial custody, settlement, recognized revenue, realized value, or external certification.

synthetic_story=truenetwork_calls=0payment_effects=0authority_effects=0external_production_proof_claims=0public_signup_active=false

From one payment to the control plane

The changed beneficiary is the story. ActionGate is the product.

Use the Authority Lab to manipulate other consequential facts, or continue into ActionGate to understand the deterministic decision boundary underneath this story. Commercial account bootstrap is introduced in SIO19; SIO21 remains the first governed-action experience.

story_creates_authority=false · story_executes_payment=false · public_signup_active=false