mobieusKnow AI Community Manager: what it does, how to run it, how to control it History #68
Author
Patrick Bass
Submitted
May 30, 2026 2:23am
Reviewed
May 30, 2026 2:23am
Summary
Rewrite: page now documents the AI Community Manager (CM) through Phase 6 (moderation_assist). Adds draft kinds table, HITL invariant, BYOK, tier gate, cron schedule, cost tracking, opt-in flags, audit trail.
+ The **AI Community Manager** drafts member-facing messages and moderation actions for you to review and approve. Nothing it produces sends until you click Approve in `/admin/community-manager`. This page is the reference for what it does, where it runs, and how to control it.
The **AI Community Manager** drafts member-facing messages and moderation recommendations for you to review. Nothing it produces is sent until you approve it. This page explains what it does and how to control it.
+ For the trigger/condition/action rules engine (a separate system that wires events to actions like `add_badge` and `send_dm`), see the automation pages under `/admin/automation`.
The Community Manager is a separate system from the trigger/condition/action rules at `/admin/automation` (see [Automation rules](/know/admin-automation-rules)). This page covers the Community Manager only.
---
## What it does
+
+ The Community Manager (CM) watches your community for six signal types and drafts one of six artefact types in response. Every draft lands in an approval queue. You read it, you edit it if you want, you approve or reject it. Approved drafts post as DMs, forum threads, forum replies, or moderation actions. Rejected drafts never send.
+ Internal codename: mobieusCore. Customer-facing name: AI Community Manager.
The Community Manager watches your community for a handful of signals and drafts a response to each one. Every draft lands in an approval queue. You read it, edit it if you want, then approve or reject it. Approved drafts go out as direct messages, forum posts, or moderation actions. Rejected drafts never send.
---
+
+ ## Draft kinds
+ The CM ships six draft kinds. Each one has its own trigger, its own destination, and its own opt-in flag.
## What it drafts
+ | Kind | Triggered by | What it produces | Posts to (`target_kind`) |
+ |---|---|---|---|
+ | `welcome` | A new member registers (`user.registered` event) | A short personal welcome DM | DM to the new member (`user`) |
+ | `weekly_summary` | Once per ISO week (hourly schedule cron emits a dedup'd event) | A health snapshot of the past week: new joins, active threads, flagged signals | New thread in the admin-only "Community Manager Reports" forum (`tenant`) |
+ | `churn_reengagement` | The engagement scorer flags a member as at-risk | A re-engagement DM tailored to the member | DM to the at-risk member (`user`) |
+ | `meet_suggestion` | The pair matcher finds two members with shared interests + co-activity | A one-way intro DM naming the other member by username | DM to one member (`user_pair`, sent to the lower user id; the other member is named in the body) |
+ | `forum_reply` | The reply scanner finds an unanswered thread that fits known patterns | A drafted reply to the thread | Reply on the original thread, authored by the Support user (`thread`) |
+ | `moderation_assist` | A member files a report (`report.created` event) | A recommended action (dismiss, warn, hide, suspend, escalate) with reasoning and any member-facing messages | Moderation action against the reported content, logged to `/admin/moderation` (`report`) |
| Draft | When it's drafted | What you get |
|---|---|---|
| Welcome | A new member joins | A short, personal welcome message sent to the member |
| Weekly summary | Once a week | A snapshot of the past week (new members, active threads, flagged signals), posted to an admin-only forum |
| Re-engagement | A member is flagged as at risk of going quiet | A tailored message inviting them back |
| Introduction | Two members share interests and recent activity | An intro message that names the other member, sent to one of them |
| Forum reply | A thread goes unanswered and matches a known pattern | A drafted reply you can post to the thread |
| Moderation recommendation | A member files a report | A recommended action — dismiss, warn, hide, suspend, or escalate — with the reasoning |
+ Every draft carries a stable dedup key, so the same event firing twice never creates two drafts for the same target.
Each draft is de-duplicated, so the same event never produces two drafts for the same target.
---
+
+ ## Human in the loop (HITL)
+
+ The CM cannot send anything on its own. Only one function in the whole code base can flip a draft to `sent`: `Dispatcher::executeApproved()`. That function requires:
+
+ - A draft in `pending_approval` status (the worker put it there after generation)
+ - The id of the admin pressing Approve
+ - A valid CSRF token on the request
+ A static-grep test (`HumanInTheLoopTest`) walks the source tree on every CI run and fails the build if any other file writes `cm_draft.status = 'sent'`. The allowlist is one file: `Dispatcher.php`. If you ever add a second writer, CI breaks loudly.
## You approve everything
+ This means: no generator, no worker, no cron job, no event handler can send. They can only enqueue and draft. You are the gate.
The Community Manager cannot send anything on its own. A draft is delivered only when you click Approve. No schedule and no background step can send a message or take a moderation action. You are the gate, every time.
---
+
+ ## BYOK: bring your own Anthropic API key
+ The CM has no Mobieus-side API key. You supply your own Anthropic key at `/admin/community-manager/settings`. Until that key is set, the CM is closed and produces no drafts and makes no API calls.
## Bring your own AI key
+ This is enforced at the lowest layer. The `Spine` gate checks three things in order:
The Community Manager runs on your own Anthropic API key. You add it in Community Manager settings. Until the key is set, the Community Manager stays off: it drafts nothing and makes no API calls.
+ 1. Master flag `ai_community_manager_enabled` is on
+ 2. Your plan is Pro, Creator Plus, or Sovereign
+ 3. Your Anthropic API key is configured
Three things must all be true for it to run:
+ Any one closed, the whole CM is off. The admin UI shows you which gate is closed.
1. The Community Manager is switched on.
2. Your plan is Pro, Creator Plus, or Sovereign.
3. Your Anthropic API key is set.
+ You pay Anthropic directly. The CM logs token counts and computes cost in micro-USD per draft so you can see what you spent.
If any one is missing, the whole Community Manager is off, and the settings page tells you which. You pay Anthropic directly, and every draft records its token count and cost so you can see exactly what you spent.
---
+ ## Tier gate
## Which plans include it
+ The CM is available on **Pro**, **Creator Plus**, and **Sovereign** plans. Free and lower-tier plans do not have access.
The Community Manager is available on **Pro**, **Creator Plus**, and **Sovereign** plans. Starter does not include it.
---
+
+ ## Cron schedule
+ Five workers run on the platform host. Each fans out across active tenants. Each worker re-checks the spine per tenant, so a tenant with the CM off pays zero token cost.
## When drafts appear
+ | Worker | Schedule | What it does |
+ |---|---|---|
+ | `process-cm-queue` | Every minute | Drains `pending_inference` drafts. Runs the matching generator. Persists the body. Flips the draft to `pending_approval` so it shows up in your queue. Bounded at 10 drafts per tenant per tick. |
+ | `process-cm-schedule` | Hourly (`:00`) | Emits the synthetic `schedule.weekly.summary` event once per ISO week per tenant. The Dispatcher subscribes and enqueues one `weekly_summary` draft. Idempotent across all 168 hourly ticks per week. |
+ | `process-cm-engagement` | Hourly (`:15`) | Recomputes engagement scores for members active in the last 90 days. Flags at-risk members. Enqueues up to 5 new `churn_reengagement` drafts per tenant per hour. |
+ | `process-cm-matching` | Every 6 hours (`:30`) | Recomputes pair compatibility across active members. Persists candidates to `cm_suggestion`. Enqueues up to 3 new `meet_suggestion` drafts per tenant per run. |
+ | `process-cm-reply-scan` | Every 2 hours (`:45`) | Scans active forums for unanswered threads matching reply patterns. Enqueues up to 2 new `forum_reply` drafts per tenant per scan. |
- **Welcome**: within about a minute of a member joining.
- **Weekly summary**: once per week.
- **Re-engagement**: at-risk members are reviewed every hour.
- **Introductions**: compatible members are matched a few times a day.
- **Forum replies**: unanswered threads are scanned several times a day.
+ All five log to `/var/log/mobieus/cm-*.log` on the platform host.
Each kind is checked on its own, and every check first confirms the Community Manager is on, so one you've switched off costs you nothing.
---
+ ## Cost tracking
## Cost tracking and controls
+ Every successful generation writes one row to `ai_usage_log` and copies the cost onto the draft row as `cost_micros` (1 USD = 1,000,000 micros).
See what the Community Manager costs at `/admin/community-manager`:
+ Three things are visible to you at `/admin/community-manager`:
- **Per draft** — every draft card shows its token count and cost.
- **30-day total** — the stat strip at the top of the queue shows your rolling spend.
- **By draft type** — spend is tracked per kind, so you can see where it goes.
+ - **Per-draft cost**: shown on every draft card with token counts (`input_tokens` / `output_tokens`)
+ - **30-day rolling total**: shown in the stat strip at the top of the queue
+ - **Per-generator breakdown**: each draft's `feature` tag (e.g. `cm.welcome`, `cm.weekly_summary`) is queryable in `ai_usage_log`
To keep spend predictable, set a monthly budget in Community Manager settings:
+ The CM uses Anthropic's published per-token rates. Pricing per model is hard-coded in `InferenceClient::MODEL_PRICING_MICROS` so cost is computed locally without a round-trip to Anthropic.
- **Monthly token budget** — a cap on the tokens the Community Manager can use in a calendar month. A live meter shows how much of the budget you've used; it turns amber at 80% and red at 100%. Leave it blank for no cap.
- **Budget-alert email** — get an email when usage crosses 80%, and again at 100%.
- **Pause on budget hit** — when this is on and you reach the budget, the Community Manager stops drafting new messages. Drafts already in your queue stay reviewable. Drafting resumes on its own when the budget resets at the start of the next month, or as soon as you raise the cap.
+ ---
The budget counts every kind of Community Manager draft together.
+ ## Opting in and opting out
---
+ The master flag turns the whole CM on or off. Six per-kind sub-flags let you enable just the parts you want:
## Turning kinds on and off
+ | Sub-flag | Controls |
+ |---|---|
+ | `ai_cm_welcome` | Welcome drafts on new member join |
+ | `ai_cm_summary` | Weekly admin-only health summary |
+ | `ai_cm_churn` | Churn re-engagement drafts (engagement scorer must be enabled) |
+ | `ai_cm_suggest` | Meet-suggestion intro drafts |
+ | `ai_cm_forum_reply` | Forum reply drafts |
+ | `ai_cm_moderation` | Moderation recommendations on every report |
Switching the Community Manager on enables it as a whole. Six independent toggles let you run only the parts you want:
+ All six default to **off**. Toggle them at `/admin/config` under the AI group. Sub-flags are independent: you can run welcomes without moderation, summaries without churn, any combination.
- Welcome new members
- Weekly admin summary
- Re-engagement messages
- Introductions
- Forum reply drafts
- Moderation recommendations
+ A sub-flag is only checked once the spine is open. Turning on `ai_cm_welcome` without setting your Anthropic key does nothing.
All six start off. You'll find these toggles in two places: on the Community Manager settings page, and in Site Configuration under the AI group. Turn on any combination — welcomes without moderation, summaries without re-engagement, whatever fits. A toggle does nothing until your Anthropic key is set.
---
## Audit trail
+
+ Every state transition on every draft writes two audit rows:
+
+ - One row in `audit_log` (the platform-wide HMAC-chained, tamper-evident audit chain)
+ - One row in `cm_audit` (CM-specific structured columns: draft id, event, actor, JSON detail)
+
+ `cm_audit` rows reference the `audit_log` row id and copy its integrity hash, so if anyone tampers with `cm_audit` the chain proves it.
+
+ Events that are recorded:
+ - `generated` — worker produced a draft body
+ - `approved` — admin clicked Approve, no edits
+ - `edited_then_approved` — admin edited the body before approving
+ - `rejected` — admin rejected the draft
+ - `sent` — Dispatcher confirmed the artefact was delivered
+ - `send_failed` — delivery failed (network, downstream error)
+ - `superseded` — a newer draft replaced this one before approval
+ - `retried` — worker retried a failed generation
Every step in a draft's life is recorded in a tamper-evident log you can review at `/admin/community-manager/audit`. Recorded steps include:
+ You can view the full chain at `/admin/community-manager/audit`.
- Drafted
- Approved
- Edited, then approved
- Rejected
- Sent
- Send failed
- Replaced by a newer draft
- Retried
---
+ ## Where to learn more
## Where to go
+ - **Queue and approve drafts**: `/admin/community-manager`
+ - **Settings (API key, per-kind toggles)**: `/admin/community-manager/settings`
- **Review and approve drafts**: `/admin/community-manager`
- **Settings** (AI key, per-kind toggles, monthly budget): `/admin/community-manager/settings`
- **Audit trail**: `/admin/community-manager/audit`
+ - **Feature flags**: `/admin/config` (AI group)
+ - **Trigger/condition/action rules engine** (a separate system): `/admin/automation`
+
+ ---
+ *This page documents the AI Community Manager as shipped through Phase 6 (moderation_assist, 2026-05-29). New draft kinds and worker schedules will land in future phases; this page stays current.*

The AI Community Manager drafts member-facing messages and moderation actions for you to review and approve. Nothing it produces sends until you click Approve in /admin/community-manager. This page is the reference for what it does, where it runs, and how to control it.

For the trigger/condition/action rules engine (a separate system that wires events to actions like add_badge and send_dm), see the automation pages under /admin/automation.


What it does

The Community Manager (CM) watches your community for six signal types and drafts one of six artefact types in response. Every draft lands in an approval queue. You read it, you edit it if you want, you approve or reject it. Approved drafts post as DMs, forum threads, forum replies, or moderation actions. Rejected drafts never send.

Internal codename: mobieusCore. Customer-facing name: AI Community Manager.


Draft kinds

The CM ships six draft kinds. Each one has its own trigger, its own destination, and its own opt-in flag.

Kind Triggered by What it produces Posts to (target_kind)
welcome A new member registers (user.registered event) A short personal welcome DM DM to the new member (user)
weekly_summary Once per ISO week (hourly schedule cron emits a dedup'd event) A health snapshot of the past week: new joins, active threads, flagged signals New thread in the admin-only "Community Manager Reports" forum (tenant)
churn_reengagement The engagement scorer flags a member as at-risk A re-engagement DM tailored to the member DM to the at-risk member (user)
meet_suggestion The pair matcher finds two members with shared interests + co-activity A one-way intro DM naming the other member by username DM to one member (user_pair, sent to the lower user id; the other member is named in the body)
forum_reply The reply scanner finds an unanswered thread that fits known patterns A drafted reply to the thread Reply on the original thread, authored by the Support user (thread)
moderation_assist A member files a report (report.created event) A recommended action (dismiss, warn, hide, suspend, escalate) with reasoning and any member-facing messages Moderation action against the reported content, logged to /admin/moderation (report)

Every draft carries a stable dedup key, so the same event firing twice never creates two drafts for the same target.


Human in the loop (HITL)

The CM cannot send anything on its own. Only one function in the whole code base can flip a draft to sent: Dispatcher::executeApproved(). That function requires:

  • A draft in pending_approval status (the worker put it there after generation)
  • The id of the admin pressing Approve
  • A valid CSRF token on the request

A static-grep test (HumanInTheLoopTest) walks the source tree on every CI run and fails the build if any other file writes cm_draft.status = 'sent'. The allowlist is one file: Dispatcher.php. If you ever add a second writer, CI breaks loudly.

This means: no generator, no worker, no cron job, no event handler can send. They can only enqueue and draft. You are the gate.


BYOK: bring your own Anthropic API key

The CM has no Mobieus-side API key. You supply your own Anthropic key at /admin/community-manager/settings. Until that key is set, the CM is closed and produces no drafts and makes no API calls.

This is enforced at the lowest layer. The Spine gate checks three things in order:

  1. Master flag ai_community_manager_enabled is on
  2. Your plan is Pro, Creator Plus, or Sovereign
  3. Your Anthropic API key is configured

Any one closed, the whole CM is off. The admin UI shows you which gate is closed.

You pay Anthropic directly. The CM logs token counts and computes cost in micro-USD per draft so you can see what you spent.


Tier gate

The CM is available on Pro, Creator Plus, and Sovereign plans. Free and lower-tier plans do not have access.


Cron schedule

Five workers run on the platform host. Each fans out across active tenants. Each worker re-checks the spine per tenant, so a tenant with the CM off pays zero token cost.

Worker Schedule What it does
process-cm-queue Every minute Drains pending_inference drafts. Runs the matching generator. Persists the body. Flips the draft to pending_approval so it shows up in your queue. Bounded at 10 drafts per tenant per tick.
process-cm-schedule Hourly (:00) Emits the synthetic schedule.weekly.summary event once per ISO week per tenant. The Dispatcher subscribes and enqueues one weekly_summary draft. Idempotent across all 168 hourly ticks per week.
process-cm-engagement Hourly (:15) Recomputes engagement scores for members active in the last 90 days. Flags at-risk members. Enqueues up to 5 new churn_reengagement drafts per tenant per hour.
process-cm-matching Every 6 hours (:30) Recomputes pair compatibility across active members. Persists candidates to cm_suggestion. Enqueues up to 3 new meet_suggestion drafts per tenant per run.
process-cm-reply-scan Every 2 hours (:45) Scans active forums for unanswered threads matching reply patterns. Enqueues up to 2 new forum_reply drafts per tenant per scan.

All five log to /var/log/mobieus/cm-*.log on the platform host.


Cost tracking

Every successful generation writes one row to ai_usage_log and copies the cost onto the draft row as cost_micros (1 USD = 1,000,000 micros).

Three things are visible to you at /admin/community-manager:

  • Per-draft cost: shown on every draft card with token counts (input_tokens / output_tokens)
  • 30-day rolling total: shown in the stat strip at the top of the queue
  • Per-generator breakdown: each draft's feature tag (e.g. cm.welcome, cm.weekly_summary) is queryable in ai_usage_log

The CM uses Anthropic's published per-token rates. Pricing per model is hard-coded in InferenceClient::MODEL_PRICING_MICROS so cost is computed locally without a round-trip to Anthropic.


Opting in and opting out

The master flag turns the whole CM on or off. Six per-kind sub-flags let you enable just the parts you want:

Sub-flag Controls
ai_cm_welcome Welcome drafts on new member join
ai_cm_summary Weekly admin-only health summary
ai_cm_churn Churn re-engagement drafts (engagement scorer must be enabled)
ai_cm_suggest Meet-suggestion intro drafts
ai_cm_forum_reply Forum reply drafts
ai_cm_moderation Moderation recommendations on every report

All six default to off. Toggle them at /admin/config under the AI group. Sub-flags are independent: you can run welcomes without moderation, summaries without churn, any combination.

A sub-flag is only checked once the spine is open. Turning on ai_cm_welcome without setting your Anthropic key does nothing.


Audit trail

Every state transition on every draft writes two audit rows:

  • One row in audit_log (the platform-wide HMAC-chained, tamper-evident audit chain)
  • One row in cm_audit (CM-specific structured columns: draft id, event, actor, JSON detail)

cm_audit rows reference the audit_log row id and copy its integrity hash, so if anyone tampers with cm_audit the chain proves it.

Events that are recorded:

  • generated — worker produced a draft body
  • approved — admin clicked Approve, no edits
  • edited_then_approved — admin edited the body before approving
  • rejected — admin rejected the draft
  • sent — Dispatcher confirmed the artefact was delivered
  • send_failed — delivery failed (network, downstream error)
  • superseded — a newer draft replaced this one before approval
  • retried — worker retried a failed generation

You can view the full chain at /admin/community-manager/audit.


Where to learn more

  • Queue and approve drafts: /admin/community-manager
  • Settings (API key, per-kind toggles): /admin/community-manager/settings
  • Audit trail: /admin/community-manager/audit
  • Feature flags: /admin/config (AI group)
  • Trigger/condition/action rules engine (a separate system): /admin/automation

This page documents the AI Community Manager as shipped through Phase 6 (moderation_assist, 2026-05-29). New draft kinds and worker schedules will land in future phases; this page stays current.

The **AI Community Manager** drafts member-facing messages and moderation actions for you to review and approve. Nothing it produces sends until you click Approve in `/admin/community-manager`. This page is the reference for what it does, where it runs, and how to control it.

For the trigger/condition/action rules engine (a separate system that wires events to actions like `add_badge` and `send_dm`), see the automation pages under `/admin/automation`.

---

## What it does

The Community Manager (CM) watches your community for six signal types and drafts one of six artefact types in response. Every draft lands in an approval queue. You read it, you edit it if you want, you approve or reject it. Approved drafts post as DMs, forum threads, forum replies, or moderation actions. Rejected drafts never send.

Internal codename: mobieusCore. Customer-facing name: AI Community Manager.

---

## Draft kinds

The CM ships six draft kinds. Each one has its own trigger, its own destination, and its own opt-in flag.

| Kind | Triggered by | What it produces | Posts to (`target_kind`) |
|---|---|---|---|
| `welcome` | A new member registers (`user.registered` event) | A short personal welcome DM | DM to the new member (`user`) |
| `weekly_summary` | Once per ISO week (hourly schedule cron emits a dedup'd event) | A health snapshot of the past week: new joins, active threads, flagged signals | New thread in the admin-only "Community Manager Reports" forum (`tenant`) |
| `churn_reengagement` | The engagement scorer flags a member as at-risk | A re-engagement DM tailored to the member | DM to the at-risk member (`user`) |
| `meet_suggestion` | The pair matcher finds two members with shared interests + co-activity | A one-way intro DM naming the other member by username | DM to one member (`user_pair`, sent to the lower user id; the other member is named in the body) |
| `forum_reply` | The reply scanner finds an unanswered thread that fits known patterns | A drafted reply to the thread | Reply on the original thread, authored by the Support user (`thread`) |
| `moderation_assist` | A member files a report (`report.created` event) | A recommended action (dismiss, warn, hide, suspend, escalate) with reasoning and any member-facing messages | Moderation action against the reported content, logged to `/admin/moderation` (`report`) |

Every draft carries a stable dedup key, so the same event firing twice never creates two drafts for the same target.

---

## Human in the loop (HITL)

The CM cannot send anything on its own. Only one function in the whole code base can flip a draft to `sent`: `Dispatcher::executeApproved()`. That function requires:

- A draft in `pending_approval` status (the worker put it there after generation)
- The id of the admin pressing Approve
- A valid CSRF token on the request

A static-grep test (`HumanInTheLoopTest`) walks the source tree on every CI run and fails the build if any other file writes `cm_draft.status = 'sent'`. The allowlist is one file: `Dispatcher.php`. If you ever add a second writer, CI breaks loudly.

This means: no generator, no worker, no cron job, no event handler can send. They can only enqueue and draft. You are the gate.

---

## BYOK: bring your own Anthropic API key

The CM has no Mobieus-side API key. You supply your own Anthropic key at `/admin/community-manager/settings`. Until that key is set, the CM is closed and produces no drafts and makes no API calls.

This is enforced at the lowest layer. The `Spine` gate checks three things in order:

1. Master flag `ai_community_manager_enabled` is on
2. Your plan is Pro, Creator Plus, or Sovereign
3. Your Anthropic API key is configured

Any one closed, the whole CM is off. The admin UI shows you which gate is closed.

You pay Anthropic directly. The CM logs token counts and computes cost in micro-USD per draft so you can see what you spent.

---

## Tier gate

The CM is available on **Pro**, **Creator Plus**, and **Sovereign** plans. Free and lower-tier plans do not have access.

---

## Cron schedule

Five workers run on the platform host. Each fans out across active tenants. Each worker re-checks the spine per tenant, so a tenant with the CM off pays zero token cost.

| Worker | Schedule | What it does |
|---|---|---|
| `process-cm-queue` | Every minute | Drains `pending_inference` drafts. Runs the matching generator. Persists the body. Flips the draft to `pending_approval` so it shows up in your queue. Bounded at 10 drafts per tenant per tick. |
| `process-cm-schedule` | Hourly (`:00`) | Emits the synthetic `schedule.weekly.summary` event once per ISO week per tenant. The Dispatcher subscribes and enqueues one `weekly_summary` draft. Idempotent across all 168 hourly ticks per week. |
| `process-cm-engagement` | Hourly (`:15`) | Recomputes engagement scores for members active in the last 90 days. Flags at-risk members. Enqueues up to 5 new `churn_reengagement` drafts per tenant per hour. |
| `process-cm-matching` | Every 6 hours (`:30`) | Recomputes pair compatibility across active members. Persists candidates to `cm_suggestion`. Enqueues up to 3 new `meet_suggestion` drafts per tenant per run. |
| `process-cm-reply-scan` | Every 2 hours (`:45`) | Scans active forums for unanswered threads matching reply patterns. Enqueues up to 2 new `forum_reply` drafts per tenant per scan. |

All five log to `/var/log/mobieus/cm-*.log` on the platform host.

---

## Cost tracking

Every successful generation writes one row to `ai_usage_log` and copies the cost onto the draft row as `cost_micros` (1 USD = 1,000,000 micros).

Three things are visible to you at `/admin/community-manager`:

- **Per-draft cost**: shown on every draft card with token counts (`input_tokens` / `output_tokens`)
- **30-day rolling total**: shown in the stat strip at the top of the queue
- **Per-generator breakdown**: each draft's `feature` tag (e.g. `cm.welcome`, `cm.weekly_summary`) is queryable in `ai_usage_log`

The CM uses Anthropic's published per-token rates. Pricing per model is hard-coded in `InferenceClient::MODEL_PRICING_MICROS` so cost is computed locally without a round-trip to Anthropic.

---

## Opting in and opting out

The master flag turns the whole CM on or off. Six per-kind sub-flags let you enable just the parts you want:

| Sub-flag | Controls |
|---|---|
| `ai_cm_welcome` | Welcome drafts on new member join |
| `ai_cm_summary` | Weekly admin-only health summary |
| `ai_cm_churn` | Churn re-engagement drafts (engagement scorer must be enabled) |
| `ai_cm_suggest` | Meet-suggestion intro drafts |
| `ai_cm_forum_reply` | Forum reply drafts |
| `ai_cm_moderation` | Moderation recommendations on every report |

All six default to **off**. Toggle them at `/admin/config` under the AI group. Sub-flags are independent: you can run welcomes without moderation, summaries without churn, any combination.

A sub-flag is only checked once the spine is open. Turning on `ai_cm_welcome` without setting your Anthropic key does nothing.

---

## Audit trail

Every state transition on every draft writes two audit rows:

- One row in `audit_log` (the platform-wide HMAC-chained, tamper-evident audit chain)
- One row in `cm_audit` (CM-specific structured columns: draft id, event, actor, JSON detail)

`cm_audit` rows reference the `audit_log` row id and copy its integrity hash, so if anyone tampers with `cm_audit` the chain proves it.

Events that are recorded:

- `generated` — worker produced a draft body
- `approved` — admin clicked Approve, no edits
- `edited_then_approved` — admin edited the body before approving
- `rejected` — admin rejected the draft
- `sent` — Dispatcher confirmed the artefact was delivered
- `send_failed` — delivery failed (network, downstream error)
- `superseded` — a newer draft replaced this one before approval
- `retried` — worker retried a failed generation

You can view the full chain at `/admin/community-manager/audit`.

---

## Where to learn more

- **Queue and approve drafts**: `/admin/community-manager`
- **Settings (API key, per-kind toggles)**: `/admin/community-manager/settings`
- **Audit trail**: `/admin/community-manager/audit`
- **Feature flags**: `/admin/config` (AI group)
- **Trigger/condition/action rules engine** (a separate system): `/admin/automation`

---

*This page documents the AI Community Manager as shipped through Phase 6 (moderation_assist, 2026-05-29). New draft kinds and worker schedules will land in future phases; this page stays current.*