// 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: