Context Fabric Work Reuse

Context Fabric work reuse helps Keeptrusts reduce repeated investigation work when a verified receipt already describes the same engineering task.

For repeated work, the gateway first decides whether a request is an exact repeat, a near repeat, a known pattern in a new location, or genuinely novel work. It then looks for verified prior evidence before opening a fresh investigation.

Use this page when you want to understand what a work receipt contains, how reuse modes differ, which safety controls block unsafe replay, and which operator signals show whether reuse is helping.

What work reuse does

At a high level, Keeptrusts follows this loop:

1. Classify the incoming task as exact_repeat, near_repeat, known_pattern_new_location, or novel.
2. Look for a scoped, verified work receipt before falling back to broader context recall.
3. Select a requested reuse mode from the receipt evidence.
4. Re-evaluate current governance policy before applying receipt context or running a verifier.
5. Apply only a mode the current gateway can execute; otherwise open a fresh investigation.
6. Record response metadata and audit events so operators can explain why reuse happened or why it did not.

This keeps repeated engineering work fast without treating every old answer as safe to replay.

What a work receipt contains

A work receipt is the reusable record for a successful, scoped piece of prior work.

Each receipt can include:

• the task intent and normalized prompt fingerprint
• repository, branch, team, and agent scope
• touched files and symbols
• reusable commands and known error signatures
• patch summary and final outcome
• verifier or test evidence
• confidence and verification status
• supersession links when a newer receipt replaces an older one

Receipts are sanitized before persistence. Keeptrusts redacts secrets and other sensitive values from the stored summaries, command previews, and evidence blobs instead of trusting callers to clean them first.

Reuse modes

The gateway does not use one generic "replay" action. It selects from several reuse modes based on novelty, confidence, scope match, and policy:

Reuse mode	Current gateway behavior	Typical selection
answer_from_receipt	Inject the verified receipt summary as governed context for the current upstream request. The gateway still makes the current model call; it does not return the old answer verbatim.	Exact repeat with a verified, high-confidence patch summary.
replay_commands	Recognized by selection and policy, but currently downgraded to open_fresh_investigation because the gateway has no autonomous command-replay execution path.	Exact or near repeat with reusable commands.
adapt_previous_patch	Recognized by selection and policy, but currently downgraded to open_fresh_investigation because the gateway has no autonomous patch-adaptation execution path.	Near repeat or known pattern with overlapping files.
run_known_verifier	Run only the receipt's known verifier commands through configured hosted-gateway local access, then add the result to the request context.	Cases where verification is reusable but replay is not.
open_fresh_investigation	Skip autonomous reuse and investigate from scratch.	Novel work, weak evidence, denied policy, or missing local prerequisites.

open_fresh_investigation is the explicit safe path when Keeptrusts cannot prove that reuse is still trustworthy.

Governance and approval boundaries

The current gateway can apply answer_from_receipt or run_known_verifier without a user loop only when the request is low risk and well supported. It does not autonomously apply replay_commands or adapt_previous_patch.

Keeptrusts can proceed autonomously only when all of these hold:

• the matched receipt is still trusted and in scope
• the selected reuse mode is currently allowed by policy
• the confidence threshold for that mode is satisfied
• hosted-gateway local access is enabled when a verifier must run
• every verifier action stays read-only and non-side-effecting

Approval or a fresh investigation is required for higher-risk cases such as:

• destructive commands
• external writes or data exfiltration
• secret-bearing or policy-sensitive operations
• production writes or service-affecting actions
• low-confidence reuse
• missing or failed policy evaluation

Policy is evaluated at replay time, not just when the original receipt was captured.

Poisoning defense and scope isolation

Work reuse is intentionally fail-closed against stale or poisoned context.

Keeptrusts excludes receipts and related context from autonomous reuse when they are:

• stale
• disputed
• superseded
• conflict_pending
• outside the current org, team, repo, branch, or agent scope
• missing the provenance needed for safe replay

Additional defenses help keep old evidence from drifting into unsafe reuse:

• work receipts are ranked by trust and recency rather than raw existence
• compiled context packs are invalidated when matching receipts or shared context change
• secret redaction happens before receipt content is persisted
• verifier commands must pass before a replayed path can claim success
• previous allow decisions do not bypass current policy checks

These controls are what prevent "context reuse" from turning into unbounded prompt injection or stale-answer replay.

Operator signals and metrics

The first release exposes operator signals directly in request metadata and audit events. Those signals are the right place to verify whether reuse is helping for your gateway and repository scope.

Watch for these fields in gateway response metadata:

• keeptrusts.context_fabric.novelty_class
• keeptrusts.work_reuse.novelty_class
• keeptrusts.work_reuse.mode
• keeptrusts.work_reuse.matched_receipt_id
• keeptrusts.work_reuse.policy_decision
• keeptrusts.work_reuse.reason_code
• verifier commands and verifier outcome when a verifier lane runs
• context-pack and lane-selection details such as pack_hash and selected receipt IDs

Watch for these audit events in trail-style workflows:

• gateway.work_reuse.policy_decision
• gateway.work_reuse.verifier.start
• gateway.work_reuse.verifier.success
• gateway.work_reuse.verifier.failure
• gateway.work_reuse.outcome

When you roll these signals into cost or reuse reporting, treat avoided work and avoided cost as telemetry estimates, not invoice-grade billing truth.

When reuse does not happen

Work reuse may legitimately do nothing even when Context Fabric is enabled.

Common reasons include:

• the task is genuinely novel
• the prior receipt is out of scope for the current team, repo, branch, or agent
• the matched receipt is no longer trusted
• the gateway cannot safely replay or verify in the current working directory
• current policy requires approval or denies the action class

In those cases, Keeptrusts is behaving correctly by opening a fresh investigation instead of forcing reuse.

Next steps

• Use Context Fabric Lifecycle to configure capture, scope, search, verification, flush, and privacy purge workflows.
• Use Setting Up the Gateway for IDE Use to route IDE traffic through a gateway that can apply Context Fabric and policy controls.
• Use IDE Integration Troubleshooting if Context Fabric connects but reuse never matches the expected repo or branch scope.
• Use Human Oversight when you want policy-backed approval rules for higher-risk work.