# Maintain the evidence mapping, not just the prompt

Citation quality depends on source records, access rules, rendering and review criteria. Give the next team enough information to maintain all four.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Name the records that make an answer inspectable

A handover should identify the evidence map, source version fields, passage locations and answer record. Explain which identifiers are stable, which exist only within a request and how a stored answer resolves its references later.

Include one complete synthetic example from retrieved passage to rendered citation. This is more useful than a prompt file alone because many citation failures occur outside generation. A developer should be able to locate the source record and understand why the displayed link points to that version.

Document known limits. If a connector cannot preserve historical versions or precise page locations, say so. Otherwise a future maintainer may interpret a fallback URL as a guarantee the system never provided.

## Divide responsibility at real boundaries

The source owner decides whether the underlying document is correct and current. The retrieval owner makes relevant evidence available. The answer pipeline associates claims with passages. The application enforces access and renders references. These responsibilities may belong to one team, but they should still be distinguishable.

Specify who handles a report that a citation contradicts an answer. Support should not have to guess whether to contact a content editor, a search engineer or a model specialist. A small triage path based on source correctness, retrieval completeness and claim support makes the report actionable.

Changes to source structure deserve the same attention as prompt changes. A new document parser can alter passage identifiers or remove headings, affecting citation meaning without changing the model at all.

## Transfer the review standard

Keep the reviewed fixture set with the code or in another maintained location. Include the reasoning behind expected outcomes, especially where a claim is only partly supported. A list of passing answer strings is brittle and does not teach the next team what matters.

Record how automated evaluation was calibrated and which failure types remain difficult. Explain the release criteria and escalation path for consequential unsupported claims. The new owner should be able to repeat the assessment after a model or source change without reconstructing the original team's judgement.

Add a simple operational view of broken references, unknown evidence identifiers and support-check failures. Avoid logging unrestricted source text merely to make that view convenient.

## Rehearse maintenance before closing the handover

Ask the receiving team to update a source version, diagnose a deliberately broken reference and test an access revocation. Watch whether the documentation leads them to the correct records and decisions. Fix gaps revealed by the exercise.

Finally, assign ownership of the evidence schema and migration process. Citation data often outlives the prompt that created it. A future release must preserve the meaning of older records or explicitly mark their limitations. Maintaining that relationship is what keeps a citation useful after the original implementation team has moved on.

## Sources

- [OWASP: logging guidance](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
- [OWASP: authorisation guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)