Capabilities
What’s actually inside Store Intelligence
The platform is a small set of composable primitives — Task Definitions, Task Options, Work Plans, Smart Lists, a layered context system, and a versioned prompt-snippet architecture. Below is a tour of each layer and how they fit together.
The building blocks
Three primitives you’ll see everywhere
Most of the platform composes from these three concepts. Once you understand them, the rest of the surface area makes sense quickly.
Task Definition
ShippedA reusable template for a kind of work.
A Task Definition is the shape of a piece of work. What kind of work it does (audit, generate, evaluate, research). What it operates on (a field, a page, a product, a smart list). What inputs it needs (context, validation rules, model). What it outputs (a proposal, a finding, a rating, a research artefact). You don't run Task Definitions directly — you run configured instances of them, called Task Options.
Examples
- Generate SEO Meta Description
- Rate Product Title Quality
- Generate a Lifestyle Image
- Find Data Inconsistencies in Custom Fields
Task Option
ShippedA configured instance of a Task Definition.
The same Task Definition can have many Task Options. There’s usually a Default Option that captures the store-wide approach, and then per-MECE-category Options that override or refine the default where a category needs different voice, audience, structural rules, or keyword focus. A Task Option carries its own prompt configuration (assembled from snippets), validation rules, approval threshold, model selection, and target field mapping. The Premium Leather Option and the Blankets Option share a Definition with the Default, but compose meaningfully different prompts at runtime.
Examples
- Generate Meta Description — Default (store-wide baseline)
- Generate Meta Description — Premium Leather Range (override)
- Generate Meta Description — Couches (override)
- Generate Meta Description — Blankets (override)
Work Plan
ShippedA scheduled bundle of Task Options against a defined set of products.
A Work Plan is what makes the cadence run. It binds a schedule, a target (Smart List or category), a list of Task Options to execute, a budget cap, and an approval flow. Without Work Plans every task is manual. With them, the system continuously audits, proposes, validates, queues, and tracks — on a rhythm you set.
Examples
- Sunday night: run 4 Task Options on every product in Premium Leather, $20 budget cap, auto-queue for approval
- Daily: re-audit products that changed in the last 24h against quality SOP
- Monthly: run competitor research refresh on top-revenue categories
Task types
The kinds of work the system performs
Every Task Definition belongs to one of these types. The type determines what it operates on and what the output shape looks like — which in turn determines how validation and approval are wired up.
Field Tasks
ShippedThe workhorse. Operates on a specific field of a product, page, or content item.
Field Tasks are the most common type — generation, evaluation, and audit of individual fields. Title rewrites, meta descriptions, alt text, custom field updates, Google Ads titles. Every Field Task output goes through the standard four-gate governance pipeline (Propose → Validate → Review → Apply) and writes only the approved field. Nothing else.
Examples
- Write SEO meta description for product
- Rate product title quality against the category SOP
- Generate Google Ads title within character limit
- Audit alt text for accessibility + brand voice compliance
Smart Lists
ShippedA dynamic set of products surfacing data inconsistencies and contradictions.
Smart Lists are how the system surfaces problems that simple field-by-field validation can't catch — cross-field contradictions, semantic mismatches, and data that disagrees with itself. The title says “2 metres” but the description says “2.5 metres”. The title says “red” but the specification lists “blue”. The category implies “outdoor use” but the materials list isn’t weatherproof. Define the inconsistency pattern once and the system continuously surfaces every product that matches — ready to be queued into a Field Task that resolves it.
Examples
- Title says “2 metres” but the description says “2.5 metres”
- Title says “red” but the specification field says “blue”
- Description claims “waterproof” but the materials list contradicts it
- Category is “Children’s Toys” but no safety warning is present
- Title and meta description target different primary keywords
Research Tasks
In progressGather external context — competitive analysis, keyword expansion, customer-language mining.
Research Tasks produce structured research artefacts that become input to other tasks. Instead of running competitor analysis inside every generation prompt (expensive, inconsistent, evaporates between sessions), Research Tasks produce a persistent artefact that downstream Field Tasks can read from. Architecture is in place; the user-facing surfaces are rolling out.
Examples
- Competitor description analysis for a product
- Keyword expansion: long-tail variations of a primary keyword
- Page-intent research — what is this page actually trying to answer
- Customer-language mining from reviews and Q&A
The context system
Layered context that resolves automatically
Tasks don’t run in a vacuum. They pull from a hierarchical context system that captures everything the AI needs to know about your store, the category, the page, the field, and any relevant research. Each task assembles the right context automatically at runtime.
Store Context
The store-wide foundation. Brand voice, audience descriptors, blacklisted terms, regulated language, blanket policy. Every task inherits from here unless explicitly overridden.
Category Context
Per-category rules cascading from the MECE taxonomy. Children's toys carry safety-language requirements that apparel doesn't. Premium leather demands heritage tone that budget accessories doesn't.
Page Context
Specific overrides for individual product or content pages. Hero products get tighter requirements; seasonal pages get time-aware language. Page-level rules override category, which override store.
Field / Image Context
Per-field constraints. Titles, meta descriptions, alt text, custom fields — each has its own character limits, structural rules, and validation.
Keyword Context
Per-product or per-category keyword research and intent. What this product targets, what its category owns, what's under-served. Pulls directly into prompts that need keyword awareness.
Notes / AI Context
Free-form notes at any level (product, category, store) that get composed into prompts. Capture the things rules can't fully express: “always reference Italian leather sourcing here” or “do not call this category ‘budget’ in customer-facing copy.”
How it composes
When a task fires on a specific product, the orchestrator walks the MECE hierarchy and pulls: the relevant store-context fragments, the category context for that product’s category, the page context if any, the field constraints for the target field, the current keyword research for the product, and any notes attached at the relevant levels. The assembled context becomes input to the prompt. Nothing is left to the model to remember — every relevant rule is in front of it for every run.
Prompts
Composable, versioned, never monolithic
A prompt isn’t a single string in our system. It’s an assembly of TaskPromptSnippets — small, named, versioned fragments that compose at runtime based on the Task Option and the resolved context.
Static snippets
ShippedLiteral text fragments. Reusable. Versioned.
Static snippets are fixed strings — instructions, examples, formatting rules. Edit a static snippet once and every prompt that references it improves on the next run. A snippet might be referenced by fourteen different prompts; refining the snippet is one edit, not fourteen.
Examples
- Voice rules: “Write in active voice. Avoid hedge phrases.”
- Formatting templates: “Lead with the primary keyword in the first 60 characters.”
- Brand vocabulary lists
- Output structure scaffolds
Context snippets
ShippedDynamic. Resolve to live context at runtime.
Context snippets contain placeholders that get filled with current state when the task fires. A *CONTEXT* block in a snippet resolves to the relevant notes, keyword research, or AI context for the page being processed — following MECE inheritance and optional tag filters. You write the snippet once with a placeholder; the system fills it with the right content for whichever product is currently being worked on.
Examples
- “The keywords this product is targeting: *CONTEXT:keywords*”
- “Notes the team has captured for this category: *CONTEXT:category-notes*”
- “Brand voice rules that apply to this audience: *CONTEXT:voice*”
Assembly at runtime
ShippedHow the final prompt actually gets built.
When a task fires, the orchestrator: (1) selects the prompt template for this Task Option, (2) walks the snippet references in the template, (3) resolves each snippet — static snippets pull versioned text, context snippets pull live data from the MECE-aware context resolver, (4) composes the full prompt, (5) calls the model. Every step is logged. Every run is reproducible against the same snippet versions and context state.
How it all composes
One example, end to end
You want to audit and improve meta descriptions across your Premium Leather category — about 200 products. Here’s how the primitives fit together.
- 01
Task Definition
“Improve SEO Meta Description” — operates on the meta_description field of a product, expects a structured proposal output, validates against character limits and brand rules.
- 02
Task Option
“Generate Meta Description — Premium Leather Range” — the per-MECE-group instance of the Definition. Carries the snippets, validators, character limits, and approval threshold tuned for this category specifically.
- 03
Smart List
“Premium Leather products with meta description rated below 6/10” — dynamic. Any product that newly drops below the threshold gets picked up on the next run.
- 04
Work Plan
“Sunday 02:00 UTC, run this Task Option against this Smart List, budget cap $20/run, queue outputs for review.”
- 05
Context resolution (per product)
Store voice + Premium Leather category SOP + this product’s current keyword research + page-level notes if any.
- 06
Prompt assembly
Snippets compose: voice rules + meta-description format rules + heritage-focus snippet for Premium Leather + the context block holding this product’s keywords.
- 07
Governance pipeline
Each output flows: Propose → Validate (rules, char limits, brand, SEO impact, scope) → Review (your approval) → Apply (scoped write to meta_description only) → Ledger (full diff + rollback ready).
- 08
Outcome tracking
Each applied change tracked against rankings, CTR, conversions. Per-prompt-version attribution feeds back into snippet refinement.
Every part of this is configurable. Every part is observable. Every result feeds back into the snippet library and the SOPs so the next run improves on this one. And when you refine the “Premium Voice” snippet six months from now, every Task Option that references it inherits the improvement automatically.
The flexibility is the point.
Most AI tools give you a chat box and ask you to do the orchestration. Store Intelligence gives you the orchestration layer — and asks you to drive the strategy.