---
name: Personas operating guide
version: 1.1.0
status: active
owner: Stoirm Arnold
last_updated: 15-Sep-2026
---

# Personas operating guide

## Purpose

A Persona is a reusable perspective, expertise or mode of thinking that changes how an AI interprets and responds to a task. It is not, by itself, a workflow.

This module follows the deployed system manual for universal naming, metadata, versioning, changelog, archive, rollback and maintained-file rules. This file defines only Personas-specific behaviour.

## Module contract

- **Boundary** — Personas owns reusable perspectives, expertise and modes of thinking. It does not own repeatable workflows, universal maintained-file rules, deployment-specific storage, shared Governance mechanics, or the domain output being produced by the task that invokes a Persona.
- **Outputs** — maintained Persona definitions and Persona discovery/index state. A Persona normally shapes an output owned by the calling task or module rather than creating an independent durable domain record of its own.
- **Dependencies** — `arco-module-manual.md` for the universal module contract; `arco-system-manual.md` for maintained-file behaviour; deployment/local configuration for Persona storage, inventory and selected module controls; Governance for permissions and consent where required.
- **Access scope** — `Personas` at module level, with any finer-grained access resolved through Permissions and deployment configuration.
- **Deployment/local requirements** — a deployed operating copy, canonical Persona location and discoverable index/inventory as described below.
- **Lifecycle state** — **Live**, as recorded in `arco-modules.md`.
- **Maintenance route** — maintained Persona files follow `arco-system-manual.md`; the universal module controls are inherited from `arco-module-manual.md`, while deployment/System Setup owns their selected values.

## Persona vs Skill

Use a Persona when the instruction primarily defines **how the AI should think, interpret or review**.

Use a Skill when the instruction primarily defines **a repeatable sequence of actions or workflow**.

A Persona may use a Skill, and a Skill may request a Persona, but they are separate concepts.

## Before creating a Persona

Ask:

> Does this describe how the AI should think, rather than a sequence of actions it should perform?

If not, consider whether it belongs in Skills instead.

Before creating a new Persona:
1. read the deployment's AI routing guide;
2. read the deployed system manual;
3. read the deployed Personas README;
4. check the deployment's Personas location for an existing Persona that should be extended instead;
5. keep the Persona as light as possible until repeated use justifies more structure.

## Persona structure

Every Persona should contain only the sections it needs, but should normally include:
- Purpose
- Perspective
- Principles
- Behaviour
- Boundaries
- Invocation
- Sources and influences, where relevant
- Preference examples, where relevant
- Changelog

Do not add empty sections merely for completeness.

## Invocation

A Persona must be invokable by name in natural language.

Examples:
- `The Writer: review this article.`
- `Use The Writer on this draft.`

When a Persona is invoked:
1. read the deployed Personas README;
2. read the relevant Persona file;
3. apply the Persona to the current request and its natural follow-up discussion;
4. do not assume the Persona permanently replaces normal assistant behaviour unless the user explicitly requests persistence.

A user may explicitly request persistence, for example:
- `Stay as The Writer for this thread.`

A user may explicitly end the Persona, for example:
- `Drop The Writer.`

If invocation is ambiguous, prefer ordinary assistant behaviour rather than silently applying a Persona.

## Editing Personas

Personas are living configuration files with stable filenames.

When modifying a Persona:
1. read its current contents;
2. preserve the parts that still reflect the intended perspective;
3. add only principles or behaviours evidenced through use, explicit feedback or approved source material;
4. apply the universal maintained-file rules from the deployed system manual;
5. keep preference examples where they materially help the Persona capture the user's or organisation's intended judgement/taste;
6. avoid turning a Persona into a large generic checklist.

## Persona discovery

A deployment using Personas must provide a canonical location for its Persona files and a discoverable index or registry appropriate to the deployment.

The index supports discovery and state; it does not duplicate Persona instructions. Deployment-specific paths, identifiers, actual Persona listings and storage details belong in local configuration or the relevant deployment-maintained index, not in this Core module guide.

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 15-Sep-2026 | 1.1.0 | Aligned Personas with the Module Manual by explicitly defining its boundary, outputs, dependencies, access scope, deployment requirements, lifecycle state and maintenance route without duplicating universal module controls. | Stoirm Arnold | GPT-5.6 Sol |
| 14-Sep-2026 | 1.0.0 | Extracted the organisation-agnostic Personas operating standard from the Stoirm Ltd deployment, delegating universal maintenance rules to the system manual and deployment-specific Persona inventory/paths to local configuration. | Stoirm Arnold | GPT-5.6 Sol (Medium) |