Workflow lifecycles
Read ModFlow work as explicit state transitions across signals, evidence, decisions, execution, and durable records.
- Audience
- moderator · senior reviewer · team lead · server admin
- Availability
- free · premium preview · feature flagged · private beta access
- Maturity
- alpha · beta · partial
Last reviewed
On this page
Read the state before taking the next action
Jails, cases, Ban Reviews, scheduled actions, and recorded sessions use different state names, but the same discipline applies: read the current state, take one permitted transition, and verify the resulting record.
A shared lifecycle reading model
| Stage | Operator question | Examples |
|---|---|---|
| Signal | What created the work and for which server? | Command, report, source message, alert, scheduled item |
| Evidence | What visible source supports review? | Case material, transcript artifact, history |
| Decision | Who recorded judgment and what remains pending? | Case decision, appeal outcome, Ban Review approval |
| Execution | Did the requested Discord action actually complete? | Applied, denied, failed, cancelled, or retryable execution |
| Record | Where can another authorized operator reconstruct the result? | Timeline, action record, transcript status |
Trace one work item from signal to record
Identify the owning record
Match the server, record identifier, source, and workflow type across Discord and dashboard surfaces.
Check: You are reading one authoritative work item.
Read current and prior states
Refresh the view and inspect the latest status plus relevant timeline events.
Check: The last confirmed transition and actor are clear.
Take one enabled transition
Choose only a visible action supported by your role and the current state.
Check: The request stays within that action and records the actor.
Verify the resulting record
Confirm the new state, execution result, and any remaining follow-up.
Check: Completion or recovery is explicit rather than inferred.
An authorized operator can explain what created the work, which state it is in, what changed, and where the result is recorded.
Read state as a contract, not a label
| Question | Example | Risk when skipped |
|---|---|---|
| What record owns the state? | Case ID, active jail ID, appeal ID, scheduled item ID, session ID. | Two similar Discord messages are treated as one workflow. |
| What transition produced it? | Claimed, decided, execution requested, cancelled, released. | A stale label hides the last actor/action. |
| What transition is allowed next? | Pending can cancel; executing may not. Approved can execute; executed cannot execute again. | Invalid or duplicate writes. |
| What proves completion? | Stored terminal state plus current Discord result and required side effects. | A button click or approval is mistaken for completion. |
Compare in-scope workflow lifecycles
| Workflow | Common states | Completion means |
|---|---|---|
| Direct action | Requested → executing → completed / denied / failed / already handled. | Discord state and stored action result agree. |
| Jail | Active → release requested → released / partial / paused/rejoin handling. | Restriction ended, active record closed, cleanup/artifact status recorded. |
| Case | Open → claimed/assigned → evidence/review → decided → executed → closed; reopen possible. | Decision, execution, follow-up, and final summary are recorded. |
| Appeal | Submitted → pending/in review → approved / denied / escalated / expired. | Decision recorded and any required reversal verified separately. |
| Ban Review | Requested → review → approved/rejected/reduced/escalated → execution pending → completed/failed. | Senior decision and separate action execution/finalization are explicit. |
| Scheduled action | Pending → executing → executed / failed; pending → cancelled. | Final queue state and linked moderation result are visible. |
| Automation recommendation | Enabled rule → trigger → recommendation → human review/dismissal/action. | Human disposition is recorded; rule never punishes automatically. |
| Soundcheck | Configured → noticed/consent → active/recording → stopped → processing → artifact available/partial/failed. | Session, consent, recording, transcript, publication, and visibility statuses are stated separately. |
Resolve Discord/dashboard disagreement
Match identities
Confirm server and owning record ID/number on both surfaces.
Check: The comparison refers to one work item.
Refresh the detail page
Use the owning dashboard detail, not a summary card or old Discord embed.
Check: The latest stored state is visible.
Read the latest event
Identify actor, transition, time, and execution result.
Check: The last confirmed change is known.
Check external Discord state
Inspect the member, ban, role, channel, or session.
Check: Stored state is compared to the external effect.
Preserve discrepancy
Record timestamps/screenshots without private content and stop duplicate writes.
Check: The mismatch can be diagnosed without changing either record.
Two surfaces still disagree
What you see: The owning detail page and current Discord state show incompatible outcomes.
What may be happening: A partial side effect, delayed update, failed worker, stale cache, concurrent moderator, or manual Discord change can create drift.
What to do
- Do not force the state with an unrelated command.
- Record the owning record, latest event, external Discord state, and exact times.
- Use the workflow’s supported recovery control if one is explicitly available.
- Escalate unresolved drift to a server administrator/product support without private evidence.
Use a universal closure standard
| Check | Complete when |
|---|---|
| Scope | Server, target, incident, and owning record are correct. |
| Evidence | Relevant visible evidence and gaps are summarized with provenance. |
| Decision | Authorized human outcome and reason are recorded. |
| Execution | Requested action result is terminal or a named recovery owner exists. |
| Side effects | The record states the result of notifications, cleanup, scheduled work, and artifacts. |
| Visibility | Restricted material remains restricted and redaction is preserved. |
| Handoff | No unresolved task lacks an owner. |
| Final summary | Another authorized operator can reconstruct the result without chat memory. |
Recover when two surfaces disagree
A Discord message or open browser tab can be stale. Partial states, hidden evidence, failed execution, and cancelled work must remain distinguishable from completion.
A cross-workflow state is unclear
What you see: The visible status, permission, source, or execution result does not support a confident next action.
What may be happening: The viewer may be reading a stale surface, a narrowed view, a separate lifecycle stage, or a partial operation result.
What to do
- Refresh the owning record before acting again.
- Compare the latest timeline event with the visible status.
- Open the concrete workflow guide for valid transitions.
- Escalate with the server, record identifier, current state, and last visible result.
Account for conversation, queue, and review states
Appeal messages can be internal, queued, accepted, failed, or held for routing. Event logs move through an outbox and retry lifecycle. Assignments add claim, delegate, replace, approve, and close states. A future MIRA run adds collection, provider, report, human-review, retry, cancel, and retention states. Scheduled work can become plan-blocked.