apunkt/ktx
1
0
Fork 0
mirror of https://github.com/Kaelio/ktx.git synced 2026-07-25 12:01:03 +02:00
Code Issues Projects Releases Packages Wiki Activity

feat(memory): encode verified question/SQL pairs as executable measures and segments

Browse source 
Adds a verified_pairs directive to the external-ingest preamble so analyst-validated question/SQL pairs become executable measures and segments and revise scan-guessed sources in place, points the workflow at sl_capture, and clarifies in the do_not block that deriving a measure from a verified query is derivation from evidence, not fabrication.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Luca Martial 2026-06-25 17:15:21 -07:00
parent 84d329b24b
commit 9c0309c525
1 changed files with 10 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

12
packages/cli/src/prompts/memory_agent_external_ingest.md
View file

@ -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>