ModeratorFactory is the policy and reversible-transition layer that sits after SpamFactory. SpamFactory produces a structured SpamAssessment; ModeratorFactory consumes that assessment together with bounded application rules and optional owner-profile rules and decides one of four actions: allow, review, hide, or quarantine.
ModeratorFactory does not analyze raw submitted content and does not call AI providers. It is an internal service intended for application adapters such as Guestbook. There is no standalone public API, navbar entry, or user-facing ModeratorFactory GUI.
The default policy is defined in config/moderatorfactory.php. Profile rules may adjust moderation thresholds for an explicitly selected owner profile, and application rules have the final bounded override. Application rules cannot add executable behavior or arbitrary actions.
Default probability thresholds are:
A degraded or unavailable assessment defaults to review unless stronger already-available evidence crosses a hide or quarantine boundary. Thresholds are normalized so review cannot be higher than hide and hide cannot be higher than quarantine.
Every state mutation requires a ModeratorActor and a ModerationTarget.
A normal user actor may moderate only resources owned by the same Tools user. An acknowledged Tools administrator may moderate another owner's resource. Internal automation is represented with ModeratorActor::automation(owner_user_id, application) and is valid only for the exact owner and application exposed by the target. This keeps a Guestbook automation binding from becoming authority over another service or owner.
Authorization is enforced in the transition service, not only in application UI visibility.
Every target exposes its current moderation state and a bounded state-application method. Successful transitions are stored in moderator_factory_transitions with owner, actor, application, optional profile id, resource type/id, previous/current state, decision, result, SpamFactory probability/classification/state, and correlation id.
Denied and failed attempts are also recorded when the audit table is available. Stored metadata is allowlisted and must not contain submitted content, credentials, tokens, provider payloads, or exception messages.
revertLatest() restores the previous state from the latest successful transition. Revert fails closed if the target's current state no longer matches that transition, preventing stale history from overwriting a newer manual or application-specific change.
Operational failures are independently reported through the always-on #toolsapi path with safe service/action/resource/error-class/correlation context. Audit persistence and operational diagnostics are separate concerns.
Application-specific behavior belongs in adapters. An adapter maps a concrete resource to ModerationTarget, supplies the owner-bound profile/application rules, and maps the four generic moderation states to its own storage and presentation contract. It must not duplicate SpamFactory scoring or ModeratorFactory policy logic.