# Manage Octy profiles > The Octy profiles page in LightHouse: create a profile, test it, publish, pause, resume and delete it, view where it runs and whether its deployment applied it, and read the audit of every change. Client administrators create, test and publish Octy™ profiles in LightHouse without a release, and see for each profile where it runs, whether its deployment applied it, and every change in the audit. Octy profiles are managed in LightHouse under **Agents → Octy profiles**. The page lists the tenant’s profiles and where each runs, and links to each profile’s page. ## Who may do what | Role | Permitted actions | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Any role (`viewer` and above) | See the profiles, their settings, status, costs, the audit, and the widget’s snippet | | `content_viewer` and `client_admin` | Also read the redacted question text of a profile that runs in a client deployment, read in place. See [Question insights](/octy/evidence/#question-insights) | | `client_admin`, signed in as a person | Create, edit, test, publish, pause, resume and delete profiles; export a command file for an air-gapped deployment | A machine key cannot change a profile. Atlantic’s own public profiles are managed by Atlantic staff in the staff console, under the same checks and the same audit. ## Profile list **Profiles** shows each profile with its state (Draft, Live or Paused), its disclosure tier, its audience, where it runs and that deployment’s [deployment profile](/concepts/deployment-profiles/), its channels, model spend this month against its cap, and the answers given in the last 30 days. **Where they run** groups the profiles by location: Atlantic-hosted, or each of the client’s deployments. A deployment that sleeps between questions is marked as such, and an air-gapped deployment is marked offline. **Costs** opens the [cost analysis](/octy/costs/) for every profile. ## Create a profile 1. Choose **Create an Octy profile**. 2. **Name and scope.** Give the profile a name, a short name, and one or two sentences on what it answers about. 3. **Tier and audience.** Choose the disclosure tier and who may ask. LightHouse offers the tier’s default controls. Apply them, or keep the current values. 4. **Knowledge.** Choose corpora from those the client’s deployments report: knowledge bases, connected sources and uploaded collections, each with its document count and whether it is published. A corpus excluded by the tier or by where the profile runs is shown with the reason. 5. **Runs on.** Choose where the profile runs. This is where its knowledge is held. 6. **Channels.** Switch on the channels it answers on. A channel that the settings do not allow shows its requirement, such as an allowed origin for the widget. 7. **Controls.** Set the rate limits, the address lists, the allowed origins and pages, the bot check, the monthly cap and its alert, and the router’s quality bar and models. See [Controls](/octy/controls/) and [The router for every profile](/octy/router/). 8. Choose **Create draft**. Result: the profile is saved in the **Draft** state. It is published only when **Publish** is chosen. A field that breaks a rule is marked on the page, with the reason. The rules are in [Octy profiles](/octy/profiles/#rules-every-profile-keeps). ## Profile page Each profile’s page has six tabs: | Tab | What it shows | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Overview** | The profile’s knowledge, audience and channels; its status, including the revision its deployment applied and how the change travelled; and model spend this month | | **Settings** | Every setting, editable by a `client_admin`. Saving makes a new revision | | **Test** | A test panel. See [below](#test-before-publishing) | | **Widget** | The widget’s snippet and the content security policy entries for the website. See [The website widget](/octy/widget/) | | **Costs and questions** | The profile’s costs, the router’s decisions and its question insights. See [Cost analysis](/octy/costs/) and [Question insights](/octy/evidence/#question-insights) | | **Audit** | Every change, with its revision and the fields that changed | ## Test before publishing The **Test** tab answers questions from a draft, a live or a paused profile, as its audience would see the answer. Choose **Search only**, which uses no model, or **Explain with a model**, which goes through the router. Each test answer shows its passages, whether a model was used and what it cost. Test answers are marked as tests and visible only to the person testing. They are charged to the profile’s cap and recorded in the audit. They are excluded from the profile’s question insights and from the router’s evidence. ## Publish, pause, resume, delete | Action | From | What happens | | ----------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------- | | **Publish** | Draft or Paused | Every check runs again; the profile goes live and is sent to where it runs | | **Pause** | Live | The profile stops answering until it is resumed | | **Resume** | Paused | The profile answers again, at its current revision | | **Delete** | Draft or Paused | Its settings are removed and a remove command is sent to its deployment. A live profile must be paused first. The audit is kept | ## How a change reaches your deployment A profile that runs in a client deployment is applied there by a **signed command** from LightHouse, on publishing and on every later change, pause, resume or deletion. The command carries the profile and a digest of it. The deployment verifies Atlantic’s signature, as for every command, and then checks the profile before applying it. - **Client administrator**: in LightHouse - **LightHouse**: the tenant - **Client deployment**: the command handler and Octy A change 1. Client administrator to LightHouse: **Publish or change**. checked again; a new revision 2. LightHouse to Client deployment: **Signed command**. the profile and its digest, on the command channel, or in a command file for an air-gapped site Applied or refused 3. Client deployment: **Check and apply**. the signature, the deployment's policy, the digest, the revision, the corpora, the tier and the models 4. Client deployment to LightHouse: **Profile state**. applied, refused with a reason, or removed, in the deployment's signed telemetry LightHouse sends each change as a signed command, live or by command file. The deployment checks it, applies it or refuses it with a reason, and reports which revision it holds. The profile's status in LightHouse comes from that report. The deployment refuses a profile, with a reason, when: - the digest does not match the profile; - it already holds a newer revision; - the profile names a corpus the deployment does not have; - a public profile would read documents that are not public; - an air-gapped deployment is asked to use a model it does not serve locally; - a limit is outside the allowed range. The **Overview** tab shows the status: **Applied**, **Refused** with the reason, or **Pending**. Profile commands are off by default in the deployment’s policy, like every command type. The policy names the roles that may send them. **Air-gapped deployments.** The command goes into the next command file. The profile shows **Waiting for the command file**, with a link to export it. Transfer the file to the site and apply it, as for any command file. The profile shows as applied once the site’s next telemetry bundle is imported. See [Air-gapped operation](/clouds/on-premises/#air-gapped-operation). ## The audit Every change is recorded in the tenant’s audit log and on the profile’s **Audit** tab: created, changed, published, paused, resumed, tested and deleted, each with the person, the time, the revision and, for a change to the controls, the fields that changed with their old and new values. The audit does not record question text. ## The API and the MCP tool The same operations are in the [LightHouse API](/api/) under `/api/v1/octy-profiles`: | Route | What it does | | ------------------------------------------------------------------- | --------------------------------------------------------------------- | | `GET /api/v1/octy-profiles` | The profiles, and the default controls for each tier | | `POST /api/v1/octy-profiles` | Create a profile, as a draft | | `GET /api/v1/octy-profiles/{id}` | One profile, its status and its recent audit | | `PUT /api/v1/octy-profiles/{id}` | Replace its settings, with `If-Match: ` | | `POST /api/v1/octy-profiles/{id}/publish`, `/pause`, `/resume` | Change its state | | `DELETE /api/v1/octy-profiles/{id}` | Delete a draft or paused profile | | `POST /api/v1/octy-profiles/{id}/test` | A test answer | | `GET /api/v1/octy-profiles/{id}/widget` | The widget’s snippet and content security policy entries | | `GET /api/v1/octy-profiles/corpora` | The corpora the client’s deployments report, for the knowledge picker | | `GET /api/v1/octy-profiles/costs`, `/{id}/costs`, `/{id}/questions` | Cost analysis and question insights | A refused change returns `422` with the error code and the field concerned. An edit without `If-Match` returns `428`, and an edit against an old revision returns `409`. The [MCP server](/mcp/) provides an `ask_octy` tool: a profile’s short name and a question, asked as the caller, read only. Source: https://docs.atlanticagenticlabs.com/octy/manage/