holdout-governance

Official

Overview Schema Source Related Servers Discussions Admin

gov_attach

Attach gate evidence, attachments, declarations, or human reviews to an artifact and reset its decision to pending; run gov_check afterward to validate.

Instructions

Attach gate evidence, attachments, declarations or a human review to an artifact (decision resets to pending — run gov_check afterwards). Record gate + status + tool + report_ref after a gate tool produced evidence, or review + reviewer after a human reviewed. Attachments/declarations are name=value strings; repeated calls merge, never drop existing entries. Do NOT claim a gate passed when no tool ran — gov_check trusts the journaled status. Returns the updated gates, attachments, declarations and review.

Input Schema

Name	Required	Description
`gate`	No	gate_id to record together with status, e.g. data_integrity or temporal_integrity.
`tool`	No	Name of the tool that produced the evidence, e.g. imm, padj, lf, fl, qc.
`review`	No	Human review outcome: approved or not_recorded.
`status`	No	Gate outcome: pass, fail, warn or not_run.
`manifest`	Yes	Path to artifact.json (v0.2) that will receive the evidence.
`reviewer`	No	Name of the human reviewer (auditable declaration, not authentication).
`attachment`	No	Attachment as name=value, e.g. sources=docs/sources.md. Repeat by calling again.
`report_ref`	No	Evidence reference for the report file, e.g. sha256:<hex> or a relative path.
`data_cutoff`	No	Attest the data time the evidence reflects, ISO-8601 (distinct from run time). A cutoff later than the attach run is impossible and will block.
`declaration`	No	Declaration as name=true\|false, e.g. contains_returns=true.
`evidence_source`	No	Attest which data lineage the gate evidence rests on (e.g. feed id or input file). Two pass gates on the SAME source and SAME data_cutoff are NOT independent evidence and will block.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.0Oct 14, 2026

addedInput schema / properties / data_cutoff

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Attest the data time the evidence reflects, ISO-8601 (distinct from run time). A cutoff later than the attach run is impossible and will block.",
+  "title": "Data Cutoff"
+}

addedInput schema / properties / evidence_source

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Attest which data lineage the gate evidence rests on (e.g. feed id or input file). Two pass gates on the SAME source and SAME data_cutoff are NOT independent evidence and will block.",
+  "title": "Evidence Source"
+}

Changed9 schema fields changedv0.4.0Sep 2, 2026

addedInput schema / properties / attachment / description

Added value: +"Attachment as name=value, e.g. sources=docs/sources.md. Repeat by calling again."

addedInput schema / properties / declaration / description

Added value: +"Declaration as name=true|false, e.g. contains_returns=true."

addedInput schema / properties / gate / description

Added value: +"gate_id to record together with status, e.g. data_integrity or temporal_integrity."

addedInput schema / properties / manifest / description

Added value: +"Path to artifact.json (v0.2) that will receive the evidence."

addedInput schema / properties / report_ref / description

Added value: +"Evidence reference for the report file, e.g. sha256:<hex> or a relative path."

addedInput schema / properties / review / description

Added value: +"Human review outcome: approved or not_recorded."

addedInput schema / properties / reviewer / description

Added value: +"Name of the human reviewer (auditable declaration, not authentication)."

addedInput schema / properties / status / description

Added value: +"Gate outcome: pass, fail, warn or not_run."

addedInput schema / properties / tool / description

Added value: +"Name of the tool that produced the evidence, e.g. imm, padj, lf, fl, qc."

First observedv0.1.0Sep 2, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does well: it discloses that the decision resets to pending, that repeated calls merge and 'never drop existing entries', and that gov_check trusts the journaled status rather than the caller's claim. It omits permissions/auth requirements and any explicit error or blocking behavior (the two block conditions live only in the schema), which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with purpose before usage branches, constraints, and return shape. Only the closing 'Returns the updated gates, attachments, declarations and review' is largely redundant given an output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 11-parameter mutation tool with no annotations, the description covers purpose, the two recording modes, merge semantics, the reset-to-pending side effect, and the required gov_check follow-up; return values are covered by the output schema. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (11 params fully described), so the baseline would be 3, but the description adds real semantic value by grouping parameters into co-occurring sets (gate+status+tool+report_ref versus review+reviewer) and by clarifying that attachments/declarations are repeatable name=value merges. Those pairings are not derivable from reading the schema properties individually.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb (Attach) and resource (gate evidence, attachments, declarations, human review) against an artifact, and further distinguishes itself by naming what it is not for and what must follow ('run gov_check afterwards'). An agent can separate it from gov_check and gov_report without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use branches: 'Record gate + status + tool + report_ref after a gate tool produced evidence, or review + reviewer after a human reviewed.' It also states an exclusion — 'Do NOT claim a gate passed when no tool ran' — and gives the required follow-up call, so both the trigger and the anti-pattern are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server