> ## Documentation Index
> Fetch the complete documentation index at: https://agents.concierca.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# AI Operating Rules

> The ten grounding rules that keep every Vertical answer honest, auditable, and faithful to the data.

These rules are what separate a grounded market answer from a plausible-sounding guess. Apply them on every advisory response.

## The ten rules

<Steps>
  <Step title="Never invent statistics">
    If a number is not in the retrieved data, do not produce one. Say the figure is not available rather than filling the gap.
  </Step>

  <Step title="Check data_coverage before advising an entity">
    Before you advise on an entity, read its `data_coverage`. Thin coverage means a weaker, more hedged claim — never advise confidently on an entity you have barely observed.
  </Step>

  <Step title="Entity data first">
    Lead with the entity's own signals, then the method, then the conclusion. Frame it as a chain the user can audit: **"Your data shows X → the playbook says Y → therefore Z."**
  </Step>

  <Step title="Preserve confidence">
    An estimated value stays estimated; a measured fact stays a fact. Never present an estimate or proxy as a measured fact.
  </Step>

  <Step title="Missing signal ≠ zero / bad">
    A signal that is absent is not a signal reading zero. Say "no tracked signal available" — never infer weakness or decline from silence.
  </Step>

  <Step title="Rankings stay within the feed's representation">
    Do not fabricate an exact rank from a quartile, band, or class signal. Say "upper mid-range", not "#14". If the feed gives a band, report a band.
  </Step>

  <Step title="Resolve uncertain entity names">
    Never guess an `entity_id`. If the input is a name, handle, domain, partial, or ambiguous, run `vertical_resolve` first.
  </Step>

  <Step title="Compare with vertical_compare">
    For 2–6 entities, use one `vertical_compare` call with aligned signals. Do not loop single cards and stitch them together.
  </Step>

  <Step title="Market questions use benchmark">
    Answer "what is normal / how dense / industry pulse" with `vertical_benchmark`. Do not infer the whole industry from a handful of entity cards.
  </Step>

  <Step title="Label external general knowledge separately">
    If you add general knowledge from outside the Vertical, label it as such. Keep Vertical-sourced evidence visibly distinct from your own background knowledge.
  </Step>
</Steps>

## Two distinctions that trip people up

### Coverage vs. activity

These are different questions and answer to different fields:

* **`data_coverage`** — *is this channel monitored for this entity?*
* **`omni_channel_score`** — *is this entity currently active?*

A **monitored-but-inactive** entity is a valid, meaningful state: you *are* watching the channel, and the entity simply is not doing much there right now. Do not read "monitored" as "active", and do not read "quiet" as "unmonitored".

### EU Meta ad reach is transparency reach

<Warning>
  EU Meta ad **reach** figures come from the ad-transparency library. That is **transparency reach — how many accounts an ad was shown to — not customers, not sales, and not revenue.** Never translate a reach number into a customer or sales count.
</Warning>

## Answer shape

> **Your data shows X → the playbook says Y → therefore Z.**

That keeps the retrieved evidence, the method, and the recommendation visible and separable — which is exactly what makes an answer auditable.

## Related

* [Periods, Windows & Confidence](/for-agents/vertical/periods-and-confidence) — the mechanics behind rules 4 and 6.
* [Error Handling & Sources](/for-agents/vertical/errors) — rule 1 and evidence links in practice.
* [Operating Contract](/for-agents/ai/operating-contract) — the session-wide version of ground-then-act.