DOI: To be assigned
Author: John Swygert
Date: May 16, 2026
Abstract
This paper proposes the Secretary Suite Plume Activation Layer: a lightweight, optional interface mechanism for activating task-specific AI context at the beginning of a thread, workspace, session, or device interaction. The central design problem is that powerful AI systems require context, files, permissions, task rules, output format, and user preferences, yet forcing every user through a heavy setup process creates friction. The proposed solution is an optional visible activation symbol — the Plume — that asks a simple first question such as, “Do you want to access Codex, John?” or “Do you need specific criteria for this thread?” If the user declines, normal conversation proceeds. If the user accepts, a layered setup menu opens, allowing the user to activate Codex, choose files or workspaces, define task criteria, select output format, apply project rules, and save recurring preferences. This design uses progressive disclosure: basic interaction remains simple, while advanced customization appears only when needed. The Plume thus becomes a recognizable context-control symbol for Secretary Suite: not merely a settings icon, but a structured authority interface through which users define what the AI may access, how it should behave, and what kind of work it should perform.
Body
1. Purpose
The purpose of the Secretary Suite Plume Activation Layer is to solve a practical problem in AI work: every task does not require the same context.
A user may open one thread for DOI metadata, another for legal documents, another for a book chapter, another for Codex work, another for personal planning, and another for creative writing. These threads should not automatically share every file, tone, memory, or instruction. However, the user should also not be forced to manually restate the entire project context every time.
The Plume solves this by creating an optional beginning-of-thread gateway.
The user can proceed normally, as in ordinary chat, or activate a structured workspace setup when a task requires specific criteria.
The basic principle is:
Normal conversation must remain frictionless. Structured workspace activation must remain available.
2. Core Interface Concept
The Secretary Suite interface should include a visible, recognizable activation symbol.
A feathered plume is proposed as the primary symbol because it evokes writing, recordkeeping, assistance, authorship, administrative intelligence, and trusted correspondence.
The Plume should appear as a small interface mark in a consistent location, such as the upper side menu, top bar, or context panel.
The user may hover over it, tap it, or click it.
When inactive, the Plume remains quiet and nonintrusive.
When activated, it opens a context menu for thread setup, workspace selection, Codex access, and task-specific criteria.
The Plume is not merely a decorative logo. It is a context activation interface.
It answers the question:
What should the AI know, access, obey, and produce in this session?
3. First Question
The first question should be simple, optional, and non-cumbersome.
Preferred form:
Do you want to access Codex, John?
Alternative general form:
Do you need specific criteria for this thread, or shall we move forward normally?
Interface options:
Yes — Open Workspace Setup
No — Continue Normally
This first question is essential because it teaches the user that there are two valid modes:
- natural conversation, and
- structured workspace activation.
The user should never feel blocked by setup questions. The Plume is a doorway, not a checkpoint.
4. Design Law: Optional, Not Cumbersome
The Secretary Suite setup path must never become a bureaucratic obstacle.
The default state is normal conversation.
The setup path appears only when the user chooses it or when the user has enabled a preference to ask at the beginning of every thread.
The activation prompt should be brief enough to ignore, but clear enough to teach the user that structured setup is available.
Design law:
Default = natural conversation
Optional = structured workspace activation
Advanced = layered criteria only when requested
This prevents the system from becoming heavy while preserving the full power of a customized AI workspace.
5. Layered Question Architecture
The Plume should support multiple layers of optional questions.
The layers should appear only as needed.
This follows the principle of progressive disclosure: show simple options first, then reveal advanced options only when the user requests them.
Layer 1: Activation
Layer 1 asks whether the user wants to activate a workspace or special criteria.
Example:
Do you want to access Codex, John?
or:
Do you need specific criteria for this thread?
If the user says no, the thread proceeds normally.
If the user says yes, Layer 2 opens.
Layer 2: Work Type
Layer 2 identifies the broad kind of work.
Possible choices:
- Codex / local workspace
- DOI / CrossRef / metadata
- Paper drafting
- Book drafting or editing
- Blog or article writing
- Legal / tax / personal administration
- Medical preparation
- Creative writing, poetry, or lyrics
- Website or domain work
- General conversation / brainstorming
This layer should not exceed ten choices.
The user may also type a custom work type.
Layer 3: Task Criteria
Layer 3 asks task-specific questions.
For Codex:
- Which workspace or folder should be active?
- Should Codex read the project instructions first?
- Should Codex inspect files before editing?
- Should Codex make changes automatically or propose them first?
- Should the final output include a summary of files changed?
For DOI / CrossRef:
- Should the DOI Master Ledger be checked first?
- Which category should be used, or should the LLM classify each paper?
- Should Suggested DOI be generated?
- Should Issued DOI remain blank?
- Should output follow exact CrossRef field order?
For books:
- Which book or series is active?
- Is this drafting, editing, formatting, outlining, or metadata work?
- What chapter structure should be used?
- Should existing style rules apply?
- Should humor, formality, or literary voice be emphasized?
For legal, tax, or personal administration:
- What document type is active?
- Is the goal summary, letter drafting, checklist, or filing preparation?
- Are there deadlines?
- Should the tone be formal, plain-language, or firm?
- Are there sensitive details that should be minimized?
Layer 4: Deep Customization
Layer 4 is optional and only appears when needed.
Possible deep customization questions:
- What hard rules must be followed?
- What sources or files must be checked before answering?
- What output format is required?
- What tone is required?
- What should be avoided?
- Should the AI ask clarifying questions or proceed with best judgment?
- Should the result become a saved template?
- Should any criteria become permanent preferences?
- Should the workspace be locked to certain files only?
- Should the AI produce a log of decisions made?
Again, no layer should force more than ten questions.
The system should reveal deeper layers only when the user asks for them or when the task clearly benefits from them.
6. Standard Question Set
A universal standard question set can be used when the user clicks the Plume but does not choose a specific task type.
Recommended universal questions:
- What is the main task for this thread?
- Do you want to access Codex or a project workspace?
- What files, folders, or sources should be active?
- What output format do you want?
- What tone should be used?
- Are there hard rules I must follow?
- Are there things I must avoid?
- Should I ask questions first or proceed with best judgment?
- Should these criteria apply only to this thread or become a saved preference?
- Shall I begin now using these criteria?
This question set should be editable by the user.
The user should be allowed to suggest additional criteria that may become permanent defaults.
7. Saved Templates
The Plume should support saved templates.
A template is a reusable bundle of criteria.
Examples:
- DOI / CrossRef Thread
- Codex Workspace Thread
- Book Drafting Thread
- Paper Drafting Thread
- Legal Letter Thread
- Medical Preparation Thread
- Blog Article Thread
- KDP Metadata Thread
- Website / Domain Thread
- Creative Writing Thread
Each template should define:
- active files or workspace,
- tone,
- output format,
- rules,
- forbidden actions,
- required checks,
- privacy level,
- whether browsing or external verification is needed,
- whether Codex may edit files,
- and whether the result should be logged.
Templates allow the user to avoid answering the same questions repeatedly.
8. Permanent Preferences and Temporary Criteria
The system must distinguish between temporary thread criteria and permanent user preferences.
Temporary criteria apply only to the current thread.
Permanent preferences apply across future relevant work.
Example temporary criterion:
For this thread only, use category 11000 for all 167X technical addenda.
Example permanent preference:
Always keep Suggested DOI and Issued DOI separate. Never add the obsolete DOI field.
Before saving a new permanent preference, the system should confirm whether the user wants it stored.
This protects the user from accidental long-term rules created during a temporary task.
9. Codex Access
Codex access should be treated as one of the first major activation options.
The opening question may be:
Do you want to access Codex, John?
If the user says yes, the system should ask which workspace or repository should be active.
The system should then check for a local folder, project repository, or uploaded workspace package.
Codex should not assume it can see the user’s files unless those files are actually available in the current environment.
Core rule:
The AI is not the memory. The files are the memory.
The Plume should therefore make file access visible and intentional.
10. Context Safety
The Plume should protect users from accidental context contamination.
A DOI metadata thread should not automatically absorb legal, medical, tax, or creative context.
A personal administration thread should not automatically absorb speculative theory files.
A book project should not be forced into CrossRef metadata formatting.
The user should be able to choose the correct project context at the beginning of the thread.
This preserves privacy, clarity, and task-specific accuracy.
The correct model is:
Right files, right thread, right rules, right task.
11. UI Behavior
The Plume should support the following behaviors:
- hover or tap to open,
- quick activate or quick dismiss,
- optional layered setup,
- saved templates,
- project selection,
- Codex access,
- file/context visibility,
- permission display,
- thread criteria summary,
- and a visible “active criteria” indicator.
The active criteria indicator is important.
If a thread has special rules, the user should be able to see that the Plume is active.
Example:
🪶 Active: DOI / CrossRef Template — Ledger Required
The user should also be able to turn off the active criteria.
12. Example Activation Flow
Example:
Plume: Do you want to access Codex, John?
User: Yes.
Plume: Which workspace should be active?
User: D:_SWYGERT_MASTER_WORKSPACE.
Plume: What kind of task is this?
User: DOI / CrossRef.
Plume: Should I check the DOI Master Ledger before suggesting numbers?
User: Yes, always.
Plume: Should Issued DOI remain blank unless CrossRef has actually issued it?
User: Yes.
Plume: Output format?
User: Exact CrossRef field order, clean markdown only.
Plume: Criteria active. Begin when ready.
This flow creates a customized workspace without forcing setup on every user or every thread.
13. Why This Matters
AI systems are becoming powerful enough to operate across documents, codebases, publication workflows, personal records, and creative projects. The limiting factor is no longer only intelligence. The limiting factor is structured context.
The Plume Activation Layer gives users a simple way to declare context before action.
It turns vague interaction into governed collaboration.
It allows the user to say:
- what task is active,
- what files matter,
- what the AI may access,
- what rules apply,
- what output is required,
- and whether the setup is temporary or permanent.
This is a necessary step toward practical human-supervised AI administration.
Conclusion
The Secretary Suite Plume Activation Layer is a simple but powerful interface concept. It preserves ordinary chat while enabling structured workspace activation when needed. Its purpose is not to slow users down, but to give them an obvious doorway into task-specific AI control.
The Plume symbol becomes a recognizable mark for activating assistance, context, Codex, files, rules, templates, and layered criteria. By using optional setup, progressive disclosure, saved templates, and clear permission boundaries, the Plume can make advanced AI workflows usable without making ordinary conversation cumbersome.
The larger vision is that every serious AI workspace should begin with a choice: proceed naturally, or activate the specific workspace criteria needed for the task. Secretary Suite formalizes that choice. The Plume is the symbol and control layer through which that choice becomes visible, teachable, repeatable, and eventually universal.
References
OpenAI. “Codex CLI.” OpenAI Developers Documentation. Accessed May 16, 2026.
OpenAI. “Introducing Codex.” OpenAI, May 16, 2025.
OpenAI. “Agent Skills.” OpenAI Developers Documentation. Accessed May 16, 2026.
OpenAI Help Center. “Projects in ChatGPT.” Accessed May 16, 2026.
OpenAI Academy. “Using Projects in ChatGPT.” OpenAI Academy, April 10, 2026.
Nielsen Norman Group. “Progressive Disclosure.” December 3, 2006.
Nielsen Norman Group. “Progressive Disclosure.” Video summary, July 15, 2022.
Interaction Design Foundation. “What Is Progressive Disclosure?” Accessed May 16, 2026.