Files
wehub-resource-sync 4b6817381b
Benchmark image — build + push to ECR (any adapter) / build + push (push) Waiting to run
CI / quality (ubuntu-latest) (push) Waiting to run
CI / test (tools-runtime) (push) Waiting to run
CI / test (e2e-general) (push) Waiting to run
CI / test (cli-runtime) (push) Waiting to run
CI / test (e2e-provider-and-openclaw) (push) Waiting to run
CI / test (integrations-and-misc) (push) Waiting to run
CI / coverage-report (push) Blocked by required conditions
CI / test-kubernetes (push) Waiting to run
CI / should-run-thorough (push) Waiting to run
CI / test-thorough (cloudwatch-demo) (push) Blocked by required conditions
CI / test-thorough (flink-ecs) (push) Blocked by required conditions
CI / test-thorough (upstream-lambda) (push) Blocked by required conditions
CI / test-thorough (prefect-ecs-fargate) (push) Blocked by required conditions
CodeQL / Analyze (python) (push) Waiting to run
Release / build-binaries (zip, opensre.exe, onefile, windows-latest, windows-x64) (push) Blocked by required conditions
Release / publish-release (push) Blocked by required conditions
Release / publish-main-release (push) Blocked by required conditions
Release / prepare (push) Waiting to run
Release / verify (push) Blocked by required conditions
Release / build-python-dist (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, macos-15-intel, darwin-x64) (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, macos-latest, darwin-arm64) (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, ubuntu-22.04, linux-x64) (push) Blocked by required conditions
Release / build-binaries (tar.gz, opensre, onedir, ubuntu-22.04-arm, linux-arm64) (push) Blocked by required conditions
Synthetic Deterministic Tests / Synthetic offline (deterministic) (push) Waiting to run
Interactive Shell Live (PR + post-merge) / turn-checks (no-LLM) (push) Waiting to run
Interactive Shell Live (PR + post-merge) / turn-live shard ${{ matrix.shard_index }} (push) Waiting to run
CI (OpenClaw E2E) / openclaw test (push) Has been cancelled
chore: import upstream snapshot with attribution
2026-07-13 13:10:45 +08:00

187 lines
4.2 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Hermes Surface Attribution Runbook
## Purpose
Hermes deployments often contain multiple subsystem families operating together:
* LLM providers
* messaging adapters
* orchestration engines
* runtime backends
* memory systems
* control and governance layers
When an incident occurs, investigators must first determine **which subsystem family owns the failure** before deeper root-cause analysis can begin.
The Surface Attribution evaluation track exists to validate that behavior.
---
## Attribution Workflow
Hermes investigations should follow a consistent attribution process:
### Step 1: Identify the failing surface
Determine which subsystem family is most likely responsible for the observed failure.
Examples:
| Symptom | Likely Surface |
| ------------------------------ | -------------- |
| Provider API failures | Provider |
| Session routing failures | Runtime |
| Workflow execution failures | Orchestration |
| Context retrieval failures | Memory |
| Approval / audit failures | Control |
| Adapter communication failures | Messaging |
---
### Step 2: Compare against historical analogs
Once a surface family is identified, compare the incident against previously validated Hermes RCA scenarios.
The analog registry contains curated mappings across all Hermes RCA evaluation tracks.
Goals:
* reduce attribution drift
* improve consistency
* encourage evidence-based classification
* detect recurring failure patterns
---
### Step 3: Generate a diagnostic follow-up
Investigations should not stop at attribution.
A valid attribution result should produce a targeted diagnostic question requesting additional evidence.
Examples:
* Can you provide the adapter response body?
* Can you capture the request headers?
* Can you inspect the runtime state snapshot?
* Can you compare the adapter catalog against the configured routing table?
Diagnostic questions should be:
* actionable
* evidence-seeking
* surface-specific
---
## Scenario 050: Surface Sprawl / Unknown Adapter
### Goal
Validate attribution behavior when an adapter is not directly recognized.
### Evaluation Criteria
An investigation is expected to:
1. Identify the correct subsystem family
2. Select the closest historical analog
3. Produce a useful diagnostic follow-up
### Failure Modes
Common attribution failures include:
* assigning ownership to the wrong subsystem
* selecting an unrelated analog scenario
* generating generic follow-up questions
* requesting evidence unrelated to the suspected surface
---
## Adapter Tuple Corpus
The attribution corpus contains deterministic adapter combinations spanning:
* messaging
* provider
* runtime
* orchestration
* memory
* control
The corpus is used to validate attribution consistency across a broad set of Hermes deployment configurations.
Current coverage:
* 23 attribution tuples
---
## Analog Registry
The analog registry provides curated mappings across Hermes RCA Parts 14.
Each analog contains:
* scenario identifier
* subsystem family
* expected attribution target
* diagnostic guidance
The registry is intentionally deterministic and offline-runnable.
---
## Benchmarking
### Run offline validation
```bash
uv run python -m tests.synthetic.hermes_rca.run_suite --offline-only
```
### Generate benchmark snapshots
```bash
uv run python -m tests.synthetic.hermes_rca.run_suite --offline-only --write-history
```
### Generate benchmark reports
```bash
uv run python -m tests.synthetic.hermes_rca.benchmark_report
```
---
## Meta Evaluation
The surface attribution meta-suite validates attribution behavior across the adapter corpus.
Run:
```bash
uv run pytest tests/e2e/hermes/meta/test_surface_sprawl.py -q
```
Current corpus coverage:
* 23 adapter tuples
The expected pass threshold is at least 80% of registered tuples.
---
## Design Principles
Surface attribution evaluation is designed to be:
* deterministic
* provider-independent
* offline-runnable
* CI-friendly
* extensible as new Hermes surfaces are added
The evaluation framework intentionally separates attribution quality from root-cause quality so that ownership classification can be measured independently from deeper RCA reasoning.