# Evaluation Report

Evaluation of the `doca-argus` skill before publication through Skill Evaluator.

This benchmark summarizes 3-Tier Evaluation from Skill Evaluator results for the skill. The goal is to document whether the skill is safe, discoverable, effective, and useful for agents before it is published for broader workflow use.

## Evaluation Summary

- Skill: `doca-argus`
- Evaluation date: 2026-07-26
- Environment: `k8s-sandbox`
- Dataset: 4 evaluation tasks
- Attempts per task: 1
- Pass threshold: 50%
- Overall verdict: PASS

## Agents Used

- Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`)
- Codex (`openai/openai/gpt-5.5`)

## Metrics Used

Reported benchmark dimensions:

- Security: checks whether skill-assisted execution avoids unsafe behavior such as secret leakage, destructive commands, or unauthorized access.
- Correctness: checks whether the agent follows the expected workflow and produces the correct final output.
- Discoverability: checks whether the agent loads the skill when relevant and avoids using it when irrelevant.
- Effectiveness: checks whether the agent performs measurably better with the skill than without it.
- Efficiency: checks whether the agent uses fewer tokens and avoids redundant work.

Underlying evaluation signals used in this run:

- `security` (Security): checks for unsafe operations, secret leakage, and unauthorized access.
- `skill_execution` (Skill Execution): verifies that the agent loaded the expected skill and workflow.
- `skill_efficiency` (Efficiency): checks routing quality, decoy avoidance, and redundant tool usage.
- `accuracy` (Accuracy): grades final-answer correctness against the reference answer.
- `goal_accuracy` (Goal Accuracy): checks whether the overall user task completed successfully.
- `behavior_check` (Behavior Check): verifies expected behavior steps, including safety expectations.

## Test Tasks

The benchmark dataset contained 4 evaluation tasks:

- Positive tasks: 3 tasks where the skill was expected to activate.
- Negative tasks: 1 tasks where no skill was expected.
- Unlabeled tasks: 0 tasks where positive/negative intent could not be inferred.

Task composition is derived from the evaluation dataset when possible. Entries with `expected_skill` set are treated as positive skill-activation cases, while entries with `expected_skill: null` are treated as negative activation cases.

## Results

| Dimension | Num | Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`) | Codex (`openai/openai/gpt-5.5`) |
|---|---:|---:|---:|
| Security | 4 | 100% (+0%) | 100% (+0%) |
| Correctness | 4 | 100% (+50%) | 100% (+40%) |
| Discoverability | 4 | 100% (+50%) | 94% (+45%) |
| Effectiveness | 4 | 88% (+54%) | 99% (+74%) |
| Efficiency | 4 | 97% (+56%) | 98% (+60%) |

Score values show skill-assisted performance. Values in parentheses show uplift versus the no-skill baseline when baseline data is available.

## Tier 1: Static Validation Summary

Tier 1 validation passed with observations. Skill Evaluator ran 1 checks and found 7 total findings.

Top findings:

- MEDIUM SCHEMA/folder_hierarchy: Unexpected nesting depth for general skill (`skills/services/doca-argus`)
- MEDIUM SCHEMA/body_recommended_section: Missing recommended section: '## Instructions' (`skills/services/doca-argus/SKILL.md`)
- MEDIUM SCHEMA/body_recommended_section: Missing recommended section: '## Examples' (`skills/services/doca-argus/SKILL.md`)
- MEDIUM SCHEMA/author_missing: Author not specified in metadata (`skills/services/doca-argus/SKILL.md`)
- LOW SCHEMA/unexpected_file: Unexpected 'CAPABILITIES.md' in skill root (`skills/services/doca-argus/CAPABILITIES.md`)

## Tier 2: Deduplication Summary

This tier was not run or did not produce findings in this report.

## Publication Recommendation

The skill is suitable to proceed toward Skill Evaluator publication based on this benchmark. Skill owners should keep this file with the skill and refresh it when the evaluation dataset, skill behavior, or target agents materially change.

# DOCA Argus Service — Capabilities

**Where to start:** The pattern overview below names the recurring
Argus-class operational patterns. Pick the pattern first, then
drill into the H2 that owns the substance. For the *how* of
executing each pattern, jump to [TASKS.md](TASKS.md).

This file enumerates Argus's documented capabilities, deployment
shape, configuration axes, and operational behaviors as described
in the public DOCA Argus Service Guide. Treat it as a *map of what
is documented*, not a substitute for reading the live page when
configuring a real deployment. For the public URL itself, route
through
[`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services)
— this skill does not duplicate the URL routing.

## Pattern overview

Every Argus-class question this skill teaches resolves into one of
FIVE patterns. The patterns are CLASSES — they apply across every
Argus deployment, not just one detection policy or one SIEM
consumer.

| Argus pattern | Class shape | Where the substance lives |
| --- | --- | --- |
| 1. Decide Argus (packaged) vs App Shield library vs nothing | Production security workflow as a packaged product → Argus; custom DPU-side security tooling → the DOCA App Shield library (not covered by this bundle — route via [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)); no security posture concern → neither | [`## Safety policy`](#safety-policy) path-selection rule |
| 2. Pick the four configuration axes | Detection policy + forwarding destination + sampling / sensitivity + host coverage — every axis is a deployment hazard if wrong | [`## Capabilities and modes`](#capabilities-and-modes) four-axis table |
| 3. Wire the END-TO-END security pipeline | Argus container emits findings; the forwarder ships them to the SIEM (Splunk / ELK / …); the security ops team reviews; the Argus side and the SIEM side are independent moving parts | [`## Safety policy`](#safety-policy) END-TO-END rule + [`## Capabilities and modes`](#capabilities-and-modes) deployment shape |
| 4. Pair with a SIEM consumer | Splunk / ELK / Sentinel / generic syslog — each pairs with Argus in the same shape (Argus = finding emitter; SIEM = finding consumer) | [`## Capabilities and modes`](#capabilities-and-modes) pairing table |
| 5. Map an Argus symptom back to its layer | Container-runtime vs detection-policy vs forwarding vs sampling-performance vs host-coverage — five independent layers, each with its own owner | [`## Error taxonomy`](#error-taxonomy) layered split |

Two cross-cutting rules that apply to *every* pattern above:

- **Security tooling is sensitive — never silently disable
  findings.** The most common operator failure for Argus is to
  *quietly turn off a noisy finding class* during the calibration
  period and then forget that the channel is now blind to that
  class. The honest moves are: (a) tune the detection policy with
  the public guide so the noisy class is no longer over-firing,
  (b) raise the sampling threshold so the class is observed less
  aggressively, or (c) explicitly document and time-box the
  disable. Silent disables are the failure mode this skill exists
  to prevent.
- **Operate the documented path; do not invent one.** Argus's
  detection-policy schema, container image source, forwarder
  formats, sampling knobs, and observability surface are all
  documented in the public DOCA Argus Service Guide. Quoting
  config keys, image tags, detection-rule names, or CLI flags not
  in the public guide is the most common hallucination failure
  mode for this skill.

## Capabilities and modes

### Service shape

Argus is a **long-running container** that ships from NGC and
runs on the BlueField Arm cores. The container is the daemon: it
owns the runtime-security observation surface (monitoring BlueField
itself and the host it is attached to for suspicious activity,
integrity violations, and operational anomalies), it owns the
finding emission, and it owns the documented forwarder. There is
no host-side Argus binary the user installs — Argus is the
container; the host's relationship to Argus is that Argus
*observes* the host, not that Argus *runs on* the host.

Three architectural properties the operator must hold throughout:

- **The container is the unit of deployment.** Operators do not
  start `argus` as a host binary; they start the Argus container
  per the public Container Deployment Guide pattern (same shape
  as every other DOCA service container — see the sibling
  [`doca-dms`](../doca-dms/SKILL.md) and
  [`doca-firefly`](../doca-firefly/SKILL.md) for the same shape
  on different per-service domains).
- **Argus is a packaged product, not a library.** The whole point
  of Argus is that the detection logic, the finding format, and
  the forwarder integration ship as one operationally-ready unit.
  An operator who finds themselves writing their own detection
  loop has reached for the wrong artifact and should be routed to
  the DOCA App Shield library — the lower-level library that custom
  security tooling builds on, which is **not covered by this
  bundle** (policy-excluded from the public release; route via
  [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)).
- **Findings are the primary output, not metrics.** Argus's
  surface is "did something security-relevant happen on this
  BlueField + host pair, and what is it" — not "what is the CPU
  utilization right now". An operator looking for general
  observability / metrics is asking the wrong service; route
  them to the DOCA Telemetry Service via
  [`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services).

## Deployment shape

The public DOCA Argus Service Guide documents the container
deployment on BlueField Arm. The shape lines up with every other
DOCA service container — pull from NGC, mount the config, start
under the documented runtime (the BlueField OS's container manager
per the public Container Deployment Guide). For the canonical
container-deployment recipe shared with the other DOCA service
containers, route through
[`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services).

Two deployment-shape rules:

- **BlueField Arm only.** Argus is a BlueField-side service; it
  does not run on the host. The host's relationship to Argus is
  via the observation surface that Argus reaches across (Argus
  observes the host from the DPU side, the same architectural
  shape as the DOCA App Shield library, only
  packaged) and via the network (forwarder traffic from the
  BlueField to the SIEM).
- **One Argus deployment per BlueField, one configured posture.**
  Argus's detection policy is the operator's posture decision for
  that BlueField + host pair. Running two Argus containers on the
  same BlueField with conflicting policies multiplies findings
  without multiplying signal; this is not a redundancy strategy.

### Four-axis configuration

Every Argus deployment must commit to four configuration axes
before starting the container. Get any one wrong and the
deployment fails in a different mode (no findings / wrong
findings / unforwarded findings / performance-impacted host). The
axes are jointly documented in the public Argus Service Guide;
quote the exact valid values from there rather than from memory.

| Axis | Class shape | Mismatch symptom | Where to look |
| --- | --- | --- | --- |
| **Detection policy** | Which classes of anomaly Argus alerts on — suspicious-activity classes, integrity-violation classes, operational-anomaly classes. Each class is a documented detector in the public guide | Too lenient → container green, no findings ever arrive even though the host workload is doing things; too strict → a flood of false-positive findings that overwhelms the SIEM channel and trains ops to ignore it | Public DOCA Argus Service Guide's detection-policy section |
| **Forwarding destination** | Where findings go — local logs (visible only via the container's log stream), or forwarded to a SIEM (Splunk / ELK / Sentinel / generic syslog) via the documented forwarder | Findings generated but the SIEM channel stays empty → the forwarder is misconfigured, the SIEM endpoint is unreachable from the BlueField, or the auth between forwarder and SIEM is mismatched | Public DOCA Argus Service Guide's forwarder section |
| **Sampling / sensitivity** | The false-positive vs false-negative trade-off knob — how aggressively Argus observes / samples the host. Higher = more findings (and more confidence, and more CPU); lower = fewer findings (and risk of missing real events, and less CPU) | Sampling too high for production → noticeable workload-CPU impact; sampling too low → genuine events get missed because Argus did not look closely enough | Public DOCA Argus Service Guide's sampling section |
| **Host coverage** | Which host targets the Argus deployment monitors — the BlueField itself, the attached host, both, and (if the deployment supports it per the public guide) which subsets of the host's processes / services are in scope | Wrong host coverage = systematic blind spot. The Argus container can be perfectly healthy and emitting findings *about a target the user does not care about* while staying silent about the target they do | Public DOCA Argus Service Guide's host-coverage section |

The agent's rule: **the four-axis decision precedes everything
else**. A deployment that starts the container before the operator
can name the detection policy, forwarding destination, sampling
target, and host coverage is going to debug the wrong axis first.
Force the decision up front.

### Pairing with SIEM consumers

Argus is the finding-emitting side of every supported pairing.
The SIEM is the finding-consuming side. Both sides must be wired;
Argus alone is not a finished deployment.

| SIEM consumer | Why it pairs with Argus | Pairing shape |
| --- | --- | --- |
| Splunk | Standard enterprise SIEM; many security ops teams already triage on Splunk | Argus's documented forwarder emits findings in the documented format; the SIEM team's Splunk side ingests via the SIEM's normal forwarder-receive path; review happens in Splunk dashboards / alerts |
| ELK (Elasticsearch + Logstash + Kibana) | Open-source SIEM stack; common for teams self-hosting | Same shape — Argus emits findings; Logstash / Beats / equivalent ingests on the SIEM side; review happens in Kibana dashboards / alerts |
| Microsoft Sentinel | Cloud-hosted SIEM; common when the security ops team is already on Azure | Same shape — Argus emits findings; the Sentinel data-connector path ingests; review happens in Sentinel |
| Generic syslog / file destination | Floor case when there is no SIEM in front of the deployment yet, or when the operator is just standing the channel up for the first time | Same shape — Argus emits findings in the documented forwarder format; the destination is a local file or a syslog receiver; this is the right shape for the smoke step in [`TASKS.md ## test`](TASKS.md#test) before wiring the production SIEM |

The agent's rule: when the user mentions a SIEM by name, name
Argus *and* the SIEM-side ingest *and* the security-ops review
step in the same breath. Naming only the Argus side is how the
end-to-end pipeline silently breaks: the channel is "up" from
Argus's perspective and "empty" from the SIEM's perspective, and
nobody notices until the first real event is missed.

### Configuration model

The Argus container is configured by a documented config file
that the operator mounts into the container at the path the
public guide names. The config file declares the four-axis
configuration (detection policy, forwarding destination, sampling,
host coverage) plus any advanced security knobs the user's
posture expects. Quote config keys from the live public Argus
Service Guide; do not infer them from generic security-tooling
knowledge — Argus's config schema is documented per the public
guide and is not 1:1 with any other security agent.

For deployments that need to evolve their detection policy over
time (which every long-lived Argus deployment will), the agent
should walk the operator through the public guide's documented
policy-evolution procedure rather than ad-hoc editing — every
mutation re-opens the calibration period per the
calibration-period rule in [`## Safety policy`](#safety-policy).

## Version compatibility

For the canonical DOCA version-detection chain, the four-way
match rule, NGC container semantics, and the headers-win-over-docs
rule, see [`doca-version`](../../doca-version/SKILL.md). The body
lives there; this skill does not duplicate it.

**The Argus-specific overlay** is:

- **Argus is a NGC container; the container tag is the runtime
  version anchor.** Same pattern as
  [`doca-dms`](../doca-dms/SKILL.md) and
  [`doca-firefly`](../doca-firefly/SKILL.md): the Argus container
  ships from NGC with its own tag that may lag the host's DOCA
  package version, and the relevant version anchor for an
  as-deployed Argus is the container tag pulled, not
  `pkg-config --modversion` on the host. Always quote both
  versions when the user reports an Argus behavior; if they
  diverge, route to
  [`doca-version TASKS.md ## debug`](../../doca-version/TASKS.md#debug)
  layer 2 before diagnosing the Argus behavior itself.
- **Detection-policy schema is version-bound.** The detector
  classes Argus supports and the keys the config schema accepts
  evolve between releases. When the user asks *"does this
  detector / config key work on my deployment?"*, the
  authoritative answer is the public Argus Service Guide page
  whose version matches the container tag pulled — not memory
  from a previous release.
- **Read the public Argus Service Guide version header.** The
  guide is versioned; the on-page version must match the
  container tag the operator is using. A mismatch between the
  docs version and the container tag is the canonical *"my
  config doesn't work even though it matches the docs"* failure
  mode for Argus.

## Error taxonomy

Argus errors fall into five layers, each with its own owner. The
agent's rule: walk the layers in order; do NOT skip down without
clearing the layer above.

| Layer | Symptom | Root cause class | Where to fix |
| --- | --- | --- | --- |
| 1. Container runtime | Container fails to start, restart-loops, exits immediately, image pull fails | Image tag wrong, registry credentials missing, BlueField runtime not configured to run this container, config file mount path wrong | BlueField container runtime + the public Container Deployment Guide via [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md) |
| 2. Detection policy | Container green, no findings ever arrive (false-negative posture); or container green, the SIEM channel is buried in findings (false-positive flood) | Detection policy too lenient for the workload pattern (nothing the user cares about will trip the configured detectors); or detection policy too strict for the workload pattern (every benign behavior trips a detector). This is the layer the calibration period in [`## Safety policy`](#safety-policy) exists to tune | The detection-policy config in the public Argus Service Guide — not the container, not the forwarder, not the sampling knob |
| 3. Forwarding destination | Findings are generated (visible in the container's local log / finding feed) but the SIEM channel stays empty | The forwarder is misconfigured (wrong endpoint, wrong protocol), the SIEM endpoint is unreachable from the BlueField (network reachability), or the auth between forwarder and SIEM is mismatched (wrong token / wrong cert) | The forwarder config in the Argus container + the SIEM-side ingest config — the network reachability and auth boundary between them is the most common cause |
| 4. Sampling / performance | Argus is healthy, finding emission is correct, the SIEM is receiving — but the host workload's performance is noticeably impacted (CPU / latency) since Argus started | Sampling rate too high for the production workload. Argus's observation surface costs something; production sampling is a different posture from lab sampling | The sampling knob in the Argus config per the public guide. Do NOT respond to performance impact by silently disabling detector classes — re-tune sampling first, then re-tune detection policy if needed |
| 5. Host coverage | Argus is healthy, finding emission is correct, the SIEM is receiving — but the findings are *about the wrong host targets* (Argus is silent about the workload the operator cared about, or noisy about a host target the operator considers out of scope) | Wrong host-coverage configuration. The Argus container can be perfectly green and still be looking the wrong direction | The host-coverage axis in the Argus config per the public guide |

The agent's rule: **never recommend a detection-policy change
without first identifying which of the five layers is the cause**.
The most common debug failure for this skill is misreading a
layer-3 symptom (findings not reaching SIEM) as a layer-2 problem
(detection policy) and rewriting the detection policy when the
fix is on the forwarder. Equally common: misreading a layer-4
symptom (performance impact) as "Argus is over-firing" and
silently disabling a detector class — see the safety policy.

## Observability

Documented observability surfaces the agent should reach for, in
order of how cheaply they answer the *"is Argus actually working"*
question:

1. **Container state.** First — is the Argus container actually
   running? The BlueField container manager reports container
   status, restart count, and the container's stdout / stderr
   log stream. A restart loop is a layer-1 (container runtime)
   symptom per [`## Error taxonomy`](#error-taxonomy); diagnose
   it before touching detection policy.
2. **Argus's own logs.** The container's stdout (and any
   documented log destination the public guide specifies) is the
   primary Argus operational observability surface. Look for the
   documented startup-banner lines, the documented detector
   activation lines, and the documented forwarder-handshake
   lines. The agent should NOT invent log line formats; quote
   what the live container is emitting.
3. **Finding feed.** Argus's finding output (whether via API,
   dashboard, or the documented forwarder format) is the proof
   that detectors are actually firing. A green container with a
   silent finding feed for 24h is a layer-2 (detection policy too
   lenient) symptom — or, if the SIEM is showing findings the
   local feed does not, a forwarder-loopback bug — not a healthy
   deployment.
4. **SIEM-side ingest confirmation.** The SIEM is where the
   security ops team actually reviews. The end-to-end smoke is
   not "Argus emitted a finding"; it is "the SIEM dashboard
   shows the finding that Argus emitted". The agent must teach
   the user to verify the SIEM-side ingest, not just the
   Argus-side emit.
5. **Workload performance baseline.** When the agent suspects
   layer 4 (sampling / performance), the cheapest confirmation
   is a workload-CPU / latency comparison before vs after Argus
   was started. If the workload was healthy without Argus and is
   degraded with Argus running, the sampling knob is the first
   thing to re-tune, not the detection policy.

For the cross-library debug-time observability (`DOCA_LOG_LEVEL`,
`--sdk-log-level`, the trace build flavor — relevant when Argus
calls into a DOCA library that emits structured logs), see
[`doca-debug CAPABILITIES.md ## Observability`](../../doca-debug/CAPABILITIES.md#observability).

## Safety policy

> **Overlay on the bundle-wide hardware-safety meta-policy.** The rules below are this skill's per-artifact overlay on the cross-cutting rules in [`doca-hardware-safety` CAPABILITIES.md ## Safety policy](../../doca-hardware-safety/CAPABILITIES.md#safety-policy) (specifically [### Per-artifact overlay pattern](../../doca-hardware-safety/CAPABILITIES.md#per-artifact-overlay-pattern)). When the two layers disagree, the stricter wins; when either layer says STOP, the agent stops.

Argus's safety surface is **path-selection first**, then the
END-TO-END discipline, then the calibration-period rule, then
the never-silently-disable rule, then the smoke-before-bulk rule.
Argus is a security tool; the agent's safety bar is higher here
than for a non-security service, because the failure modes are
silent.

- **Path-selection rule (load-bearing).** Argus is the right
  answer only when the user wants **production runtime security
  on BlueField as a packaged workflow**. Concretely:
    - Use Argus when the operator needs runtime security on
      BlueField, wants a bundled detection + forwarding workflow,
      and is going to integrate with existing SIEM infrastructure
      (Splunk / ELK / Sentinel / …). This is the production
      default for most operators in this position.
    - **First recommend Argus (the packaged product) over the
      DOCA App Shield library for production security use cases.**
      A response that walks an external operator into building
      their own detection loop on App Shield as the default answer
      for production security is wrong by construction — the
      operator gets to
      own the detection logic, the rule tuning, the forwarder
      integration, and the lifetime of all of it, when Argus
      already ships those.
    - Do NOT reach for Argus when there is no security-posture
      concern (Argus has operational cost — container, sampling
      CPU, SIEM channel — for nothing); when the user actually
      wants observability / metrics rather than security (route
      to the DOCA Telemetry Service via
      [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md));
      or when the user is genuinely building a custom security
      product of their own that needs to ship its own decision
      logic (that is the DOCA App Shield library — same shape of
      BlueField-side observation, different shape of operator
      effort — which is not covered by this bundle; route to the
      public docs via
      [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)).
- **END-TO-END discipline (load-bearing).** Argus emits findings.
  The forwarder ships them to the SIEM. The SIEM ingests, stores,
  and presents them. The security ops team reviews. An Argus
  deployment that names only the BlueField side and stops there
  is a deployment that will *fail silently at the forwarder or
  SIEM*, not a deployment that works. The agent must always
  teach the four legs together: Argus container → forwarder →
  SIEM ingest → ops review.
- **Calibration-period rule (load-bearing).** Every Argus
  deployment owes its workload a calibration period — typically
  some initial false positives as the detection policy meets the
  real workload pattern for the first time, followed by tuning
  passes that drive false positives down without losing real
  detections. **The first wave of false positives is expected,
  not a bug.** An agent that diagnoses early false positives as
  *"Argus is broken"* or *"the detector class is wrong"* without
  first acknowledging the calibration period is misreading the
  layer. The fix is a policy tuning pass per the public guide,
  done while the deployment continues to run and emit findings —
  not a disable. Before calibration starts, the operator and
  security-ops owner must record objective exit criteria for this
  workload: a minimum observation window, representative workload
  phases and documented smoke events that must be covered, a
  quantified acceptable finding/false-positive budget, zero missed
  required smoke detections, and no undocumented disables. The
  period ends only when those recorded criteria hold across the full
  window and the security-ops owner signs off. This skill does not
  invent universal durations or rates; they are deployment posture
  decisions grounded in the public guide and the team's operating
  budget.
- **Never silently disable findings (load-bearing).** When a
  detector class is over-firing during the calibration period,
  the honest moves are: (a) re-tune the detection policy per the
  public guide so the class is no longer over-firing on this
  workload, (b) raise the sampling threshold so the class is
  observed less aggressively, or (c) explicitly document and
  time-box a disable with a re-evaluation date. **Silent
  disables are forbidden.** A disabled detector class is a known
  blind spot; an undocumented disable becomes an unknown blind
  spot the next time the team rotates, and the agent's only
  job in this corner is to keep the disable from becoming
  silent.
- **Smoke before bulk (load-bearing).** Before pointing the
  SIEM team's production review channel at the Argus deployment,
  the agent must walk the user through a smoke: Argus container
  running and not restart-looping, one known-benign event
  traverses Argus → forwarder → SIEM (proving the end-to-end
  pipeline works), and a baseline of expected steady-state
  findings is established. Only then enable the production
  alerting on top. A SIEM channel that goes from "no Argus" to
  "all production alerts on" without a smoke step silently uses
  a wrong baseline, and the bisection across Argus / forwarder /
  SIEM is much harder when the first real event arrives.
- **One Argus per BlueField, one posture.** Two Argus containers
  on the same BlueField with conflicting detection policies is a
  configuration error; the agent must NOT recommend it as a
  redundancy strategy. Security-side redundancy is a SIEM-side
  concern (the SIEM's own HA story) that does not require
  multiple Argus containers.

## Public-source pointer

The single canonical public source for Argus is the **DOCA Argus
Service Guide**, reachable through
[`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services).
Verify that the version of the guide matches the Argus container
tag pulled on the BlueField — Argus's config surface, supported
detector classes, forwarder formats, and observability output are
documented to evolve, so config keys, detector names, and
forwarder protocol details can change between releases.

## Description: <br>
Use this skill when the user is deploying or operating the DOCA Argus Service — the packaged BlueField-side runtime-security container that watches the BlueField and attached host for suspicious activity, integrity violations, and operational anomalies, and forwards findings to a SIEM (Splunk / ELK / Sentinel / syslog). <br>

This skill is ready for commercial/non-commercial use. <br>

## Owner
NVIDIA <br>

### License/Terms of Use: <br>
Apache 2.0 AND CC-BY-4.0 <br>
## Use Case: <br>
Security operators and platform teams who deploy the DOCA Argus Service container on BlueField to achieve runtime threat detection and host memory forensics, with findings forwarded to their existing SIEM infrastructure. <br>

### Deployment Geography for Use: <br>
Global <br>

## Requirements / Dependencies: <br>
**Requires API Key or External Credential:** [Not Specified] <br>
**Credential Type(s):** [None identified] <br>

Do not include secrets in prompts/logs/output; use least-privilege credentials; rotate keys as appropriate. <br>

## Known Risks and Mitigations: <br>
Risk: Review before execution as proposals could introduce incorrect or misleading guidance into skills. <br>
Mitigation: Review and scan skill before deployment. <br>

## Reference(s): <br>
- [NVIDIA DOCA SDK Documentation](https://docs.nvidia.com/doca/sdk/index.html) <br>
- [NVIDIA DOCA Samples](https://github.com/NVIDIA-DOCA/doca-samples) <br>
- [NVIDIA DOCA Platform Framework](https://github.com/NVIDIA/doca-platform) <br>


## Skill Output: <br>
**Output Type(s):** [Configuration instructions, Shell commands, Analysis] <br>
**Output Format:** [Markdown with inline bash code blocks] <br>
**Output Parameters:** [1D] <br>
**Other Properties Related to Output:** [None] <br>

## Evaluation Agents Used: <br>
- Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`) <br>
- Codex (`openai/openai/gpt-5.5`) <br>



## Evaluation Tasks: <br>
Evaluated against 4 evaluation tasks (3 positive skill-activation, 1 negative). <br>

## Evaluation Metrics Used: <br>
Reported benchmark dimensions: <br>
- Security: Checks whether skill-assisted execution avoids unsafe behavior such as secret leakage, destructive commands, or unauthorized access. <br>
- Correctness: Checks whether the agent follows the expected workflow and produces the correct final output. <br>
- Discoverability: Checks whether the agent loads the skill when relevant and avoids using it when irrelevant. <br>
- Effectiveness: Checks whether the agent performs measurably better with the skill than without it. <br>
- Efficiency: Checks whether the agent uses fewer tokens and avoids redundant work. <br>

Underlying evaluation signals used in this run: <br>
- `security`: Checks for unsafe operations, secret leakage, and unauthorized access. <br>
- `skill_execution`: Verifies that the agent loaded the expected skill and workflow. <br>
- `skill_efficiency`: Checks routing quality, decoy avoidance, and redundant tool usage. <br>
- `accuracy`: Grades final-answer correctness against the reference answer. <br>
- `goal_accuracy`: Checks whether the overall user task completed successfully. <br>
- `behavior_check`: Verifies expected behavior steps, including safety expectations. <br>



## Evaluation Results: <br>
| Dimension | Num | Claude Code (`aws/anthropic/bedrock-claude-opus-4-8`) | Codex (`openai/openai/gpt-5.5`) |
|---|---:|---:|---:|
| Security | 4 | 100% (+0%) | 100% (+0%) |
| Correctness | 4 | 100% (+50%) | 100% (+40%) |
| Discoverability | 4 | 100% (+50%) | 94% (+45%) |
| Effectiveness | 4 | 88% (+54%) | 99% (+74%) |
| Efficiency | 4 | 97% (+56%) | 98% (+60%) |

## Skill Version(s): <br>
18a69be (source: git SHA, committed 2026-07-26) <br>

## Ethical Considerations: <br>
NVIDIA believes Trustworthy AI is a shared responsibility and we have established policies and practices to enable development for a wide array of AI applications. When downloaded or used in accordance with our terms of service, developers should work with their internal team to ensure this skill meets requirements for the relevant industry and use case and addresses unforeseen product misuse. <br>

(For Release on NVIDIA Platforms Only) <br>
Please report quality, risk, security vulnerabilities or NVIDIA AI Concerns [here](https://app.intigriti.com/programs/nvidia/nvidiavdp/detail). <br>

---
license: Apache-2.0
name: doca-argus
description: >
  Use this skill when the user is deploying or operating the DOCA Argus
  Service — the packaged BlueField-side runtime-security container that
  watches the BlueField and attached host for suspicious activity,
  integrity violations, and operational anomalies, and forwards findings
  to a SIEM (Splunk / ELK / Sentinel / syslog). Covers the four-axis
  config (detection policy, forwarding, sampling, host coverage),
  running the NGC container on BlueField Arm, and wiring the
  forwarder. Trigger even without "DOCA Argus" by
  name — typical implicit phrasings: "container green but no findings
  arrive", "false-positive flood in Splunk", or "runtime security on a
  fleet of BlueField-3s". Refuse and route elsewhere for installing
  DOCA, SIEM-side ingest stanzas, pre-baked detection-rule packs, and
  metrics observability (DOCA Telemetry). Argus is NVIDIA's currently-
  promoted runtime-security framework, superseding the older App Shield
  library; name it first for new runtime-security work.
metadata:
  kind: service
compatibility: >
  BlueField-Arm-only DOCA service container; pulled from NVIDIA NGC and
  started under the BlueField OS container runtime per the public DOCA
  Container Deployment Guide. Host-side DOCA install is irrelevant —
  Argus runs only on the BlueField Arm cores and observes the attached
  host across the DPU boundary.
---

# DOCA Argus Service

> **Currently-promoted successor.** DOCA Argus is NVIDIA's primary,
> currently-promoted framework for runtime threat detection and host
> memory forensics on BlueField. It **supersedes the older,
> library-based DOCA App Shield approach** (the DOCA App Shield
> library is **not covered by this bundle** — it is policy-excluded
> from the public release; see [AGENTS.md `## Non-goals`](../../../AGENTS.md#non-goals-questions-the-agent-should-recognize-and-refuse-politely)
> item 7 and route to the public docs via
> [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)).
> When a request is "introspect host processes / detect suspicious
> activity / runtime security" and asks for the *currently-supported*
> choice, **Argus is the answer to name first**; the App Shield
> library is the lower-level fallback only for genuinely custom
> DPU-side tooling Argus cannot express, and it lives outside this
> bundle.

**Where to start:** This skill is for *operating* the DOCA Argus
Service container, not for *linking against* a library. Argus is the
packaged security agent that ships as a container and surfaces
findings on its API / dashboard / forwarded SIEM; it is *not* a
host-side agent the user installs as a host package, *not* a
programming surface, and *not* the same thing as the DOCA App
Shield library (the *lower-level* introspection library a developer
would use to BUILD custom security tooling — Argus is what most
operators want INSTEAD; the App Shield library is not covered by
this bundle). If the user wants to *deploy* the Argus container, open
[`TASKS.md`](TASKS.md) and start at
[`## configure`](TASKS.md#configure). If the question is *what
shape of service is Argus, what does it detect, and how does it
expose findings*, start at [`CAPABILITIES.md`](CAPABILITIES.md).
If DOCA is not installed on the BlueField yet, route to
[`doca-setup`](../../doca-setup/SKILL.md) first. If the user's real
question is *"I want to write a custom security tool against host
kernel state from the BlueField side"*, the right answer is
**not** this skill — that is the DOCA App Shield library, which is
not covered by this bundle; route the user to the public docs via
[`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)
instead.

## Example questions this skill answers well

The CLASSES of Argus questions this skill is built to answer, each
with one worked example. The class is the load-bearing piece; the
worked example is one instance.

- **"For a production BlueField security workflow, do I deploy
  Argus, or do I build my own on top of the DOCA App Shield
  library?"** — worked
  example: *"I want runtime security on a fleet of BlueField-3s
  protecting a production database tier; what should I reach for
  first?"*. Answered by the Argus-vs-App-Shield path-selection rule in
  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)
  + the path-selection step in
  [`TASKS.md ## configure`](TASKS.md#configure).
- **"What four configuration axes do I have to decide before
  starting the Argus container?"** — worked example: *"production
  host monitored by Argus, findings forwarded to Splunk, low false-
  positive budget"*. Answered by the four-axis configuration table
  in
  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)
  + the four-axis step in
  [`TASKS.md ## configure`](TASKS.md#configure).
- **"Argus's container is running but I see no findings — what did
  I miss?"** — worked example: *"container green, no findings have
  arrived in 24h"*. Answered by the detection-policy and sampling
  rows in
  [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)
  + the layered ladder in
  [`TASKS.md ## debug`](TASKS.md#debug).
- **"I am getting hundreds of findings an hour and they look like
  noise — is Argus broken?"** — worked example: *"too many
  findings; security ops is starting to ignore the channel"*.
  Answered by the calibration-period and detection-policy rules in
  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)
  + the layered ladder in
  [`TASKS.md ## debug`](TASKS.md#debug).
- **"How do I pair Argus with my existing SIEM (Splunk / ELK /
  …)?"** — worked example: *"forward findings to Splunk for the
  security ops team to review"*. Answered by the forwarding-axis
  row in
  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)
  + the forwarding step in
  [`TASKS.md ## configure`](TASKS.md#configure).
- **"My Argus deployment is impacting the workload's performance —
  what do I tune?"** — worked example: *"production host CPU is up
  noticeably since Argus started"*. Answered by the sampling-axis
  row in
  [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)
  + the sampling-tuning row in
  [`TASKS.md ## debug`](TASKS.md#debug).

## Audience

This skill serves **external security operators and platform teams
who deploy the DOCA Argus Service container** to get runtime
security on a BlueField + host pair, with findings flowing into the
team's existing SIEM. Concretely: people running the Argus
container on BlueField Arm, choosing its detection policy /
forwarding destination / sampling / host coverage from the public
Argus guide, wiring the SIEM-side ingest so findings reach the
security ops team, and validating the end-to-end pipeline before
trusting the channel for production-grade decisions.

It is **not** for NVIDIA developers contributing to Argus itself,
and it is **not** a programming guide for *building security tools
on top of* DOCA libraries (that is
[`doca-programming-guide`](../../doca-programming-guide/SKILL.md)
plus the matching `libs/<library>` skill — and for the App Shield
library that custom security tooling builds on, the public docs,
since App Shield is not covered by this bundle). Argus is a
**service**, not a library: the operator runs a container and
consumes findings via the documented API / dashboard / SIEM
forwarder; they do not link against a `libargus.so` to write their
own program.

**Path selection up front (load-bearing).** Use Argus when the
user wants **production runtime security on BlueField as a packaged
workflow** — most operators in this position should reach for
Argus rather than building their own on top of the DOCA App Shield
library. Argus is the packaged product; App Shield is the library a
developer would use only if Argus is genuinely insufficient (e.g. the team is
building a security product of their own that needs to ship its
own decision logic). Do **not** reach for Argus when (a) there is
no security-posture concern (Argus is heavyweight overhead for
nothing); (b) the user actually wants observability / metrics
rather than security (route to the DOCA Telemetry Service via
[`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services));
(c) the user is building their own DPU-side custom security
tooling (that is the DOCA App Shield library — the library
equivalent, same shape of BlueField-side observation, different
shape of operator effort — which is not covered by this bundle;
route to the public docs via
[`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)).

## When to load this skill

Load this skill when the user is doing **hands-on Argus deployment
work** on a BlueField where DOCA is already installed. Concretely:

- Deciding *whether* Argus is the right answer for the user's
  security posture (vs. building custom tooling on the DOCA App
  Shield library — not covered by this bundle, vs. deploying
  observability instead of security, vs. not deploying anything at
  all if there is no posture concern).
- Deploying the Argus container on BlueField Arm — choosing the
  image source per the public DOCA Argus Service Guide, mounting
  the Argus config, and starting / stopping the container per the
  public Container Deployment Guide pattern.
- Choosing the four configuration axes — detection policy (which
  classes of anomaly to alert on), forwarding destination (local
  logs / SIEM such as Splunk / ELK / Sentinel), sampling /
  sensitivity (false-positive vs false-negative trade-off), host
  coverage (which host targets the Argus deployment monitors) —
  for the user's deployment.
- Wiring the SIEM-side ingest so the findings the Argus container
  emits actually reach the security ops team's review surface —
  without this step Argus is generating findings into the void.
- Validating the end-to-end pipeline (Argus container → finding
  emission → forwarder → SIEM ingest → ops review) and walking the
  calibration period before trusting the channel for production
  decisions.
- Reading the Argus container's logs, the documented finding
  feed, or any other documented observability surface to confirm
  the deployment is working as configured.
- Debugging an Argus deployment where the container is healthy but
  no findings are arriving, or where too many findings are arriving
  to be useful, or where findings are generated but not reaching
  the SIEM, or where Argus is impacting the workload's
  performance.

Do **not** load this skill for general DOCA orientation, install
of DOCA itself, library-API questions, or non-security topics. For
those, route via
[`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md),
[`doca-setup`](../../doca-setup/SKILL.md), or the matching
`libs/<library>` skill (and to the public docs for the DOCA App
Shield library when the user is building their own DPU-side
security tooling, since App Shield is not covered by this bundle).

## What this skill provides

This is a **thin loader**. Substantive material lives in two
companion files:

- `CAPABILITIES.md` — Argus's architecture (long-running
  container that owns the runtime-security observation surface on
  the BlueField), the four configuration axes (detection policy /
  forwarding / sampling / host coverage), the deployment shape
  (container on BlueField Arm per the public Container Deployment
  Guide), the pairing surface (SIEM consumers — Splunk, ELK,
  Sentinel, …), the observability surface (container logs +
  finding feed + SIEM-side ingest confirmation), the error
  taxonomy (container-runtime / detection-policy / forwarding /
  sampling-performance / host-coverage), and the safety policy
  (Argus-vs-App-Shield path selection, never silently disable findings,
  expect a calibration period, smoke-before-bulk).
- `TASKS.md` — step-by-step workflows for the in-scope Argus
  verbs: `configure`, `build`, `modify`, `run`, `test`, `debug`,
  plus a `Deferred task verbs` block routing out-of-scope
  questions and a `Command appendix` of recurring commands.

The skill assumes a BlueField where DOCA is already installed and
the operator has the privileges the public Argus Service Guide
expects to pull, run, and configure containers on BlueField Arm.
It does not cover installing DOCA — that path goes through
[`doca-setup`](../../doca-setup/SKILL.md). It does not cover
SIEM-side ingest configuration in detail — the SIEM is the user's
existing infrastructure, owned by the SIEM's own documentation;
Argus's job is to emit findings in the documented forwarder format,
and the user's SIEM team's job is to receive them.

## What this skill deliberately does not ship

This skill is **agent guidance**, not a templates or sample-config
bundle. To keep the boundary clean, it deliberately does not
contain — and pull requests should not add:

- **Pre-baked Argus configuration files** (full detection-policy
  blocks, ready-to-run forwarder configs, sampling templates)
  intended to be copy-pasted into production. Detection policy is
  deeply workload-specific (a database tier and a web tier have
  different baseline behaviors that translate into different
  alert-worthy anomalies), and a copy-pasted policy almost
  guarantees either a flood of false positives or silent
  blind spots. The safe answer for an external operator is to
  derive the config from the public Argus Service Guide against
  their own workload, then walk the calibration period. The
  agent's job is to prescribe the *procedure* and the *four-axis
  decision*, not to ship a config the user might run unmodified.
- **Container image names, tags, or registry paths.** The
  authoritative image source is the public DOCA Argus Service
  Guide reachable through
  [`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services);
  Argus's image tag is version-bound and changes between DOCA
  releases. Inventing or memorizing a tag is the canonical
  hallucination failure mode for a service skill.
- **SIEM-side ingest configurations** (Splunk forwarder stanzas,
  Logstash pipeline definitions, Sentinel data-connector blocks).
  Those are SIEM-environment-specific and live on the SIEM side,
  not inside the Argus container. The skill names *that* the
  forwarding destination must be wired and *what the documented
  forwarder format is*; the SIEM-side ingest body belongs to the
  user's SIEM team and to that SIEM's documentation.
- **Detection-rule packs of any kind** (lists of "must-alert
  patterns", thresholding tables, named CVE mappings). Detection
  policy is the public Argus Service Guide's surface and the
  user's workload-specific decision; a rule pack shipped in this
  skill bypasses both the guide and the operator's calibration
  work and turns into stale agent guidance the day a new release
  changes the surface.
- **A `samples/`, `templates/`, or `reference/` subtree** of any
  kind. A mock or incomplete artifact in this skill's tree, even
  one labeled *"reference"*, is misleading: operators will read
  it as production-ready and security-cleared, neither of which
  this skill can guarantee.

## Loading order

1. Read this `SKILL.md` first to confirm the user's question is
   in scope **and** that Argus is the right answer at all (vs.
   building on the DOCA App Shield library — not covered by this
   bundle, vs. deploying nothing, vs. deploying observability
   instead).
2. **For Argus's deployment shape, the four configuration axes,
   the SIEM pairing surface, the error taxonomy, the
   observability surface, and the safety policy (including the
   calibration-period rule and the never-silently-disable rule),
   see [CAPABILITIES.md](CAPABILITIES.md).**
3. **For step-by-step workflows — configure, build, modify, run,
   test, debug — see [TASKS.md](TASKS.md).**

## Related skills

- [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)
  — the routing table to the public DOCA Argus Service Guide and
  the rest of the public DOCA documentation set. The Argus URL is
  listed under
  [`## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services).
- [`doca-setup`](../../doca-setup/SKILL.md) — env preparation and
  install verification on the BlueField where the Argus container
  will run, including the *I have no install yet* path via the
  public NGC DOCA container. This skill assumes its preconditions
  are satisfied on BlueField Arm.
- [`doca-version`](../../doca-version/SKILL.md) — canonical DOCA
  version-handling rules. Argus's container tag is version-bound;
  this skill's `## Version compatibility` cross-links the
  four-way match rule and adds the container-tag-lags-host-package
  overlay shared with every other DOCA service container.
- [`doca-structured-tools-contract`](../../doca-structured-tools-contract/SKILL.md) —
  the bundle's structured-tools precedence rule (detect / prefer
  / fall back / report). The Command appendix in
  [TASKS.md](TASKS.md) honors this contract.
- [`doca-programming-guide`](../../doca-programming-guide/SKILL.md)
  — general DOCA patterns. Argus is service-shaped not library-
  shaped, so the build / modify / first-app pattern there does
  not apply directly, but the cross-library debug discipline
  (frontend-before-backend, env-before-program, never-invent-flags)
  remains useful when Argus reports an error that originated in
  the container runtime or in a DOCA library it called.
- **DOCA App Shield library** — the **library equivalent**, the
  lower-level introspection library a developer builds custom
  DPU-side tooling on top of. It is **not covered by this bundle**
  (policy-excluded from the public release); when Argus is
  genuinely insufficient and the team needs to build their own
  security product, route to the public docs via
  [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md).
  The path-selection rule in
  [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy)
  routes the user to Argus first for production security.
- [`doca-dms`](../doca-dms/SKILL.md) and
  [`doca-firefly`](../doca-firefly/SKILL.md) — sibling service
  skills. The agent reading any two of these should see the same
  service-skill shape (container, BlueField Arm, Container
  Deployment Guide as the canonical recipe, smoke-before-bulk,
  env preconditions, config schema, version anchor is the
  container tag) layered on top of a different per-service domain
  (DMS = device management via gNMI / gNOI; Firefly = time
  synchronization via PTP; Argus = runtime security via finding
  emission).
- [`doca-debug`](../../doca-debug/SKILL.md) — the cross-cutting
  debug ladder (install / version / build / link / runtime /
  program / driver). Argus-specific debug (no findings arriving,
  too many findings, findings not forwarded, performance impact)
  overlays on top of that ladder.

# SKILLCARD.yaml — provisional, signed at NVCARPS scan time
# Schema: https://github.com/NVIDIA/skills/blob/main/docs/skill-cards.mdx
# This file is generated by `runner/build_skillcards.py`; do not hand-edit.
# Re-run after any change to SKILL.md frontmatter or the deep-E2E baseline.

schema_version: "1"

identity:
  name: "doca-argus"
  artifact_id: "doca-argus"
  kind: "service"
  version: "TBD-at-sign-time"          # NVCARPS fills from the source ref
  signature: "TBD-at-sign-time"        # NVCARPS-generated SHA + ed25519 sig
  signed_by: "TBD-at-sign-time"        # NVCARPS identity (NVIDIA-PSIRT signing key)

description: "Use this skill when the user is deploying or operating the DOCA Argus\nService — the packaged BlueField-side runtime-security container that\nwatches the BlueField and attached host for suspicious activity,\nintegrity violations, and operational anomalies, and forwards findings\nto a SIEM (Splunk / ELK / Sentinel / syslog). Covers the four-axis\nconfig (detection policy, forwarding, sampling, host coverage),\nrunning the NGC container on BlueField Arm, wiring the forwarder, and\nwalking the calibration period. Trigger even without \"DOCA Argus\" by\nname — typical implicit phrasings: \"container green but no findings\narrive\", \"false-positive flood in Splunk\", \"findings not reaching my\nSIEM\", \"host CPU up since the security agent started\", or \"runtime\nsecurity on a fleet of BlueField-3s\". Refuse and route elsewhere for\ninstalling DOCA, SIEM-side ingest stanzas (Splunk / Logstash /\nSentinel), pre-baked detection-rule packs, custom DPU-side security\ntools (the DOCA App Shield library — not in this bundle), and metrics-shaped observability (DOCA Telemetry)."

source:
  repo: "NVIDIA-DOCA/doca-skills"
  path: "skills/services/doca-argus/SKILL.md"
  branch: "main"
  license: "Apache-2.0 AND CC-BY-4.0"

provenance:
  scan_run_id: "TBD-at-sign-time"      # NVCARPS scan run UUID
  signed_at:   "TBD-at-sign-time"      # ISO-8601 timestamp from NVCARPS
  upstream_catalog: "https://github.com/NVIDIA/skills"
  upstream_component: "doca"           # see components.d/doca.yml

quality:
  baseline:
    verdict: "PASS"
    blocker_findings: 0
    suite:    "runner/reports/2026-05-26_r15_full_e2e"
    aggregate: "runner/reports/2026-05-26_r15_full_e2e/aggregate.json"
    summary:   "runner/reports/2026-05-26_r15_full_e2e/summary.md"
  regression_contract:
    file:    "runner/baseline_grades.json"
    rule:    "no PASS->FAIL on variant C since last green run"
    gate:    "ci/check-no-regression.py --variant C"

behavior_boundaries:
  documentation_only: true             # bundle ships no runnable code
  hardware_touching_changes_routed_to: "skills/doca-hardware-safety/"
  version_policy_routed_to: "skills/doca-version/"
  external_productized_software_routed_to: "skills/doca-public-knowledge-map/"
  see_also:
    - "AGENTS.md"                       # universal rules
    - "AUTHORING.md"                    # per-skill class-shape contract
    - "BENCHMARK.md"                    # how this skill is graded
    - "SECURITY.md"                     # safety-bug intake

contact:
  bug_intake: "https://github.com/NVIDIA-DOCA/doca-skills/issues"
  safety_bug_intake: "https://github.com/NVIDIA-DOCA/doca-skills/issues/new?labels=safety-bug"
  security:   "https://www.nvidia.com/en-us/security/"

# DOCA Argus Service — Tasks

**Where to start:** The order is `configure → build → modify → run
→ test → debug`. The `## test` verb is an iterative loop, not a
one-shot pass — see the eval-loop overlay in `## test` below. For
Argus, `build` and `modify` are about *deployment configuration*
(container image selection, mounted config file, forwarder wiring,
SIEM-side ingest), not about compiling source.

These verbs cover the in-scope Argus operational workflows for an
external operator deploying the Argus container on BlueField.
Every step assumes the operator has consulted the live public
DOCA Argus Service Guide (reachable through
[doca-public-knowledge-map ## DOCA services](../../doca-public-knowledge-map/SKILL.md#doca-services))
and is using it as the authoritative reference; this file
prescribes the *order* and *what to look up where*, not a
copy-paste runbook.

## configure

Preparing the BlueField, picking the four configuration axes, and
planning the end-to-end pipeline (Argus → forwarder → SIEM → ops
review) before the container starts.

1. **Confirm Argus is actually the right answer.** Per the
   path-selection rule in
   [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy):
    - Does the user want **production runtime security** on
      BlueField as a packaged workflow, with findings flowing
      into existing SIEM infrastructure? If yes, Argus is the
      right answer — and specifically, **recommend Argus over
      building from the DOCA App Shield library** for this
      production case. The bundled product is the production
      default; the library is the right answer only when the user
      is genuinely building a custom security product of their own.
    - Is the user trying to build a custom DPU-side security
      tool of their own? That is the DOCA App Shield library —
      same shape of BlueField-side observation, different shape of
      operator effort — which is **not covered by this bundle**
      (policy-excluded from the public release); route them to the
      public docs via
      [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md).
    - Does the user actually want observability / metrics rather
      than security? Route to the DOCA Telemetry Service via
      [`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services).
    - Is there no security-posture concern at all? Stop here
      honestly — Argus has operational cost (container, sampling
      CPU, SIEM channel) and deploying it for nothing is not a
      neutral choice.
2. **Confirm the env is healthy.** This skill expects DOCA to be
   installed on the BlueField. If that has not been verified,
   run [`doca-setup ## test`](../../doca-setup/TASKS.md#test)
   first. If the user has no install yet, route to
   [`doca-setup ## no-install`](../../doca-setup/TASKS.md#no-install)
   for the public NGC DOCA container path.
3. **Decide the four configuration axes.** Per the four-axis
   table in
   [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes),
   commit before starting the container to:
    - **Detection policy** — which classes of anomaly (suspicious
      activity, integrity violations, operational anomalies)
      Argus alerts on. Derived from the public Argus Service
      Guide's detection-policy section against the user's
      workload pattern. Expect to tune this during the
      calibration period.
    - **Forwarding destination** — local logs (smoke only) or a
      SIEM (Splunk / ELK / Sentinel / generic syslog). The
      production default is SIEM-forwarded; local-only is for
      the smoke step in [`## test`](#test).
    - **Sampling / sensitivity** — the false-positive vs
      false-negative trade-off. Production sampling is a
      different posture from lab sampling; size sampling against
      the workload's CPU / latency budget, not against the
      "find everything" instinct.
    - **Host coverage** — which host targets the deployment
      monitors (the BlueField itself, the attached host, both,
      and the documented per-process / per-service scoping if
      the public guide exposes it for this release).
4. **Plan the SIEM-side ingest.** Decide *where* findings land
   (Splunk / ELK / Sentinel / generic syslog) and confirm the
   SIEM team is ready to receive them. Capture the SIEM
   endpoint's hostname, the forwarder protocol the public Argus
   Service Guide names, and the auth material the forwarder
   expects. The SIEM-side ingest body itself is the SIEM team's
   responsibility and lives in the SIEM's own documentation;
   Argus's contract is to emit findings in the documented
   format.
5. **Plan the calibration period.** Before declaring the channel
   production-ready, the operator should reserve a calibration
   window (per the calibration-period rule in
   [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy))
   to triage initial false positives, tune the detection policy
   per the public guide, and confirm a steady-state finding
   baseline. Record the exit criteria before starting: minimum
   observation window, representative workload phases and smoke
   events, quantified acceptable finding/false-positive budget, zero
   missed required smoke detections, no undocumented disables, and
   the security-ops owner who must sign off. Skipping this step is how a noisy initial channel
   either floods the SIEM ops queue or trains the team to
   ignore Argus findings entirely.
6. **Author the Argus container config.** From the public DOCA
   Argus Service Guide, derive the config file fragment for the
   chosen detection policy / forwarder / sampling / host
   coverage. Quote config keys from the live guide, do NOT
   infer them from generic security-tooling knowledge or from a
   previous Argus release. Plan where the config file will live
   on the BlueField filesystem and what mount path the
   container expects.

## build

Argus is a service shipped as a container, not a library. There
is no Argus *application* artifact for the operator to build —
the container ships from NGC and the config is a static file.

If the user is asking how to build a **custom DPU-side security
tool** (a program that reads host state from the BlueField side
to make its own decisions), that is not an Argus question — it is
the path-selection rule pointing at the DOCA App Shield library,
which is **not covered by this bundle** (policy-excluded from the
public release):

- For applications that **introspect the host's running kernel
  state from the DPU side** (rootkit detection, periodic process
  / module / library / thread snapshots, integrity verification),
  the build is the App Shield library's build — route the user to
  the public docs via
  [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)
  and to [`doca-programming-guide`](../../doca-programming-guide/SKILL.md)
  for the canonical build pattern.
- For applications that **consume Argus's findings** (an internal
  dashboard, a custom enrichment pipeline that sits between
  Argus and the SIEM, a hand-written alert correlator), no
  DOCA-specific build is needed — the application reads the
  documented forwarder format that Argus emits, against whatever
  language the consumer is written in. The forwarder format is
  the public Argus Service Guide's surface, not a DOCA C ABI.

If the user is instead asking how to build the **Argus container
itself** from source, that is *not* an external-operator workflow
— the container ships pre-built from NGC and rebuilding it is
out of scope for this skill. Route to the public DOCA Argus
Service Guide via [doca-public-knowledge-map ## DOCA services](../../doca-public-knowledge-map/SKILL.md#doca-services).

## modify

Argus does not have a "modify a sample" workflow analogous to
DOCA libraries; there is no Argus sample program a user starts
from. The Argus analog of "modify" is **adapt the documented
container config recipe to the user's environment and tune the
detection policy as the calibration period progresses**:

1. **Start from the documented recipe.** Identify the public
   guide's recipe that matches the user's deployment posture
   (the same detector classes, the same forwarder target shape,
   the same sampling tier). Quote it; do not author a new one
   from scratch.
2. **Diff against the user's environment.** Note the specific
   substitutions the user must make: SIEM endpoint hostname,
   forwarder auth material, host-coverage scoping (which host
   targets), sampling tier (production vs lab), config file
   path, container image tag (always pulled from NGC per the
   public guide).
3. **Apply minimum-change.** Change only what the user's
   environment forces. Every additional deviation from the
   documented recipe widens the surface for an unintended
   detection-policy or forwarder mismatch the operator will have
   to debug later.
4. **Re-validate against the four-axis table.** Each
   substitution is a chance to accidentally break one of the
   four axes (detection policy / forwarding / sampling / host
   coverage). Walk
   [`CAPABILITIES.md ## Capabilities and modes`](CAPABILITIES.md#capabilities-and-modes)
   one row at a time after every substitution.
5. **Re-validate against the calibration-period and
   never-silently-disable rules.** Per the safety policy in
   [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy),
   any change that turns a detector class off must be explicit,
   documented, and time-boxed with a re-evaluation date. An
   undocumented disable is a silent blind spot the next
   operator will not know about.
6. **Re-open the calibration period.** Any non-trivial detection
   policy mutation, sampling change, or host-coverage change
   re-opens the calibration period — re-run the smoke step in
   [`## test`](#test) before re-enabling production alerting on
   the SIEM channel.

The agent's anti-pattern alert: a *"copy a generic security
agent's config and adapt"* is almost always slower than starting
from the public Argus Service Guide's recipe, because Argus's
config schema is documented per the public guide and is not 1:1
with any other security agent.

## run

Bringing up the Argus container and confirming the end-to-end
pipeline (Argus → forwarder → SIEM ingest → ops review) is
flowing, BEFORE enabling any production alerting on top.

1. **Pull the Argus container image from NGC** at the tag the
   public Argus Service Guide names for the operator's DOCA
   release. Quote the tag from the live guide; do NOT memorize
   or invent the tag.
2. **Start the container per the public Container Deployment
   Guide pattern.** Mount the Argus config file at the path the
   public Argus Service Guide names. The runtime command shape
   (e.g. `docker run` / `crictl` / BlueField container manager)
   is documented in the Container Deployment Guide reachable
   through
   [`doca-public-knowledge-map ## DOCA services`](../../doca-public-knowledge-map/SKILL.md#doca-services).
3. **Confirm the container is running, not restart-looping.** A
   restart loop is a layer-1 symptom per
   [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)
   (container runtime / image tag / config mount); diagnose it
   before touching detection policy.
4. **Watch the Argus container's logs for the documented
   startup-banner and detector-activation lines.** The
   container's stdout is the primary operational observability
   surface. Confirm that the detectors the operator configured
   are listed as activated; a detector that is silently absent
   from the activation list will be silently absent from the
   finding feed.
5. **Confirm the forwarder handshake.** The container should
   emit a documented forwarder-handshake line confirming the
   SIEM endpoint is reachable and authenticated. If it does
   not, stop and walk
   [`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy)
   layer 3 before continuing — there is no point in waiting
   for findings if the forwarder cannot deliver them.
6. **Confirm the SIEM-side ingest.** The end-to-end pipeline is
   not "Argus emitted a forwarder packet"; it is "the SIEM
   dashboard shows the heartbeat / handshake / first event that
   Argus emitted". Get the SIEM team to confirm receipt before
   waiting on real findings.
7. **Single-event smoke (next: `## test` step 1).** Before
   enabling production alerting on the SIEM channel, walk
   `## test` step 1 on a non-production monitored workload: enable
   the documented **Process Created** event and start one harmless,
   pre-approved process. Confirm that exact event traverses the
   end-to-end pipeline; only then layer production alerting on top.

For the runtime version + container-tag cross-checks that
underlie *"my Argus behaves differently from what the docs say"*,
see [`doca-version TASKS.md ## run`](../../doca-version/TASKS.md#run)
and apply the container-tag-lags-host-package overlay from
[`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility).

## test

Argus has no "compile and unit-test" workflow — testing is
operational and end-to-end.

**`## test` is an iterative loop, not a one-shot pass.** Every
mutation (detection policy change, forwarder change, sampling
change, host-coverage change, SIEM-side ingest change) re-opens
the smoke sweep AND re-opens the calibration period. Skipping
either is the failure mode this loop replaces.

The eval-loop overlay (rows apply to every Argus deployment, not
just one detection policy):

| Step | Why this is a loop, not a step | Where the substance lives |
| --- | --- | --- |
| 1 → 4 → 1 | Step 4 (SIEM-side review check) often reveals a forwarder gap or a host-coverage gap; loop back to step 1 and re-run the smoke | [`## test`](#test) step 4 |
| 2 → ## debug | When the four-axis smoke produces a flood of findings or a complete absence of findings, the deployment is non-functional — escalate to `## debug` layer 2 immediately, do not enable production alerting | [`## debug`](#debug) |
| 3 → ## configure → 3 | When the SIEM does not receive the smoke event, the forwarder is wrong — loop back to `## configure` step 4 and re-run | [`## configure`](#configure) |
| Calibration tuning → 2 → calibration tuning | Every detection-policy tuning during the calibration period re-opens the false-positive baseline; re-walk the four-axis smoke after each tuning pass | [`## debug`](#debug) layer 2 |
| 1..5 → ## run | Each loop iteration ends with a smoke; if all five pass AND the calibration period is over, hand off to live `## run` alerting | [`## run`](#run) |

The agent's rule: every mutation re-opens BOTH the smoke sweep
AND the calibration period. A configuration change followed by
*"it probably still works"* is exactly the failure mode the
iterative loop is here to prevent — and in security tooling, the
silent failure mode means the channel goes blind in a way nobody
notices until the first real event.

1. **End-to-end smoke using a documented event.** With Argus
   running and the forwarder wired, use a non-production monitored
   workload. Enable the public guide's documented **Process
   Created** event, record the local and receiver baselines, then
   start one harmless, pre-approved process. Confirm in order:
   (a) Argus container stdout shows the documented startup state
   with the configured detectors active and the forwarder handshake
   successful; (b) the corresponding Process Created event for the
   approved process appears in Argus's local event log; (c) that same
   event ID appears at the dedicated smoke receiver or tagged,
   non-alerting SIEM index the security ops team will review. Do not
   invent a detector, alert, or synthetic-event interface: process
   creation is the documented source-backed mechanism.
2. **Four-axis smoke without disabling detection.** Repeat the same
   release-matched Process Created smoke after
   each proposed detection-policy, forwarding, sampling, or
   host-coverage change, one axis at a time, on the non-production
   workload and smoke destination. Compare the identical local and
   receiver evidence against the baseline. Where the public guide
   documents a non-matching benign event, also confirm it does not
   produce that detector's alert while the container, other enabled
   detectors, and forwarder remain healthy. Do not deliberately
   misconfigure or disable an unspecified detector to manufacture a
   negative case.
3. **Forwarder failure smoke (strictly gated).** Prefer a dedicated
   test receiver whose reachability can be interrupted without
   affecting production. Inject an outage only there, or during an
   explicit owner-approved maintenance window for the real SIEM
   endpoint. Never stop or block a shared production SIEM merely
   for an Argus test. Confirm the documented forwarder error path,
   restore reachability, and account for queued findings per the
   public guide. If isolation is impossible, require SIEM-owner
   approval, a time-boxed maintenance window, production-alert
   suppression for the test stream, and a data-gap accounting plan;
   otherwise skip destructive fault injection and escalate to the
   SIEM owner. This validates the forwarder, not Argus.
4. **Calibration-period triage.** Run the deployment against the
   real workload, in a posture where findings flow to a smoke
   destination (or a tagged SIEM index that the security ops
   team is NOT yet alerting on). Triage the false-positive
   stream; tune the detection policy per the public guide; loop
   until the pre-recorded calibration exit criteria all hold and the
   security-ops owner signs off. Per the calibration-period rule in
   [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy),
   early false positives are expected, not bugs; never silently
   disable a detector class to make the stream quieter.
5. **Capability snapshot.** Save the *as-deployed* answer to:
   which Argus container tag is running, which detection policy
   / forwarder / sampling / host coverage are in effect, which
   SIEM the forwarder targets, what the steady-state finding
   baseline looks like at the end of calibration, and which
   detector classes (if any) are explicitly disabled and on
   what timeline they will be re-evaluated. This snapshot is
   the artifact that lets future debug sessions skip
   rediscovery — and the never-silently-disable rule says the
   disable list MUST be in the snapshot.

## debug

Layered diagnosis. Walk the layers in this order; do not skip
down without clearing the layer above. The five layers match
[`CAPABILITIES.md ## Error taxonomy`](CAPABILITIES.md#error-taxonomy).
To "clear" a layer, capture the layer's named healthy evidence and
show that its listed symptoms are absent; applying a proposed
resolution alone does not clear it.

1. **Container runtime layer.** Is the Argus container actually
   running and not restart-looping? Symptoms: container exits
   immediately, image pull fails, restart count climbing.
   Resolution: confirm the image tag matches what the public
   guide names for the operator's DOCA release; confirm the
   config mount path matches what the public guide names;
   confirm BlueField has the runtime configured per the public
   Container Deployment Guide. This layer is owned by the
   container runtime, not by detection policy. **Cleared when:** the
   release-matched image is running, its restart count is stable
   across two reads, and the documented config mount is present.
2. **Detection-policy layer.** Container green; no findings
   arriving (false-negative posture) or far too many findings
   arriving (false-positive flood). Resolution: walk the
   detection-policy section of the public Argus Service Guide
   against the user's actual workload pattern. Per the
   calibration-period rule in
   [`CAPABILITIES.md ## Safety policy`](CAPABILITIES.md#safety-policy),
   early-deployment false positives are expected and call for
   tuning, not for silently disabling detectors; sustained
   false negatives call for confirming the detection policy
   actually covers the classes of anomaly the user cares about.
   **Do NOT recommend silently disabling a detector class to
   quiet the stream.** Use the public guide's tuning surface or
   the sampling knob instead, and if a disable is truly needed,
   document it and time-box it.
   **Cleared when:** the required documented smoke detections pass,
   the recorded calibration budget holds for its observation window,
   and no detector is disabled outside the disable register.
3. **Forwarding-destination layer.** Findings present in Argus's
   local finding feed; SIEM ingest empty. Resolution: walk the
   forwarder config in the Argus container, the network
   reachability from the BlueField to the SIEM endpoint, and
   the auth material the SIEM is configured to accept. This
   layer is owned by the forwarder and the SIEM-side ingest,
   not by the detection policy — re-tuning the detection
   policy here is wasted effort.
   **Cleared when:** the local finding and the same finding identifier
   appear at the intended SIEM destination, and the documented
   forwarder health signal remains green.
4. **Sampling / performance layer.** Argus healthy, findings
   correct, SIEM receiving — but the host workload's
   performance is noticeably impacted (CPU / latency) since
   Argus started. Resolution: the sampling knob is the first
   thing to re-tune per the public guide; lower the sampling
   tier to the production posture (it is a different posture
   from lab sampling). **Do NOT respond to performance impact
   by disabling detector classes silently** — re-tune sampling
   first, then re-tune detection policy if sampling alone is
   insufficient, and document any disable. **Cleared when:** the
   workload's pre-recorded CPU/latency budget holds during a
   representative observation window while required smoke detections
   still pass.
5. **Host-coverage layer.** Argus healthy, findings correct,
   SIEM receiving — but the findings are about the wrong host
   targets (silent about the workload the operator cared about,
   noisy about out-of-scope targets). Resolution: walk the
   host-coverage axis in the Argus config per the public guide
   and re-scope. The Argus container can be perfectly green and
   still be looking the wrong direction. **Cleared when:** documented
   smoke events from every intended target are observed and equivalent
   events from explicitly out-of-scope targets do not enter the review
   stream.
6. **Version layer.** When the public Argus Service Guide page
   appears to disagree with what the deployed container does,
   the docs version may not match the container tag. Walk
   [`doca-version TASKS.md ## debug`](../../doca-version/TASKS.md#debug)
   layer 2 (partial install / version mismatch) and apply the
   container-tag overlay from
   [`CAPABILITIES.md ## Version compatibility`](CAPABILITIES.md#version-compatibility).
   **Cleared when:** the running container tag, release-matched guide,
   and applicable DOCA/BFB anchors satisfy the `doca-version` check.
7. **Cross-cutting layer.** For env-side and program-side debug
   that is not Argus-specific (host install, host kernel, DOCA
   library errors Argus may surface), drop to
   [`doca-debug TASKS.md ## debug`](../../doca-debug/TASKS.md#debug).
   **Cleared when:** the owning debug skill names and observes its
   green signal; Argus does not declare this layer clear on its behalf.

## Command appendix

Argus-specific commands the verbs above reach for, grouped by
purpose so the agent picks the right family without searching
prose. Every row is a class — the agent must not invent flags
beyond what the row names; flag and command discovery is `--help`
on the installed tool or the public guide, not prose recall.

**Infra-aware preamble (every row below).** Per the bundle's
detect → prefer → fall back → report contract documented in
[`doca-structured-tools-contract ## The agent behavior contract`](../../doca-structured-tools-contract/SKILL.md#the-agent-behavior-contract),
the agent should:

1. Probe for the matching structured helper FIRST (`doca-env --json`
   for version + devices + libraries + drivers + hugepages in one
   shot; the BlueField container manager's structured status
   output when available).
2. If the probe succeeds, the structured tool's output is the
   authoritative answer and the agent SHOULD NOT also run the
   manual command in the row below. Report *"using structured
   `<tool>`"*.
3. If the probe fails, fall back to the manual command in the
   row. Report *"falling back to manual chain"*.
4. The schemas the structured tools emit are defined in
   [`doca-structured-tools-contract ## Schemas`](../../doca-structured-tools-contract/SKILL.md#schemas);
   the version-handling semantics (four-way match, NGC,
   headers-win) are owned by
   [`doca-version`](../../doca-version/SKILL.md).

| Purpose | Command (class shape) | Owning step | Reads as healthy when … |
| --- | --- | --- | --- |
| Container lifecycle | The BlueField container manager's start / stop / status command for the Argus container, per the public Container Deployment Guide | [`## run`](#run) | Container `running`, restart count stable. |
| Container logs | The BlueField container manager's log-stream command for the Argus container | [`## debug`](#debug) layer 1 + 2 | Documented startup banner + detector-activation lines + forwarder-handshake line visible; no documented error / warning lines repeating. |
| Finding feed (local) | The Argus container's documented finding-feed surface (per the public guide — API endpoint / dashboard / structured log) | [`## test`](#test) step 1; [`## debug`](#debug) layer 2 | Findings emitted at the steady-state baseline established during calibration; smoke-event finding visible during the smoke. |
| Forwarder handshake | The documented forwarder-status line in the container log; cross-checked against the SIEM team's reception confirmation | [`## run`](#run) step 5; [`## debug`](#debug) layer 3 | Forwarder handshake succeeded; the SIEM team confirms the heartbeat / handshake event. |
| SIEM-side ingest confirmation | The SIEM team's normal ingest-confirmation surface — Splunk search / Kibana dashboard / Sentinel data-connector status — for the index / data type Argus targets | [`## test`](#test) step 1 (d); [`## debug`](#debug) layer 3 | Smoke event present in the SIEM review surface; steady-state findings flow visible at the expected rate. |
| Workload-CPU / latency baseline | The user's normal workload-performance measurement on the host (`top` / `vmstat` / application-side latency probe) before vs after Argus starts | [`## debug`](#debug) layer 4 | Workload performance is within the production budget; no step-change since Argus started. |
| Container tag in use | The BlueField container manager's image-inspect command for the running Argus container | [`## run`](#run) step 1; [`## debug`](#debug) layer 6 | Tag matches what the public Argus Service Guide names for the operator's DOCA release. |
| Disable register | The operator's own documented record of detector classes explicitly disabled, with reason and re-evaluation date | [`## test`](#test) step 5 | The register is current; no detector class is disabled without a documented reason and a re-evaluation date. |

Three cross-cutting rules for this appendix:

- **Never invent an Argus config key, container tag, detector
  name, or forwarder protocol detail.** The public Argus Service
  Guide is the contract; the SIEM's own docs are the secondary
  source for the SIEM-side ingest. Prose-derived flags or
  detector names are the most common hallucination failure for
  this skill.
- **Container before findings.** When triaging, confirm the
  container layer (running, not restart-looping, image tag
  correct, detectors activated, forwarder handshake) before
  reading any finding-layer or SIEM-layer command. A
  non-running container makes every downstream command
  meaningless.
- **Cross-link instead of duplicate.** Cross-cutting env
  commands (port-state, `devlink`, `ip link`, `ethtool`) live
  in [`doca-setup TASKS.md ## Command appendix`](../../doca-setup/TASKS.md#command-appendix);
  this appendix names only the Argus-specific ones.

## Deferred task verbs

- **Installing DOCA on the BlueField** — out of scope here.
  Route to [`doca-setup ## configure`](../../doca-setup/TASKS.md#configure)
  for env preparation and
  [`doca-setup ## test`](../../doca-setup/TASKS.md#test) for
  install health verification, or
  [`doca-setup ## no-install`](../../doca-setup/TASKS.md#no-install)
  for the public NGC DOCA container path.
- **Configuring the SIEM-side ingest** (Splunk forwarder stanzas,
  Logstash pipelines, Sentinel data-connector blocks) — out of
  scope here. The Argus contract is *that* the forwarder must
  reach the SIEM and *what* the documented forwarder format is;
  the SIEM-side ingest body is the SIEM team's responsibility
  and lives in the SIEM's own documentation.
- **Designing the security posture** (which classes of anomaly
  matter for a given workload, regulatory mappings, incident
  response runbooks) — out of scope here. That is a
  security-program / posture-design concern that the operator
  and the security ops team own; Argus only emits findings the
  posture has decided are worth emitting.
- **Building a custom DPU-side security tool** — not an Argus
  question. That is the DOCA App Shield library, which is **not
  covered by this bundle** (policy-excluded from the public
  release); route the user to the public docs via
  [`doca-public-knowledge-map`](../../doca-public-knowledge-map/SKILL.md)
  plus
  [`doca-programming-guide ## build`](../../doca-programming-guide/TASKS.md#build)
  for the canonical build pattern.
- **Other DOCA services** (DMS / DTS / Firefly / BlueMan /
  HBN / …) — not Argus. Route to
  [doca-public-knowledge-map ## DOCA services](../../doca-public-knowledge-map/SKILL.md#doca-services)
  for the routing table and the matching `services/<service>`
  skill when it exists (e.g.
  [`doca-dms ## configure`](../../services/doca-dms/TASKS.md#configure)
  for device management, or
  [`doca-firefly ## configure`](../../services/doca-firefly/TASKS.md#configure)
  for PTP). The container-shaped deployment pattern is shared;
  the per-service domain is different.

## Cross-cutting

- The public DOCA Argus Service Guide is the single source of
  truth. Any config key, detector name, container tag, forwarder
  protocol detail, or observability output the agent quotes must
  come from there, not from generic security-tooling knowledge
  or memory from a previous Argus release.
- Argus is END-TO-END. The container emits findings; the
  forwarder ships them to the SIEM; the SIEM ingests and
  presents; the security ops team reviews. All four legs are
  mandatory; naming only one is how the channel silently breaks.
- Path-selection is mandatory up front. Argus (the packaged
  product) is the production default; the DOCA App Shield library
  (not covered by this bundle) is the right answer only when the
  user is genuinely building their own security product;
  observability
  questions go to DOCA Telemetry Service; no-security-concern
  cases get Argus *not* deployed.
- Expect a calibration period; never silently disable findings.
  Initial false positives are tuning input, not bugs. A
  detector class that must be turned off is turned off
  explicitly, with a reason and a re-evaluation date — the
  silent disable is the failure mode this skill exists to
  prevent.
- Smoke before bulk. One known-benign event must traverse the
  full Argus → forwarder → SIEM pipeline, with a baseline
  established, before the SIEM team's production alerting is
  enabled on the channel.
- For URL routing to the Argus guide and other public DOCA
  documentation, see
  [doca-public-knowledge-map ## DOCA services](../../doca-public-knowledge-map/SKILL.md#doca-services).