AWS Builder Center

Enrich your datasets with business context: Migrating from Topics to semantic datasets in Amazon Quick

In this post, we walk through what Dataset Enrichment is, how it differs from Topics, and provide three migration scenarios with step-by-step guidance so you can move your business context into the dataset layer with confidence.

About the Authors

  • Ashok Dasineni - Sr WW GenAI SA, Amazon Quick
  • Salim Khan - Sr WW GenAI SA, Amazon Quick
  • Neeraj Kumar - Sr WW GenAI SA, Amazon Quick

Amazon Quick  now lets you embed that business context directly into the dataset itself through Dataset Enrichment in the new data prep experience. Column descriptions, synonyms, calculated fields, custom instructions, and business rules all live alongside the data. One asset, one source of truth, one place to govern.

What is Dataset Enrichment?

Dataset Enrichment is Amazon Quick Sight's approach to embedding semantic context directly into the dataset layer. Instead of maintaining a separate Topic object that describes your columns from the outside, you define that meaning inside the dataset metadata itself: column descriptions, synonyms, business rules, calculated fields, and custom instructions all travel with the data.
When a user asks a question in Amazon Quick chat, the system reads this embedded context to resolve ambiguous language, map synonyms to the correct columns, and apply the right business logic. There's no external object to keep in sync, no separate permissions to manage, and no risk of the semantic layer drifting from the underlying schema.
 

What is Topics (legacy)

Topics is Quick Sight's original approach to adding business context to datasets. It stores column synonyms, calculated fields, named entities, filters, and custom instructions in a separate object that sits on top of the dataset — linked but independently managed.
Going forward, existing Topics are classified as legacy. The new version of Topics is being elevated to a multi-dataset semantic layer — a single entry point for cross-dataset Q&A that lets business users and AI workflows query across multiple enriched datasets in one conversation. Dataset Enrichment is the foundation that makes this possible: each dataset must carry its own semantic context before Topics can unify them at a higher level.

Key differences: Topics (legacy) vs. Dataset Enrichment (new data prep)

CategoryTopics (legacy)Dataset Enrichment
Where metadata livesSeparate Topic object, linked to a 
dataset
Inside the dataset metadata itself
Column synonymsDefined in Column Synonyms on the  TopicDefined in Additional Notes on the 
column
Business rules & filtersNamed Filters with structured 
conditions
Text-based rules in Custom Instructions
Calculated fieldsTopic-level calculations (named expressions)Calculated column (row-level transformation)
Named entitiesStructured entity objects with synonymsText entries in Custom Instructions (dataset OUTPUT tab)
Custom instructionsCustom Instructions String on TopicText entries in Custom Instructions (dataset OUTPUT tab)
GovernanceTwo assets to permission and auditOne asset to permission and audit
 

What stays the same

Not everything changes. These aspects of your Quick Sight environment remain unchanged during migration:
  • Rules datasets don't require migration. Rule-based logic continues to work as before.
  • SPICE storage and Direct Query mode are unaffected. Your data access patterns remain the same regardless of whether you use Topics or Dataset Enrichment.
  • Dashboards and analyses aren't rebuilt. They use the enriched dataset.
  • The user-facing Q&A interaction model doesn't change. Users still ask questions in natural language through Amazon Quick chat. The difference is invisible to them.

Why move business context into the dataset?

When business metadata lives in a separate Topic object, you manage two assets that must stay synchronized. Permissions, lineage, and discoverability all split across boundaries. Dataset Enrichment collapses this: 
  • Single source of truth. Business context travels with the data. There's no separate asset to drift out of sync.
  • Automatic inheritance. Any dashboard, analysis, Topic, or AI-powered chat feature built on the enriched dataset inherits the semantic context without additional configuration.
  • Simpler governance. One asset to manage permissions, audit, and version control.
  • AI-readiness. The dataset becomes self-describing for natural language querying. Amazon Quick's chat experience can resolve ambiguous business language directly from dataset metadata without requiring a separate Topic.

Whats changed in the dataset definition as part of Dataset Enrichment.

The new data prep experience introduces semantic_model_configuration on datasets. It has two layers:
 Column-level metadata (inside TableMap):
PropertyPurposeExample
DescriptionWhat the field represents"Unique identifier for each sales 
transaction"
AdditionalNotesSynonyms and alternative names users 
might say
"order id, sale id, receipt 
number"
Dataset-level metadata (inside SemanticMetadata):
PropertyPurposeExample
DescriptionOverall summary of what the dataset 
contains
"Sales fact table covering 
transactions, revenue, and margins"
CustomInstructionsBusiness logic, formulas, named 
entities, and rules
"Revenue = quantity * unit_price * 
(1 - discount_applied)"
Mapping from Topic fields to Dataset Enrichment:
Topic (legacy) FieldDataset SemanticModel Target
ColumnDescriptionColumnProperties.Description.Text
ColumnSynonyms[]ColumnProperties.AdditionalNotes.Text (comma-joined)
CalculatedFields.ExpressionDataPrepConfiguration → CreateColumnsStep
NamedEntities.EntityName + EntityDescription + DefinitionCustomInstructions.InlineCustomInstruction.InstructionText
(as "Entity Name: definition (fields: ...) (synonyms: ...)")
FiltersCustomInstructions.InlineCustomInstruction.InstructionText
(as "Business Rule - Name: Output Column Name IN [values]")
CustomInstructionsStringCustomInstructions.InlineCustomInstruction.InstructionText

Solution Overview 

Prerequisites

Before you begin, make sure you have the following in place: 
RequirementDetails
AWS CLI v2Version 2.34.50 or later. Installed and configured with valid credentials (aws sts
get-caller-identity should succeed). Verify with aws
--version.
Python 3.6+Required for the mapping script in Step 3
QuickSight AccountEnterprise edition with Q enabled
Target DatasetMust be in new data prep experience
(uses DataPrepConfiguration,
not LogicalTableMap).
Must have column IDs on all InputColumns.
Source Q TopicAn existing topic with columns, descriptions, synonyms, and optionally
calculated fields, entities, and filters
IAM Permissionsquicksight:DescribeDataSet,
quicksight:UpdateDataSet,
quicksight:DescribeTopic

Migration scenarios

The right approach depends on your current setup. We cover three scenarios, from simplest to most involved.

Scenario 1: Legacy datasets with no Topics

Your dataset was built using the classic Quick Sight experience and has no semantic layer of any kind. Users see raw column names — TXN_DT, CUST_ID, AMT_USD — in dashboards, filters, and tooltips. When someone types a natural language question in Amazon Quick chat, the system has zero context to work with: no descriptions, no synonyms, no business rules. A question like "what's our revenue this quarter?" returns nothing because nothing maps the word "revenue" to any column in the schema.
Legacy datasets ( using LogicalTableMap rather than DataPrepConfiguration) don't support Dataset Enrichment. There's no in-place upgrade path — you can't add SemanticModelConfiguration to a legacy dataset, and there's no migration API that converts one to the other.For teams in this position, the path forward is to recreate the dataset using the new data prep experience, which unlocks Dataset Enrichment from the start. Until that step is taken, no semantic context can be applied — not through Topics, not through enrichment, not through any workaround.

Scenario 2: Topics with legacy datasets

A Topic sits on top of a legacy dataset, providing the semantic layer your users depend on — column synonyms, calculated fields, named entities, named filters, and custom instructions. Users query through the Topic and get results. But underneath, the dataset itself has no enrichment. It still uses LogicalTableMap and exposes raw column names with no descriptions or business context of its own.
Like Scenario 1, the underlying legacy dataset doesn't support SemanticModelConfiguration. There's no way to push your Topic metadata into the dataset directly — the API won't accept it on a legacy dataset structure. The only path forward is creating a new dataset using the new data prep experience, migrating your Topic's metadata into it as Dataset Enrichment, validating the results, and cutting over. Your existing Topic remains active during this transition — you don't lose Q&A coverage until you're ready to switch.

Scenario 3: Topics with new data prep datasets

Current state: You already use the new data prep experience for your dataset — it has DataPrepConfiguration with SourceTableMap, TransformStepMap, and DestinationTableMap. But a Topic is still layered on top providing the semantic context your users rely on: column synonyms, calculated fields, named entities, filters, and custom instructions. The dataset structure supports enrichment natively; it just hasn't been applied yet.This is the only scenario where a direct, in-place migration is possible. Your dataset already speaks the right API language, you don't need to recreate it.Because the dataset uses DataPrepConfiguration, the update-data-set API accepts SemanticModelConfiguration directly on it. This means you can:
  • Migrate column descriptions and synonyms from your Topic into ColumnProperties.Description and ColumnProperties.AdditionalNotes on the dataset. Every column that had a ColumnDescription or ColumnSynonyms array in the Topic gets an equivalent entry in the dataset's semantic layer.
  • Migrate calculated fields from Topic-level expressions into CreateColumnsStep entries in DataPrepConfiguration. These become first-class computed columns in the dataset, visible in dashboards and available for natural language queries without a Topic.
  • Migrate named entities, filters, and custom instructions into CustomInstructions.InlineCustomInstruction.InstructionText. Entity definitions, business rules, and formula documentation are preserved as structured text that the chat system reads at query time.
  • Keep the Topic active during migration. Both the Topic and the dataset enrichment can coexist temporarily. You validate the enriched dataset's Q&A behavior against the Topic's, and only remove the Topic once you're satisfied.
  • Run the entire migration with a script. Because both describe-topic and update-data-set are API calls, the transformation can be automated end-to-end — extract Topic metadata, transform it, apply it to the dataset, and verify. No manual UI work required.
This below steps automates the enrichment of an Amazon Quick Sight dataset with semantic metadata extracted from a Quick Sight Topic. It transfers business context, column descriptions, synonyms, calculated fields, named entities, filters, and custom instructions from a Topic directly into the dataset's SemanticModelConfiguration.

Step overview

StepActionInputOutput
1Describe target datasetDataset IDdataset-schema.json
2Describe source topicTopic IDtopic-metadata.json
3Run mapping scriptBoth JSON files aboveenriched-payload.json
4Update datasetenriched-payload.jsonUpdated dataset

Required parameters

  • ACCOUNT_ID = <<0358134xxxxx>>
  • REGION = <<us-east-1>>
  • DATASET_ID = <<30c1e26a-e02a-4f2a-ac48-xxa1xxxxx916>>
  • TOPIC_ID = <<Lqly6sc7WtziPgm9tinzjxxxxxxxxxxx>>
Note: Dataset name is automatically read from dataset-schema.json during the update step.

Step 1: Describe the Target Dataset and Save JSON

Purpose: Extract the dataset's column schema (names, IDs, types) and data prep configuration. This JSON is used by the mapping script in Step 3.

1.1 Run CLI and save to file

1
2
3
4
5
aws quicksight describe-data-set \
  --aws-account-id ACCOUNT_ID \
--data-set-id DATASET_ID \
--region REGION \
--output json > dataset-schema.json

1.2 Verify the saved file

# Linux/Mac:
python -m json.tool dataset-schema.json | head -30
# Windows PowerShell:
Get-Content dataset-schema.json | python -m json.tool | Select-Object -First 30

1.3 What to confirm in the output

  • DataSet.PhysicalTableMap exists with InputColumns (each column has Name and Id)
  • DataSet.DataPrepConfiguration exists (not LogicalTableMap)

Step 2: Describe the Source Topic and Save JSON

Purpose: Extract all semantic metadata from the Q Topic — column descriptions, synonyms, calculated fields, named entities, filters, and custom instructions. This JSON is used by the mapping script in Step 3.

2.1 Run CLI and save to file

1
2
3
4
5
aws quicksight describe-topic \
  --aws-account-id ACCOUNT_ID \
--topic-id TOPIC_ID \
--region REGION \
--output json > topic-metadata.json

2.2 Verify the saved file

# Linux/Mac:`` python -m json.tool topic-metadata.json | head -30 ``# Windows PowerShell:`` Get-Content topic-metadata.json | python -m json.tool | Select-Object -First 30

2.3 What to confirm in the output

  • Topic.DataSets[0].Columns[] — each has ColumnName, ColumnDescription, ColumnSynonyms
  • Topic.DataSets[0].CalculatedFields[] — has Expression, CalculatedFieldSynonyms
  • Topic.DataSets[0].NamedEntities[] — has EntityName, EntityDescription, EntitySynonyms
  • Topic.DataSets[0].Filters[] — has FilterName, conditions
  • CustomInstructions.CustomInstructionsString — business formulas

Step 3: Run Mapping Script to Generate Enriched Payload

Purpose: Read both JSON files, map topic metadata into the dataset's SemanticModelConfiguration format, add calculated fields, named entities, filters as business rules, and output a single enriched-payload.json ready for the update call.

3.1 Save the script below as enrich_dataset.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
"""
enrich_dataset.py
Reads: dataset-schema.json, topic-metadata.json
Outputs: enriched-payload.json (ready for update-data-set)
"""

import json
# --- Load inputs ---
with open("dataset-schema.json") as f:
ds = json.load(f)["DataSet"]
with open("topic-metadata.json") as f:
topic_raw = json.load(f)

topic = topic_raw["Topic"]["DataSets"][0]
custom_instructions_str = topic_raw.get("CustomInstructions", {}).get("CustomInstructionsString", "")
# --- Extract dataset structure ---
physical_table_map = ds["PhysicalTableMap"]
data_prep = ds["DataPrepConfiguration"]
ptable_key = list(physical_table_map.keys())[0]
input_columns = physical_table_map[ptable_key]["RelationalTable"]["InputColumns"]
# Build column ID lookup: {ColumnName: ColumnId}
col_id_map = {col["Name"]: col["Id"] for col in input_columns}
# --- 1. Map column descriptions and synonyms ---
# NOTE: ColumnIds is NOT supported in ColumnMetadata — use ColumnNames only
column_metadata = []for tc in topic["Columns"]:
col_id = col_id_map.get(tc["ColumnName"])
if not col_id:
continue
column_metadata.append({
"ColumnNames": [tc["ColumnName"]],
"ColumnProperties": [{
"Description": {"Text": tc.get("ColumnDescription", "")},
"AdditionalNotes": {"Text": ", ".join(tc.get("ColumnSynonyms", []))}
}]
})
# --- 2. Add calculated fields ---
# Find the ImportTableStep as the base (safe for re-runs on already-enriched datasets)
dest_key = list(data_prep["DestinationTableMap"].keys())[0]
import_step = None
for step_id, step in data_prep["TransformStepMap"].items():
if "ImportTableStep" in step:
import_step = step_id
break
last_step = import_step
# Remove any previously added calc steps to avoid circular references
data_prep["TransformStepMap"] = {k: v for k, v in data_prep["TransformStepMap"].items() if "ImportTableStep" in v}
for i, calc in enumerate(topic.get("CalculatedFields", [])):
col_name = calc["CalculatedFieldName"].upper().replace(" ", "_")
col_id = f"col-{col_name.lower().replace('_', '-')}"
step_id = f"calc-step-{i}"
# Add CreateColumnsStep to transform chain
data_prep["TransformStepMap"][step_id] = {
"CreateColumnsStep": {
"Alias": f"Add {calc['CalculatedFieldName']}",
"Columns": [{
"ColumnName": col_name,
"ColumnId": col_id,
"Expression": calc["Expression"]
}],
"Source": {"TransformOperationId": last_step}
}
}
last_step = step_id

# Add column metadata for the calculated field (no ColumnIds)
column_metadata.append({
"ColumnNames": [col_name],
"ColumnProperties": [{
"Description": {"Text": calc.get("CalculatedFieldDescription", "")},
"AdditionalNotes": {"Text": ", ".join(calc.get("CalculatedFieldSynonyms", []))}
}]
})
# Point destination to the last step
data_prep["DestinationTableMap"][dest_key]["Source"]["TransformOperationId"] = last_step
# --- 3. Build CustomInstructions text ---
lines = []
# Add topic custom instructions (formulas)
if custom_instructions_str:
lines.append(custom_instructions_str)
# Add named entities with their field definitions
for entity in topic.get("NamedEntities", []):
synonyms = ", ".join(entity.get("EntitySynonyms", []))
fields = ", ".join(d.get("FieldName", "") for d in entity.get("Definition", []))
entry = f"Entity {entity['EntityName']}: {entity.get('EntityDescription', '')}"
if fields:
entry += f" (fields: {fields})"
if synonyms:
entry += f" (synonyms: {synonyms})"
lines.append(entry)
# Add filters as business rules (supports CATEGORY_FILTER and NUMERIC_RANGE_FILTER)
for f in topic.get("Filters", []):
fname = f.get("FilterName", "Unnamed")
field = f.get("OperandFieldName", "")
ftype = f.get("FilterType", "")
if ftype == "CATEGORY_FILTER":
cf = f.get("CategoryFilter", {})
func = cf.get("CategoryFilterFunction", "")
values = cf.get("Constant", {}).get("CollectiveConstant", {}).get("ValueList", [])
inverse = cf.get("Inverse", False)
op = "NOT IN" if inverse else "IN"
lines.append(f"Business Rule - {fname}: Filter where {field} {func} {op} [{', '.join(values)}].")
elif ftype == "NUMERIC_RANGE_FILTER":
nrf = f.get("NumericRangeFilter", {})
agg = nrf.get("Aggregation", "")
inclusive = nrf.get("Inclusive", False)
minimum = nrf.get("Constant", {}).get("RangeConstant", {}).get("Minimum", "")
maximum = nrf.get("Constant", {}).get("RangeConstant", {}).get("Maximum", "")
if minimum:
op = ">=" if inclusive else ">"
lines.append(f"Business Rule - {fname}: Filter where {agg}({field}) {op} {minimum}.")
elif maximum:
op = "<=" if inclusive else "<"
lines.append(f"Business Rule - {fname}: Filter where {agg}({field}) {op} {maximum}.")

instruction_text = "\n".join(lines)
# --- 4. Assemble final payload ---
# Get topic description for dataset-level description
topic_desc = topic_raw["Topic"].get("Description", "")

semantic_model_config = {
"TableMap": {
"semantic-table": {
"Alias": "Semantic Table",
"DestinationTableId": dest_key,
"SemanticMetadata": {
"ColumnMetadata": column_metadata
}
}
},
"SemanticMetadata": [{
"Description": {"Text": topic_desc},
"CustomInstructions": [{
"InlineCustomInstruction": {
"InstructionText": instruction_text
}
}]
}]
}

output = {
"physical_table_map": physical_table_map,
"data_prep_configuration": data_prep,
"semantic_model_configuration": semantic_model_config
}
with open("enriched-payload.json", "w") as f:
json.dump(output, f, indent=2)
print("SUCCESS: enriched-payload.json created")print(f" - Columns enriched: {len(column_metadata)}")print(f" - Calculated fields added: {len(topic.get('CalculatedFields', []))}")print(f" - Named entities: {len(topic.get('NamedEntities', []))}")print(f" - Filters as rules: {len(topic.get('Filters', []))}")

3.2 Run the script

python enrich_dataset.py

3.3 Expected output

1
2
3
4
5
SUCCESS: enriched-payload.json created
- Columns enriched: 9
- Calculated fields added: 1
- Named entities: 4
- Filters as rules: 1

3.4 Verify the output file

1
2
3
# Check the three sections exist:
python -c "import json; d=json.load(open('enriched-payload.json')); print(list(d.keys()))"
# Expected: ['physical_table_map', 'data_prep_configuration', 'semantic_model_configuration']
  • physical_table_map — unchanged from source dataset
  • data_prep_configuration — with added CreateColumnsStep for calculated fields
  • semantic_model_configuration — with column descriptions, synonyms, custom instructions (formulas + entities + business rules) 

Step 4: Update the Dataset with Enriched Payload

Purpose: Apply the enriched schema to the dataset using update-data-set. This reads the three JSON sections from enriched-payload.json and passes them as CLI parameters.

4.1 Extract parameters from enriched-payload.json and run update

Option A: Using a helper script (recommended — avoids shell escaping issues)
Save as update_dataset.py:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
"""
update_dataset.py
Reads enriched-payload.json and calls aws quicksight update-data-set
"""

import json, subprocess
# --- Load payload and dataset info ---
with open("enriched-payload.json") as f:
payload = json.load(f)
with open("dataset-schema.json") as f:
ds = json.load(f)["DataSet"]
ACCOUNT_ID = ds["Arn"].split(":")[4]
REGION = ds["Arn"].split(":")[3]
DATASET_ID = ds["DataSetId"]
DATASET_NAME = ds["Name"]
# --- Build CLI command ---
cmd = [
"aws", "quicksight", "update-data-set",
"--aws-account-id", ACCOUNT_ID,
"--data-set-id", DATASET_ID,
"--name", DATASET_NAME,
"--import-mode", "SPICE",
"--region", REGION,
"--physical-table-map", json.dumps(payload["physical_table_map"]),
"--data-prep-configuration", json.dumps(payload["data_prep_configuration"]),
"--semantic-model-configuration", json.dumps(payload["semantic_model_configuration"])
]
# --- Execute ---
print("Running update-data-set...")
result = subprocess.run(cmd, capture_output=True, text=True)
if result.returncode == 0:
response = json.loads(result.stdout)
print(f"SUCCESS! Status: {response.get('Status')}")
print(f"DataSetId: {response.get('DataSetId')}")
print(f"IngestionId: {response.get('IngestionId')}")else:
print(f"ERROR: {result.stderr}")
Run it:
python update_dataset.py

4.2 Expected output

1
2
3
4
Running update-data-set...
SUCCESS! Status: 200
DataSetId: sales-fact-002
IngestionId: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Option B: Direct CLI (single command)

If you prefer a single CLI command, extract each section into separate files first:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Extract the three JSON sections into separate files:
python -c "
import json
p = json.load(open('enriched-payload.json'))
json.dump(p['physical_table_map'], open('ptm.json','w'))
json.dump(p['data_prep_configuration'], open('dpc.json','w'))
json.dump(p['semantic_model_configuration'], open('smc.json','w'))
"

# Run update-data-set with file:// references:
aws quicksight update-data-set \
--aws-account-id ACCOUNT_ID \
--data-set-id DATASET_ID \
--name "DATASET_NAME_FROM_DESCRIBE" \
--import-mode SPICE \
--region REGION \
--physical-table-map file://ptm.json \
--data-prep-configuration file://dpc.json \
--semantic-model-configuration file://smc.json

4.3 Verify the update

1
2
3
4
5
6
aws quicksight describe-data-set \
--aws-account-id ACCOUNT_ID \
--data-set-id DATASET_ID \
--region REGION \
--query "DataSet.SemanticModelConfiguration" \
--output json
Confirm:
  • TableMap.*.SemanticMetadata.ColumnMetadata has entries with Description and AdditionalNotes
  • SemanticMetadata[].CustomInstructions contains formulas, entities, and business rules
  • Calculated field column appears in OutputColumns

Validation best practices

Across all scenarios, we recommend the following validation approach:
  • Build a validation question set. Before migration, document 10–20 natural language questions that work correctly against your current Topic. These become your regression test suite.
  • Run side-by-side comparisons. Ask the same questions against the Topic (before removal) and against the enriched dataset. Results should match.
  • Test edge cases. Try ambiguous questions, synonym variations, and multi-step queries. The enriched dataset should handle these as well as (or better than) the Topic did.
  • Validate with actual users. Have 2–3 business users test the enriched dataset chat experience before you deprecate the Topic. Their natural phrasing may reveal gaps in your synonym or entity coverage.
  • Document behavioral differences. Some behaviors will differ between Topic-based querying and dataset enrichment querying:
    • Topic filters are pre-defined and selectable; business rules in custom instructions require the user to reference them by name or intent.
    • Topic calculated fields support aggregation-level expressions; dataset calculated fields operate row-by-row (aggregations happen at query time).
    • Named entities in Topics have structured metadata; in dataset enrichment they're text-based instructions.

Key Considerations

  • The update-data-set API requires a full replacement of all configuration on every call. Incremental updates to individual columns aren't supported.
  • Named entities and filters don't have dedicated API fields in SemanticModelConfiguration. They must be expressed as text within CustomInstructions.
  • Not all Topic calculation expressions translate directly to dataset-level expressions. Aggregation-based calculations may need restructuring.
  • Legacy datasets cannot be upgraded in-place currently, you must create a new dataset with new data prep experience to be able to enrich the dataset
  • Legacy datasets that cannot be updated to new

Conclusion

Dataset Enrichment in Amazon Quick moves business intelligence metadata from a separate Topic layer into the dataset itself. One asset carries its own business meaning: column descriptions, synonyms, calculation logic, entity definitions, and business rules, all governed in one place.
To get started, identify your highest-value dataset, apply enrichment using the patterns in this post, and test it in Amazon Quick chat. For the full SemanticModelConfiguration API reference, see the Amazon Quick documentation. For questions and community discussion, visit the Amazon Quick Community.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article