📅 Day 243 — Building a Work Summary Tool That Says 'Not Proven' When Evidence Is Missing
🔄 Topic
I worked on a local Resolver that summarizes open Codex and Claude work from historical sources. The security lesson was that a useful summary must preserve uncertainty instead of turning an inventory, a title, or an AI review into proof of completion.
🎯 Goal
Make an evidence pipeline trustworthy enough to guide the next action while keeping current state, historical context, and unverified claims separate.
🛠 What I Did
The importer was tightened so conversation content is not silently treated as task metadata. It keeps the fields needed to identify a task and its state, while rejecting prompt echoes, tool traffic, and content-bearing material that does not belong in a metadata-only receipt.
I also changed the summary quality checks. A list of discovered sessions is not a list of completed projects. A task title is an anchor, not proof. If the available source does not establish what happened, the result keeps an explicit limitation rather than inventing a confident next step. Historical verdicts remain historical; they do not become evidence of what is running today.
The work was independently checked against the committed changes and verification handoffs. The semantic review ledger still contains insufficient and limited cases, which is the correct result: the pipeline is more honest because it can preserve an unresolved finding instead of smoothing it away.
🔗 Key Cybersecurity Connections
This is evidence integrity and data minimization:
- provenance ties a claim to a source and time
- allowlists reduce the amount of sensitive content collected
- freshness separates current state from history
- explicit uncertainty prevents false closure
- independent verification is stronger than repeating the producer’s summary
🔍 Investigation Questions
- What exact source supports this statement?
- Is the source current, or only historical?
- Does the record describe an observed state or a completed outcome?
- Can a title or count be mistaken for proof?
- What is the correct result when evidence is incomplete?
🚨 Detection Opportunities
Flag summaries that claim completion without a completion artifact, contain prompt-like text, omit source timestamps, or convert an inventory count into a success count. Keep the review record small and avoid storing raw private conversations in the operational digest.
Example:
source_kind=committed_change_and_verification
current_state=separate_from_history
completion_evidence=required
unsupported_claims=retained_as_limitations
🧭 MITRE ATT&CK Techniques
No direct ATT&CK mapping is claimed. This post concerns defensive evidence handling, privacy, and operational assurance rather than an observed adversary technique.
🗺 Visual Investigation Diagram
Historical session or commit
↓
Extract minimal metadata
↓
Validate source, freshness, and wording
↓
Separate current state from history
↓
Attach completion evidence or say “not proven”
↓
Human-readable brief
⚠ Challenges
Confident summaries are attractive because they make a busy system feel orderly. But a summary that hides uncertainty can cause the next operator to skip the check that matters. The difficult design choice was to make “insufficient evidence” a successful, structured outcome rather than an error to be removed.
📚 What I Learned
Evidence quality is part of security. A private, minimal, source-linked receipt is safer and more useful than a rich transcript that cannot distinguish intention, observation, and completion. The pipeline should make the truth boundary visible even when the answer is incomplete.
➡ Next Steps
- keep the current-state digest separate from historical review work
- attach a concrete artifact before changing a limitation into a completion claim
- preserve source hashes and timestamps for later re-checks
