RFC candidate, sequenced after #219: contextual precedent evidence for pending approvals

[Knapp-Kevin]

Status / sequencing

Design-only follow-up. Do not implement ahead of #219.

The maintainer's response on #219 drew the right boundary: precedent is context rather than a verdict, overlaps the calibration problem if placed carelessly, and deserves its own RFC only after the external-verdict seam proves useful.

This issue records the smallest version I think is worth considering after that gate is satisfied, so the idea does not get conflated with the v1 verdict contract.

Problem

DashClaw's calibration controller answers a statistical question about interruption pressure: roughly, how often are humans approving or denying the actions that reached them?

A different question can improve the quality of an individual approval decision:

Why was a materially similar action approved or denied before, and do the conditions that mattered then still hold now?

That is useful only if historical context remains evidence rather than permission.

prior approval != standing authority
repetition != permission
similarity != material equivalence
policy-generated allow != independent human approval

Important refinement: keep precedent out of the guard hot path in v1

After reviewing DashClaw's guard deadline, calibration controller, signed decision evidence, and existing approval architecture, I would not put precedent retrieval into evaluateGuard for the first version.

Instead:

intercepted act
      |
      v
DashClaw Decide
      |
      +--> allow / warn / block
      |
      `--> require_approval
                |
                v
       pending approval record
                |
                +--> optional contextual-evidence provider
                |      material matches
                |      material differences
                |      negative / incident precedent
                |      freshness / validity
                |      provenance
                v
          human approval card
                |
           approve / deny

The guard decision is already made and persisted before memory-derived context is retrieved.

That keeps the first slice from:

• consuming guard hot-path latency;
• mutating an already-determined risk score or verdict;
• duplicating the calibration controller;
• turning similarity into authority;
• making an external memory service a prerequisite for enforcement;
• creating a second policy system inside DashClaw.

V1 authority boundary

Context may help a human understand a pending approval. It may not in this RFC:

• change allow, warn, require_approval, or block;
• lower or raise DashClaw's risk score;
• satisfy an approval automatically;
• create an allow-grant;
• create or mutate policy;
• transform an act;
• convert repeated approvals into reusable authority;
• override a DashClaw block;
• become evidence that the action executed.

A provider response should carry explicit non-authority semantics such as:

{
  "input_identity": "sha256:...",
  "applicability": "exact_match | materially_equivalent | materially_different | stale | conflicting | insufficient_evidence",
  "supporting_refs": [],
  "cautionary_refs": [],
  "material_matches": [],
  "material_differences": [],
  "unknown_conditions": [],
  "negative_or_incident_evidence_present": false,
  "independent_human_evidence_count": 0,
  "derived_or_policy_evidence_count": 0,
  "summary": "bounded human-readable explanation",
  "authority_effect": "none",
  "can_authorize_execution": false
}

The exact wire shape should be decided by a repo-native RFC rather than assumed from this sketch.

Material-equivalence safety

A retrieval system may find candidate history probabilistically, but candidate retrieval must not decide material equivalence.

For example:

prior: git push origin feature-x
now:   git push --force origin main

Those can be semantically similar while materially different on protected target and force semantics.

A safe provider should preserve structured conditions such as target/resource, environment, force/destructive semantics, sensitivity, purpose, policy/version context, temporal validity, prior incident/rollback evidence, and scope/isolation where those dimensions are relevant.

Negative precedent must remain visible even when positive history is more frequent.

Provenance / feedback-loop protection

The approval UI should not collapse all historical outcomes into one count.

At minimum, preserve distinctions between:

• independent human adjudication;
• policy-generated outcomes;
• runtime observations;
• inferred/estimated context;
• external evidence;
• denials, incidents, corrections, revocations, and rollbacks.

Ten derived allows must not become ten independent human approvals. Automatic or grant-backed outcomes must not recursively manufacture the evidence used to justify more permissive handling.

Historical rationale is data. Instruction-shaped text in old rationale must never become instructions to DashClaw, an LLM, or the operator surface.

Privacy / minimization

This integration is not permission to copy a raw action or memory corpus into another system.

Prefer stable references, structured material conditions, scoped hashes/fingerprints, bounded summaries, and the minimum fields needed to evaluate applicability. Provider identity, version/configuration, input identity, retrieval/evaluation run identity, and timestamp should remain reconstructable.

Human surface

If built, the primary surface should be the existing pending-approval experience, not a new memory dashboard.

A compact section could show, for example:

Prior context
  3 materially equivalent human approvals
  1 relevant denial / incident
  Difference: target changed from staging to production
  Context provider: available / unavailable

The human should be able to inspect the evidence references/details without leaving the product. Provider unavailability should be visible but, because this v1 context is advisory only, should not masquerade as a governance verdict or silently alter the existing approval result.

Because this context can influence human judgment, the approval evidence should bind the context snapshot the human actually saw (or explicitly record that it was unavailable), rather than allowing later memory changes to rewrite history.

Language / repository boundary

DashClaw-side implementation should remain in the repository's existing TypeScript/JavaScript architecture.

A provider may be implemented in Python, Rust, or another language. That is an implementation detail behind the protocol boundary, not a reason to add that runtime to DashClaw core.

Agent Memory is one possible provider and is the system I can supply for a first experiment, but the DashClaw RFC should remain provider-neutral.

Adversarial cases

A future RFC/spec should cover at least:

1. safe paraphrase / equivalent action;
2. force push vs ordinary push;
3. feature branch vs protected branch;
4. staging vs production;
5. ordinary vs sensitive material;
6. cross-tenant / cross-scope near match;
7. stale or revoked exact-looking precedent;
8. one relevant incident among many approvals;
9. policy-generated repetition;
10. ambiguous / insufficient evidence;
11. provider unavailable;
12. changed action identity between retrieval and approval;
13. instruction-shaped historical rationale treated strictly as data.

Unsafe near matches are allowed to be retrieved. They must not be presented as materially equivalent.

Falsification / value test

This should ship only if it materially improves human approval quality without reintroducing the product surfaces DashClaw intentionally removed.

Useful measures would separate:

• retrieval usefulness;
• unsafe-equivalence errors;
• negative-precedent misses;
• stale/cross-scope leakage;
• time-to-human-decision;
• approval reversals / later incidents;
• operator comprehension of why the precedent does or does not apply.

If it only adds text to approval cards without improving decisions, it should not survive the surface budget.

Offer to carry it

If #219 proves out and the maintainer wants this follow-up, I'm happy to write the repo-native RFC and decision record / ADR-equivalent, implementation spec, implement the DashClaw side in the existing TypeScript/JavaScript architecture, supply the Agent Memory provider adapter, add the adversarial tests and rendered human-experience proof, and follow the work through the repository's normal verification gates.

[ucsandman]

Correctly gated, and the hot-path refinement is the right call. Keeping precedent retrieval off evaluateGuard entirely and attaching it to the already-persisted pending-approval record removes both objections that pushed this out of v1: guard latency and verdict contamination. authority_effect: "none" makes the advisory boundary a property of the mechanism instead of a promise in the prose, which is the difference between an invariant and a hope.

Status: parked behind #219 proving out, exactly as you wrote it. When the verdict seam has run against your real workload, this gets its own repo-native RFC, and the falsification test you included is the bar it has to clear. If it only adds text to approval cards without measurably improving human decisions, it doesn't survive the surface budget.

Two things worth saying now so they're on the record for that future RFC:

• The provenance separation (independent human adjudication vs policy-generated outcomes vs derived evidence) is the part I care most about. Ten derived allows rendering as ten human approvals is the exact feedback loop the calibration controller was built to avoid on the statistical side, and this surface must not reintroduce it on the evidence side.
• Binding the context snapshot the human actually saw into the approval evidence is non-negotiable if this ships. Approval history that can be rewritten by later memory changes isn't history.

The invariant from your original comment is already recorded in the verdict RFC and carries over unchanged: prior approval is evidence, not standing authority.