Octy profiles

An Octy™ profile lets the organisation put Octy on a chosen body of knowledge for a chosen audience, with its own limits and monthly cap, without changing code.

Octy is the same agent in every deployment, with an Octy profile for each use. A profile is configuration: it names the knowledge Octy may read, who may ask it, where they ask, the limits it runs under, how its models are chosen, and where it runs. Octy’s character and rules are defined in code. Profile settings cannot change them or grant a tool that writes, approves, pays or changes access.

Octy profiles are managed on the Octy profiles page in LightHouse™ and applied to a client deployment by signed command. A client deployment applies them when its policy turns on octy_profiles, which is off by default. Without it, Octy in a client deployment is configured in one file in the organisation’s catalogue repository, as described below.

An Octy profile: set by client administrators in LightHouse

• Name and scope: a short name, and one or two sentences on what it answers about
• Tier and audience: public, NDA or internal; the public, signed-in customers, or staff
• Knowledge: the corpora it may search, all held where the profile runs
• Channels: web panel, website widget, portal, Teams, Slack, MCP, API
• Controls: rate limits, address lists, origins and pages, bot check, monthly cap
• Router: a quality bar, and optionally the models it may choose from
• Runs on: Atlantic-hosted, or one of the organisation’s deployments

Checked by LightHouse; enforced where the profile runs, outside the prompt

• Boundary (downward): only the profile’s knowledge, within the caller’s access
• Controls (downward): checked on every request, before any model is called
• Router (downward): the cheapest model that meets the profile’s bar

Octy: the same code, character and rules everywhere

• Answers: from retrieved passages, each source cited
• Says when it cannot: “not covered”, before an answering model is called
• Does not act: no tool that approves, pays or changes access or a limit
• Hands work on: to an agent, through an approval card

A profile is configuration. LightHouse checks it on every change and again on publishing. The service that answers applies its boundary and controls outside the model's prompt, and the text of a question cannot widen them.

The settings

Setting	Values
Name and short name	A display name, and a short name of lower-case letters, digits and hyphens that appears in the profile’s address and in the widget
Scope	One or two plain sentences on what the profile answers about, shown to the people it answers. It sets the subject; it cannot change Octy’s rules
Disclosure tier	Public, NDA or internal. The tier limits the knowledge the profile may hold. See Disclosure tiers
Audience	The public; signed-in customers; staff, through the organisation’s sign-in
Knowledge	One or more corpora: a knowledge base, a connected source, an uploaded collection, the tenant’s LightHouse data, or Atlantic’s public documentation and published knowledge. See Knowledge and boundaries
Runs on	Atlantic-hosted, or a named deployment of yours. A profile runs where its knowledge is held. See Where Octy runs
Channels	Web panel, website widget, LightHouse portal, Microsoft Teams, Slack, MCP and the API, each switched on or off. See Channels
Controls	Rate limits per visitor, per session and overall, with separate limits for answers that use a model; address allow and deny lists; allowed origins and pages; the bot check; a monthly cap with an alert. See Controls
Router	A quality bar (standard, high or strict) and, optionally, the models the router may choose from. See The router for every profile

Each tier has its own default controls, which LightHouse fills in when a profile is created or its tier changes, and which an administrator can then adjust within fixed ceilings. The defaults and ceilings are in the client documentation.

States and revisions

A profile is in one of three states:

State	What it means
Draft	The initial state of every profile. Answers only test questions from a client_admin in the test panel
Live	Published: it answers its audience on its channels
Paused	Does not answer until resumed. A visitor receives a notice that Octy is unavailable

Every change makes a new revision, numbered from 1. Publishing runs every check again. An edit made against an earlier revision is refused. A live profile must be paused before it is deleted. See Manage Octy profiles.

Rules every profile keeps

LightHouse checks these on every change and again on publishing, and refuses a profile that breaks one, naming the field.

• The tier fits the audience. A public audience needs the public tier; the public tier answers only the public or signed-in customers.
• A public profile holds only published knowledge. A corpus counts as published only when every document in it is cleared for the public tier. LightHouse determines this from the deployment’s report on its index. Values in the request are not used.
• A public profile has the bot check on. It cannot be turned off for a public audience.
• Knowledge is read where it is held. A profile over the client’s own knowledge runs in the client’s deployment. A profile over the tenant’s LightHouse data or Atlantic’s public material runs at Atlantic. A profile cannot mix the two. LightHouse does not store client content.
• Channels fit the audience. The widget needs at least one allowed origin; MCP and the API need an audience that signs in; Teams and Slack need a deployment with that channel connected.
• The boundary is enforced in the engine. A profile sees only its own corpora. The limit is applied inside the search, by the same access scoping that limits what a person can search, so the text of a question cannot widen it.
• Actions require a person. A profile can hand work to an agent where its audience is signed in. It holds no approval, payment, role or key tool. See Octy and agents.
• Who pays. Profiles in a client deployment run on the client’s models, through its gateway, and the client pays its own provider. Atlantic-hosted profiles run in Atlantic’s account.
• Client separation. Conversations, indexes, memory and credentials are not shared between one client’s profiles and another’s.

Built-in profiles and profiles in use

Profile	Knowledge	Audience	Runs on	Status
Octy in a client deployment	The organisation’s documents and sources, read in place	Staff, through the organisation’s channels	Client deployment	Built
Octy in the LightHouse portal	The tenant’s LightHouse data, read under the person’s role	People signed in to the tenant	Atlantic-hosted	Built
Octy on these docs	This documentation, the OpenAPI document and the MCP reference	The public	Atlantic-hosted	Built, as the built-in profile docs
Client-created profiles	Any knowledge the deployment reports, or the tenant’s LightHouse data	Any audience the tier allows	Where the knowledge is	Built

Atlantic’s own public profiles, such as the one on these docs, are built-in profiles managed by Atlantic staff through the same checks. Their short name, owner and tier are fixed.

Before Octy profiles

Until the Octy profiles page is available in the tenant, Octy in a client deployment is configured in one file in the organisation’s catalogue repository, and released through the release gate like any agent change. Our certified forward-deployed engineers set it up and evaluate it with the organisation.