Apps, features, tiers, and rules

An app has an authentication contract, a default tier, allowance-bearing tiers, and feature contracts. A feature owns modality, provider routing, model, output contract, unit cost, key policy, enabled state, and mock/live mode. Application callers select only the stable feature ID; client-supplied model and token ceilings are overridden.

Config changes are durable proposals bound to the current tenant revision. Rules changes also require preview evidence over a completed lookback window. Applying a stale proposal fails with proposal_stale; fetch current config, rebase the intended change, and propose again.