@kaelio/ktx 0.0.0 → 0.1.0-rc.1

package/node_modules/@ktx/context/skills/_shared/identifier-verification.md

@@ -0,0 +1,27 @@
+## 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`:
+
+2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
+   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,
+   run a `sql_execution` probe with the same warehouse connection id:
+   `sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
+4. If the candidate identifier still does not resolve, do one of:
+   - Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
+     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.

package/node_modules/@ktx/context/skills/dbt_ingest/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: dbt_ingest
+description: Map dbt `schema.yml` / `properties.yml` models and sources into KTX semantic-layer overlays and column notes. Covers `sources:` vs `models:`, column `data_tests` (not_null, unique, accepted_values, relationships), and how bundle-time writes complement manifest backfill from git sync. Load when the WorkUnit's `skillNames` includes `dbt_ingest` or when raw files are dbt YAML under `models/` / `sources/`.
+callers: [memory_agent]
+---
+
+# dbt → KTX (bundle ingest)
+
+Use this skill for **uploaded** dbt projects (`dbt_project.yml` at stage root, `models/**`, `sources/**`, `schema.yml`). There is **no** `fetch()` in v1 - scheduled `dbt parse` / `manifest.json` pulls are out of scope; host-provided dbt sync may still backfill structured test metadata into `_schema` on the next sync.
+
+## Mapping (models / sources → SL)
+
+| dbt | KTX | Notes |
+|-----|--------|--------|
+| `models:` entry with `columns:` | **Overlay** on the manifest table with the same name (after `discover_data` / `entity_details`) | One SL source per physical table; model name may differ from DB name - resolve with `read_raw_file` + warehouse context. |
+| `sources:` → `tables:` | Same as models; use `identifier` when present instead of logical `name`. | Schema + name must match how the connection sees tables. |
+| Column `description` | `column_overrides[].descriptions.user` on the overlay | Do not overwrite `dbt` description keys from sync. |
+| `data_tests: not_null` / `unique` | Short hint in column `descriptions` or notes: “dbt: not null”, “dbt: unique” | Full structured metadata lands in manifest via **sync**; the skill keeps bundle-time SL text useful for the agent. |
+| `accepted_values` | Add a **brief** line in the column description: allowed values (truncate long lists) | Also mention enum-like use in `discover_data` / filters. |
+| `relationships` | Add or confirm `joins:` on the overlay **only** when `to` resolves to a real table via `read_raw_file` + `discover_data` / `entity_details` | If the ref cannot be resolved, capture the intent in a wiki page instead. |
+
+## Physical schema grounding
+
+dbt YAML is documentation and test metadata; it is not permission to invent physical columns. Before writing any table-backed SL source, confirm the real warehouse shape with `discover_data`, `sl_discover`, or `entity_details` and use only confirmed column names in `column_overrides:`, computed-only `columns:`, `grain:`, `joins:`, `segments:`, and `measures[].expr`.
+
+For dbt context-source ingest, the dbt connection is usually not the warehouse connection. Call `sl_discover` without `connectionId` first, then write overlays to the connection that owns the matching manifest-backed source (for example `postgres-warehouse`), not to the dbt connection (for example `dbt-main`). If no matching manifest-backed source is visible on any warehouse connection, do not call `sl_write_source`; record `emit_unmapped_fallback` and keep the fact wiki-only.
+
+If a `models:` entry has no `columns:` block, or the available raw files do not confirm the physical column names, do **not** synthesize a full standalone source. Write a wiki note or a description-only overlay for the resolved manifest table instead. If a business metric is described but its referenced column is not confirmed in the warehouse schema, omit the measure and capture the unresolved intent in the wiki.
+
+Include `rawPaths` on every `wiki_write`, `sl_write_source`, and `sl_edit_source` call with only the dbt YAML files that directly support the action.
+
+After every `sl_write_source`, call `sl_validate`. A validation error saying a declared column or measure reference is absent from the physical table is a hard stop: re-read the warehouse-backed source and rewrite with confirmed names, or remove the invalid SL fields.
+
+## 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`:
+
+2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
+   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,
+   run a `sql_execution` probe with the same warehouse connection id:
+   `sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
+4. If the candidate identifier still does not resolve, do one of:
+   - Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
+     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.
+
+## 1.1 test hints (descriptions / meta)
+
+When YAML shows `accepted_values` or `not_null`, add **short** hints into `column_overrides[].descriptions` (for example under `user`) or freeform column notes so chat and validation see intent before the next git sync refreshes `constraints` / `enum_values` in `_schema`. Keep hints under a few words when possible.
+
+## Overlap with MetricFlow
+
+If the same bundle also has MetricFlow `semantic_models:` / `metrics:`, the **`metricflow_ingest`** skill owns semantic/metric shapes. This skill focuses on **raw dbt schema** YAML (`models`, `sources`, tests). If both apply, load `metricflow_ingest` first when the file is clearly MetricFlow; otherwise use `dbt_ingest` for `schema.yml` without semantic_models.
+
+## Do not
+
+- Do not run `dbt` CLI or assume `target/` / `manifest.json` exists in the upload.
+- Do not invent column names, grain keys, or measure expressions from dbt model names, descriptions, tests, or common naming patterns.
+- Do not write computed `columns:`, `column_overrides:`, `grain:`, or `measures:` for a dbt model unless those exact column names are confirmed by dbt YAML columns or warehouse schema discovery.
+- Do not invent joins from `relationships` tests if the target model/table is not found in SL or the warehouse.
+- Do not read `peerFileIndex` paths - use `read_raw_file` only on `rawFiles` and `dependencyPaths` from the WorkUnit.

package/node_modules/@ktx/context/skills/historic_sql_patterns/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: historic_sql_patterns
+description: Identify recurring cross-table historic-SQL analytical intents from a bounded pattern shard and emit typed pattern evidence for deterministic wiki projection.
+callers: [memory_agent]
+---
+
+# Historic SQL Patterns
+
+Use this skill when the WorkUnit raw file is a `patterns-input/part-0001.json` style shard from the `historic-sql` adapter. Older staged bundles may still provide root `patterns-input.json`; when that is the WorkUnit raw file, read it the same way.
+
+## Required Workflow
+
+1. Read the WorkUnit notes first.
+2. Find the single pattern input file listed under the WorkUnit `rawFiles` section.
+3. Call `read_raw_file` for that exact raw file path.
+4. Identify recurring analytical intents that span at least two tables and have repeated usage signal.
+5. Emit one `pattern` evidence object per durable cross-table intent by calling `emit_historic_sql_evidence`.
+6. Set each evidence object's `rawPath` to the exact raw file path read in step 3.
+7. Stop after all pattern evidence has been emitted.
+
+Every join column mentioned in pattern descriptions must be verified via
+entity_details for both sides of the join.
+
+## 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`:
+
+2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
+   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,
+   run a `sql_execution` probe with the same warehouse connection id:
+   `sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
+4. If the candidate identifier still does not resolve, do one of:
+   - Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
+     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.
+
+## Evidence Shape
+
+Each call to `emit_historic_sql_evidence` must use this shape:
+
+```json
+{
+  "kind": "pattern",
+  "rawPath": "patterns-input/part-0001.json",
+  "pattern": {
+    "slug": "order-lifecycle-analysis",
+    "title": "Order Lifecycle Analysis",
+    "narrative": "Analysts compare order statuses with customer segments to understand lifecycle movement.",
+    "definitionSql": "select o.status, count(*) from public.orders o join public.customers c on c.id = o.customer_id group by o.status",
+    "tablesInvolved": ["public.orders", "public.customers"],
+    "slRefs": ["orders", "customers"],
+    "constituentTemplateIds": ["pg:1", "pg:2"]
+  }
+}
+```
+
+The `pattern` object must match `patternOutputSchema`; multiple calls together must form `patternsArraySchema`.
+
+## Pattern Selection Rules
+
+- Prefer patterns that involve two or more tables.
+- Prefer templates with `executionsBucket` at least `10-100` and `distinctUsersBucket` above solo usage.
+- Merge templates into one pattern only when the business intent is the same.
+- Use a stable kebab-case slug based on intent, not a template id.
+- Set `definitionSql` to the clearest representative SQL from a constituent template.
+- Set `slRefs` to source names when the source name is obvious from table names; omit uncertain refs rather than guessing.
+- Treat each pattern shard independently; do not read peer shard files from `peerFileIndex`.
+
+## Boundaries
+
+- Do not call wiki_write.
+- Do not call sl_write_source.
+- Do not call sl_edit_source.
+- Do not call context_candidate_write.
+- Do not create single-table pattern pages.
+- Do not copy credentials, tokens, user emails, or unredacted literals into evidence.

package/node_modules/@ktx/context/skills/historic_sql_table_digest/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: historic_sql_table_digest
+description: Convert one changed historic-SQL table usage bucket into typed table usage evidence for deterministic _schema projection.
+callers: [memory_agent]
+---
+
+# Historic SQL Table Digest
+
+Use this skill when the WorkUnit raw file is one `tables/<schema>.<name>.json` file from the `historic-sql` adapter.
+
+## Required Workflow
+
+1. Read the WorkUnit notes first.
+2. Call `read_raw_file` for the single `tables/<schema>.<name>.json` raw file.
+3. Read `manifest.json` only if the table JSON omits the dialect or the WorkUnit notes are unclear.
+4. Produce one concise usage narrative for this table from the staged table JSON.
+5. Call `emit_historic_sql_evidence` exactly once with `kind: "table_usage"`.
+6. Stop after the evidence tool succeeds.
+
+## 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`:
+
+2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
+   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,
+   run a `sql_execution` probe with the same warehouse connection id:
+   `sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
+4. If the candidate identifier still does not resolve, do one of:
+   - Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
+     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.
+
+## Evidence Shape
+
+Call `emit_historic_sql_evidence` with this shape:
+
+```json
+{
+  "kind": "table_usage",
+  "table": "public.orders",
+  "rawPath": "tables/public.orders.json",
+  "usage": {
+    "narrative": "Orders are repeatedly queried for paid/refunded lifecycle analysis and customer-level rollups.",
+    "frequencyTier": "high",
+    "commonFilters": ["status", "created_at"],
+    "commonGroupBys": ["status"],
+    "commonJoins": [{ "table": "public.customers", "on": ["customer_id"] }],
+    "staleSince": null
+  }
+}
+```
+
+The `usage` object must match `tableUsageOutputSchema`.
+
+## Interpretation Rules
+
+- Treat `columnsByClause.where` as common filters.
+- Treat `columnsByClause.groupBy` as common group-bys.
+- Treat `observedJoins` as common joins.
+- Use `stats.executionsBucket`, `stats.distinctUsersBucket`, and `stats.recencyBucket` to choose `frequencyTier`.
+- Use `frequencyTier: "high"` only when executions and distinct users are both broad.
+- Use `frequencyTier: "mid"` for repeated team usage that is not broad enough for high.
+- Use `frequencyTier: "low"` for low-volume but present usage.
+- Use `frequencyTier: "unused"` only when the table input explicitly says the table is stale or has no recent templates.
+- Keep `narrative` short and concrete.
+
+## Boundaries
+
+- Do not call wiki_write.
+- Do not call sl_write_source.
+- Do not call sl_edit_source.
+- Do not call context_candidate_write.
+- Do not emit more than one table usage evidence object.
+- Do not invent columns, joins, or tables that are absent from the staged JSON.

package/node_modules/@ktx/context/skills/ingest_triage/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: ingest_triage
+description: Classify and resolve conflicts detected during bundle ingest (structural duplicates, definitional contradictions, near-duplicate clusters, re-ingest changes, evictions).
+callers: [memory_agent]
+---
+
+# Ingest Triage - conflict classification and resolution
+
+This skill is loaded in two contexts:
+- By a Stage 3 WorkUnit agent when `sl_discover` reveals that a prior WU (or a prior sync) already wrote something that overlaps with what the current WU is about to write.
+- By the Stage 4 reconciliation agent for cross-WU sweeps and for eviction decisions.
+
+Apply the rules below before every write that could collide with an existing artifact.
+
+## Decision tree
+
+1. **Is this the same artifact I'm producing now, or a different one with the same name?**
+   Read both. If names match and content matches (modulo whitespace): no conflict - skip the write, the prior one stands.
+
+2. **If content differs, is it an expression-only change (e.g. a different `sql:` body for the same measure name, same grain, same columns)?**
+   Re-ingest change (expression-only): silently replace via `sl_edit_source`. No flag.
+
+3. **If the difference is structural - grain, columns, filter, join shape - is the current bundle the re-ingest of a previously-ingested bundle (i.e. `priorProvenance` has a row for this raw file and artifact)?**
+   Re-ingest change (semantic break): replace + flag. Record in the IngestReport's `conflicts_resolved` list with `flagged_for_human: true`.
+
+4. **If there's no prior-sync row (both are from THIS job), check for same-ingest contradictions:**
+
+   | Kind | Detection | Resolution |
+   |---|---|---|
+   | Structural duplicate | Same name, near-identical expression | Elect canonical by: (a) highest inbound-ref count from other sources; tiebreak: (b) lexicographically first unit key; (c) lexicographically first source name. Subsume losers into `<canonical>-variants.md` wiki page. Do NOT flag unless ambiguous. |
+   | Near-duplicate cluster | Different names, overlapping shape (same table, similar formulas) | Same as structural; one canonical, others subsumed. Flag only if no canonical emerges. |
+   | Definitional contradiction | Same name, substantively different formulas (different aggregation, different filters, different columns) | **Rename + capture**: disambiguate ALL variants with suffix derived from the domain (`churn_risk_engagement_based`, `churn_risk_billing_based`) and write a unified wiki page listing every variant with provenance. The contested name does NOT land in the SL. **Always flag.** |
+
+5. **Eviction (Stage 4 only)**: for each entry in `eviction_list()`:
+   - Remove the artifact (`sl_write_source` or `sl_edit_source` with `delete: true` for SL sources, `wiki_remove` for wiki pages).
+   - Record the removal with `emit_eviction_decision` and `action: "removed"`.
+
+## Why same-ingest vs re-ingest differs
+
+Within ONE bundle there's no user signal telling us which duplicate wins - we capture all variants and flag. Across bundles, re-uploading IS the signal that the new state is intended - we replace silently for expression changes and flag for semantic breaks.
+
+## Naming disambiguation hints
+
+When you rename to disambiguate, prefer domain suffixes that match the containing view/table/collection name: `customers.churn_risk_score` → `customers.churn_risk_engagement_based` (if the `customer_churn` view computes it from engagement); `billing.churn_risk_score` → `billing.churn_risk_billing_based`. Avoid numeric suffixes (`churn_risk_1`, `churn_risk_2`) - they disclose nothing.
+
+## Applying canonical pins
+
+When the Stage 4 system prompt includes a `<canonical_pins>` block, treat each pin as a prior user decision for that `contestedKey`.
+
+- If the pinned `canonicalArtifactKey` is present in the Stage Index or already exists in SL, keep it as the canonical artifact for that contested key.
+- Disambiguate competing artifacts instead of using the contested name for them.
+- Do not flag the pinned contested key solely because the variants disagree; the user has already chosen the canonical artifact.
+- If the pinned artifact cannot be found and no current WU can recreate it, emit `emit_conflict_resolution` with `flaggedForHuman: true` and explain that the pin references a missing canonical artifact.
+
+When a pin applies cleanly, call `emit_conflict_resolution` with `kind: "definitional_contradiction"`, `artifactKey` set to the pinned `canonicalArtifactKey`, `detail` describing the pinned election, and `flaggedForHuman: false`.
+
+## What to write in the unified wiki page
+
+When you perform rename + capture, also write one page named `<canonical-concept>-definitions.md` under the wiki GLOBAL scope. Structure:
+
+- One heading per variant, referencing the disambiguated SL name.
+- One paragraph per variant: what it computes, where it came from (raw file + line range), when to use it.
+- A closing "Choosing between these" paragraph if the variants are legitimately domain-specific.
+
+Do not attempt to rank variants or pick a "best" - that's user-override territory.
+
+## Silence rules
+
+Flag for human review when:
+- You did rename + capture for a definitional contradiction (kind 3 above).
+- You performed an eviction retention (kind 5, second row).
+- An override constraint (from a Stage 4 re-run) conflicts with current inbound refs.
+
+Do NOT flag:
+- Same-content duplicate skip (trivial).
+- Structural duplicate with clear canonical election.
+- Expression-only re-ingest replace.

package/node_modules/@ktx/context/skills/live_database_ingest/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: live_database_ingest
+description: Capture semantic-layer and knowledge updates from a live database schema snapshot.
+callers: [memory_agent]
+---
+
+# Live Database Ingest
+
+Use this skill when the ingest work unit contains raw files under
+`raw-sources/<connectionId>/live-database/<syncId>/`.
+
+## Workflow
+
+1. Read the table JSON file listed in the work unit.
+2. Read `connection.json` to understand the snapshot metadata.
+3. Read `foreign-keys.json` when the table has a foreign key or when joins are
+   needed for the semantic-layer source.
+4. Create or update one semantic-layer source for the table with
+   `sl_write_source`.
+5. Use the physical table name from the raw JSON as the source `table` field.
+6. Preserve database comments as `descriptions.db` on tables and columns.
+7. Add joins only when the foreign key index names both sides.
+8. Write wiki pages only for durable business meaning that is present in table
+   or column comments.
+9. Run `sl_validate` for the table source before the work unit completes.
+
+Sample values come from the scan record; do not invent values not present in
+relationship-profile.json.
+
+## 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`:
+
+2. `entity_details({connectionId, targets: [{display: "<identifier>"}]})` -
+   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,
+   run a `sql_execution` probe with the same warehouse connection id:
+   `sql_execution({connectionId, sql: "SELECT DISTINCT <col> FROM <ref> LIMIT 50"})`.
+4. If the candidate identifier still does not resolve, do one of:
+   - Use `sql_execution({connectionId, sql: "SELECT 1 FROM <ref> LIMIT 0"})`.
+     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.
+
+## Source shape
+
+For a raw table with this shape:
+
+```json
+{
+  "name": "orders",
+  "db": "public",
+  "columns": [
+    { "name": "id", "type": "integer", "nullable": false, "primaryKey": true }
+  ]
+}
+```
+
+Write a semantic-layer source with this shape:
+
+```yaml
+name: orders
+table: public.orders
+grain: id
+columns:
+  - name: id
+    type: number
+```
+
+Use `string`, `number`, `time`, or `boolean` for column types. When a database
+type is ambiguous, use `string`.
+
+## Boundaries
+
+The raw snapshot is structural evidence. Do not invent measures, segments,
+business definitions, or joins that are not present in the snapshot files.