# settings (/product/modules/settings)



`settings` is the tenant's behaviour: one key-value table, one row per scope, the configuration in a JSON column. The [configuration](/product/infrastructure/configuration) page carries the model; this page is the module's surface.

## Owns

`settings`, and beside it `settings_secrets`, the sealed, server-only row that holds the tenant's storage keys and nothing else.

Application-wide rows hold what the app as a whole needs: currency and gateway, the shop, the marketing site, the chat, the theme, storage. A module row holds that module's form surface and, per grid, its setting flags, column definitions and filter definitions. A `defaults` row is the fallback.

## Routes

`/settings`: the application-wide settings, and per module its form surface and grids. `/settings/memory` is the owner's view of what the assistant has remembered across conversations, with the option to retract any of it.

## Chat tools

`get_module_settings`, `manage_grid_settings`, `manage_form_settings`. Each replaces one node of a module row, so an edit to one grid leaves its siblings alone, and a role restriction on a setting stays an admin-panel decision the assistant cannot make. Every change is audited and reversible from the entry that recorded it.

## Permissions

`settings.manage`. Module rows resolve against the reader's role, so a grid looks richer to an admin and leaner to a standard user from one configuration.

## Switched off

Never. Every project links it at provisioning.