Invariant 1
Presence precedes meaning
Trust
Safety is architecture in MAPLE, not a policy memo
The platform is built around hard runtime guarantees: explicit authority, deny-by-default capability grants, immutable receipts, and a commitment boundary that cannot be bypassed by application code.
Architectural Invariants
Runtime guarantees that shape all governed execution
Invariant 2
Meaning precedes intent
Invariant 3
Intent precedes commitment
Invariant 4
Commitment precedes consequence
Invariant 5
Coupling is bounded by attention
Invariant 6
Safety overrides optimization
Invariant 7
Human agency cannot be bypassed
Invariant 8
Failure must be explicit
Control Tiers
Higher-risk actions demand stronger gate posture
| Tier | Example | Typical control posture |
|---|---|---|
| Tier 0 | Read-only and simulation flows | Logging plus lightweight validation |
| Tier 1 | External I/O and low-risk side effects | Commitment receipt, policy check, capability grant |
| Tier 2 | Funds movement or regulated data handling | Approvals, stronger evidence requirements, richer audit trails |
| Tier 3 | Operator upgrades and self-modifying behavior | Highest scrutiny, staged rollout, replay verification |
Audit Surfaces
What operators can inspect after a decision
maple commit submit --file payment.json maple provenance worldline-history <worldline-id> GET /api/v1/commitments/:id/audit-trail GET /api/v1/provenance/worldline/:id/history
Need the detailed trust model?
The docs section includes the architectural invariants, profiles, and commitment-boundary details behind MAPLE's trust posture.