Keep the workflow. Tighten its contracts and its decision-driving evidence checks; do not rebuild it or add more agents by default. The documented core is good for personal investigations and reusable decision reports: task-specific publishers, primary sources, opposing evidence, synthesis, self-critique, an isolated researcher profile, and published artifacts plus second-brain reuse. The clearest demonstrated weakness is instruction drift between the default and researcher-profile skill copies. The evidence and decision-framing improvements below are mostly about making existing good behavior consistent—not introducing practices that never existed.
Status: PROPOSAL FOR REVIEW. Nothing here authorizes implementation. This review created a new article and a separate proposal note only. Existing skills, wrappers, configurations, profiles, scheduled jobs and reports were not changed.
Approve a small pilot, not a global rollout. My recommendation is to test this on three representative requests, review the added burden and usefulness, and only then approve any edits to shared workflow documents.
DOCUMENTED finding: The core instructions already require varied evidence, distinction between consensus and speculation, and uncertainty. Both opportunity-publishing copies explicitly require self-critique. The grounded-citations skills already provide evidence quotes and independent cross-checks for disputed facts. Second-brain reuse is already a documented convention. Calling these capabilities “missing” would be misleading. The proposed change is to make a small subset mandatory and visible for load-bearing claims, across report types.
SAMPLED observation: Two recent available reports were read and their exact HTML routes returned HTTP 200: a September 27 allocation follow-up and an August 27 compensation comparison. These were selected from recent analysis artifacts, not randomly sampled. Both lead with decisions and distinguish important limitations; the first explicitly separates conflicting data definitions, names unverified checks and supplies watch items. The second distinguishes observed ranges from statistical inference and identifies terms that could change its recommendation. Neither sampled narrative has a dedicated compact claim-to-evidence-to-independence ledger. That does not establish that its underlying work lacked one. The compensation page also failed a literal “Sources” text check despite having source material in the narrative input; this is a narrow presentation observation, not proof that citations were absent from the served page.
PROPOSED improvement: Standardize the best behavior already present and add traceable support/independence fields for the few claims that matter most.
UNVERIFIED runtime assumption: This review did not audit all launch paths, cron jobs, relay wrappers, effective model settings, session loading, historical correctness or Telegram delivery. A skill file's existence does not prove it loads during every run. Hermes officially describes profiles as separate Hermes home directories with their own configurations and skills; the live docs identify HERMES_HOME as the profile boundary.[3] That explains why copies can diverge, but does not prove what every wrapper actually loads.
No error rate, measured improvement, runtime baseline or numerical confidence estimate is claimed.
The following are observations of files read on October 6, 2026. Paths and sections are included so the proposal can be reviewed against the actual text. No credentials, delivery identifiers or private report details are reproduced.
Default /opt/data/skills/research/evidence-report-publishing/SKILL.md, “Publishing behavior,” lines 120–125, specifies host-served port 5401 with <slug>.html by default and explicitly retires older hostname/public-domain references unless re-enabled. Researcher copy /opt/data/profiles/researcher/skills/research/evidence-report-publishing/SKILL.md, “Publishing behavior,” still says to verify the public page and prefer the public HTTPS domain; its earlier “Desired behavior” allows a host-served route. This is a concrete conflicting completion default within the loaded profile copy, not merely a historical incident note.
The default opportunity skill also has an explicit later current-contract section: lines 413–414 say local port 5401 and no public-domain verification by default. Older HTTPS prose should not be treated as an equally authoritative default after that override. The profile opportunity skill's “Publishing behavior,” line 152, retains public HTTPS verification without that current-contract override in the read text. For this run, Brian's explicit host-served contract resolves the ambiguity.
Researcher opportunity copy, “Background spawning model,” line 92, says use the single researcher profile; line 97's executable example instead uses hermes -p research chat -q .... The default copy's equivalent line 106 uses researcher.
The researcher copy's “Non-business research correction,” lines 125–132, suggests immediate execution through a near-future cron, while its “Background spawning model,” line 97, forbids cron for manual requests unless explicitly scheduled. These are sections of the live skill, not a labeled historical transcript. The default evidence skill now expressly distinguishes parent sessions from already-isolated workers (lines 137–143); the shorter profile evidence copy lacks that explicit exception. Brian supplied it in this request, so no nested worker was needed.
Default /opt/data/skills/local/brian-telegram-research-style/SKILL.md, “Brian-facing behavior,” lines 41–45, says ask for rigor, but also default to Standard if unspecified. Both opportunity copies' “Manual Telegram rigor gate” say stop and ask before research; their “Rigor tiers” sections separately say default to Standard. This is ambiguous for an unsupplied manual tier, but not for this run: Standard was supplied. A canonical rule should explicitly separate manual unspecified, scheduled unspecified, and already-isolated worker cases.
The default Telegram research-style skill says it does not control routing, spawning or publishing (lines 25–32), yet later gives trigger routing and a conditional hostname/port delivery instruction (line 146). That line says to use the older route when Brian explicitly requests it; it is not evidence that the old route is today's default. Likewise the opportunity skill's explicitly labeled “Historical OpenCode examples” are not active execution policy. A cleanup proposal should preserve history as history rather than treating every old command as an active contradiction.
The default adaptive-routing skill explicitly prioritizes the current request's contract (lines 16–18 and “Routing procedure”). Default second-brain reuse and both grounded-citations files were read. No adaptive-routing, Brian Telegram research-style or second-brain-task-reuse counterpart was found in the researcher's inspected skill tree. That is a discovery result, not proof those conventions can never enter its prompt by another mechanism.
The Government Analysis Function's AQuA Book distinguishes verification—meeting a specification and checking errors—from validation—being fit for the intended use. It makes assurance proportional to risk and complexity, and asks decision makers to challenge whether uncertainty was considered and communicated.[1] That supports separate evidence and publishing gates, and stronger checking for consequential decisions without making every small question bureaucratic.
Cochrane's handbook treats studies, not their multiple reports, as the unit of evidence and recommends independent extraction of interpretation-critical data in systematic reviews.[2] The transferable principle is provenance and independent checking. We are not proposing clinical systematic-review requirements for a casual product question. Five articles quoting the same announcement remain one underlying evidentiary origin; they do not establish consensus.
These references support principles, not a measured claim that this exact proposed workflow improves Brian's decisions. A model challenging its own draft remains useful, but it is not another empirical source or an independent reviewer. A second model looking at the same misleading excerpt also does not create source independence.
Exact proposed behavior: At request start, resolve a short contract containing task class, selected rigor, stakes, effective profile, parent-versus-worker role, publication mode, renderer entrypoint, exact served-route pattern and completion owner. Record which instruction supplied each value and any explicit user override. Use one approved canonical specification; profile skills should reference it or carry a clearly versioned copy, not independently accumulate competing defaults. Do not invent new configuration keys: initially this can be a prompt checklist and run artifact.
Suggested policy to approve: Supplied rigor is used without re-prompting; unspecified manual published research asks once; scheduled runs use their configured tier; workers never ask again or spawn recursively. Narrow quick answers do not become reports without a reason. A parent relays completion once; a worker publishes and returns its exact sentinel. Current per-run user instructions outrank the default.
Benefit: Removes avoidable wrong-profile, wrong-workflow and wrong-route failure paths. Effort/overhead: Moderate one-time reconciliation; tiny per-run metadata. Acceptance: A tabletop test of personal shopping, vendor comparison, scheduled monitoring, quick inline waiver and already-isolated worker resolves to one unambiguous contract each; no legacy route leaks into a current-contract test. Actual launch-path verification is a later approved task, not completed here.
Exact proposed behavior: Identify the handful of facts that could flip the recommendation. For each record claim; source and exact supporting passage/table/API field; source publication/update date when available; observation date; scope and definitions; originating study/dataset/organization; independence status; and supported, contradicted or unresolved result. Unknown dates and provenance remain unknown. Exclude minor background facts from the ledger.
Benefit: Makes checking targeted and avoids a bibliography that looks rigorous without carrying the decision. Effort/overhead: Low to moderate; grows with genuinely consequential claims, not prose length. Reuse existing grounded-citations tooling rather than build another source database. Acceptance: A reviewer can locate direct support for each decisive factual claim, see its freshness and tell whether corroborating links share the same origin. An unresolved critical claim changes or conditions the recommendation; it cannot disappear behind a citation count.
Exact proposed behavior: After drafting, ask “what must be true for this recommendation to work, and what is the strongest reason it may not?” Reopen the most vulnerable source, check its context and units, look for contrary primary evidence, and recompute consequential calculations with a tool. Record what changed or what remains unresolved. Use an independent empirical origin where corroboration matters; one authoritative source can settle what a policy actually says without a second paraphrase.
Benefit: Targets persuasive-but-wrong synthesis. Effort/overhead: Small for ordinary reports; higher when evidence conflicts or stakes rise. Keep same-model self-critique, but label it accurately. Human/domain review or a separate reviewer is an escalation for high-stakes/ambiguous work, not the default for every task. Acceptance: The challenge log identifies a specific tested vulnerability and disposition. “Another agent agreed” is not sufficient evidence.
Exact proposed behavior: Open with the actionable thesis. End with “recommendation now,” “what would change it,” and “revisit when.” Mark recommendations as judgment, distinct from established facts. If the evidence cannot distinguish options, say what check would settle the choice rather than manufacture a winner.
Benefit: Turns a reusable report into decision support. Effort/overhead: Very low, often just a few sentences. Acceptance: Brian can tell what to do, what unresolved condition blocks action, and which event warrants rereading. URL-only delivery remains clean, but the article's first screen contains the answer—not merely an introduction.
Exact proposed behavior: Retain Brief/Standard/Deep as budgeting expectations, not quality certificates. Brief checks the decisive current fact and gives a compact caveat; Standard uses a small ledger and focused challenge; Deep expands uncertainty analysis when stakes, complexity or disagreement warrant it. Medical, legal, safety or irreversible financial decisions can require escalation or a non-actionable answer even on a short budget.
Stop when the decisive claims have adequate direct support, important disagreements are reconciled or exposed, the challenge no longer changes the recommendation, and the requested output is complete. If time runs out first, disclose which essential check is missing and give a conditional/deferred recommendation. Escalate instead of padding the page or silently exceeding the user's scope.
Benefit: Avoids both shallow consequential answers and ceremonial research for small questions. Effort/overhead: Low; one scope/stop paragraph. Acceptance: No filler sources to satisfy the current Standard “8–15” guideline, and no intentional waiting to appear rigorous. A narrow authoritative answer may finish early; an unresolved question may need more time. Time, model choice and source count remain useful planning inputs, not proof of correctness.[1]
Exact proposed behavior: Perform a bounded search of curated second-brain notes and relevant prior reports before broad browsing; load the best match, record what is reused and refresh volatile facts. If no useful match appears, move on. Save only a distilled conclusion with date, proposal/approved status, limits and full-article link. Do not let a previous confident report become an independent source for itself.
Benefit: Reduces repeated investigation while avoiding stale conclusions. Effort/overhead: Low when retrieval works; bound it so weak search does not consume the research budget. Acceptance: The run records either the prior artifact and refreshed claims or “no relevant prior artifact found.” Reuse is already documented; this proposal concerns consistent execution, not a new memory platform.
Exact proposed behavior: For pilot reports, note decision usefulness, corrections to decisive claims, unresolved questions, refresh usefulness, observed effort where available, and publication/delivery success separately. Brian can give a one-line “helped / too much / missing X” response. Do not collect satisfaction on every trivial answer or create another dashboard by default.
Benefit: Optimizes for useful decisions rather than pages produced. Effort/overhead: Low pilot log; only expand if it guides changes. Acceptance: The pilot comparison names concrete gains and costs without invented baseline percentages or composite quality scores. A clean HTTP 200 does not count as factual accuracy.
Factual evidence gate: Decisive claims have direct, relevant, dated support or explicitly declared limits; definitions and arithmetic are checked; source dependence and important contrary evidence are addressed; the recommendation follows from the evidence and user constraints. A sourced quote establishes what a source says, not automatically that its claim is true.
Publishing/delivery gate: The new exact slug route returns HTTP 200; expected title and core content are present; relevant sources render visibly; the selected renderer is used; the final output matches the URL/failure contract; the relay owns any messaging. Publication failure does not necessarily mean research failure, and publication success does not mean the thesis survived challenge. Both gates matter.
For a tiny question, collapse this into a few sentences; do not mechanically create seven sections. A report need not claim expert consensus. If representative surveys or syntheses do not establish it, say “the sources reviewed suggest” and describe coverage.
Question: “Should I switch my personal notes app because it says it supports offline use?”
Illustrative bottom line: Keep the current app until a small offline-export test passes; the feature claim alone does not establish recoverability.
Illustrative ledger: Claim A: “the new app supports offline editing”—support would be the exact official feature documentation, update date if disclosed, and observation date. Claim B: “offline edits survive sync and can be exported”—support would require the relevant documentation plus a reproducible disposable-note test. A blog repeating the vendor's feature page shares Claim A's origin and is not independent corroboration. These placeholders are not actual retrieved evidence or test results.
Challenge: Simulate lost connectivity with disposable notes, edit on two devices, reconnect, then inspect conflicts and export. Never experiment on the only copy of real notes. A separate test is a different checking method; it still covers only the tested version and scenario.
Reversal condition: Switch only if offline edits and usable export are verified and the practical benefit exceeds migration burden. Refresh trigger: A major sync/export change or a failure in the test. Stop rule: Once the decisive feature and recoverability questions are answered, stop browsing generic “best notes app” lists. This illustrates proportional evidence checking without a multi-agent pipeline.
Step 1 — approve the pilot scope. Brian chooses three representative requests: a quick factual/personal-use question, a Standard comparison, and a disputed or time-sensitive question. Identify the decision and stakes in advance. No shared workflow changes yet; apply the proposed checklist only to those authorized pilot runs.
Step 2 — compare outputs. Use relevant existing reports as qualitative reference material where available, not as a fabricated matched baseline. Record whether the pilot produced a clearer top-line action, traceable decisive evidence, a meaningful challenge and a usable refresh trigger. Record actual added effort only if observed. Do not duplicate expensive research solely to obtain a numerical comparison.
Step 3 — review acceptance. Every pilot must resolve its execution contract, expose unsupported decisive claims, separate evidence from delivery success, and return the correct artifact. Brian must find the decision ending useful. The quick question must not become an unnecessary review pipeline. If overhead dominates or the ledger merely repeats citations, simplify it; if a critical claim survives unchecked, strengthen that specific check.
Step 4 — authorize a narrow rollout, or decline it. Only after review should Brian approve reconciliation of the canonical contract and the relevant profile/default references. Preserve original examples as labeled historical material where useful; do not mass-delete or rewrite reports. Escalation rules, renderer/wrapper changes or scheduled-job changes require separate explicit approval and runtime tests.
What Brian would approve: the manual unspecified-tier rule; the canonical host-served completion contract and ownership; which stakes trigger deeper review; the three pilot requests; whether the compact ledger earns its overhead. What is not requested now: a new agent fleet, new research platform, new scheduler, model replacement, wholesale skill rewrite or global rollout.
This is a read-only documentation review with two recent content samples and targeted source retrieval—not a full correctness audit or benchmark. Search results were unhelpful and extraction was unavailable; authoritative HTML was fetched directly instead. A candidate IPCC document returned 403 and was not used as evidence. The selected methodological references are deliberately few: they support proportional assurance, provenance, independent checking and uncertainty handling without padding a source quota.
The strongest counterargument is that good reports already do much of this. The samples support that objection. That is why the proposal is small: make the contract consistent, surface the decisive evidence chain, and copy the best decision endings. Too much process can make simple questions slower without making them better. More agents can increase output and agreement without increasing independent evidence. Reuse can propagate old mistakes if freshness and provenance are ignored.
Practical recommendation: approve only the three-request pilot and the proposed contract decisions. Prioritize instruction reconciliation, a tiny load-bearing claim ledger, and recommendation/reversal/refresh framing. Keep the present architecture. Defer global edits until the pilot demonstrates usefulness at acceptable overhead.