6.19 ConfigDriftDetector

1. Bot Identity

Operational profile

2. Purpose

Compares the running BotConfig of every live bot against the latest committed config in the config repo. Any drift (running != committed) is surfaced as a ConfigDriftReport naming the bot, the field, and the drift amount. Operators are forced to either commit the change or revert it.

3. Why This Bot Matters

• Untracked tuning

  An on-call who tweaks a threshold via the Admin UI without committing the change loses an audit trail; the next incident review cannot reconstruct the system state.

• Drift between staging and prod

  Without an explicit comparison, prod can silently run an ancient config while staging is updated.

• Compliance evidence

  Auditors require evidence that the running configuration matches a reviewed and signed-off version.

No worked examples on this bot yet. Worked examples are optional but strongly recommended — they turn an abstract failure mode into something a developer can verify in a fixture.

4. Required Polymarket Inputs

— not yet authored —

5. Required Internal Inputs

6. Parameter Guide

7. Detailed Parameter Instructions

{ "check_interval_minutes": 15 }

schedule.every(p.check_interval_minutes).do(check);

{ "tolerance_for_numeric_drift": 0 }

if (abs(running - committed) > p.tolerance_for_numeric_drift) flag(field);

8. Default Configuration

{
  "check_interval_minutes": 15,
  "tolerance_for_numeric_drift": 0
}

9. Implementation Flow

— not yet authored —

10. Reference Implementation

Pseudocode is language-agnostic. FETCH = read input. EMIT = produce output. IF/THEN/ELSE = decision. Translate directly to TypeScript, Python, Go, or Rust.

for bot in registry.live_bots():
  running = bot.runtime_config()
  committed = repo.config(bot.slug, branch='main')
  diffs = canonical_diff(running, committed, p.tolerance_for_numeric_drift)
  if diffs: emit('ConfigDriftReport', bot.slug, diffs)

11. Wire Examples

Input — what arrives on the wire

{
  "bot_slug": "risk.killswitch",
  "running": {
    "intraday_drawdown_pct": 10
  },
  "committed": {
    "intraday_drawdown_pct": 12
  }
}

Output — what the bot emits

{
  "kind": "ConfigDriftReport",
  "bot_slug": "risk.killswitch",
  "drifts": [
    {
      "field": "intraday_drawdown_pct",
      "running": 10,
      "committed": 12
    }
  ]
}

12. Decision Logic

13. Standard Decision Output

This bot returns a RiskVote object. See RiskVote schema.

{
  "kind": "ConfigDriftReport",
  "bot_slug": "risk.killswitch",
  "drifts": [
    {
      "field": "intraday_drawdown_pct",
      "running": 10,
      "committed": 12,
      "since_ts_ms": 1715260000000
    }
  ]
}

14. Reason Codes

15. Metrics & Logs

Metrics emitted

Dashboards

• 6.19 overview dashboard

16. Developer Reporting

"Per check: bot_slug, drifts_count, fields_drifted."

17. Plain-English Reporting

18. Failure-Mode Block

19. Failure-Injection Recipes

20. State & Persistence

Last drift report per bot. Persisted to KV.

State stores

Cold-start recovery

Cold-start hydrates from fast KV; missing keys default to safe fallback.

On restart

All in-flight decisions are re-evaluated; no bot decision is trusted across restart without re-emit.

21. Concurrency & Idempotency

22. Dependencies

23. Security Surfaces

Read-only access to config repo. Read-only RPC into bot runtime.

Signing surface

None — bot does not sign or submit.

Mitigations

• Rate-limit per source
• Audit-log every override
• Require role-based authz on admin paths

24. Polymarket V2 Compatibility

25. Versioning & Migration

26. Acceptance Tests

Unit Tests

Integration Tests

Property Tests

27. Operational Runbook

If multiple bots drift simultaneously: confirm the config repo branch the checker is reading from is the production branch.

On-call actions

Manual overrides

• polytraders bot pause 6.19 — Disables the bot's enforcement layer; downstream consumers fall back to safe defaults.

Healthcheck

GET /healthz/config_drift_detector → 200 if last successful evaluation < 60s ago.

28. Promotion Gates

A bot does not advance to the next readiness state until every gate below is green. Gates are observable from production data — no subjective sign-off.

Promote to Shadow

Promote to Limited live

Promote to General live

29. Developer Checklist

Ready-to-ship score: 27/27 sections complete · 100%