../constitution/founding-constitution.md
⚠️ Reconstructed from the material we have, not recovered. Tags: [derived] is supported by evidence in the repository · [inferred] is deduced · [proposed] is a gap I filled.
Context
Every module eventually needs to ask “is this tenant allowed to do this”. Answered ad hoc, that question ends up as plan-name comparisons scattered across the codebase —if (plan === 'pro') —
and changing a plan then means finding every one of them. [inferred]
Decision
Capabilities are named entitlements, and code asks about the capability, never about the plan. [inferred] A plan is a bundle of entitlements; askinghasEntitlement('custom_domain') survives a
plan rename, a promotion and a bespoke enterprise contract, while asking about the plan does not.
Entitlements are either boolean capabilities or numeric limits. [inferred] A limit is checked at
the point of use and either blocks or permits an overage, per metric, configurable per tenant from
Softcrum Ops (DEC-G2). [derived]
Metered consumption is a separate concern from entitlements: usage snapshots measure, entitlements
gate. [derived]
Consequences
- A plan change is data. A bespoke enterprise deal is a row, not a branch.
- Ops can grant a capability to one tenant without a deploy. − Two systems to reason about — gating and metering — and the boundary has to stay clear.