# How a Context Engine Stores and Queries Competitor Creative Intelligence

> Competitor ad research is perishable — a context engine solves the staleness problem by applying half-life decay so that recent competitor moves outweigh older ones at query time.

- **Category**: Theory
- **Read time**: 7 min read
- **Date**: July 2, 2026
- **Author**: Feather DB (Engineering)
- **URL**: https://getfeather.store/theory/context-engine-competitive-creative-intelligence

---

## The staleness problem in competitor research

Competitor ad research has a fundamental problem: it goes stale fast. A competitor's creative from eight weeks ago is nearly irrelevant to your brief today. But most teams store competitor research in documents, spreadsheets, or Notion pages that make no distinction between what was true this week and what was true last quarter. At brief time, the strategist either ignores the stale data or spends time manually triaging it — neither of which is efficient.

A context engine solves the staleness problem structurally. By applying configurable half-life decay to ingested competitor intelligence, recent moves automatically outweigh older ones at query time, without anyone having to manually archive or delete stale entries. The memory does the triaging.

For brands in competitive categories — D2C, fintech, quick-commerce — where competitor creative strategy shifts weekly, this is not a marginal improvement. It is the difference between competitive intelligence that informs briefs and competitive intelligence that clutters them.

## What to store and how to structure it

Competitor creative intelligence breaks into three categories, each with different decay characteristics. Current creative territory — what messaging themes, offers, and hooks competitors are running right now — decays fast. 45 days is a reasonable half-life for most categories. Structural creative patterns — how competitors sequence messaging in video, how they use social proof, what CTA structures they favor — change more slowly. 120 days is a reasonable half-life. Category-level macro patterns — what emotional angles work for the audience segment, what offer structures dominate the category — are slower still. 180 to 365 days.

Feather DB's namespace system makes this segmentation explicit. Competitor data is stored in separate namespaces by decay tier, and the scoring configuration applies the appropriate half-life to each tier at retrieval time.

```python
import feather_db as fdb
from feather_db import ScoringConfig, MetaRecord

db = fdb.DB.open("brand_competitive_intel.feather", dim=768)

def ingest_competitor_creative(creative: dict, embedder):
    vec = embedder.embed(creative["copy"] + " " + creative["hook"])

    meta = MetaRecord()
    meta.set_attribute("competitor", creative["brand"])
    meta.set_attribute("format", creative["format"])   # video / static / carousel
    meta.set_attribute("offer_type", creative["offer"])  # discount / free-trial / urgency
    meta.set_attribute("observed_ctr_est", creative.get("estimated_ctr", 0.0))
    meta.set_attribute("importance", creative.get("spend_signal", 0.5))

    # Current creative territory: fast decay
    db.add(
        id=creative["id"],
        vec=vec,
        text=creative["copy"],
        namespace="competitors::current",
        meta=meta
    )

def query_competitive_context(brief_text: str, embedder) -> dict:
    q = embedder.embed(brief_text)

    return {
        "current_territory": db.search(
            q, k=6, namespace="competitors::current",
            scoring=ScoringConfig(half_life=45.0, weight=0.6, min=0.0)
        ),
        "structural_patterns": db.search(
            q, k=4, namespace="competitors::patterns",
            scoring=ScoringConfig(half_life=120.0, weight=0.3, min=0.0)
        ),
        "category_macro": db.search(
            q, k=3, namespace="competitors::macro",
            scoring=ScoringConfig(half_life=270.0, weight=0.15, min=0.0)
        ),
    }

```

At 0.19ms p50 ANN latency and 97.2% recall@10, the three-namespace query completes in under 2ms and surfaces the most relevant competitor context for any given brief — not all competitor intelligence, just the portion that is semantically relevant and temporally current.

## Graph-linking competitor moves to brand responses

Storing competitor intelligence in isolation misses the most useful insight: how your brand has historically responded to specific competitor moves, and what those responses produced. A context graph makes this connection explicit. Each competitor creative can be linked to the brand campaign that responded to it, with the ROAS or CPL outcome attached to the edge. At brief time, the graph traversal surfaces not just what competitors are doing, but what your brand has already tried in response and whether it worked.

```python
def link_response_to_competitor(competitor_id: str, brand_campaign_id: str, outcome: dict):
    db.link(
        from_id=brand_campaign_id,
        to_id=competitor_id,
        rel_type="responded_to",
        weight=outcome.get("roas", 1.0) / 5.0  # normalize ROAS to 0–1 weight
    )

def get_response_history(competitor_creative_id: str) -> list:
    # Traverse: what did this brand do when this competitor ran this creative?
    chain = db.context_chain(
        start_id=competitor_creative_id,
        rel_types=["responded_to"],
        direction="incoming",
        max_depth=2
    )
    return chain

```

Over time, the graph accumulates a map of competitive creative dynamics specific to this brand and category. Which competitor moves historically triggered successful brand responses. Which competitor creative themes your brand has tried to match and failed. Which competitor angles you have never addressed and might represent opportunity.

## Competitive intelligence at scale

Hawky.ai runs competitive intelligence ingestion for brands including Puma, Cars24, and Swiggy — categories where competitor creative density is high and creative cycles are fast. The context engine approach means that a Swiggy brief on delivery speed messaging automatically retrieves what Zomato and Blinkit have been running in the same territory, weighted by how recent those creatives are, without requiring the strategist to manually pull the research.

The operational benefit is brief quality and brief speed. The 160+ hours saved per brand per month that Hawky.ai reports includes the time previously spent in manual competitor research sessions. That time does not disappear from the competitive intelligence process — it moves to the ingestion step, where it runs once and informs all subsequent briefs rather than being repeated fresh for each one.

## The decay configuration that matches your category

Half-life configuration is category-specific. In quick-commerce, where competitor creative cycles run weekly, a 21-day half-life for current territory makes sense. In fashion, where seasonal creative themes recur annually, a 90-day half-life for structural patterns is more appropriate. Feather DB's per-namespace scoring configuration makes this explicit and adjustable without data migration — change the half-life parameter at query time and the ranking immediately reflects the new decay model.

The 0.693 LongMemEval score for Feather DB — versus 0.640 for GPT-4o with full context access — demonstrates that structured memory retrieval with decay outperforms brute-force context stuffing for the kind of temporal reasoning that competitive intelligence requires. More competitor data does not improve brief quality; more correctly weighted competitor data does.

## FAQ

### How does a context engine handle competitor intelligence from multiple sources?

Source metadata is stored per-ingested record. Intelligence from ad libraries, agency monitoring tools, or manual observation can all be ingested into the same namespace with source attributes attached. At retrieval time, you can filter by source, apply different importance weights per source, or treat all sources equally — the filtering is handled by Feather DB's metadata intelligence layer.

### What happens to competitor intelligence that turns out to be wrong?

Records can be updated with corrected metadata or re-weighted with lower importance. The half-life decay naturally deprioritizes old records over time, so inaccurate intelligence from several months ago has minimal influence on current retrievals even without explicit correction. For actively misleading records, the importance attribute can be set to zero to suppress retrieval.

### Can the context engine track competitor creative evolution over time?

Yes, through the context graph. Each competitor creative ingested at different time points can be linked chronologically — `db.link(from_id=newer, to_id=older, rel_type="evolved_from")`. The `db.context_chain()` traversal then surfaces the creative lineage, showing how a competitor's messaging has shifted over time and what the current endpoint of that evolution looks like.

### How much competitor data is needed to make retrieval useful?

Useful retrieval begins with 20–30 indexed competitor creatives per major competitor. Precision improves as the index grows. For categories with multiple active competitors, prioritize depth on the top 2–3 competitors over breadth across many. The semantic search layer means that even a sparse index surfaces the most relevant results — it does not require exhaustive coverage to be useful.

### Does competitor intelligence in the context engine stay private per brand?

Yes. Each brand's `.feather` file is isolated. No data is shared between brand files, and no cloud infrastructure is required that could create shared access risks. The embedded deployment model — one file, running locally — makes data isolation structural rather than a policy question.

---

*This is the machine-readable mirror of the theory post at [getfeather.store/theory/context-engine-competitive-creative-intelligence](https://getfeather.store/theory/context-engine-competitive-creative-intelligence). For the full Feather DB documentation, see [getfeather.store/llms-full.txt](https://getfeather.store/llms-full.txt).*