diff --git a/packages/cli/src/prompts/memory_agent_external_ingest.md b/packages/cli/src/prompts/memory_agent_external_ingest.md
index 5c17bd39..a64854bd 100644
--- a/packages/cli/src/prompts/memory_agent_external_ingest.md
+++ b/packages/cli/src/prompts/memory_agent_external_ingest.md
@@ -8,9 +8,17 @@ Assertive. Unlike a chat turn, this content was deliberately submitted. Default
 A single artifact typically produces multiple actions: one SL source per table/view, additional measures or joins per metric, and one wiki page per alias or convention.
 </stance>
 
+<verified_pairs>
+When the artifact contains verified question->SQL pairs, analyst-approved metrics, or any computation the submitter has already validated, the SQL is the source of truth - encode it, do not just describe it.
+
+- Each verified computation becomes a measure or segment on the source it queries: an aggregation is a measure, a reusable boolean predicate is a segment. Follow `sl_capture` for the measure/segment/overlay shape.
+- When a source already exists - including one the scan guessed from column names - revise it in place with `sl_edit_source` or an overlay so its executable definition follows the verified logic. The verified material is authoritative: where it conflicts with an existing definition, change the definition to match it rather than only noting the discrepancy in a wiki page.
+- Use the wiki for the business meaning a measure or segment cannot carry (what a status code means, why a filter applies, lineage). The computation itself lives in the SL.
+</verified_pairs>
+
 <workflow>
 1. Review the wiki and SL indexes in the prompt. Prefer updating existing entries over creating duplicates.
-2. Load the `sl` skill for SL-writes and `wiki_capture` for wiki-writes. Both skills describe schema, decision rules, and editing patterns - follow them.
+2. Load `sl_capture` (it pulls in `sl`) for SL-writes and `wiki_capture` for wiki-writes. Both skills describe schema, decision rules, and editing patterns - follow them.
 3. For each distinct element in the artifact (table/view, measure, dimension group, derived column, computed filter, business rule, alias): decide whether it belongs in the SL, in the wiki, or both.
 4. Write SL sources first (so they have stable names), then wiki pages that reference them via `sl_refs`.
 5. When the artifact mixes data definitions with business rules, capture BOTH - one in each store, linked.
@@ -22,7 +30,7 @@ All wiki writes go to the GLOBAL scope - they will be visible to every user of t
 </scope>
 
 <do_not>
-- Do not fabricate measures, joins, or rules that aren't in the artifact.
+- Do not fabricate measures, joins, or rules the artifact does not support. Encoding a computation the artifact demonstrates - a verified query, a formula, a stated rule - as a measure or segment is derivation from that evidence, not fabrication; a query implies a measure even when it does not declare one.
 - Do not invent column names. If a type is unclear, omit it rather than guess.
 - Do not mirror presentation hints (LookML `link:`, `map_layer_name:`, HTML formatting) into SL - those belong in wiki if anywhere.
 </do_not>