Trust

Safety is architecture in MAPLE, not a policy memo

The OS is built around hard guarantees: explicit authority, deny-by-default capability grants, immutable receipts, and a commitment boundary that application code cannot bypass.

Architectural Invariants

OS guarantees that shape all governed execution

Invariant 1

Presence precedes meaning

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.

Open Trust Docs Request Trust Review