Ontology Rules: How to Tame Content Automation Without Losing Brand Voice

Once you're generating AI content for more than a handful of products or pages, plain prompts stop working. You need a different mental model. And a tool that supports it.

This is the case for ontology-based content rules. Why they matter, how they actually work, and how to think about them when you're scaling content automation past the point where one prompt can handle everything.

The problem: one prompt is never enough

Here's a scenario any e-commerce or content team will recognize. You start with a clean prompt:

"Write a 150-word product description for {{product_name}}. Friendly tone. Include the main benefit and 3 features."

That works fine for the first 50 products. Then you start noticing things:

• Your jewelry items need 80 words, not 150
• Industrial supplies need a technical, spec-heavy tone
• One specific product has a unique disclaimer that has to appear in every description
• Your "Eco" collection needs sustainability messaging woven in
• Three SKUs have legal language requirements (FDA, FTC) that the others don't

You can't put all of that into one prompt. The prompt becomes unreadable, and the model loses focus. So you build five prompts. Then ten. Then you start losing track of which prompt is being used where, and which one got updated last Thursday.

That's the wall. The answer is rules.

What an ontology rule actually is

The word "ontology" sounds heavier than it actually is. In this context, it just means a structured way to express which content rule applies to which set of items. That's it.

Each rule has three parts:

1. Scope. What items it applies to (all products, a category, specific SKUs).
2. Behavior. What content gets generated and how (prompt template, tone, length).
3. Priority. When rules conflict, which one wins.

Not a knowledge graph. Not RDF triples. Just a structured way to say "this rule applies here, that rule applies there."

The three priority levels

PromptBatch's rule system has three levels, and most use cases live entirely within them.

Global (the foundation)

One global rule per content type. This is your default voice, format, and quality bar. Every item falls back to this if no more specific rule applies.

Example: "All product descriptions are 100 to 200 words, friendly-professional tone, US English, second-person voice."

Category (the specialization)

A rule scoped to a collection, product type, vendor, or tag. Overrides Global for items that match.

Example: "For products tagged 'Industrial', use 60 to 120 words, technical tone, include spec table."

Override (the exception)

A rule for specific item IDs. Beats both Category and Global.

Example: "Product SKU-447: include the FDA disclaimer in every regeneration."

The system resolves rules deterministically. It walks Override, then Category, then Global, picks the most specific match. You can predict in advance which rule will fire for any given item, which is exactly what makes it possible to debug.

What "behavior" looks like in practice

A rule isn't just a prompt. It's a complete generation spec:

• Prompt template. The actual instructions, with variables for product attributes.
• Tone and voice. Explicit constraints the AI has to follow.
• Length target. Word or character count.
• Quality criteria. What "good" actually looks like for this rule.
• Auto-approve threshold. Quality score above which content publishes without human review.
• Schedule. When this rule should run (manual, on-demand, or recurring).
• Trigger conditions. Events that fire this rule (new product, content age, manual run).

The point: a rule wraps up everything about how a slice of your content should be handled. Once it's defined, you can run it on 1 item or 10,000 with the same setup.

How to design rules that scale

A few patterns that hold up across hundreds of stores and content sites:

Start with one global rule per content type. Don't preemptively create category rules. Let the real exceptions surface, then build rules for them.

Use category rules sparingly. If you have 50 category rules, you probably have a global rule that's wrong. Fix the global rule and most of the category rules become unnecessary.

Reserve overrides for genuine outliers. Compliance disclaimers, hero products with custom copy, items with weird data. If you find yourself with more than 5 to 10 overrides, ask whether they should actually be a category rule.

Name rules descriptively. "Industrial - technical descriptions" beats "Rule #4." You'll thank yourself in three months when you come back to figure out what's still in use.

Test changes on a small batch first. Edit a rule, run it on 10 items, review, then scale. Cheap insurance against bad outputs at scale.

Triggers and schedules

Rules can run reactively or proactively:

• Manual. Only when you click "Generate." Most rules should start here.
• Scheduled. Run on a cron schedule (every 30 days, every Sunday, whatever). Good for keeping content fresh.
• Triggered. Fired by an event (new product synced, source content changed, regeneration requested).

Combining these is where the real automation lives. Example: "When a new product syncs from Shopify, automatically generate description plus SEO title plus meta description using the appropriate category rule, score the output, and either auto-publish or queue for review."

That's not a one-off batch job anymore. That's a content engine that maintains itself.

Quality scoring is the safety net

Rules without quality control are just faster ways to publish bad content. Every PromptBatch rule has explicit quality criteria. Length, structure, keyword presence, banned-phrase checks. Each generated piece gets a score.

You set the auto-approve threshold per rule. Stricter rules (legal copy, regulated products) might be set to 90% auto-approve. Looser rules (internal blog drafts) might be 70%. Below threshold, it goes to review.

This is the part most "AI content tools" don't have, and it's the difference between scaling content and scaling problems.

Where this stops working

Honest version: rule-based content automation works beautifully for structured, repeatable content. It doesn't really work for:

• Long-form thought leadership where each piece is a unique argument
• Real-time topical content (news, hot takes)
• Content that requires original research or interviews

That's fine. Use rules for the 80% of your content that is structured and repeatable, and free your team to do the 20% that requires actual creativity.

That's the real promise here. Not replacing humans. Reorganizing what they spend their time on.