Manage Octy profiles

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
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, 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 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 and The router for every profile.
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.

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
Widget	The widget’s snippet and the content security policy entries for the website. See The website widget
Costs and questions	The profile’s costs, the router’s decisions and its question insights. See Cost analysis and 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.

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 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: <revision>
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 provides an ask_octy tool: a profile’s short name and a question, asked as the caller, read only.