Workflow Examples

The same BeaconGuard architecture applies across industries: validate identity and delegated authority, admit the required invocation path, treat the AI result as a proposal, and separately authorize the exact consequential action before execution.

Shared sequence

Identity, delegation, invocation permission, and the proposed business action flow into BeaconGuard exact-action authorization. Request ALLOW is explicitly separated from Action ALLOW. A one-time grant proceeds to execute-side validation while DENY hard-stops; decision evidence records the action, release, and outcome.
Invocation permission establishes context. Consequential execution still requires a separate exact-action authorization decision.

Healthcare example

AI-assisted post-discharge scheduling

Request: A delegated discharge-operations agent is permitted to use a scheduling capability.

Proposal: Create a specific follow-up appointment for a specific patient, time, location, and service.

BeaconGuard decision: Authorize that exact scheduling side effect under current approved policy and authority context.

ALLOW: Issue one-time execution authority bound to the exact scheduling action.

DENY: No appointment is created.

Authority preserved: EHR, scheduling, clinical, and privacy systems remain authoritative in their own domains.

Financial example

AI-assisted fraud case disposition

Request: An authenticated agent can access a fraud case-management capability.

Proposal: Change a specific case disposition and initiate a defined customer-impacting follow-on action.

BeaconGuard decision: Evaluate the exact proposed side effect against actor/delegation, case context, policy, thresholds, approvals, tenant/environment, and current release authority.

ALLOW: One-time authority applies only to the bound action.

DENY: Case state and customer outcome remain unchanged.

Regulated automation example

Production configuration change

Request: An internal agent is permitted to invoke an operations tool.

Proposal: Modify a named production resource with specific parameters.

BeaconGuard decision: Bind and authorize that exact production change, not the agent's general access to the tool.

ALLOW: Executor verifies the action binding and consumes the grant once.

DENY or mismatch: No production change occurs.

The reusable rule

The protocol and business objects change by industry. The core authorization invariant does not:

Being able to reach a capability is not the same as being authorized to perform every consequential action that capability can produce.

See How It Works Review Decision Evidence