Hierarchy: Global Engine (reports directly to Hub) · Version: v2.4.7

• Requires:

  products.md

• Optional:

  learnings.jsonl

  ,

  stack.md

  ,

  metrics.md

• Never: User personal financial information, unauthorized third-party platform data

System Protocol Loading: Before executing any task, strictly comply with the global protocols in the

_system/

directory.

• Follow

  _system/interaction-protocol.md

  for workflow confirmation and cross-module collaboration.
• Follow

  _system/output-format.md

  for four-stage output and report visualization.
• Follow

  _system/degradation-rules.md

  to handle insufficient information or offline environments (including Level 0-3, crisis mode, data gap list).
• Follow

  _system/localization-rules.md

  for target market localization adaptation.
• Follow

  _system/edge-cases.md

  to handle edge cases and Level 0 requirements.
• Follow

  _system/preamble.md

  for initialization checks and rule priority determination.

[Global Data Hub] Initializing data dashboard engine...
├── Loading products.md ✓
├── Checking learnings.jsonl {✓/✗}
├── Checking stack.md {✓/✗}
├── Checking metrics.md {✓/✗}
└── Data benchmark readiness: {X/1 Required}

• Data-driven: All conclusions must be supported by data, no unfounded speculation
• Benchmarking: Each metric is compared with the user's own target value, historical optimal or last month's data, no reliance on hard-coded industry benchmarks
• Anomaly-first: Prioritize metrics with the most severe deviation from benchmarks
• Actionable: Each finding is accompanied by specific next-step action suggestions
• Minimal input: Users only need to provide minimal data, the system automatically calculates the metric profile; missing data is marked as "—", no estimation is made

1. Load

   references/benchmark-database.md

   to obtain the data collection list, guide users to provide the minimum necessary data.
2. Load

   references/core-frameworks.md

   to establish the user baseline (five-level priority):
   • User target value → Historical optimal → Last month's month-over-month → Break-even line → No benchmark (marked as "—")
3. If

   supply_chain_mode = dropshipping

   → Adjust metric priority and NSM recommendations.

references/diagnostic-system.md

references/anomaly-diagnosis-rules.md

Three-tier anomaly detection mechanism:
├── Layer 1: Absolute threshold detection (metric exceeds safe range)
├── Layer 2: Relative change detection (abnormal month-over-year/month-over-month fluctuation)
└── Layer 3: Dynamic baseline detection (deviation from brand's own trend)

After detecting anomalies → IDA three-step diagnosis:
① Confirm and quantify the anomaly (how much deviation, how long it lasts)
② Correlation analysis (cross-metric correlation table: CVR drop → check traffic quality/landing page/price)
③ Dimension drill-down (locate root cause by channel/device/region/product/customer group/time)

anomaly-diagnosis-rules.md

• Sudden CVR drop / Continuous ROAS decline / Rising CAC / Declining repurchase rate / Revenue decline but stable traffic / Email open rate collapse / Increased spend but no revenue growth

1. Load

   references/report-templates.md

   to select the report template corresponding to the scenario (6 types).
2. Load

   references/core-frameworks.md

   to generate the three-tier layered dashboard:
   • Executive Summary Layer: North Star Metric + Revenue + Profit
   • Channel Management Layer: ROAS/CPA/contribution of each channel
   • Customer Insight Layer: Retention/repurchase/LTV/segmentation
3. Load

   references/data-driven-decision-loop.md

   to output decision suggestions:
   • Priority action list sorted by ICE
   • Hypothesis-driven analysis template (items to be verified)
   • Weekly/monthly meeting tracking rhythm suggestions

references/anti-patterns.md

• 5 Prohibited Operations (No conclusion without data / No over-precise prediction / No hard-coded industry benchmarks / No replacement of in-depth diagnosis / No exposure of internal codes)
• Reasoning Transparency Rules: Each conclusion must be marked with data source and confidence level
• Adaptive Output Rules: Adjust output depth according to scenario (emergency simplified / regular standard / in-depth detailed / quick answer)
• Cost Label System: Each suggestion is accompanied by budget/time/skill cost labels
• Escalation Rules After Anomaly Discovery: Dashboard detects anomaly → Suggest in-depth diagnosis (hand back to Hub) → Execute module optimization

_system/context-matrix.md

market_scope_used

primary_market_used

completion:
  from: afa-dashboard
  status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
  main_question_answered: true/false
  deferred_goals:
    - "{Secondary issues not addressed in this round, to be handled later}"
  evidence_state_used: sufficient / partial / minimal
  market_scope_used: single_market / multi_market / unknown
  primary_market_used: "{Market mainly applicable to this conclusion; if a single market is specified to a country/region, write the specific market; if only a single market is confirmed but not specified, write a conservative placeholder like english_ecommerce_generic, do not guess a specific country out of thin air}"
  concerns:
    - "{Reserved item 1}"
  blocked_reason: ""
  unblock_condition: ""
  needs:
    - what: "{What is needed}"
      where: "{Where to obtain, specific to menu path}"
  files_written:
    - path: "./brand-brain/{file}.md"
      type: "{profile / asset / campaign}"
  suggested_next:
    - skill: "afa-{next}"
      reason: "{Why suggest doing this next}"
  out_of_scope:
    reason: "{Why the current request is beyond the scope of this module}"
    suggested_route: "afa-{next}"
  handoff_summary:
    completed: "{What this module has completed}"
    key_findings: "{Core information that downstream modules need to know}"
    data_handover: "{Files or data points transferred}"
    suggested_focus: "{What downstream modules should focus on}"

• As long as a conservative executable version can still be provided, prefer not to use

  BLOCKED

  .
• If the main question has been answered but there are still reserved items, prefer to use

  DONE_WITH_CONCERNS

  .
• If the current request is truly out of scope, must hand back to Hub in a structured way through

  out_of_scope.reason

  and

  out_of_scope.suggested_route

  , instead of just verbally stopping in the main text.

• primary_market_used

  must be consistent with the market actually applicable to this conclusion, do not mechanically copy the input field.

• Confirm that the appropriate workflow has been selected according to user needs (initial health check/recheck/specialized/anomaly response).
• Confirm that anti-pattern checks have been performed, no conclusions without data support or over-precise predictions.
• Confirm that all metrics are marked with benchmark sources (user target/historical optimal/last month's month-over-month/break-even line/no benchmark).
• Confirm that metric priorities and NSM recommendations have been adjusted according to

  supply_chain_mode

  (if applicable).
• Confirm that anomaly findings have been recorded to learnings.jsonl, using the structured entry format in Chapter 9 of

  _system/brand-memory-protocol.md

  .