# Company Admin non-financial settings runtime audit
This audit is limited to the non-financial groups rendered by the non-Filament Company Admin settings page: booking, notifications, discounts, POS, policies, and PWA. The catalogs were compared with consumers in `app/`, `routes/`, and `resources/`. A setting is considered applied only when it changes a runtime decision; being editable in Company Admin does not count.
## Coverage found
- Booking settings: 18 of 24 leaf values have direct consumers. The remaining six are availability, verification, auto-confirmation, and notification decisions that need to be enforced in the public and company-admin booking creation paths.
- Notification settings: 11 of 30 have direct consumers. Reminder scheduling and channel-specific delivery are incomplete.
- Discount and promotion settings: 0 of 29 have reliable direct consumers in the current search. These need to be routed through the pricing and promotion services.
- POS settings: 2 of 45 have direct consumers. The POS UI stores most values without enforcing them in cashier, inventory, receipt, and shift workflows.
- Policy/document settings: 2 of 32 have direct consumers. Consent, retention, export/deletion, signed documents, and liability waivers need explicit runtime checks.
- PWA settings: 2 of 31 have direct consumers. The manifest, service worker, install prompt, permissions, and update behavior need to read company-scoped settings.
- Tremol settings are excluded from this audit because they have a dedicated fiscal-device settings flow.
## Required next implementation
Introduce a company-scoped settings policy service and make every relevant Company Admin entry point use it: public booking creation, company-admin booking creation, checkout/payment, cancellation/refund, notifications/jobs, POS actions, PWA manifest/service worker, and data-retention commands. Each setting should have one focused feature test proving the behavior changes when the setting is toggled.
The current audit identifies storage and UI coverage separately from algorithm coverage. Until the listed gaps are wired and tested, the settings should be treated as configuration data rather than enforced policy.