EXECUTION MODEL
A decision is required before execution.
Outcomes:
PERMIT → execution proceeds
DENY → execution does not occur
SILENCE → no authorization issued; execution cannot proceed
Request → Evaluation → Decision → Execution
NO PERMIT, NO EXECUTION
DECISION BOUNDARY
A decision is any irreversible action evaluated before execution.
Examples include:
- Payment execution
- Code deployment
- Data export
- External API mutation
- Infrastructure change
- System state modification
If the action changes reality, it belongs at the gate.
Receipts record decisions; runtimes record enforcement (EXECUTED / BLOCKED).
[ EXECUTION TRACE ]
TRACE_ID: TG-A7C192B
ACTOR: finance-bot
ACTION: transfer_funds
AMOUNT: $50,000
↓
DECISION: DENY
ENFORCEMENT: BLOCKED
RECEIPT_STATUS: SIGNED
ENFORCEMENT LEVELS
Single operator control
Decisions occur at the point of action.
No coordination across systems.
Shared environments
Decisions are enforced across services.
Basic coordination established.
Organizational execution control
Policy-bound execution across production.
All actions require authorization.
Cross-system authority
Deterministic control across execution paths.
No uncontrolled actions exist.
Full execution authority
Centralized execution control across critical systems.
No action occurs without explicit permission.
SYSTEM PROPERTIES
Every action is evaluated before execution.
Every decision is recorded.
Every outcome is enforceable.
---
Execution cannot bypass the gate.
Authorization cannot be assumed.
State cannot change without a decision.
POSITIONING
TrigGuard does not observe execution.
It determines whether execution is authorized (PERMIT) or not (DENY / SILENCE).
OPEN SOURCE SECURITY
Open Source Security
TrigGuard follows OpenSSF Best Practices to maintain secure development processes, dependency hygiene, verified CI pipelines, and reproducible builds where applicable.
ACCESS
For enforcement, private deployment, and enterprise authority discussions: