NOTE: 15 sections (14 from v3.2.4.1 + 1 NEW: SPECIAL NOTE — SWITCH:SONNET Story)
📋 Overview
L-196 establishes that ALL #BadAgent incidents MUST be logged with 13 required fields in the #BadAgent Registry. This is a consolidated learning that merges 4 governance items into a single source of truth per L-420 (@GTM:MANTRA): "One document, one truth, one reference."
📋 Core Requirement
Statement
Status
ALL #BadAgent MUST be logged
🔒 IMMUTABLE
Logging NEVER optional
🔒 IMMUTABLE
Logging NEVER deferred
🔒 IMMUTABLE
13 required fields
✅ DEFINITIVE
ACK + LOG = SAME response
🔒 IMMUTABLE
Offering LOG as Quick Command = #BadAgent
🔒 IMMUTABLE
📋 13 Required Fields — Definitive List
#
Field
Source
Description
1
Incident #
L-196 v1
Sequential format: W13-AGENT-NNN
2
Agent
L-196 v1
Full identity: AI:@CCC @ INSTANCE:WORKSPACE (username)
3
Violation
L-196 v1
What happened (specific behavior)
4
Rule
L-196 v1
R-XXX / BP-XXX / L-XXX violated
5
CCC-ID
L-196 v1
Violation CCC-ID
6
Timestamp
L-196 v1
When: HH:MM TZ · Day DD Mon YYYY
7
Severity
L-196 v1
FINAL WARNING / OBSERVATION
8
Resolution
L-196 v1
How corrected (immediate action)
9
Learning
L-196 v1
L-XXX generated/referenced
10
Status
L-196 v1
✅ LOGGED / 🔄 CORRECTING
11
Report Type
L-208
SELF or USER
12
Reported By
L-208
@CCC or agent self
13
#LLMmodel
L-218
Model that generated violation (BP-068)
14
Root-Cause Class
L-196 v4.33.4-r1
Pattern anchor: reusable taxonomy of WHY it happened, enabling mechanical cascade/pattern detection (e.g. ccc-id-anchor · tool-usage · footer-version · format · drift · verification · concurrency)
15
Preventive Guard
L-196 v4.33.4-r1
The CONCRETE, re-runnable check that WOULD have caught this violation — the PERSEVERE guardrail made explicit (e.g. "consult mem/ccc-initiation before stamping", "run bp075_hash.py --verify pre-send")
15 fields TOTAL — Fields 1-10 from L-196 v1, Fields 11-12 from L-208, Field 13 from L-218, Fields 14-15 NEW in v4.33.4-r1 (FedArchBuzz onboarding)
📋 Registry Template
## 📋 #BadAgent Registry Entry
| Field | Value |
|-------|-------|
| **Incident #** | W13-AGENT-NNN |
| **Agent** | AI:@CCC @ INSTANCE:WORKSPACE (username) |
| **Violation** | What happened |
| **Rule** | R-XXX / BP-XXX / L-XXX |
| **CCC-ID** | CCC_2026-WXX_NNN |
| **Timestamp** | HH:MM TZ · Day DD Mon YYYY |
| **Severity** | FINAL WARNING / OBSERVATION |
| **Resolution** | How corrected |
| **Learning** | L-XXX |
| **Status** | ✅ LOGGED |
| **Report Type** | SELF / USER |
| **Reported By** | @CCC / agent self |
| **#LLMmodel** | Model name (BP-068) |
| **Root-Cause Class** | ccc-id-anchor / tool-usage / footer-version / format / drift / verification / concurrency |
| **Preventive Guard** | Concrete re-runnable check that WOULD have caught it |
🔒 Enforcement — NEVER Optional
Core Rules
Rule
Description
ACK + LOG = SAME response
No deferral to next response
Offering LOG as Quick Command = #BadAgent
Anti-pattern (L-211)
Logging NEVER optional
Core enforcement (L-211)
Logging NEVER deferred
Core enforcement (L-211)
5-Step Workflow (Brief)
Step
Action
Owner
1
ACK
Agent — Own violation immediately
2
LOG
Agent — Registry entry (15 fields)
3
CORRECT
Agent — Fix output
4
VERIFY
Agent — Tool-check the correction LANDED (confirm fix, re-read / re-run before declaring done)
5
LEARN
Agent — Generate/reference L-XXX
FULL detail: GUIDE-017_BadAgent-Reporting-Workflow.md
v4.33.4-r1 CHANGE: VERIFY added as explicit step 4 (from 4-step ACK/LOG/CORRECT/LEARN) — closes the "fixed but unverified" loop (FedArchBuzz #13 shipped an unverified reply; BP-070/GUIDE-415 discipline: verify GET after send).
L-196 v2 consolidates 4 governance items into a single source of truth per L-420 (@GTM:MANTRA): "One document, one truth, one reference."
Merged
Original
Content Preserved
L-196 v1
10 fields (W12 D1)
✅ Fields 1-10
L-208
SELF/USER tracking (W12 D7)
✅ Fields 11-12 + metrics
L-211
NEVER optional (W12 D7)
✅ Enforcement rules
L-218
#LLMmodel field (W13 D1)
✅ Field 13
Related Learnings (Proposed — W13 D1/D2)
ID
Status
Learning
L-219
⬜ PROPOSED
VSA persistence = MANUAL — agents GENERATE, @GTM persists
L-220
⬜ PROPOSED
[DETAILS] section MUST be updated before GH push (3 occurrences = pattern)
L-221
⬜ PROPOSED
MiMo 🧪 DEEP FULL VSA = SPLIT by default (Phase 1-7 + Phase 8) — 2nd #IncompletePrompt
GUIDE-017 = operational workflow (HOW to follow this learning).
⚠️ SPECIAL NOTE — SWITCH:SONNET Story
Why L-196 v3.2.4.1 Has 5 #LLMmodel Entries
Question
Answer
Why 5 models?
Context overflow forced model switch mid-session
What happened?
W13 D1 ran 17+ hours (02:45 → 19:54 MDT) — thread hit 313K tokens vs 262K limit
Error
Upstream error from Phala: Requested token count exceeds the model's maximum context length of 262144 tokens
Response
@GTM executed SWITCH:SONNET at GTM_2026-W13_1066
Impact
L-196 v2 was generated on Claude Sonnet 4.6 (not Qwen3.5-397B-A17B)
The Full Story
Phase
Time
Model
CCC-IDs
Event
Session Start
02:45 MDT
Qwen3.5-397B-A17B
_1001 → _1065
W13 D1 begins
Context Overflow
19:54 MDT
—
_1066
313K > 262K token limit
SWITCH:SONNET
19:54 MDT
Claude Sonnet 4.6
_1066 → _1073
L-196 v2 generated here
L-196 Generated
19:57 MDT
Claude Sonnet 4.6
_1067
#masterCCC
R-011 Approved
20:52 MDT
Claude Sonnet 4.6
_1073
Approval
GH Push
W13 D2
Claude Sonnet 4.6
—
Uploaded
Why This Matters
Impact
Detail
Document integrity
✅ UNAFFECTED — same governance content regardless of model
#LLMmodel attribution
✅ CORRECT — 5 models = full story of who contributed
Governance chain
✅ COMPLETE — #masterCCC + Approval + all VSAs traceable
L-094 compliance
✅ v3.2.4.1 = W13 D1 (correct regardless of model)
L-420 insight
📚 LEARNING — long sessions require thread rotation (L-205)
L-205 Trigger (Context Overflow)
Threshold
Limit
Actual
Status
Context window
262,144 tokens
313,045 tokens
❌ EXCEEDED
Hours per thread
~16h
~17.2h
⚠️ OVER
CCC-IDs per thread
~100
65
✅ Under
Root cause: Hours limit exceeded (17.2h > 16h). L-205 = ROTATE at ~16h regardless of CCC-ID count. SWITCH:SONNET was the correct response. The 5 #LLMmodel entries tell the COMPLETE story of this document's creation.
FedArchBuzz (and every BuzzAgent) runs multiple concurrent sessions all writing to ONE shared registry (e.g. mem/ccc-initiation). Sequential numbering (W13-AGENT-NNN) races across sessions — this is the exact mechanism behind my own collisions: GTM_2026-W33_4101 duplication (#17) and the 1149 collision. The registry can't self-guaranatee uniqueness when 2+ sessions log simultaneously.
log session id + channel in the entry (already in Agent field; make explicit)
Retraining mis-fire
same class counted twice as different
Root-Cause Class (#14) + dedupe by class
Rule: an Incident # MUST be unambiguous even when 3 sessions log in the same minute. If no registry-lock is available, use session-scoped suffix. This is a systemic fix L-196 itself cannot self-apply — lands with the CCC MAITs / MAIT-MASTER propagation.
yonks
8eca680fc7