Context Fabric Work Reuse

Context Fabric work reuse prevents the same investigation from running again when a verified receipt identifies the same engineering task.

When the same work occurs again, the gateway first classifies the request.

The classes are exact_repeat, near_repeat, known_pattern_new_location, and novel.

The gateway then searches for verified prior evidence before it starts a new investigation.

This page gives information about receipt data, reuse modes, safety controls, and verification signals.

What work reuse does

Verdictan uses 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. Before reuse, evaluate the active governance policy.
5. Apply only a mode that the active gateway can execute.
6. If no executable mode is available, open a new investigation.
7. Record response metadata.
8. Record audit events for the reuse decision.

This loop prevents the same work from running again. It does not identify each previous answer as safe to reuse.

What a work receipt contains

A work receipt is a record for prior work that software can use again in a specified scope.

Each receipt can include:

• A receipt can contain the task intent and normalized prompt fingerprint.
• A receipt can contain repository, branch, team, and agent scope.
• A receipt can contain changed files and symbols.
• A receipt can contain commands that software can use again and known error signatures.
• A receipt can contain a patch summary and last result.
• A receipt can contain verifier or test evidence.
• A receipt can contain confidence and verification status.
• A receipt can link to a newer receipt that replaces it.

Verdictan sanitizes receipts before it stores them. It redacts detected secrets and other sensitive values from stored summaries, command previews, and evidence objects.

Before submission, remove secrets and sensitive values that are not necessary. Sanitization is one more control. It does not authorize storage.

Reuse modes

The gateway does not use one generic reuse action. It selects a reuse mode from novelty, confidence, scope match, and policy:

Reuse mode	Active gateway behavior	Typical selection
answer_from_receipt	The gateway adds the verified receipt summary to the active request context. It continues with the model call for this request. It does not return the previous answer.	This mode fits an exact_repeat task with a verified, high-confidence patch summary.
replay_commands	The selection logic and policy logic recognize this mode. The gateway changes it to open_fresh_investigation. It has no autonomous path to replay commands.	This mode fits an exact_repeat or near_repeat task with commands that software can use again.
adapt_previous_patch	The selection logic and policy logic recognize this mode. The gateway changes it to open_fresh_investigation. It has no autonomous path to adapt patches.	This mode fits a near_repeat or known pattern with overlapping files.
run_known_verifier	The gateway runs only known verifier commands from the receipt. It uses configured local access and adds the result to request context.	This mode fits work with verification that the gateway can use again but without safe command reuse.
open_fresh_investigation	The gateway skips autonomous reuse and starts a new investigation.	This mode fits novel work, weak evidence, denied policy, or missing local requirements.

open_fresh_investigation is the safe path when Verdictan cannot prove that reuse is trustworthy.

Governance and approval boundaries

For a low-risk request with strong support, the gateway can apply answer_from_receipt or run_known_verifier without a user action.

The gateway does not automatically apply replay_commands or adapt_previous_patch.

Verdictan can operate autonomously only when all these conditions are true:

• The matched receipt is trusted and in scope.
• Active policy allows the selected reuse mode.
• The result satisfies the confidence threshold for that mode.
• A verifier must have local access through the hosted gateway.
• Each verifier action stays read-only and has no side effects.

Higher-risk work must use approval or a new investigation. These cases include:

• The work uses destructive commands.
• The work makes external writes or causes data exfiltration.
• The work uses secrets or sensitive policy operations.
• The work writes to production or changes a service.
• The reuse result has low confidence.
• The policy evaluation is missing or unsuccessful.

The gateway evaluates policy at reuse time. It does not rely only on the policy from receipt capture.

Poisoning defense and scope isolation

Work reuse uses fail-closed controls for stale or poisoned context.

Verdictan applies these exclusions to autonomous reuse:

• Verdictan excludes receipts with stale state.
• Verdictan excludes receipts with disputed state.
• Verdictan excludes receipts with superseded state.
• Verdictan excludes receipts with conflict_pending state.
• Verdictan excludes context that is not in the active organization, team, repository, branch, or agent scope.
• Verdictan excludes receipts without the necessary provenance for safe reuse.

More defenses help keep previous evidence from being used when it is not safe:

• Verdictan ranks work receipts by trust and recency, not only by existence.
• A change to matching receipts or shared context invalidates compiled context packs.
• Verdictan redacts secrets before it stores receipt content.
• Verifier commands must pass before a reused path can report success.
• Previous allow decisions do not bypass active policy checks.

These controls prevent unbounded prompt injection and reuse of a stale answer.

Verification signals and metrics

Verdictan puts work-reuse signals in request metadata and audit events.

Use these signals to verify reuse for the applicable gateway and repository scope.

Monitor these fields in gateway response metadata:

• verdictan.context_fabric.novelty_class
• verdictan.work_reuse.novelty_class
• verdictan.work_reuse.mode
• verdictan.work_reuse.matched_receipt_id
• verdictan.work_reuse.policy_decision
• verdictan.work_reuse.reason_code
• The metadata includes verifier commands and the verifier result when a verifier lane runs.
• The metadata includes details about the context pack and lane selection. These details include pack_hash and selected receipt IDs.

Monitor these audit events in Trail:

• 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 use these signals in cost or reuse reports, identify work not done and its cost as telemetry estimates.

They are not invoice data.

When reuse does not occur

Work reuse can correctly select no reuse when the organization enables Context Fabric.

Frequent causes include:

• The task is novel.
• The prior receipt is not in the active team, repository, branch, or agent scope.
• The matched receipt is no longer trusted.
• The gateway cannot safely reuse or verify work in the active work directory.
• Active policy denies the action class or makes approval necessary.

In these cases, Verdictan correctly starts a new investigation. It does not make reuse occur.

Next steps

• Use Context Fabric Lifecycle to configure capture, scope, search, verification, flush, and privacy purge.
• Use Setting Up the Gateway for IDE Use to route IDE traffic through a governed gateway.
• If reuse does not match the specified scope, use IDE Integration Troubleshooting.
• For approval rules for higher-risk work, use Human Oversight.