2026-05-13 13:43:23 +02:00
|
|
|
## Identifier Verification Protocol
|
|
|
|
|
|
|
|
|
|
Before writing a wiki page or SL source on any topic:
|
|
|
|
|
|
|
|
|
|
1. `discover_data({query: "<topic>"})` - see what wikis, SL sources, and raw
|
|
|
|
|
tables already exist. Prefer updating existing pages over creating new ones.
|
|
|
|
|
|
|
|
|
|
Before emitting any `schema.table` or `schema.table.column` into a wiki body,
|
|
|
|
|
SL source, `tables:` frontmatter, `sl_refs`, or `emit_unmapped_fallback`:
|
|
|
|
|
|
2026-05-15 02:35:09 +02:00
|
|
|
2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
|
2026-05-13 13:43:23 +02:00
|
|
|
confirm the identifier resolves; inspect native types, FK/PK, and
|
|
|
|
|
sampleValues.
|
|
|
|
|
3. For literal values from the source, such as status codes or plan tiers,
|
|
|
|
|
check whether they appear in `entity_details` sampleValues for the relevant
|
|
|
|
|
column. If sampleValues is short or the sample may have missed real values,
|
2026-05-15 02:35:09 +02:00
|
|
|
run a `sql_execution` probe with the same warehouse connection id:
|
|
|
|
|
`sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
|
2026-05-13 13:43:23 +02:00
|
|
|
4. If the candidate identifier still does not resolve, do one of:
|
2026-05-15 02:35:09 +02:00
|
|
|
- Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
|
2026-05-13 13:43:23 +02:00
|
|
|
If it errors, the identifier is fictional.
|
|
|
|
|
- Wrap the identifier in `[unverified - from <rawPath>]` in the wiki body,
|
|
|
|
|
citing the exact raw path that mentioned it.
|
|
|
|
|
- When recording `emit_unmapped_fallback` with `no_physical_table`, include
|
|
|
|
|
the failing probe error in `clarification`.
|
|
|
|
|
5. Never copy `<schema>.<table>` placeholder strings from these instructions
|
|
|
|
|
into output.
|