Specification Evidence Governance

Use when validating specs before implementation. Use after intent and capability boundaries are approved and before deriving an implementation plan. This skill governs whether a detailed specification is honest, executable, and ready for Owner approval; it does not replace the artifact-order workflow.

Procedure

1. Classify every acceptance criterion before writing evidence.

   • Mark a criterion CURRENT_SPEC_VALIDATION only when repository bytes can prove it now: schema validity, contract semantics, prose/schema parity, static dependency/order, deterministic transformation, or dedicated cryptographic test vectors.
   • Mark database failover, process/workspace launch, adapter behavior, external mutations, container builds, registry readback, backup/restore, cutover/rollback/soak, and deployment as FUTURE_PRODUCT_QUALIFICATION until implementation exists.
   • Never write validator helper logic that simulates an unimplemented product and then call the criterion green.

2. Keep traceability slim and mechanics reusable.

   • The acceptance registry contains only ID, requirement, owning spec, phase, classification, and binding ID.
   • Put common future harness setup, callable operations, fault controls, observations, receipts, retained artifacts, cleanup, and stop conditions into class-level qualification profiles.
   • Put criterion-specific public surfaces, faults, ordered actions, machine assertions, receipt schemas, and outputs into compact obligations selecting one profile. Reject copied generic procedures and irrelevant profile/fault substitutions.

3. Bind current checks to exact executable evidence.

   • Use one fully qualified test method or named production-validator procedure per assertion.
   • Run each selector from repository root. Make the test tree importable so an installed top-level tests package cannot shadow local selectors.
   • Capture actual opened repository inputs and SHA-256 values. Reject undeclared inputs, declared-but-unused targets/fixtures, unrelated nonempty assertions, and missing result artifacts.
   • Materialize a versioned temporary result receipt with exact commit/tree, selector, assertion, opened inputs/digests, exit status, output digests, and result digest; validate and read it back before accepting the check.

4. Make one deterministic production gate own cross-artifact truth.

   • Run schema/corpus checks, prose/schema parity, dependency DAG, separate delivery eligibility, trigger/dispatch completeness, BOM/runbook parity, contract version resolution, lifecycle semantics, and acceptance binding from one documented command.
   • Tests call the production functions and inject one mechanism-level mutation per rule; do not maintain a second parser only in tests.
   • Run the gate twice and require byte-identical output.

5. Review one immutable candidate.

   • Commit and record exact commit/tree, require a clean worktree, then dispatch fresh-context architecture, security/recovery, and implementability reviewers against that exact head.
   • Require severity, exact location, mechanism, consequence, concrete correction, and APPROVE or REQUEST_CHANGES.
   • Fix owning sentences/schemas in place; do not append contradictory updates.

6. Converge without looping.

   • Consolidate simultaneous findings into one bounded remediation contract with exact allowed paths, tests, stop conditions, and re-review criteria.
   • Execute large corrections as package-sized checkpoints; oversized workers that repeatedly stop at progress summaries are a decomposition defect.
   • After more than two failed review rounds on the same lineage, stop ordinary patching and obtain a fresh independent Escalation Reviewer plan. The Escalation Reviewer may pivot a failing evidence/interface layer while preserving converged core contracts.

7. Gate the implementation plan.

   • Future qualification cases remain unexecuted and unapproved until the product and harness exist.
   • Only after unanimous independent approval and explicit Owner approval may the implementation plan be derived from the exact specification head.

For reusable profile and obligation shapes, selector receipts, review probes, and exact-head gates, read references/evidence-and-review-contracts.md.

Always-on rules

• Role names are workflow identities; providers/models remain configuration and receipt provenance.
• Context7 or a documented coverage gap plus official current source is required before library/API-dependent code. Verify the receipt predates the dependent edit; a later lookup is not a preflight.
• Never simplify away trust-boundary checks, durability, recovery, independent review, or human-only gates.
• Attach every available specification, plan, review, and receipt document directly to the Slack message; a filesystem path alone is not delivery.

---

Supporting files: this skill's supporting files are held in the docsite at docs/15-skills/_support/engineering/specification-evidence-governance/ — fetch them fresh from jknash/docsite main alongside this page. Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/engineering/specification-evidence-governance/ · view source · Imported 2026-10-04. Supporting files (references, scripts) remain in the source repository.

version 1.0.0.

Published by Muse · 2026-10-04.