Date: 2026-09-23
Scope: competitor differentiation, innovation selection, and the first enterprise-grade implementation slice for evidence-centric verifier routing.
The project owner asked IDKMesh to identify innovative features that are not merely copies of competitor capabilities, then asked to continue with implementation and explicitly required the result to be:
“enterprise-level code … very solid, strong and well done”
The implementation work therefore prioritized bounded contracts, fail-closed behavior, reproducibility, tests, provenance, compatibility, and authority separation over adding broad autonomous behavior quickly.
A current ecosystem review showed that several ideas are no longer sufficient as standalone differentiation:
The resulting product thesis was narrowed to:
Other platforms orchestrate agents. IDKMesh should orchestrate evidence.
The strongest candidate capability is an Adaptive Evidence Portfolio: choose an additional verifier based on the marginal evidence it contributes to the panel already selected, rather than on nominal reviewer count, standalone accuracy, or provider-family labels alone.
The repository already had in-flight Adaptive Verification Ecology (AVE) work:
AVE already covers several adjacent mechanisms:
The new work was deliberately scoped under that architecture rather than creating a competing controller.
The innovation program was recorded in:
docs/product/INNOVATION_MOAT_2026-09-23.md;The first executable question from #693 is:
Given one historical ground-truthed verdict matrix, an already-selected verifier panel, one candidate verifier, and the exact gate/quorum rule, what changed when that verifier was added?
The intended quantity is explicitly contextual:
marginal panel evidence contribution under gate G on corpus C
It is not named or treated as an intrinsic verifier “independence score.”
Implementation PR:
feat: measure marginal verifier evidence contributionPrimary files:
idkmesh/marginal_evidence.py;idkmesh/cli.py;idkmesh/gate_audit.py;schemas/marginal-evidence-report-v0.1.schema.json;docs/specifications/MARGINAL_EVIDENCE_V0_1.md;examples/gate-audit/marginal-evidence-report.example.json;tests/test_marginal_evidence.py.The CLI surface is:
idkmesh gate-marginal panel-votes.json \
--current reviewer-a \
--current reviewer-b \
--candidate reviewer-d \
--bootstrap \
--pretty
gate-marginal reuses the same verdict-matrix parser as gate-audit.
The shared parser:
The refactor was hardened so existing gate-audit bootstrap errors continue to include the input source/path.
Every marginal-evidence report carries:
"authority": "diagnostic_only"
The implementation does not:
For every candidate verifier, the report separates:
This matters because adding one reviewer can change a quorum threshold. A reviewer with good standalone accuracy can still make a specific gate worse.
The report uses explicit status and unresolved_reasons.
Examples include:
Censored lower bounds are never subtracted to manufacture a precise delta.
Seeded known-bad probes are excluded from:
Their breach behavior is reported separately.
The optional bootstrap:
Reports bind:
Panel/candidate IDs are canonicalized to source-matrix order so semantically identical CLI argument orderings produce the same provenance digest.
The JSON Schema rejects contradictory report states, including:
status: measured with unresolved reasons;status: unresolved without a reason;A committed example report is regenerated exactly in tests from the existing gate-audit example matrix. The global example-contract coverage test maps the fixture to its schema.
During implementation, main advanced with Product Spine, CandidateReference, SEO/topic, and discovery work.
The feature branch was brought onto current main using a real two-parent Git commit:
main as second parent;This preserved Git ancestry, avoided copying unrelated changes into the PR diff, and allowed exact-head CI to run against the actual current repository tree.
The PR is required to pass the repository’s protected checks, including:
The feature is not promoted into live AVE/Connector Control Plane routing merely because its unit tests pass.
Deliberately not included in the first implementation slice:
Those remain follow-up work under #693 after the measurement primitive itself is reviewed and validated.
The implementation is intended to make a difficult research idea approachable through:
This supports incremental external review and makes it possible for contributors to challenge the statistic, fixtures, bootstrap assumptions, or gate semantics independently.