Council

<!-- council-exempt: true (this skill IS a verifier; running the council gate on its own output is recursive, see rules/council-gate.md exemptions) -->

_council, Council-as-Workflow (v1)

council.js is a Workflow-tool script: a reusable adversarial-verify primitive. It verifies a set of research findings against a pluggable rubric using ONE tool-using reviewer per item that re-fetches each cited URL before judging, and returns a per-item PASS | FIXED | FLAG verdict.

This was validated empirically by the council-prototype-spike: a workflow subagent verifier DID re-fetch URLs (a 404 URL correctly produced FLAG, a supported claim produced PASS), and rubric-pluggability is just data.

Scope (v1)

• Ships: the research-finding rubric (rubrics/research-finding.json), per-claim verification (source-supports-claim, no-fabricated-URLs, tag-syntax, claim-is-sourced) with mandatory URL re-fetch.
• Deferred to v2: a multi-reviewer panel (every v1 consumer uses one reviewer per item), and the persona/meddpicc/tone rubrics.
• Reference only (not re-implemented here): the always-on single-reviewer council in rules/council-gate.md is the canonical 12-criterion rubric for customer-facing prose (Factual Accuracy, Source Citations, Logical Consistency, Vendor Objectivity, Required Structure, Epistemic Honesty, Sharpness, Corroboration Integrity, Document-Claim Framing, Tone Match, Authority-Poisoning Detection, and, as of v0.2, Impact Framing, which fails an output that omits or generic-izes why the technical content matters to THIS buyer). _council does NOT duplicate that rubric; skills/_council/rubrics/customer-output.json is a separately-tracked parity copy (see tests/integration/council-customer-output-rubric.test.sh), updated to 12 criteria (Task E4 of the eval-framework spec, 2026-07-18) to close the v0.2 gap.

How it relates to the existing council

This is additive. The always-on auto-trigger council (rules/council-gate.md, single-reviewer curl, fires on every skill save) is unchanged. _council is the on-demand, composable, tool-using verifier for research findings, a different mechanism (a workflow subagent that can fetch URLs), not a replacement for the curl gate.

Self-exemption

_council is a verifier. Running the council quality gate on its own output is recursive, so it is council-exempt (consistent with the exemption in rules/council-gate.md).

Invocation contract

council.js runs via the Workflow tool. Workflow scripts have no filesystem access, so the CALLING AGENT loads the rubric file and passes it in as args:

args = {
  rubric:    <object loaded by the caller from skills/_council/rubrics/research-finding.json>,
  findings:  [ { claim, cited_url?, sources?: [{url}], materiality? } ],
  mode:      "compose" | "standalone",   // default "compose"
  reviewers: 1                            // v1: single reviewer per item
}

Returns: { rubric, mode, reviewers, verdicts: [ { claim, cited_url, url_refetched, http_ok, source_supports_claim, verdict, fix, corrected_claim, notes } ] }.

compose mode (the deep-researcher / rfp use)

A parent workflow calls council.js as a nested sub-step via the Workflow tool's one-level workflow({scriptPath}, args) nesting:

const { verdicts } = await workflow(
  { scriptPath: 'skills/_council/council.js' },
  { rubric: researchFindingRubric, findings: laneFindings, mode: 'compose' }
)
// caller applies FIXED corrections (corrected_claim) and surfaces FLAGs before
// the findings are used. council writes NO files in compose mode.

Cost note: per-item URL-refetch verification is token-heavy (~250k tokens/verifier observed in the spike). Callers MUST scope verification to top-N HIGH-materiality findings, not every finding. This is a scalpel, not a sprinkler.

standalone mode

/council-review --workflow <findings-file> style: verify a supplied findings set and return verdicts. The calling agent (which has filesystem access) writes any .council-reviewed sidecar, council.js does not.

Availability & fallback

The caller branches on whether the Workflow tool is in its toolset:

IF the Workflow tool is available:
    load rubrics/research-finding.json, call council.js via workflow({scriptPath}, args)
ELSE (Workflow tool absent, Claude.ai, older Claude Code, or opted out):
    run a single inline reviewer using the SAME rubric file's criteria as a prose
    checklist, attempting the URL re-fetch with the agent's own WebFetch.

Because both paths read the SAME rubric file, there is no criteria drift. On a non-Workflow harness the floor is a single inline verifier, never worse than today.

Rubric registry

Rubrics are flat data in rubrics/. Adding one is adding a file:

{ "name": "...", "requires_url_refetch": <bool>, "reviewer_persona": "...",
  "verdict_vocabulary": ["PASS","FIXED","FLAG"],
  "criteria": [ { "id": "...", "pass": "...", "fail": "...", "verdict_on_fail": "FLAG|FIXED" } ] }

Tools used

• Workflow tool, runs council.js (fan-out of one reviewer per finding).
• WebFetch (inside each reviewer subagent), re-fetches cited URLs. This is what the Anthropic API curl council cannot do and why the verifier must be a workflow subagent.

Citations

• rules/council-gate.md, the always-on single-reviewer curl council this primitive is additive to (unchanged).
• rubrics/research-finding.json, the v1 rubric.