Reputation Flair

Reputation Flair
Type	Reddit moderation and reputation application
Platform	Reddit Devvit
Primary function	Subreddit-level contributor reputation scoring and generated flair display
Runtime model	Event-driven Reddit application with web interface
Storage model	Redis-backed application state
Primary interface	Reputation Portal
Major components	Reputation scoring, generated flair, moderation routing, transparency statistics, RF check reports, human verification, MB3I aggregate analysis, PTT-assisted routing
License	BSD-3-Clause
Documented version	v0.0.8

Reputation Flair is a Reddit Devvit application designed to generate subreddit-local contributor reputation signals. The application records participation history, contribution quality, trigger categories, bot-like signals, optional verification state, and activity count, then condenses those records into generated user flair and related moderation tools.

The system is intended as a community-level moderation and transparency tool, not a universal user ranking system. Reputation records are local to the subreddit where the application is installed. A user's reputation score in one subreddit is not presented as a global judgment of that user across Reddit or outside Reddit.

Reputation Flair differs from vote-based reputation systems because it does not use karma or public votes as the primary basis for scoring. It instead maintains subreddit-local records and applies configurable scoring rules. It also differs from ordinary rule-based moderation systems because it maintains contributor-level history rather than treating each post or comment as an isolated event.

Overview

Reputation Flair combines reputation scoring, generated flair, moderation routing, human verification, public transparency reporting, and contributor lookup tools into one subreddit application. Its public-facing output is a compact user flair that summarizes a contributor's local reputation state. Its administrative function is to give moderators configurable tools for identifying repeated low-quality, hostile, manipulative, spam-like, or bot-like behavior while preserving visibility into how the system is being used.

The application processes subreddit activity through Reddit Devvit event triggers. When a post or comment is created, the application may score the item, update contributor records, update subreddit statistics, write or update generated flair, route the item to review, remove the item under configured conditions, add mod notes, or generate limited bot replies. Most write actions are bounded by rate limits to reduce API pressure and avoid excessive automated activity.

The application also provides a dashboard called the Reputation Portal. The portal may display contributor statistics, subreddit-wide transparency statistics, verification status, frequently asked questions, lookup tools, and optional MB3I or PTT-related analysis. This makes the application both a moderation tool and a public accountability surface.

Purpose

The purpose of Reputation Flair is to make recurring contributor patterns visible at the subreddit level. A single comment may be ambiguous, but repeated behavior across time can form a clearer moderation pattern. Reputation Flair attempts to summarize that pattern in a compact form that moderators and readers can interpret.

The application is intended to help with several moderation problems:

distinguishing long-term constructive contributors from low-history or high-risk accounts;
identifying repeated hostility, dismissal, credibility attacks, condescension, bad-faith framing, manipulation, spam-like behavior, or bot-like behavior;
reducing reliance on one-off moderation decisions;
making automated reputation and enforcement signals more visible;
providing public transparency about subreddit-wide moderation signals;
supporting human verification without requiring every moderation decision to be manual;
giving moderators configurable thresholds rather than fixed enforcement rules.

The application is not intended to replace moderators. Its score is an operational signal, not an absolute judgment. Moderators remain responsible for rule interpretation, context review, appeals, configuration, exemptions, and final enforcement decisions.

Scope

Reputation Flair is subreddit-local. It records and displays information for the subreddit in which it runs. It does not claim to measure a user's entire Reddit history, real-world identity, personality, intelligence, ideology, moral character, or truthfulness.

The application is designed around participation patterns within a community. A high score indicates that the contributor has accumulated favorable local signals under that subreddit's configuration. A low score indicates that the contributor has accumulated unfavorable local signals, trigger pressure, or configured risk markers. A neutral score may indicate mixed behavior, insufficient data, recent activity, or a balance between positive and negative signals.

Because the system is local and configurable, scores should be interpreted in relation to the subreddit where they appear.

Core components

Component	Function
Reputation scoring	Produces a bounded contributor score from positive records, negative records, triggers, bot-like signals, and activity history.
Generated flair	Displays a compact contributor summary directly in Reddit user flair.
Review routing	Sends qualifying posts or comments to moderator review according to configured thresholds.
Removal routing	Removes severe or high-risk posts or comments when removal thresholds are enabled and reached.
Reputation Portal	Provides public and moderator-facing dashboards, statistics, FAQ material, and verification entry points.
Human verification	Allows a subreddit to request or require user verification through a challenge-style flow.
RF check reports	Produces contributor reputation summaries on request or through configured commands.
Transparency statistics	Aggregates subreddit-wide behavior, trigger, verification, and scoring statistics.
MB3I analysis	Optionally records broad family-style text-structure aggregate signals.
PTT-assisted routing	Optionally routes content based on structural text-classification signals.
Moderator configuration	Lets moderators control scoring display, routing thresholds, verification behavior, and feature visibility.

Flair system

The generated flair is the most visible part of Reputation Flair. It condenses the application’s local record for a contributor into a short string attached to that user's subreddit flair.

A generated flair may include several parts:

Flair element	Meaning
Streak or activity marker	Indicates participation continuity or a configured activity signal.
Reputation percentage	Displays the contributor's bounded local reputation score.
Warning count	Displays hard-trigger pressure recorded by the application.
Contribution count	Displays the number of recorded subreddit contributions.
Verification badge	Indicates optional human verification state.
MB3I family label	Shows an optional broad text-structure family signal when enabled.
Color	Applies reputation-dependent visual state when enabled.

A typical display may resemble:

🔥1 · a⁣ ∣ ⚖️ 100% ∣ ⚠️ 0 ∣ ⌨️ [3]

The exact display is configurable. Moderators may choose which flair parts appear, whether color is used, whether existing custom flair text is preserved, whether a verification badge is shown, and whether experimental family labels are included.

The display is intentionally compact. It is meant to be read quickly beside a username while allowing a fuller explanation through the portal or RF check reports.

Reputation percentage

The reputation percentage is a bounded score ranging from −100% to +100%. Positive values indicate favorable local contribution signals. Negative values indicate unfavorable local signals. Values near zero indicate mixed, undeveloped, or insufficiently differentiated records.

The score may be derived from several classes of internal data:

good contribution counts;
bad contribution counts;
good reputation points;
bad reputation points;
hard trigger totals;
bot-trigger totals;
streak or continuity signals;
configured weighting rules;
optional routing or classifier signals.

The score is not designed as a simple ratio of good items to bad items. Negative signals may be weighted more strongly than positive signals because repeated harmful behavior can have greater moderation impact than ordinary constructive participation. A gravity or buffer term can prevent low-sample accounts from swinging too sharply before enough activity has accumulated.

The percentage should be read as a local operational indicator, not as a moral or personal evaluation.

Contributor status bands

The application defines descriptive status bands for reputation ranges. These labels help readers interpret the score without treating every percentage point as a separate qualitative state.

Score range	Status label	General interpretation
85 to 100	Elite contributor	Strong sustained positive local record.
70 to 84	Top contributor	High positive contribution history.
50 to 69	Strong contributor	Consistently constructive record.
30 to 49	Reliable contributor	Generally positive record.
10 to 29	Positive contributor	Mild or developing positive record.
−9 to 9	Mixed contributor	Mixed, neutral, or undeveloped record.
−29 to −10	Developing contributor	Some negative pressure or weak positive history.
−49 to −30	Limited contributor	Recurring negative signals or limited constructive record.
−69 to −50	Minimal contributor	Stronger negative local pattern.
−100 to −70	Needs improvement	Severe or repeated negative local pattern.

These labels do not override context. A contributor may have a low score because of repeated behavior, a small sample, strict configuration, or hard triggers. Moderator review remains necessary for enforcement decisions.

Trigger system

Reputation Flair tracks warning-like signals through internal trigger categories. These triggers summarize behavior patterns and, when configured, help route content for review or removal.

The main trigger families include categories corresponding to:

direct attacks or aggressive address;
dismissive shutdown behavior;
credibility attacks;
condescension;
bad-faith framing;
manipulation or gaslighting-style framing;
minor triggers;
bot-like triggers;
PTT-derived triggers.

The six primary discourse categories are treated differently from minor triggers. Minor triggers may be counted for statistics and profile context without automatically carrying the same routing weight as the main categories. Bot triggers are also tracked separately from ordinary discourse triggers. PTT triggers are stored separately so that structural classifier signals do not get confused with bot-trigger counts.

This separation is important because a single displayed warning number can hide different kinds of risk. A user with many discourse triggers is not the same as a user with bot-like markers, and neither is identical to a user with minor style warnings. The application therefore records multiple internal arrays even when the public flair remains compact.

Contribution counts and reputation points

The application distinguishes contribution counts from reputation points. A user may have a number of good and bad contributions, while the reputation score may also include point weights, trigger penalties, bot pressure, and continuity adjustments.

Contribution counts represent classified items. Reputation points represent weighted scoring impact. This allows the system to count activity while also assigning greater or lesser weight to different kinds of behavior.

The distinction matters because not all negative signals are equal. A low-quality comment, a hostile attack, a manipulation trigger, and a bot-like pattern may all count as negative in some form, but they may not carry the same scoring consequence.

Review routing

Review routing sends posts or comments to the moderator queue when they meet configured thresholds. This allows questionable content to be inspected without immediate removal.

Review routing may consider:

negative point totals;
hard trigger counts;
bot-like signals;
PTT routing signals;
user reputation state;
subreddit configuration;
exemptions for moderators or approved users;
original-poster self-reply protection;
rate limits.

The threshold logic can be configured so that routing occurs when either a negative point threshold or a trigger threshold is reached. This allows moderators to catch both heavily scored items and items that contain several discrete trigger categories.

Review routing is less severe than removal routing. Its purpose is to place content in front of moderators rather than hide it automatically.

Removal routing

Removal routing is a stricter form of automated action. When enabled, it can remove posts or comments that meet configured removal thresholds.

Removal routing may be used for severe negative signals, high trigger totals, bot-like patterns, verification failures, or other configured conditions. It is intended to be stricter than review routing and should be configured carefully.

The application includes protections intended to reduce over-enforcement, including exemptions, rate limits, original-poster self-reply handling, and separation between ordinary triggers, bot triggers, and PTT triggers.

Because false positives are possible, removal routing should be paired with transparency, moderator review, and restoration procedures where appropriate.

Original-poster self-reply protection

The application can treat original-poster self-replies differently from ordinary comments. This is useful because original posters often answer questions, clarify claims, defend their position, or continue a thread in ways that can appear repetitive or argumentative under naive classification.

Original-poster self-reply protection can reduce accidental penalties when a post author replies within their own thread. Configuration may also cap how many good points can be earned from self-replies, preventing a user from artificially building reputation by repeatedly replying to their own post.

Human verification

Reputation Flair includes an optional human verification system. Verification can be disabled, displayed passively, encouraged through reminders, required for certain commands, or required before posting or commenting.

The verification system is intended to reduce bot-like abuse and automated participation while preserving a path for legitimate users to participate. Verification status can be displayed in flair through a badge or checkmark, depending on configuration.

Verification behavior may include:

verification entry through the portal;
reminders for unverified users;
temporary enforcement for unverified posts or comments;
restoration paths after verification;
expiration handling;
configurable cleanup of verification-related comments;
optional requirement before RF check commands.

Human verification is not proof of character or expertise. It is a participation-control signal that helps distinguish verified users from unverified or automated-looking accounts.

RF check reports

RF check reports provide fuller contributor summaries than the compact flair display. A report may include:

reputation percentage;
contribution totals;
good and bad contribution counts;
good and bad reputation points;
warning totals;
bot-trigger totals;
verification state;
first recorded participation context;
activity streak;
moderation routing context;
top MB3I family signals when enabled;
subreddit-local interpretation notes.

RF check output helps moderators and users understand what the flair compresses. It also supports transparency by making the system’s local record more inspectable.

RF check commands may be rate-limited. In communities using human verification, RF check access may also require verification.

Reputation Portal

The Reputation Portal is the application’s main dashboard interface. It provides a central location for contributor information, subreddit transparency statistics, verification access, help content, and moderator-controlled visibility.

The portal may include:

contributor lookup;
personal reputation summaries;
subreddit transparency summaries;
daily aggregate statistics;
FAQ material;
verification controls;
status explanations;
configuration visibility;
MB3I analysis when enabled;
RF check access points.

The portal is important because generated flair is intentionally short. A compact flair string cannot explain how the score was produced, what the warning count means, or what configuration is active. The portal provides the extended context needed to interpret those signals.

Transparency statistics

Reputation Flair includes subreddit-level transparency statistics. These statistics summarize aggregate activity and scoring patterns rather than only individual scores.

Statistics may include:

total posts processed;
total comments processed;
total unique users;
good and bad contribution counts;
trigger totals by category;
bot-trigger totals;
PTT-trigger totals;
review-routing counts;
removal-routing counts;
verification counts;
RF check usage;
skipped-processing markers;
queue or scheduler activity;
daily activity totals;
MB3I family counts when enabled.

Transparency statistics help moderators and community members understand whether the application is acting rarely, frequently, broadly, narrowly, or in category-specific ways. This is important for accountability. A reputation system should not only produce outputs; it should expose enough aggregate context for the community to judge whether the system is behaving appropriately.

MB3I analysis

The application includes optional MB3I analysis. MB3I is used as an aggregate family-style classifier based on text-structure patterns. It is not a personality diagnosis and should not be treated as proof of a user's psychological type.

The implemented family structure groups text into broad no-I/E families:

Family	Label
NFJ	Intuition-feeling-judging family
NFP	Intuition-feeling-perceiving family
NTJ	Intuition-thinking-judging family
NTP	Intuition-thinking-perceiving family
SFJ	Sensing-feeling-judging family
SFP	Sensing-feeling-perceiving family
STJ	Sensing-thinking-judging family
STP	Sensing-thinking-perceiving family

The no-I/E design reflects the view that introversion and extraversion may be weaker or less stable in text-structure signals than the other dimensions. MB3I outputs can appear in contributor lookup reports, subreddit aggregate statistics, and optional flair displays when enabled.

Because MB3I is experimental, it should be interpreted as a structural resemblance signal, not as a personal diagnosis or final classification.

PTT-assisted routing

Reputation Flair can optionally use PTT, or Parametric Text Tessellation, as part of review or removal routing. PTT is a structural text-classification method that compares text by character geometry, punctuation behavior, word-edge patterns, and other non-semantic features.

In Reputation Flair, PTT is used as an auxiliary signal. It can contribute to routing when enabled and when ordinary first-layer routing has not already acted. PTT triggers are tracked separately from bot triggers and ordinary discourse triggers.

This separation allows moderators to distinguish between semantic or rule-based triggers and structural classifier signals. It also allows PTT routing to be disabled without disabling the rest of the reputation system.

Moderator configuration

Reputation Flair includes a moderator configuration interface. Configuration is divided into practical sections rather than requiring moderators to edit raw application state.

Area	Function
Runtime	Controls core app behavior, high-traffic mode, mod notes, RF check comments, challenge difficulty, custom bad terms, score decay, and streak mode.
Flair	Controls automatic flair updates, preservation of custom flair, color changes, verification display, visible flair parts, and streak thresholds.
Review	Controls review routing, negative thresholds, trigger thresholds, and moderator or approved-user exemptions.
Removal	Controls removal routing, stricter thresholds, and removal exemptions.
Protections	Controls original-poster self-reply protection and self-reply scoring caps.
Experimental features	Controls PTT routing, MB3I classification, and MB3I flair display.
Human verification	Controls verification mode, RF check requirements, posting/commenting gates, reminders, restoration behavior, and cleanup timing.

This structure allows moderators to tune the application to the norms and risk tolerance of their own subreddit. A strict debate subreddit may use different routing thresholds than a casual community, support forum, or research subreddit.

Version 0.0.8 operational profile

Version 0.0.8 is described as a production-hardening release. Its main purpose is to reduce high-volume write pressure, preserve expanded reputation and behavior records, expire temporary Redis keys, prevent processed-item key growth, improve large-subreddit user tracking, centralize bot messages, keep MB3I and PTT bounded, and separate moderator-facing diagnostics from public-facing displays.

In this version, the application can:

score new posts and comments;
update user reputation records;
generate user flair;
track soft and hard trigger signals;
detect bot-like or low-quality patterns;
require human verification before participation when enabled;
show contributor statistics to moderators;
show subreddit-wide transparency statistics;
maintain daily and all-time subreddit counters;
optionally add MB3I family-distribution analysis;
optionally route posts or comments to review or removal/filter;
post limited bot replies when enabled and allowed by rate limits.

All records remain subreddit-local. The application does not create a sitewide Reddit reputation score.

Main flair format in v0.0.8

A normal generated flair may appear as:

🔥1 ∣ ⚖️ 23% ∣ ⚠️ 317 ∣ ⌨️ [1622]

Flair part	Meaning
`🔥1`	Participation streak. Higher values indicate continued contribution without recent negative contribution classification.
`⚖️ 23%`	Reputation balance from −100% to +100%. Higher values indicate sustained constructive contribution history; lower values indicate repeated negative, bot-like, hostile, or low-value contribution signals.
`⚠️ 317`	Total warning signal display. This may include scaled category warning signals, PTT triggers, and bot triggers.
`⌨️ [1622]`	Total subreddit contributions tracked by the application for that contributor.

If MB3I flair display is enabled and preserve-flair mode is off, the flair may include an MB3I family marker such as NTJ. If the top-two MB3I display is enabled, it may show a combined marker such as NTJ/NTP. MB3I flair output does not use an emoji.

Reputation formula in v0.0.8

The reputation score is displayed as ⚖️ ±n% and remains clamped between −100% and +100%. In the documented v0.0.8 formula, reputation pressure may include good reputation points, bad reputation points, good contribution count, bad contribution count, participation streak, scaled warning triggers, PTT triggers, and bot triggers.

Formula element	Documented value or behavior
Bad reputation multiplier	2.5
Gravity buffer	50
Contribution sway	10
Trigger sway	15
Bot trigger multiplier	1.5
Streak bonus	+0.12 per streak unit, capped at +4
Score clamp	−100% to +100%

The contribution classification is blended. Each processed item receives 50% weight from the first-layer category system and 50% weight from the PTT layer. The blended result determines whether the item is counted as a good contribution or bad contribution, affecting contribution counts, streak behavior, dashboard totals, leaderboard placement, and the contribution bonus or penalty in the reputation formula.

First-layer scoring categories

The first layer is the direct phrase, stem, and category scoring system. It tracks six main discourse categories.

Category	Interface label	Meaning
`direct`	Attack	Direct insult or attack language.
`dismiss`	Shutdown	Dismissive or conversation-ending language.
`credibility`	Credibility	Claims attacking honesty, legitimacy, or source credibility.
`condescension`	Condescension	Belittling or patronizing phrasing.
`badFaith`	Bad Faith	Bad-faith or trolling-style framing.
`manipulation`	Gaslighting	Manipulation, gaslighting, or goalpost-shifting language.

Detailed per-user category breakdowns are moderator-facing. Public or ordinary user-facing displays should prefer compact totals rather than a full six-category profile.

Minor triggers

Version 0.0.8 adds minorTriggers as a seventh category for weaker one-word or stem-based hits. These signals are tracked separately so that weak matches do not inflate the six main categories.

Moved into minor triggers are:

mildStems;
oneWordTokens;
stems;
mentalHealthStems;
shillStems;
insultStems;
nonsenseStems;
memeStems.

Minor triggers do not count toward category-reach review or removal routing, do not act like main category triggers, and do not drive review or removal by themselves.

Warning totals

The application separates hard moderation outcomes from warning signals. Hard warnings are review and remove/filter actions. Flair warning signals use scaled category warnings plus PTT triggers plus bot triggers.

Category signals are scaled before use:

scaled warnings = floor(categorySignals / 6)

PTT triggers and bot triggers are then added for display and reputation pressure.

PTT layer behavior

PTT is the second-layer classifier. It is supplementary and does not replace the user-record system. In Reputation Flair, PTT can produce good points, bad points, bot points, PTT triggers, PTT-review routing, and PTT-removal routing.

PTT good and bad points are added to the contributor's stored reputation totals. PTT triggers are tracked separately from bot triggers.

PTT-review routing and PTT-removal routing are configured independently from category and point triggers. They fire only when PTT catches the item, the relevant option is enabled, and the first layer has not already sent the item to review or removal. This prevents double-routing when the first layer has already handled the item.

Bot triggers

Bot triggers are separate from PTT triggers. They represent signals that appear bot-like, spam-like, automated, or low-quality in ways the application tracks separately from ordinary discourse friction. Bot triggers may affect reputation pressure, warning display, dashboard totals, RF check reports, and mod notes.

MB3I storage and display

When enabled, MB3I scores text against family-style models and collapses the output into eight no-I/E families: NTJ, NTP, NFJ, NFP, STJ, SFJ, STP, and SFP.

MB3I stores aggregate family statistics only. It persists itemCount, family wins or core model detections, family totals, entropy totals, and update timestamps. It does not store raw text.

A single processed comment or post can produce multiple core-model detections because multiple MB3I models may be used. Therefore, "core model detections" is not the same as the number of comments.

Column	Meaning
Family	MB3I family group.
Core Model Detections	Number of times core MB3I models selected that family as the top result.
Score Rate	Average family score or probability across processed items.

When MB3I is disabled, MB3I surfaces are hidden from My MB3I Stats, My Subreddit Stats, Contributor Stats Lookup, Subreddit Transparency, Analysis charts, flair, and mod notes. When MB3I is enabled, those surfaces may show aggregate or per-user family distributions depending on configuration and available data.

If preserve-flair text is enabled, the application does not replace the preserved flair slot with MB3I. Preserve-flair mode disables both "Show MB3I in flair" and "Show top 2 MB3I" in the interface and backend configuration sanitizer.

Human verification behavior

Human verification is optional and configurable. It can be used to require verification before posting, require verification before commenting, remind unverified users to verify, or require verification before RF check commands.

The RF Check Verification Required option applies only when human verification is enabled. If enabled, users must verify before using RF check commands.

The Verify Account menu item remains visible when a user is already verified. Verified users see their saved verification state and score rather than being allowed to repeatedly retake the test. The retake verification button has been removed.

Human verification messages are centralized in src/server/core/botDialog.ts. The verification prompt explains that users must complete a 160-second challenge to protect the subreddit against automated bot attacks and that completion updates the account flair to a checkmark granting access to participate. Expired verification messages explain that verification must be renewed.

Welcome messages and automatic stat checks

First-comment welcome messages are optional. The default deletion time is 30 minutes, under the configuration label "Delete welcome bot comments after." Welcome comments use the centralized bot dialog file and may include a welcome line, deletion line, short Reputation Flair explanation, portal link, and transparency footer.

The configuration label "Automatic stat-check comments on new posts" controls compact RF check replies on new posts when allowed by rate limits. The application should not post automatic RF check replies on every post if rate limits prevent it.

RF check reports in v0.0.8

RF check reports show compact user statistics. A report may include overall reputation balance, activity, trigger total, bot triggers, verification/status, good reputation contributions, bad reputation contributions, good reputation points, bad reputation points, first participated date, and an install-date note.

If MB3I is enabled and the user has MB3I data, RF check output may include the top three MB3I families. RF check output is also centralized in botDialog.ts.

Bot transparency footer

Bot comments include a transparency footer stating that Reputation Flair reads post and comment text to score discourse, does not store full post or comment bodies in Redis, does not transmit scored content outside the app/subreddit, treats Bot Shield telemetry as separate and short-lived, and only receives the final verification result, hashes, and bot-scoring signals. The footer may link to FAQ, privacy policy, terms, the Devvit app page, the Metopedia article, and GitHub or source pages.

Mod notes

If enabled, Reputation Flair can update moderator notes. Mod notes may include reputation score, good and bad points, good and bad contribution counts, activity totals, six main category counters, minor triggers, PTT triggers, bot-trigger rate, full warning total, verification state, and top MB3I families when enabled and available.

Mod notes are subject to write throttling and should not be written for every processed item in a fast subreddit.

Contributor and user statistics surfaces

Contributor Stats Lookup lets moderators inspect reputation score, activity, good/bad contribution totals, trigger totals, verification status, and MB3I stats when MB3I is enabled. Its comparison view compares MB3I family rows separately by family, user core model detections, user score rate, comparison-user core model detections, and comparison-user score rate.

My Subreddit Stats shows normal user and subreddit reputation statistics. MB3I user statistics are not duplicated there because MB3I has a separate My MB3I Stats page. My MB3I Stats appears only when MB3I is enabled and may show items scored, core model detections, top family, second family, score margin, family distribution, score distribution, and chart views.

Subreddit Transparency shows subreddit-wide statistics, including total activity, good/bad contribution totals, reputation trends, trigger totals, bot/PTT/minor trigger totals, verification totals, RF call counters, and MB3I statistics when enabled.

The Transparency Analysis tab is organized as a focused chart navigation screen. The Metrics menu opens one chart at a time, with current focused chart areas for reputation, contributions, activity, users, triggers, and MB3I families. MB3I Families appears only when MB3I is enabled. Chart ranges include day-to-day, month-to-month, and all-time. The MB3I Families chart shows the eight family lines by date.

Daily subreddit statistics and RF counters

Daily statistics track activity and application processing by date. Counters may include item count, comment count, post count, review count, removal/filter count, trackOnly count, RF calls, RF comment calls, RF post calls, RF queue calls, RF processed skips, and MB3I core model detections when enabled. Daily MB3I family distribution is stored separately and shown only when MB3I is enabled.

RF call counters include rfCalls, rfCommentCalls, rfPostCalls, rfQueueCalls, and rfProcessedSkips. These counters exist for subreddit-wide and daily tracking and help moderators understand how much processing the application is doing.

Routing actions

The application can route items to several action states.

Action	Meaning
`allow`	Item is processed and no moderation action is requested.
`trackOnly`	Soft tracking only; no hard warning and no removal.
`review`	Item qualifies for moderator review.
`removeOrFilter`	Item qualifies for removal or filter action.
`ignore`	Empty, deleted, removed, or invalid item is ignored.

trackOnly means the application found a soft or weak signal worth counting internally, but not enough for review or removal. It should not be treated as a violation, and visible warning displays should not inflate based only on broad soft tracking.

PTT-review and PTT-removal can add routing only when enabled and when the first layer has not already routed the item.

Rate limits and write throttling in v0.0.8

The application is designed so high-volume subreddits process activity silently while limiting visible or external Reddit writes.

Area	Intended policy
Bot comments, global	About 12 per subreddit per minute.
Verification enforcement replies	About 12 per minute.
Verification expired replies	About 10 per minute.
Manual RF check replies	About 8 per minute.
Automatic RF check replies	About 6 per minute.
First-comment welcome replies	About 4 per minute.
Flair writes	Subreddit-wide and per-user throttled.
Mod notes	Write-bucket limited.
Reports/removals	Action-gated and write-bucket limited.
Nuclear flair cleanup	Batched and cursor-based.

At 100 comments per minute, the intended behavior is to score everything, update counters, update user records, avoid posting replies for most items, avoid writing flair on every item, avoid writing mod notes on every item, and only report, remove, or review when thresholds are met.

Version 0.0.8 includes stronger flair-write controls: subreddit-wide flair-write throttling, per-user flair-write throttling, no-change flair update skipping, and app-managed flair cleanup batching. The contributor's internal flair timestamp updates only when flair was actually written or when the generated flair was already unchanged. It does not update when a write is skipped because of rate limits or failure.

Persistent and expiring data

Main reputation and flair-state data is intended to persist. Persistent keys may include user reputation records, user behavior stats, user MB3I family stats, subreddit aggregate stats, daily subreddit stats, install date, first participation date, and verification state according to verification expiry policy.

Temporary data should expire. Expiring data includes trigger dedupe keys, processed-item keys, bot-comment dedupe keys, temporary verification sessions, human-verification telemetry/debug keys, portal URL cache, admin grant/session keys, comment purge queue buckets, rate-limit buckets, and temporary pending verification-removal queues.

The processed-item key uses the form:

rf:proc:{sub}:{thingId}

It prevents repeated processing of the same Reddit item. In high-volume subreddits, this key must expire. Version 0.0.8 uses a TTL policy for processed items so the application does not accumulate millions of permanent processed-item keys.

Nuclear flair cleanup

Moderator Configuration includes a nuclear cleanup option labeled REMOVE-APP SET FLAIRS. The safeguard requires the moderator to type REMOVE RF FLAIRS and then press the cleanup control. There is no browser confirmation box.

This action removes flairs set by the application. It does not wipe reputation records, behavior statistics, MB3I statistics, PTT statistics, verification state, or subreddit counters. If a user comments or posts again and flair updates are enabled, the application can rebuild that user's flair from existing records.

Version 0.0.8 makes cleanup batched, cursor-based, rate-limited, and able to scan tracked-user shards beyond the older 5,000-user limit.

Tracked users and legacy migration

The application maintains tracked-user lists so dashboards, leaderboards, cleanup tools, and aggregate operations can identify known users. Version 0.0.8 improves tracking by using sharded tracked-user lists, which helps large subreddits and cleanup operations.

Old records from earlier versions can be read and migrated lazily per user. The legacy key is:

rf:rec:{sub}:{user}

Old field	New meaning
`a`	Good reputation points.
`b`	Bad reputation points.
`c`	Comments.
`p`	Posts.
`g`	Streak.
`x`	Streak timestamp fallback.
`t`	Last activity fallback.

Lazy migration occurs when a user is touched by new post or comment processing, a dashboard read, a lookup read, or another runtime path that loads their profile or statistics. The application cannot reconstruct old PTT, MB3I, category, minor-trigger, bot-trigger, or daily history from versions where those features did not exist.

Moderator configuration relationships

Important configuration relationships in v0.0.8 include:

preserve flair disables MB3I flair display;
preserve flair disables top-two MB3I display;
human verification off disables RF Check Verification Required;
verification requirement toggles and verification reminders disable each other where their behavior conflicts;
MB3I disabled hides MB3I from all statistics and menu surfaces.

The main configuration areas are Runtime, Flair, Human Verification, Welcome / RF Check, PTT / Scoring, MB3I / Experimental Features, Moderation Routing, Transparency / Stats, and Nuclear Cleanup.

Moderator-facing model

For moderators, the application can be understood as four layers.

Layer	Function
Activity layer	Tracks posts, comments, streaks, first participation, and total contribution count.
Reputation layer	Tracks good/bad points, good/bad contribution count, triggers, bot signals, and reputation balance.
Safety/moderation layer	Handles human verification, review routing, removal/filter routing, bot replies, mod notes, and rate limits.
Analysis layer	Shows subreddit trends, daily totals, leaderboards, MB3I family distributions, and contributor lookups.

Operationally, moderators should watch whether the application posts too many bot comments, whether flair writes are throttled properly, whether review/remove thresholds are too sensitive, whether trackOnly counts are too noisy, whether MB3I is hidden when disabled, whether verification states are correct, whether mod notes are useful but not excessive, whether daily statistics update, whether analysis charts are readable on mobile, and whether older users migrate correctly when active.

Item processing flow

In v0.0.8, a newly observed post or comment is processed as an update to the contributor's subreddit-local record rather than as an isolated moderation event. The general processing sequence is:

load the contributor's current subreddit stats;
apply weekly bad-reputation decay if that feature is enabled;
add the post or comment to the contributor's activity count;
update the contributor's streak state;
calculate starting good reputation from context and approved positive-side values;
scan for warning, bot, PTT, and optional MB3I signals;
convert retained negative matches into severity;
apply buffers, reductions, forgiveness rules, and protections;
check review, removal, and verification rules;
update user stats, subreddit stats, daily stats, mod notes, and generated flair where enabled.

This sequence makes the application cumulative. A post or comment can update a user profile, trigger aggregate counters, alter a flair display, change daily subreddit statistics, and affect later routing decisions.

Context scoring and good-side value

The application uses a context value, referred to in configuration and code as textContextScore, as part of the positive-side scoring process. This value represents the item's quality or contextual value for scoring purposes. It can increase good reputation, increase forgiveness on the bad-reputation side, and prevent every item from being treated as if it had the same informational value.

Good reputation starts with a scaled context calculation:

goodRaw = floor(textContextScore / goodDivisor) + bonusScore
earnedGood = clamp(goodRaw, 0, scoreCeiling)

The terms have the following meanings:

Term	Meaning
`textContextScore`	Quality or context value assigned to the item.
`goodDivisor`	Scale factor that controls how quickly context becomes good reputation.
`bonusScore`	Approved extra good-side value.
`scoreCeiling`	Maximum good reputation one item can receive.

The clamp operation prevents a single item from producing negative good-side value or exceeding the configured ceiling. The application does not expose every internal factor that contributes to textContextScore.

Bad-side scoring and context forgiveness

Bad reputation is calculated through a staged process. The app first scans phrase, token, stem, regex, extreme-normalized, and moderator-added bad-term sources. Where possible, weaker overlapping matches are removed so the same language does not inflate the score through redundant matches.

The current scoring mode is severity-based. Retained negative hits use:

severity = min(5, ceil(abs(weight) / 2))

Weight	Severity
`-10`	`5`
`-8`	`4`
`-7`	`4`
`-6`	`3`
`-5`	`3`
`-4`	`2`
`-3`	`2`
`-2`	`1`

Retained severities are then summed:

rawBadScore = sum of severities of all kept matches

A bad-side buffer is applied after the raw score is calculated. If textContextScore is below 15, no buffer is applied. If textContextScore is at least 15, the effective buffer subtracts 3:

bufferedBad = max(0, rawBadScore - effectiveBuffer)

The system can then apply context forgiveness. Higher context can reduce bad-side pressure, while streak can slightly strengthen that effect:

streakAdjustment = min(128, floor(streak / 2))
errorDivisor = 256 - streakAdjustment
badReduced = max(0, scaledBad - floor(textContextScore / errorDivisor))

This does not mean a high-context item is immune from bad scoring. It means the app can distinguish low-context negative material from a more substantive item that contains some trigger language.

Category pressure and score modifiers

Several rules can alter the final scoring effect of an item or profile.

Weekly decay can reduce accumulated bad reputation once per full week since last activity when the feature is enabled:

decayFactor = 1 - weeklyDecayPercent / 100
badPoints = badPoints * decayFactor^weeksPassed

Streak mode controls how streaks are retained or expired. Supported modes include noexpire, hourly24, and hourly48.

Category pressure can add extra bad-side force when trigger distribution crosses configured thresholds. If any one category reaches at least three points, the item can receive an additional point of pressure. If four or more categories are hit, the item can receive two additional points of pressure.

Original-poster self-reply protection can override ordinary scoring for a user's comments on the user's own post. When enabled, it can cap good reputation to ownPostCommentGoodCap, force bad reputation to 0, and clear category flags for the protected self-reply context.

Final point application and item classification

After checks, reductions, and protections, the app applies bad reputation first:

user.badPoints += badReduced

If bad reputation was earned on the item, earned good reputation can be reduced:

reduction = min(6, floor(badReduced / 2))
earnedGood = max(0, earnedGood - reduction)

Good reputation is then applied:

user.goodPoints += earnedGood

This means bad reputation can partially cancel good reputation on the same item. The item classification is separate from raw point totals. A good reputation contribution is an item whose final reduced bad reputation is 0. A bad reputation contribution is an item whose final reduced bad reputation is greater than 0.

Contribution counts and point totals should therefore be read separately. Contribution counts describe how many items landed on the good or bad side. Point totals describe how strongly those items affected the reputation score.

Blended contribution classification

The application uses a blended contribution classification for deciding whether an item counts as good or bad. The regular scoring layer and the PTT layer each contribute to the final classification. The regular layer produces good and bad points from runtime scoring. PTT produces its own good, bad, and bot-like signals.

In the documented v0.0.8 behavior, the contribution classification uses a balanced blend:

50% regular scoring layer
50% PTT layer

The blended result affects good contribution count, bad contribution count, contribution bonus or penalty in the reputation formula, streak behavior, dashboard totals, and leaderboard placement.

Reputation score calculation details

The reputation score combines good reputation points, bad reputation points, good and bad contribution counts, streak, scaled warning pressure, PTT triggers, and bot triggers.

The documented v0.0.8 calculation uses:

weightedBad = badRepPoints * 2.5
pool = goodRepPoints + weightedBad + 50
base = 100 * (goodRepPoints - weightedBad) / pool
streakBonus = min(4, streakDays * 0.12)
contributionBonus = 10 * ((goodItems - badItems) / totalItems)
triggerPressure = scaledWarnings + PTTTriggers
rawPressure = (triggerPressure + botTriggers * 1.5) / totalItems
trustFactor = clamp(1 + ((weightedBad - goodRepPoints) / pool), 0.35, 2.25)
triggerPenalty = (rawPressure / (rawPressure + 1)) * 15 * trustFactor

Minor triggers are tracked separately. Bot triggers remain separately weighted. The final score is clamped between -100% and +100%.

Verification-only blocking and restoration

Verification-only blocking is handled separately from ordinary removal. If an item qualifies for ordinary removal, it is removed for that reason first. If the item is blocked only because the user is not verified, it is treated as a verification-only action.

Verification-only blocking can apply to posts, comments, or both, depending on configuration. Verification-only removals may be restored after the user verifies when restoration is enabled. Restoration is bounded by configured post and comment limits.

When blocking is active, verification reminder comments may be skipped because the blocking action takes priority. This avoids creating redundant bot messages when the moderation action already explains the participation requirement.

Verification fields and flair effects

Verification records can include whether a user is verified, when the current verification period began, when it expires, and how many recent failed verification attempts occurred. These fields are operational participation-control signals, not identity, expertise, or trustworthiness claims.

When human verification is active and verification badges are enabled, a verified account can have the ordinary streak badge replaced by a verification badge. If the account is not verified, the ordinary streak badge remains unless the subreddit uses a configured unverified badge.

Installation-based totals and delayed visible updates

Subreddit-wide totals described as "since installation" begin when Reputation Flair is installed in that subreddit. They are subreddit-specific, not Reddit-wide, and reflect only the app's recorded history in that community.

Visible updates may not occur instantly. Flair writes, bot comments, mod notes, automatic stat-check comments, and other visible outputs can be delayed or skipped by traffic controls, high-traffic mode, disabled settings, rate limits, verification requirements, or no-change update skipping. In high-volume communities, the intended behavior is to continue processing and updating counters while reducing visible write pressure.

Stored counters and behavior indexes

For each user, the application keeps a running subreddit reputation record. This can include good reputation points, bad reputation points, post count, comment count, streak, activity timestamps, and flair update time.

The behavior counter structure includes the following indexed meanings:

Index	Meaning
`[0]`	Attack
`[1]`	Shutdown
`[2]`	Credibility
`[3]`	Condescension
`[4]`	Bad Faith
`[5]`	Gaslighting
`[6]`	Posts
`[7]`	Comments
`[8]`	Good item count
`[9]`	Bad item count
`[10]`	Bot triggers
`[11]`	Failed verification attempts
`[12]`	Verification state
`[13]`	PTT triggers
`[14]`	Minor triggers

When MB3I is enabled, the app stores aggregate MB3I family statistics, including item count, family detections, family score totals, entropy total, and update time. It does not store a per-item MB3I history table.

Data visibility model

Reputation Flair separates user-facing, moderator-facing, and internal app state.

Surface	Typical data
User-facing displays	Compact flair, reputation score, activity count, verification state, and compact warning totals.
Moderator-facing displays	RFstats mod notes, review or removal state, subreddit totals, detailed category profiles, generated flair output, and MB3I summaries when enabled.
Internal app state	Processed flags, review or removal markers, verification values, restoration tracking, daily counters, PTT counters, minor-trigger counters, rate-limit keys, and MB3I aggregate counters when enabled.

The app reads post and comment text for scoring, but the runtime design does not keep a long-term private Redis copy of every post or comment body. It stores counters, state, and markers needed for the app to operate. It also does not persist a raw phrase log of every matched trigger into Redis. Reviewed or removed items can use state markers so the app knows what happened, and verification-only restoration can store limited metadata such as username, item type, item id, and timestamp.

A narrow flair exception exists when custom flair text is preserved. In that case, the app may cache the user-facing flair-head segment so it can rebuild flair later. That is flair state, not stored post or comment body content.

RFstats mod notes as moderation context

An RFstats mod note is a compact moderator note added when mod-note updates are enabled. The app removes the old RFstats note and writes a fresh summary when stats update.

An RFstats note can include reputation points, good and bad contribution counts, category counters, minor triggers, PTT triggers, bot-trigger rate, verification state, and MB3I top families when MB3I data exists. RFstats is moderator context. It is not the same as public flair.

Runtime and storage model

Reputation Flair is built as a Reddit Devvit application. It uses event triggers for posts and comments, menu actions for user and moderator commands, a web interface for the portal, and scheduled tasks for cleanup or maintenance.

The application stores state through Redis-backed records. Stored records may include contributor reputation data, subreddit statistics, daily statistics, verification metadata, processed-item markers, configuration state, portal state, rate-limit keys, queue markers, and temporary removal or restoration data.

The application distinguishes persistent records from temporary operational records. Persistent records support reputation continuity, aggregate statistics, and verification state. Temporary records support deduplication, rate limiting, cleanup, session flow, or restoration workflows.

Privacy posture

The application’s public documentation and transparency text describe a privacy posture in which the app reads post and comment text for scoring but does not store a full private copy of post or comment bodies in its Redis state. Instead, it stores counters, scores, classifications, category totals, verification metadata, and operational markers.

The distinction matters because reputation systems can become privacy risks if they retain unnecessary raw text. Reputation Flair’s stated design emphasizes derived scoring records rather than private body archives.

The application still processes user activity and produces reputation records, so communities using it should disclose its presence and explain what the generated flair and portal statistics mean.

Rate limiting and high-traffic behavior

Reddit applications can create operational risk if they write too often. Reputation Flair includes rate limits and high-traffic controls to reduce excessive automated actions.

Rate-limited actions include:

generated bot comments;
flair writes;
mod notes;
review reports;
removals;
verification-removal replies;
RF check replies;
welcome comments;
cleanup actions;
portal-related operations.

The application can skip unnecessary flair writes when the existing flair text or color already matches the intended output. It can also limit how often a user's flair is updated and how many flair writes occur in the subreddit over a time window.

These safeguards are important because a reputation system should not flood a community, overload APIs, or create more moderation noise than it resolves.

Bot comments and messaging

Reputation Flair can generate bot comments for selected events, such as RF check replies, verification reminders, verification-required notices, expired-verification notices, welcome messages, or restoration notices. These comments are controlled by configuration and rate limits.

Bot comments are not the primary output of the system. The primary output is generated flair and portal visibility. Bot comments are used when the system needs to explain an action, direct a user to verification, respond to a command, or provide a compact report.

Flair cleanup

The application includes tools for cleaning up app-managed flair. This is useful if a community disables the app, changes its display style, resets reputation records, or wants to remove generated flair while preserving custom user flair where possible.

Cleanup is designed to operate in batches rather than all at once. Batch behavior reduces operational risk and helps avoid excessive API writes.

Public interpretation

A Reputation Flair display should be interpreted as a summary of local recorded behavior under the subreddit’s configuration. It is not a universal score. It is not a Reddit-wide trust mark. It is not an accusation by itself.

A high score suggests that the contributor has a strong constructive record in that subreddit. A low score suggests repeated negative scoring pressure, hard triggers, bot-like signals, or other configured risk markers. A warning count indicates recorded trigger pressure, not necessarily a formal rule violation. An activity count indicates how many contributions the app has recorded under its configured processing rules.

Readers should use the flair as context, not as a substitute for reading the comment, checking sources, or applying judgment.

Moderator interpretation

For moderators, Reputation Flair is best understood as a signal-routing and context tool. It can help identify patterns, but it should not be treated as a final authority.

Moderators should consider:

the user’s actual comment or post;
the user’s contribution history;
whether triggers reflect genuine misconduct or quoted/contextual material;
whether the configuration is too strict or too permissive;
whether removal thresholds need adjustment;
whether exemptions are appropriate;
whether a false positive occurred;
whether transparency statistics show excessive routing;
whether user appeals or corrections reveal a scoring problem.

A reputation system gains legitimacy when it is configurable, reviewable, and explainable. It loses legitimacy when it becomes opaque or automatic without recourse.

Relationship to ordinary moderation

Reputation Flair is not a replacement for subreddit rules or human moderation. It supplements ordinary moderation by creating a historical signal layer.

Ordinary moderation often asks whether one post or comment violates a rule. Reputation Flair adds another question: whether the contributor has a repeated local pattern that changes how the item should be interpreted or prioritized.

This can be useful in communities where bad actors avoid obvious rule violations in individual comments but repeat low-quality, dismissive, manipulative, or disruptive behavior over time.

Relationship to karma

Reputation Flair is different from Reddit karma. Karma is based on user voting and can be affected by popularity, ideology, timing, subreddit culture, brigading, humor, controversy, and visibility. Reputation Flair is based on local application records and configured scoring rules.

This distinction gives the system a different purpose. It is not meant to show how popular a user is. It is meant to summarize locally recorded contribution quality and risk signals.

Relationship to Automoderator

Reputation Flair also differs from Automoderator-style rule systems. Automoderator rules usually respond to the content or metadata of a single item. Reputation Flair maintains contributor history and can use accumulated behavior in later decisions.

This makes it closer to a reputation-aware moderation layer. It can still perform item-level routing, but it does so with access to a persistent contributor profile.

Design philosophy

The application reflects several design principles:

reputation should be local rather than universal;
public signals should be compact but explainable;
automated routing should be configurable;
severe actions should be stricter than review actions;
positive and negative history should both matter;
bot-like behavior should be tracked separately from ordinary discourse behavior;
experimental classifiers should be optional;
transparency statistics should be visible;
rate limits should prevent automated overreach;
moderators should retain final judgment.

This philosophy treats reputation as a moderation aid rather than a social identity label.

Limitations

Reputation Flair has several limitations.

Short histories are unstable. A contributor with only a few recorded items may not have a meaningful score.

False positives are possible. Sarcasm, quotation, technical debate, hostile source material, moderation discussion, reclaimed language, or adversarial context can trigger categories incorrectly.

Training and classification choices matter. If trigger rules, PTT signals, MB3I outputs, or scoring weights are poorly calibrated, the visible reputation score may become misleading.

Community norms vary. A configuration that works in one subreddit may be too strict or too lenient in another.

Reputation can become socially sticky. Users may overread a flair and ignore the actual content of a comment. This risk is reduced by clear explanation, transparency statistics, RF check reports, and moderator review.

Automated removal requires caution. Review routing is safer than automatic removal because it preserves human judgment. Removal thresholds should be stricter and monitored.

MB3I and PTT are supplementary signals. They should not be treated as proof of motive, identity, personality type, bot status, or misconduct.

Criticisms and concerns

Reputation systems raise several concerns.

One concern is opacity. If users cannot understand why a score appears, the score may feel arbitrary. Reputation Flair addresses this partly through RF check reports, portal statistics, configurable display, and public explanations, but any deployment still depends on moderator transparency.

A second concern is false positives. Any automated classifier can misread context. This is why review thresholds, exemptions, appeals, and restoration paths are important.

A third concern is chilling effect. If users fear that disagreement will lower their score, they may avoid legitimate criticism. A well-configured system should distinguish disagreement from harassment, manipulation, spam, or repeated low-quality conduct.

A fourth concern is social labeling. A visible low score may cause readers to dismiss a user before reading the substance of a comment. This risk is inherent in public reputation display and should be mitigated through clear documentation and careful score design.

A fifth concern is moderator overreliance. Automated tools can assist moderation but should not replace judgment. Reputation Flair is strongest when used as a context layer rather than a final authority.

Significance

Reputation Flair is significant as an attempt to combine contributor reputation, generated flair, moderation routing, optional human verification, and public transparency into one subreddit-level application. It addresses a gap between one-off rule enforcement and long-term community trust.

Its core innovation is not the existence of a score, but the combination of visible flair, local history, configurable routing, transparency statistics, verification, and optional structural text analysis. The application attempts to make repeated contribution patterns visible while preserving moderator control over thresholds and enforcement.

The system is best understood as a moderation infrastructure experiment. It creates a public-facing reputation layer while retaining the need for human oversight, local configuration, and transparent explanation.

References