Modzard

Inspiration

Moderating a subreddit is not just about writing rules. It is also about understanding what those rules will actually change in the community. In many subreddits, rules grow over time and are often written by different moderators. Some are broad, some are very specific, and some overlap without anyone noticing. Because of that, adding a new rule can create confusion. A rule might quietly contradict an older rule, make moderation harder, or suddenly affect a large group of existing posts and users. That was the main idea behind our project: before a moderator adds a new rule, they should be able to see what that rule might break, what it overlaps with, and what parts of the community it is likely to affect.

What it does

Our MVP is a rule analysis tool for moderators. When a moderator writes a new subreddit rule, the app first compares it against the existing rules and checks whether there is no conflict, a potential conflict, or a direct contradiction. If a conflict is detected, the app shows which existing rule is involved, so the moderator can review it before publishing anything. The second part of the app looks at the existing subreddit content and estimates what would be affected if the new rule were applied. It retrieves posts and comments that match the rule context and shows them in an analytics view. From there, moderators can see which content categories would be affected, what percentage of the content may fall under the new rule, and which users appear most often in the affected content.

How we built it

We built the project in TypeScript. The core of the app is not LLM-driven. We parse new and existing rules with regular expressions and convert them into a structured object that we call RuleSpec. That gives us a consistent way to compare rules based on attributes like action, target, keywords, flair, domains, and content type. From there, we built two main engines. The Conflict Engine checks whether a new rule overlaps with or contradicts an existing rule. The Impact Engine scans existing posts and comments, scores them against the proposed rule, and surfaces the content that is likely to be affected.

Challenges we ran into

One of the biggest challenges was deciding how much we should rely on AI. At first, it seemed tempting to let an LLM handle rule parsing and contradiction detection. But that quickly introduced overhead, inconsistency, and slower responses. For moderation tools, speed and clarity matter a lot, so we moved the core logic to a rule-based system built with regex and structured comparison. Another challenge was retrieving affected posts accurately. We explored more advanced semantic retrieval ideas, including transformer-based approaches, but we ran into memory and storage limits in the Devvit environment. That pushed us to design a lighter system that still works well enough for an MVP. We also had to think carefully about how to present impact. A moderator does not just want a list of matching posts. They want to understand what kinds of content and which users will be touched by the rule, and whether that change is small, broad, or disruptive.

Accomplishments that we're proud of

The part we are most proud of is that the core of the app works without depending on an AI. We designed the Conflict Engine and Impact Engine ourselves and made them deterministic. Parsing, comparison, overlap detection, and impact scoring are handled manually in code. That gave us a system that is faster, easier to debug, easier to explain, and more reliable in real time. We are also proud that the project does not stop at saying this rule conflicts or these posts match. It tries to show moderators the broader effect of a rule change inside the community.

What we learned

We learned that regular expressions and structured parsing can go much further than we first expected. For messy human-written rules, they are not perfect, but they are surprisingly effective when combined with a good intermediate structure. We also learned that not every moderation problem should be solved with an LLM. In our case, deterministic logic worked better for the main decision flow, while the LLM was more useful for summarizing patterns and giving moderators additional context. Another thing we learned is that moderation is not only about enforcement. It is also about predictability. A new rule may look reasonable on its own, but once you compare it to existing rules and real community content, its effect can be very different from what the moderator intended.

What's next

The next step is to make the rule analysis more context-aware. Right now, our app works well as an MVP, but we want to improve deeper handling of exceptions and edge cases in rules, better grouping of affected content into meaningful clusters, stronger retrieval for comments and older posts, and better explanations for why a specific post was marked as affected. We also want to make the analytics view more useful for moderators by showing trends over time, not just a snapshot. For example, a moderator could see whether a proposed rule mostly affects new users, repeat offenders, certain flairs, or recurring topics. Long term, we want this to feel like a preview mode for moderation policy: before a rule goes live, moderators can understand its likely consequences instead of discovering them after the fact.

Built With

• devvit
• html
• regex
• typescript