Foreword

In DeepSeek Harness (DSH) usage scenarios, a common requirement is: wanting to retain key observation points from a single run for later local verification, but without writing prompts, tool arguments, tool results, or session IDs in plaintext into logs.

Qiushi DSH Evidence Audit provides an observe-only DSH Profile Bundle. It listens to the official tools/result and session/event extension points and organizes the observed results into a deterministic, hash-chained JSONL evidence receipt.

What This Is

The project boundaries are outlined below.

  • Project name: qiushi-dsh-evidence-audit
  • Maintainer: 030611
  • License: MIT
  • Positioning: An observe-only evidence audit bundle for DeepSeek Harness
  • Source nature: Community-maintained, not an official DeepSeek project

It operates solely as an observer. It does not register model-visible tools, does not modify prompts, does not transform tool results, and does not append content to sessions.

Core Features

This plugin primarily does one thing: organizing observation events published by DSH into a locally verifiable JSONL evidence chain.

  1. Listens to the official tools/result and session/event extension points.
  2. Appends deterministic, hash-chained JSONL evidence receipts.
  3. Does not store plaintext of prompts, tool arguments, tool results, or session IDs.
  4. Can make certain anomalies detectable when validating existing files, such as modified retained records, deleted untouched prefixes, broken links, or incomplete final lines.
  5. Can display which event categories and hashes this observer saw in a local sequence.

The default receipt path is:

$DSH_HOME/evidence-audit/evidence-receipts.jsonl

If DSH_HOME is not set, the default is:

~/.dsh/evidence-audit/evidence-receipts.jsonl

Each line contains:

schemaVersion
sequence
collectedAt
previousRecordHash
recordHash

Where recordHash is the SHA-256 of a canonical JSON serialization of all fields except itself. The next line points to the previous line’s recordHash via previousRecordHash; the first line’s previousRecordHash uses null.

On startup, the plugin validates the complete existing file. If any line, sequence, record hash, or previous-hash link is invalid, it refuses to continue appending.

Installation and Enabling

Prerequisites are:

Node.js: ^22.19.0 || >=24.0.0
DSH installation: built from the tested commit

First, perform the installation. Using the web profile as an example:

dsh plugin --profile web add qiushi-dsh-evidence-audit

If you are using a different profile, you can use the general form:

dsh plugin --profile <profile> add qiushi-dsh-evidence-audit

After installation, use the following command to check whether the plugin has been added to the current profile’s configuration:

dsh --profile <profile> --dump-config

The configuration output should show a record with id qiushi-evidence-audit and name qiushi-dsh-evidence-audit.

Default receipts are written to:

$DSH_HOME/evidence-audit/evidence-receipts.jsonl

If DSH_HOME is not set, they are written to:

~/.dsh/evidence-audit/evidence-receipts.jsonl

To remove this bundle from the current profile, you can run:

dsh plugin --profile <profile> remove qiushi-dsh-evidence-audit

If you are running from a DSH source checkout, replace dsh with the corresponding launcher as described in that checkout’s documentation, for example the pnpm dsh launcher mentioned in the docs.

What Is Recorded in the Receipts

The session-event receipt stores hashed or auditable-category fields, including:

  • Hashed session ID
  • Event type
  • Event sequence
  • Event time
  • Event data hash
  • Optional ignorable flag

The tool-result receipt stores:

  • Tool name
  • Hashed call ID, root-call ID, and session ID
  • Argument hash
  • Final outcome hash
  • Error flag
  • Parent-presence flag
  • Optional error code

It must be emphasized here: eventDataHash, argumentsHash, and outcomeHash are not anonymization, encryption, digital signatures, or external trust anchors. The JSONL file does not store observed plaintext, but the received file itself should still be handled as sensitive pseudo-anonymized data.

What It Cannot Prove

The capability boundaries of this plugin are clear.

It allows you to see which event categories and hashes the observer recorded in a local sequence, and it can make certain anomalies in the existing evidence chain visible during validation. However, it cannot prove:

  • Whether a certain command ran correctly
  • Whether a certain result is authentic
  • Who produced the file
  • Whether a legitimate suffix was ever deleted

Additionally, event types and tool names remain readable because they are stable audit categories.

The tools/result and session/event feeds are not deduplicated. DSH may first publish a logical tool result via tools/result, and then later persist it as a tool/result event via session/event. In such cases, this plugin will write two separate receipts describing two observations. Do not directly sum these receipts as independent tool execution counts.

Compatibility

The compatibility statement for this version is narrow: it targets commit 47f943859bef60e4160492346772ded9b24f765a of deepseek-ai/deepseek-harness, tested on 2026-08-13.

This is a commit-pinned declaration, not a commitment to the npm release 0.0.1-rc.1, future DSH commits, or any semver range.

Output Override

If you need to override the default output location, the override path must be an absolute path.

Subsequent profile patches will replace the complete line configuration. Therefore, if you modify the output configuration, you must preserve the original row name and provide the complete configuration, rather than only a single field.

Use Cases and Considerations

It is suitable for users who want to retain a verifiable observation chain in local DSH runs while avoiding writing prompts, tool arguments, tool results, and session IDs in plaintext to disk.

Consider the following before use:

  1. It is a community-maintained project, not an official DeepSeek project.
  2. The plugin runs with the permissions of the current dsh process. Review the source code and the MIT license before installation.
  3. Receipt files should be protected as sensitive pseudo-anonymized data.
  4. Do not treat hashes as anonymization, encryption, digital signatures, or external trust anchors.
  5. The two event feeds are not deduplicated, so receipt counts cannot be directly used as independent tool execution counts.
  6. The plugin validates the complete existing file on startup. If path issues or pre-existing chain corruption are detected during startup, the plugin fails directly rather than silently discarding audit records.
  7. The primary runtime overhead includes canonical serialization, SHA-256, synchronous append I/O for each observation record, and full chain validation at plugin startup.

Conclusion

What Qiushi DSH Evidence Audit does is quite restrained: it does not modify model inputs, does not alter tool results, and does not make execution judgments on behalf of DSH. It simply organizes the observation events exposed by DSH into a locally verifiable hash-chained JSONL.

If you need to retain a local evidence chain in DSH without plaintext sensitive content, you can follow the steps above to install and verify the configuration, and then check whether the default receipt file meets expectations.

Project source:

https://github.com/030611/qiushi-dsh-evidence-audit