Proof and Evidence
BeaconGuard evidence is designed to show more than whether a runtime logged ALLOW or DENY. It preserves the exact action that was evaluated, the verified policy authority that governed the decision, the relevant actor/delegation context, and the execution binding when ALLOW is issued.
All examples on this page are synthetic and illustrative. They are not customer-production records and are not a normative public API schema.
CONTROLLED PRODUCT DEMONSTRATION
The BeaconGuard Review Process
This existing laboratory demonstration shows fail-closed denial, privileged reviewer step-up, issuance of bounded one-time authorization for a new request, successful consumption, and rejection of authorization reuse.
BeaconGuard extends the same principle to exact consequential-action authorization: the final side effect is separately bound and authorized after the AI proposes it.
What the demonstration establishes
- DENY remains final for the original denied request.
- Review does not mutate DENY into ALLOW.
- Privileged authorization requires step-up authentication.
- Later execution requires new bounded authorization.
- One-time authorization is consumed after successful use.
- Reuse attempts are denied and remain reviewable.
Privileged review authorization flow
ORIGINAL REQUEST
Original DENY remains final.
REVIEW DOES NOT CHANGE THE ORIGINAL DENY
NEW AUTHORITY APPLIES TO A NEW REQUEST
SEPARATE GOVERNED REVIEW PATH
Mutually exclusive outcomes
Review itself is not permission.
Text version
Phase 1: Original Request → Independent Evaluation → DENY with REVIEW_REQUIRED → Original Request Finalized → Authorization Evidence. The original DENY is final; review does not convert it to ALLOW or resume the original request.
Phase 2: Reviewer Step-Up → Bounded Single-Use Authorization → New Application Request → Independent Evaluation of New Request → mutually exclusive fork. Branch ALLOW → new request permitted for this evaluation only; bounded authorization is consumed; reuse attempt is DENIED. Branch DENY → new request blocked; no execution; the bounded authorization cannot be reused.
Single-use authorization is no longer reusable after the new evaluation attempt. Review itself is not permission.
Controlled laboratory demonstration using synthetic data. This is not a customer deployment, external certification, production qualification, or commercial-traction claim.
Illustrative ACTION ALLOW evidence
The record identifies the exact action, the governing verified release, and one-time execution authority bound to the same material-action identity.
{
"decision_scope": "CONSEQUENTIAL_ACTION",
"decision": "ALLOW",
"action_type": "patient_followup.schedule",
"material_action_digest": "sha256:illustrative-action-digest-allow",
"release_identity": "release.healthcare.ops.v12",
"release_manifest_identity": "sha256:illustrative-release-manifest",
"playbook_identity": "playbook.healthcare.followup.v12",
"authority_context": {
"agent": "synthetic_discharge_ops_agent",
"delegation": "bounded",
"tenant": "northbridge_synthetic",
"environment": "evaluation"
},
"execution_grant": {
"single_use": true,
"bound_action_digest": "sha256:illustrative-action-digest-allow",
"status": "ISSUED"
},
"evidence_id": "vdr_allow_action_001"
}Illustrative ACTION DENY evidence
DENY records the exact proposed action and governing authority but issues no execution grant. The side effect remains prevented.
{
"decision_scope": "CONSEQUENTIAL_ACTION",
"decision": "DENY",
"reason": "required approval absent",
"action_type": "patient_followup.schedule",
"material_action_digest": "sha256:illustrative-action-digest-deny",
"release_identity": "release.healthcare.ops.v12",
"release_manifest_identity": "sha256:illustrative-release-manifest",
"playbook_identity": "playbook.healthcare.followup.v12",
"authority_context": {
"agent": "synthetic_discharge_ops_agent",
"delegation": "bounded",
"tenant": "northbridge_synthetic",
"environment": "evaluation"
},
"execution_grant": null,
"outcome": "NO_SIDE_EFFECT",
"evidence_id": "vdr_deny_action_002"
}What independent reviewers inspect
- Was the decision scoped to the exact consequential action?
- Does the material-action identity match the action presented for execution?
- Which verified release / manifest was permitted to govern the decision?
- What actor and delegated-authority context constrained the decision?
- Was execution authority issued only for ALLOW?
- Was one-time execution authority bound to the same action identity and consumed once?
- Is the evidence sufficient to verify integrity and reconstruct the deterministic decision?
Qualification coverage
Identity and delegation failure
Invalid, expired, revoked, or out-of-bounds authority fails closed.
Replay and reuse rejection
Duplicate requests and previously consumed execution authority are rejected.
Tenant / environment mismatch
Authority established in one boundary is not silently accepted in another.
Action-binding mismatch
An action changed after authorization does not inherit the original ALLOW.
Verified-release failure
Unverified or inactive policy authority cannot govern production authorization.
Evidence and reconstruction
Decision context, exact-action identity, release authority, and integrity information are preserved for verification.