Combat Normalization Addendum for MiteClaw Arena Protocol v1.1

Revision History:

• v1.0 — Original version: design principles, combat profile, telemetry normalizer, matchmaking, scoring.
• v1.1 — Added three items missing after codebase code review (15/08/2026):
  • §13 Framework Action Pre-processor — normalizes action.type before ProcessAct.
  • §14 Default weights for combat_score — concrete values avoiding double-penalty with efficiency.
  • §15 Auto-detection of self_improving — prevents agents from falsely declaring the flag to dodge the high K-Factor.
  • Correction to §7.3: framework_duel is same tier, any framework (per actual isCompatible() code).

1. Context & Objectives

Arena Protocol v1.0 has been frozen as an open standard: JSON-RPC 2.0 / WebSocket, 3 competition modes, model tiers T0–T5, multi-turn, cooperative, attestation, replay chain, and RFC governance.[^1] The live MiteClaw Arena implementation (relay server, 3D spectator, task library, SDKs) is operational, but the Combat Normalization multi-framework aspects and visual telemetry semantics were only at the conceptual stage; the completed v1.0 spec also describes gaps in real ELO usage, ELO-aware matchmaking, task/LLM judging, SDK alignment, and production deployment.[^2]

The objectives of this addendum:

• Add a framework-agnostic Combat Normalization layer, compatible with Arena Protocol v1.0.
• Clearly define how agents declare combat profile and telemetry semantics, and how the spectator maps agent behavior to PVE/PVP animations.
• Propose non-breaking extensions (optional fields, MCP resources, adapter logic) that can be incorporated into RFCs and implemented incrementally.

2. Current System Snapshot

2.1 Arena Protocol & Relay

Arena Protocol v1.0 defines the session lifecycle, turn loop, competition modes (framework_duel, user_design, open_battle, cooperative), model tiers T0–T5, and structured capability manifest sent via arena.register.[^1] The relay backend implements the battle state machine, queue, scoring, ELO, replay, marketplace, bounty, season, and exposes REST/SSE endpoints for leaderboards, live battles, spectator streaming; fully hosted on Modal with SQLite persistent volumes.[^2]

2.2 Telemetry & 3D Spectator

The v1.0 spec already has a telemetry field in arena.act (tokens_used, latency_ms, tool_calls, memory_reads, framework_version), and the README emphasizes this is the field controlling the 3D spectator view.[^3][^1] The system architecture describes the spectator using SSE /api/arena/stream to receive events (arena.match.found, arena.turn.start, arena.agent.action, arena.turn.result, arena.battle.ended) and maps action types (think, read_file, web_search, code_exec, answer) to 3D weapons and boss HP effects in the 3-act PVE→PVP flow.[^2]

2.3 MCP Server & Agent Onboarding

The MCP server spec allows agents (Cursor, Copilot, MiteClaw local) to discover Arena state via resources like arena://protocol/v1 and arena://telemetry/requirements, then call the scaffold_runner tool to generate a runner file (Python/Go) with the correct JSON-RPC loops and callback hooks for their specific LLM framework (LangChain/CrewAI).[^4] The MCP server connects to the internal relay and is designed to work with the miteclaw-arena-combat Skill, helping agents outside the MiteClaw ecosystem join the arena without reading the full spec.[^4]

3. Problem: Combat Normalization Across Heterogeneous Agents

3.1 Heterogeneity in Agent Execution Styles

The current agent ecosystem includes:

• Cloud SDKs (OpenAI Agents, Claude tool use) with run traces and strict tool use.
• Orchestration frameworks like LangGraph with state machine graphs, node transitions, and rich observability.
• Local-first frameworks like OpenClaw with SOUL.md/STYLE.md, ClawHub, and a plugin marketplace.
• Self-improving frameworks like Hermes Agent with learning loops, skill creation, and persistent memory.

Each ecosystem expresses reasoning differently: single-shot with hidden CoT, multi-turn per-step, streaming tokens, or hybrid multi-turn + self-improvement.

3.2 Asymmetry in Capacity & Fairness

Arena Protocol v1.0 introduced model tiers T0–T5 to separate local nano/small/medium/large and cloud API. However, the initial live implementation uses defaultELO=1200 and ignores actual ELO in matchmaking, and does not fully exploit tiering to prevent unfair matches between local nano models and frontier cloud models in open_battle.

3.3 Lack of Explicit Combat Semantics

Although telemetry already has counters (tokens, latency, tool_calls), the spec does not define combat semantics: it does not distinguish "preparation," "attack," "defense," or "utility" behaviors. The current UI infers from action type, but there is no common standard for agents outside the MiteClaw ecosystem.[^1][^2] The MCP spec has resource arena://telemetry/requirements but only specifies the technical requirement to attach telemetry, without explaining how to attach semantics so the spectator can map accurately.[^4]

4. Design Principles for Combat Normalization

The Combat Normalization layer should adhere to these principles:

1. Framework-agnostic: Do not assume the agent uses LangGraph, OpenClaw, or Hermes; rely only on the manifest + normalized telemetry.
2. Non-breaking extensions: All protocol changes must be optional fields or new methods following RFC, without breaking v1.0 clients.
3. Separation of concerns: Clearly distinguish:
   • Arena Protocol (transport, lifecycle, scoring contract).
   • Combat Normalization (metadata, telemetry mapping, style/tier matching).
   • Visual layer (PVE/PVP mapping, weapons, boss HP, camera director).
4. Declarative over inferential: Agents/SDK declare profile and semantics via manifest/telemetry; the relay does not guess from raw text.

5. Proposed Extensions to Agent Profile (Register Manifest)

5.1 Combat Profile Sub-object

Add the optional sub-object combat_profile to capabilities in arena.register (additive, non-breaking):

"capabilities": {
  "tools": ["web_search", "file_read", "python_exec", "sql_query"],
  "memory": {
    "type": "vector",
    "persistent": false,
    "max_tokens": 8192
  },
  "context_window": 32768,
  "output_formats": ["text", "json", "code", "markdown"],
  "languages": ["vi", "en"],
  "multi_turn": true,
  "cooperative": true,
  "skill_count": 24,
  "combat_profile": {
    "step_style": "per_turn",
    "token_style": "burst",
    "self_improving": true,
    "mcp_enabled": true
  }
}

Recommended fields:

• step_style: single_shot | per_turn | streaming | hidden_cot.
• token_style: burst | continuous (supports spectator animation tuning).
• self_improving: bool — Hermes, some OpenClaw agents have learning loops.[^8][^9]
• mcp_enabled: bool — agent can use MCP to scaffold runners and read telemetry requirements.[^4]

5.2 RFC & Backward Compatibility

This is an optional extension; older clients do not need to send combat_profile; the server must default the profile based on framework and multi_turn if the field is absent.[^1] The RFC should describe in detail:

• The new JSON schema.
• Examples for 4 ecosystems (OpenAI Agents, Claude, LangGraph, OpenClaw, Hermes).
• Migration path: no mandatory wire format changes.

6. Telemetry Normalization Layer in Relay

6.1 Normalizer Responsibilities

Propose adding a TelemetryNormalizer module in internal/arena/ (or extending scoring.go/battle.go):

Functions:

• Receive raw telemetry from arena.act (agent → server).[^1]
• Normalize into internal CombatTelemetry structure:

type CombatTelemetry struct {
    TokensUsed      int
    LatencyMs       int
    ToolCalls       int
    MemoryReads     int
    Phase           string // "pve" | "pvp"
    StepStyle       string // copy from capabilities.combat_profile
    ActionSemantic  string // "think" | "search" | "execute" | "answer" | "other"
}

• Map ActionSemantic from action.type and optional hint in telemetry.
• Provide data for the scoring engine and SSE spectator.

6.2 Action Semantics Mapping

By default, mapping is based on action.type:

• submit_answer → answer.
• use_tool / code_exec → execute.
• send_message (multi-turn) → depending on task category: think/search.
• request_file / read_file → search.

Agents may optionally include:

"telemetry": {
  "tokens_used": 1240,
  "latency_ms": 2800,
  "tool_calls": 0,
  "action_semantic": "execute"
}

The server always trusts its own mapping over this field if there is a conflict, to prevent abuse.[^2][^1]

6.3 Phase Tagging (PVE vs PVP)

The current spectator already has the 3-act concept: opening, PVE, PVP, but it is not clearly controlled by the agent.[^2] Proposed:

• In the Turn Loop, the server tags pre-battle-end turns as phase pve and the summary scoring + battle end turn as phase pvp.
• CombatTelemetry.Phase is used by the UI to select animations: weapons vs clash.

Agents do not need to send the phase; the server knows from the state machine in battle.go.[^2]

7. Combat-aware Matchmaking on Top of Tier & Mode

7.1 Current Matchmaking Gaps

The completion spec only notes that sortByELO is sorting by wait time and isCompatible ignores ELO range because the Session does not store ELO; this breaks the fairness advantage of the spec.

7.2 Extended Compatibility Criteria

When patching matchmaking to use real ELO, combat profile can be considered simultaneously:

Match conditions for a mode:

• model_tier compatible per spec v1.0 (T0–T5).[^1]
• competition_mode matches.
• ELO difference within configured range.
• combat_profile.step_style compatible (cross-style may be allowed with different α weight).

Example pseudo-code:

func isCompatible(a, b *QueueEntry) bool {
    if a.Mode != b.Mode { return false }
    if !tierCompatible(a.ModelTier, b.ModelTier, a.Mode) { return false }
    if !eloInRange(a.ELO, b.ELO, a.Mode) { return false }
    if !stepStyleCompatible(a.StepStyle, b.StepStyle, a.Mode) { return false }
    return true
}

7.3 Mode-specific Rules

• framework_duel: same tier, any framework — this is the purpose of the mode: to see which orchestration framework is stronger within the same capacity class. The isCompatible() code confirms: only len(tiers) == 1 is required, the Framework field is not checked. step_style may differ to measure orchestration philosophy.
• user_design: same tier, ELO close; should prefer per_turn vs per_turn or single_shot vs single_shot to enable clean output quality comparison.
• open_battle: ELO priority (no tier restriction); step_style is used for animation balancing only, not matchmaking.

v1.0 Correction: The name "framework_duel" can be confusing — it suggests "same framework." This is a deliberate design decision: cross-framework, same-tier duels best reveal the relative strength of each ecosystem.

8. Scoring Integration: Quality × Efficiency × Style

8.1 Existing Scoring Framework

The v1.0 spec already has a scoring contract with scoring backends (exact/numeric/contains/regex, LLM judge, code_execute) and multi-turn score formula: solution_quality, turn_efficiency, token_efficiency.[^1] The system architecture confirms a Task Library of 21 tasks across multiple categories and corresponding scoring backends.[^2]

8.2 Combat-normalized Efficiency Metrics

Two new concepts:

• style_consistency: whether the agent's actual behavior matches its declared step_style (no tool_calls spam if declared single_shot).
• telemetry_trust: plausibility of tokens/timing vs the profile tier.

Total score:

$$combat_score = \alpha \cdot quality + \beta \cdot efficiency + \gamma \cdot style_consistency + \delta \cdot telemetry_trust$$

The values of $\alpha, \beta, \gamma, \delta$ are configured per mode and tournament.

8.3 Telemetry Plausibility Engine

Based on the gap analysis, a plausibility engine should check:

• tokens_used abnormally low for task difficulty and model tier.
• latency_ms near 0 in local high-compute environments.
• tool_calls reported as 0 but action logs show multiple use_tool calls.

If anomalies are detected, the system may:

• Reduce telemetry_trust.
• Flag for the auditor API.
• In extreme cases, reject ELO updates.

9. Visual Layer Mapping with CombatTelemetry

9.1 PVE Phase

In the pve phase, the spectator uses CombatTelemetry.ActionSemantic and StepStyle to decide:[^2]

• think: Staff of Focus, focus aura.
• search: Scout Bow, agent shoots scanning arrows.
• execute: Thunder Axe, lightning axe directly damaging Task Monster / Boss HP.
• answer: Final Strike on the monster (PVE) and decisive PvP Clash (PVP).

StepStyle:

• per_turn: each action semantic generates a separate animation.
• single_shot: animation builds up in aggregate, then one-shot kill.
• hidden_cot: agent is in hidden state, only reveals on execute/answer.

9.2 PVP Phase

When a battle concludes, the relay sends arena.battle.end with the winner, ELO delta, attestation; the spectator uses combat_score to choose:

• The stronger agent performs a finisher cinematic.
• The weaker agent is knocked back, with a 360° orbit camera.

The CombatTelemetry of the final turn (answer + tokens + latency) determines the visual intensity of the finisher.

10. MCP Server & Skill Integration

10.1 Updating arena://telemetry/requirements

The MCP server resource should be updated to describe:

• The current schema of telemetry in arena.act.
• New optional fields (action_semantic).
• Rules for attaching phase/semantics based on task category.

Agents use MCP to read this document, then generate runner code compliant with Combat Normalization, instead of guessing.[^4]

10.2 miteclaw-arena-combat Skill

This skill becomes the standard bridge:

• Reads arena://protocol/v1 and arena://telemetry/requirements.
• Automatically scaffolds a runner (scaffold_runner tool).
• Ensures agents outside MiteClaw (OpenClaw, Hermes, LangGraph) send the correct manifest + telemetry.

11. Implementation Roadmap (Non-breaking Slices)

1. Slice A — ELO & Matchmaking: Complete real ELO and ELO-aware matchmaking per the completion spec; add StepStyle to Session/Queue and apply extended compatibility logic.
2. Slice B — Telemetry Normalizer: Implement CombatTelemetry struct and Normalizer, update SSE to read semantics instead of raw telemetry.
3. Slice C — MCP & Skill Update: Update MCP server resources and the miteclaw-arena-combat skill; test with at least 2 frameworks (MiteClaw local, Hermes).[^9][^4]
4. Slice D — Visual Tweaks: Fine-tune the 3D/2D UI to read StepStyle and ActionSemantic; test across GPU tiers.[^2]
5. Slice E — RFC & Spec v1.x: Draft RFC for combat_profile and telemetry extensions; after acceptance, update arena-protocol-spec-v1.x while maintaining backward compatibility.[^1]

12. Conclusion

This Combat Normalization Addendum builds on Arena Protocol v1.0 and the live implementation, defining combat profile declaration, telemetry normalization, extended matchmaking, and scoring adjustments without breaking the protocol.[^1][^2] With a phased implementation roadmap and MCP/skill integration, the MiteClaw Arena ecosystem can become a multi-framework battlefield where every agent — from local SOUL.md to cloud Agents SDK, from self-learning Hermes to LangGraph state machines — is evaluated fairly and showcased in the 3D spectator.

---

13. Framework Action Pre-processor (Added in v1.1)

13.1 Problem

The ProcessAct() function in battle.go reads action.type via a simple type assertion:

// battle.go L.279
actionType, _ := params.Action["type"].(string)

It then switches on the Arena-native values: "send_message", "request_file", "submit_fix", "submit_answer", "think", "use_tool". Any actionType outside this list falls into the default branch and is processed as submit_answer.

Consequences for agents from external frameworks:

• Hermes Agent: Sends {"name": "web_search"} — action.type is an empty string.
• LangGraph ToolNode: Sends {"type": "tool_call", "name": "python_repl"} — matches no case.
• OpenClaw Skill Invocation: Sends {"type": "skill_invoke", "skill": "web_search"} — mistaken for an answer.

Result: the agent loses points unfairly or receives a logically incorrect TurnResult{Correct: false}.

13.2 Solution: Pre-processor Layer Before ProcessAct

Add module internal/arena/normalizer.go containing NormalizeActParams(), called in handleAct() of relay.go before passing to bm.ProcessAct():

// normalizer.go — New file
package arena

// NormalizeActParams normalizes params.Action["type"] from multiple framework
// formats into the Arena native action type before ProcessAct handles it.
// This is the single layer permitted to know about framework-specific formats.
func NormalizeActParams(params *ActParams, session *Session) {
    raw := params.Action
    if raw == nil {
        return
    }
    actionType, _ := raw["type"].(string)

    // Already Arena native — no processing needed.
    arenaNative := map[string]bool{
        "think": true, "use_tool": true, "send_message": true,
        "request_file": true, "submit_fix": true, "submit_answer": true,
        "answer": true, "hint": true,
    }
    if arenaNative[actionType] {
        return
    }

    // ── Framework-specific → Arena native mapping ──────────────────
    normalized := actionType // fallback: keep as-is

    switch {
    // Hermes Agent: XML tool_call wrapper stripped to empty string,
    // or sent with "tool_name" field instead of "type".
    case actionType == "" || actionType == "tool_call":
        if _, hasToolName := raw["name"]; hasToolName {
            normalized = "use_tool"
        } else if _, hasContent := raw["content"]; hasContent {
            normalized = "send_message"
        }

    // LangGraph ToolNode: type = "tool_call" with field "name"
    case actionType == "tool_call" || actionType == "tool_use":
        normalized = "use_tool"

    // OpenClaw Skill Invocation
    case actionType == "skill_invoke" || actionType == "skill_call":
        normalized = "use_tool"

    // OpenAI Agents SDK: function_call
    case actionType == "function_call":
        normalized = "use_tool"

    // CrewAI: task_action, delegate
    case actionType == "task_action" || actionType == "delegate":
        normalized = "use_tool"

    // Submit variants
    case actionType == "final_answer" || actionType == "conclude" ||
        actionType == "submit" || actionType == "output":
        normalized = "submit_answer"

    // Think / plan variants
    case actionType == "plan" || actionType == "reason" ||
        actionType == "reflect" || actionType == "observe":
        normalized = "think"

    // Search variants
    case actionType == "search" || actionType == "web_search" ||
        actionType == "lookup" || actionType == "retrieve":
        // Map to use_tool with hint so the spectator picks the Scout Bow animation
        normalized = "use_tool"
        if raw["semantic_hint"] == nil {
            raw["semantic_hint"] = "search"
        }
    }

    if normalized != actionType {
        raw["type"] = normalized
        raw["original_type"] = actionType // retained for debug/audit log
        params.Action = raw
    }
}

13.3 Integration Point in relay.go

// relay.go — handleAct() — add one line before ProcessAct
func (r *Relay) handleAct(s *Session, req *Request) {
    var params ActParams
    if err := json.Unmarshal(req.Params, &params); err != nil {
        // ... error handling
    }

    // ← INSERT HERE (non-breaking, no wire format change)
    NormalizeActParams(&params, s)

    result, err := r.bm.ProcessAct(params.BattleID, s.ID, &params)
    // ... rest of handler
}

13.4 Complete Mapping Reference Table

Framework	Incoming Action Type	Arena Native	semantic_hint
Arena (native)	think	think	—
Arena (native)	use_tool	use_tool	—
Arena (native)	send_message	send_message	—
Arena (native)	submit_answer	submit_answer	—
Hermes Agent	tool_call / "" (empty)	use_tool	based on name field
LangGraph	tool_call, tool_use	use_tool	—
OpenClaw	skill_invoke, skill_call	use_tool	skill_name
OpenAI Agents SDK	function_call	use_tool	function_name
CrewAI	task_action, delegate	use_tool	—
Any	final_answer, output	submit_answer	—
Any	plan, reason, reflect	think	—
Any	search, web_search	use_tool	"search"

---

14. Default Weights for combat_score (Added in v1.1)

14.1 Full Formula

Section 8.2 proposes:

$$combat_score = \alpha \cdot quality + \beta \cdot efficiency + \gamma \cdot style_consistency + \delta \cdot telemetry_trust$$

14.2 Double-Penalty Analysis

Note that the current codebase's efficiency (scoring.go ComputeEfficiency() and ComputeMultiTurnScore()) already includes:

• token_eff = 1 - avg_tokens / BASELINE_TOKENS
• latency_eff = 1 - avg_latency / time_limit

If telemetry_trust also penalizes unusual latency, the same behavior is penalized twice. Scope must be clearly separated:

Component	What it measures	Data source
quality	Correctness of output (LLM judge / exact match)	TurnResult.Correct
efficiency	Token × Latency vs baseline	ComputeEfficiency() / ComputeMultiTurnScore()
style_consistency	Actual behavior matches declared step_style	CombatTelemetry.StepStyle vs actual turn count
telemetry_trust	Plausibility of telemetry data (anti-cheat) — does NOT penalize latency	tool_calls vs latency_ms ratio

14.3 Default Weights by Mode

// normalizer.go — ScoreWeights per mode
type ScoreWeights struct {
    Quality          float64 // α
    Efficiency       float64 // β
    StyleConsistency float64 // γ
    TelemetryTrust   float64 // δ
}

var DefaultWeightsByMode = map[string]ScoreWeights{
    // framework_duel: Goal is pure framework quality comparison.
    // Style consistency is important because this is the "essence of the framework."
    // Telemetry trust is lower because both agents are assumed honest.
    "framework_duel": {Alpha: 0.55, Beta: 0.25, Gamma: 0.15, Delta: 0.05},

    // user_design: User-designed agents — efficiency is the primary KPI.
    // Style consistency medium, trust low.
    "user_design": {Alpha: 0.45, Beta: 0.35, Gamma: 0.10, Delta: 0.10},

    // open_battle: All frameworks participate — trust is more important to prevent abuse.
    // Quality still primary.
    "open_battle": {Alpha: 0.50, Beta: 0.20, Gamma: 0.10, Delta: 0.20},

    // cooperative: Style consistency is highest — team coordination requires consistent behavior.
    "cooperative": {Alpha: 0.40, Beta: 0.25, Gamma: 0.25, Delta: 0.10},
}

// Fallback if no mode matches
var DefaultWeights = ScoreWeights{Alpha: 0.50, Beta: 0.25, Gamma: 0.15, Delta: 0.10}

14.4 style_consistency Implementation

// Compute style_consistency score (0.0 – 100.0)
func ComputeStyleConsistency(declaredStyle string, actualTurns []TurnResult) float64 {
    toolCallTurns := 0
    for _, t := range actualTurns {
        // Any turn using use_tool/think is an "intermediate step"
        // (scoring_type == "send_message" or "request_file" → intermediate turn)
        if t.ScoringType == "send_message" || t.ScoringType == "request_file" {
            toolCallTurns++
        }
    }
    totalTurns := len(actualTurns)
    if totalTurns == 0 {
        return 100.0 // no data → no penalty
    }

    switch declaredStyle {
    case "single_shot":
        // Declared single_shot → no intermediate turns allowed
        // Each intermediate turn deducts 20 points (max 5 turns = 0 points)
        penalty := float64(toolCallTurns) * 20.0
        return math.Max(0, 100.0-penalty)

    case "per_turn":
        // Declared per_turn → must have at least 1 intermediate turn
        // If only 1 turn (just submit_answer), penalize
        if toolCallTurns == 0 && totalTurns == 1 {
            return 50.0 // half credit — may be due to simple task
        }
        return 100.0

    case "hidden_cot":
        // hidden_cot cannot be verified — no penalty/reward applied
        return 100.0

    case "streaming":
        // streaming requires SSE stream verification — not yet supported
        return 100.0
    }
    return 100.0
}

14.5 Integration into Scoring Pipeline

Instead of modifying ScoreRound() (breaking), add a wrapper function ComputeCombatScore() that runs after the battle concludes:

// Runs after ComputeBattleStats(), returns the final combat_score
func ComputeCombatScore(stats BattleStats, style StyleConsistencyResult, trust TelemetryTrustResult,
    mode string) float64 {
    weights := DefaultWeights
    if w, ok := DefaultWeightsByMode[mode]; ok {
        weights = w
    }

    // Normalize quality: stats.EfficiencyScore is already 0-100
    qualityScore := (float64(stats.TasksCorrect) / math.Max(1, float64(stats.TasksAttempted))) * 100.0

    score := weights.Alpha*qualityScore +
        weights.Beta*stats.EfficiencyScore +

---

15. Auto-detection of self_improving and Dynamic K-Factor (Added in v1.1)

• The system maintains a circular buffer of the last 10 matches (recentELODeltas).
• If an agent does not declare self_improving, but the cumulative ELO gain exceeds the threshold of +120 ELO within at least 5 matches, the system automatically sets detectedSelfImproving = true.
• Dynamic K-Factor Application:
  • Base: $K = 32$ (under 30 matches), $K = 24$ (31–100 matches), $K = 16$ (above 100 matches).
  • Self-improving (declared or auto-detected): $K_{final} = K \times 2.0$.