Skip to main content

Prompt Control

Prompt Control is the lead-only surface for tuning how SABLE behaves in production. Use it when SABLE needs a behavior adjustment: tone, prioritization, evidence standards, naming, escalation rules, or a standing preference that should apply to future runs.

It lives in the SABLE app at /admin.html. Leads and admins see it as Prompt in the app navigation.

This page covers changing the prompt. For the recurring routine that keeps it from growing without limit — working the proposal queue, the health check, retiring folded rules, and comparing against the canonical prompt — see Prompt Maintenance.

Who can change the live prompt​

Any admin or lead can open Prompt Control, edit the draft, and Test it. But promoting a prompt live, rolling back, and approving learned rules are restricted to a single prompt owner (Lindsey) so behavior doesn't drift — everyone else submits prompt ideas via a ticket. The owner is configured by the SABLE_PROMPT_OWNER environment variable (the owner's email); if it isn't set, those actions fall back to any admin/lead. Non-owners see the Promote/Approve/Rollback controls disabled with a "prompt owner only" note.

What You Are Editing​

The page has two prompt layers:

  • Live base prompt is the editable foundation for SABLE's behavior.
  • Managed rules are machine-managed learned rules folded in from approved prompt_update proposals.

Edit the live base prompt when you want to change SABLE's standing behavior deliberately. Do not paste temporary project notes, client facts, or one-off task instructions into the base prompt. Those belong in the project spine, source documents, approvals, or the immediate request.

The managed rules panel is read-only on purpose. Approve or reject proposed rules from the queue instead of hand-editing that block.

Everyday Flow​

  1. Open Prompt from SABLE's navigation.
  2. Read the current Live base prompt and Managed rules.
  3. Edit only the base prompt.
  4. Click Test.
  5. Read the staged output.
  6. If the staged output behaves correctly, click Promote.
  7. After promotion, confirm the page says the prompt is synced and the agent version changed.

Testing runs the candidate prompt through a staged agent session. It can read the live spine, but it uses staging safeguards so the test does not deliver boards or propose production actions.

When To Use Test​

Use Test before every meaningful prompt change. A good test should answer:

  • Did SABLE keep the intended tone?
  • Did it cite or ground claims the way we expect?
  • Did it avoid overreaching?
  • Did it preserve the rules already shown in Managed rules?
  • Did the change fix the issue without making SABLE more vague?

Small typo fixes are low risk, but the safest habit is still test, then promote.

Promoting A Change​

Click Promote only when the staged result is acceptable. Promote writes the edited base prompt to the live production agent and records a prompt version for rollback.

Before promoting, check:

  • The edit is general enough to help future work.
  • The edit does not encode private one-off context as a permanent rule.
  • The edit does not conflict with the managed rules panel.
  • The edit does not ask SABLE to skip evidence, approvals, access checks, or client safety language.

After promoting, SABLE uses the new prompt for future agent runs. Runs that already started keep whatever prompt they started with.

Proposed Rules​

The Proposed rules panel shows pending prompt updates that SABLE or the learning loop has suggested.

  • Approve accepts the rule and folds it into the managed rules block.
  • Reject dismisses the rule.

Approve rules that are durable, clear, and behavior-level. Reject rules that are project-specific, duplicative, too broad, or based on a single weird output.

Good rule:

When summarizing a client decision, include the source meeting or document when available.

Bad rule:

Always mention Tuesday's HubSpot call before the project budget.

If approving a rule shows Rule approved; fold needs retry, the approval was saved but the prompt fold did not complete. Reload the page and try again later, or ask engineering to retry apply_prompt_rules.

Rollback​

Use History when a promoted prompt makes SABLE worse.

  1. Find the last known-good version.
  2. Click Rollback on that version.
  3. Confirm the rollback.
  4. Run a quick Test to verify the restored behavior.

Rollback creates a new live agent version from the selected historical base prompt. It does not delete the bad version; the audit trail stays intact.

What Not To Put In The Prompt​

Do not put these in the base prompt:

  • Secrets, tokens, passwords, or private keys.
  • Client facts that should live in source documents or the spine.
  • One-time instructions for a single run.
  • Instructions to bypass approval, evidence, permissions, or client release gates.
  • Long pasted transcripts or documents.
  • Personal preferences that only apply to one client unless they are written as a clearly scoped rule.

If the instruction depends on a specific client, project, source, or date, it probably belongs somewhere other than Prompt Control.

Writing Good Prompt Changes​

Prefer small, explicit changes. SABLE usually gets better from one precise instruction, not a paragraph of new philosophy.

Use this shape:

When [specific situation], SABLE should [observable behavior], unless [clear exception].

Examples:

When SABLE drafts client-facing copy, avoid internal system names unless the client already uses that name.
When SABLE states a project risk, include the source signal or say that it is an inference.
When a user asks for a status update, prioritize decisions, blockers, upcoming commitments, and owner names.

If Something Looks Wrong​

Use Reload if the page looks stale after a promote or rollback.

If the page says Lead access required, confirm you are signed in with a lead or admin account. The navigation hides Prompt Control for non-leads, and the server enforces the same rule.

If Test fails, do not promote. Keep the current live prompt as-is and ask engineering to inspect the staged session.

If Promote fails, copy the visible error into the engineering thread. The live prompt should remain on the previous version.

If SABLE behaves badly after a promote, rollback first, then diagnose. The rollback path is intentionally faster than a code deploy.