diff --git a/microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md b/microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md
index d3e1e55..97c9858 100644
--- a/microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md
+++ b/microsoft/knowledge/privacy/data-classification-required-on-pii-fields.md
@@ -11,7 +11,7 @@ application-area: [all]
 
 ## Description
 
-`DataClassification` is the AL property that tells the platform what kind of data a table field stores so that telemetry, GDPR data-subject requests, and the platform's audit surfaces can treat it correctly. It is required on any field that holds personal, customer, or organization data. When the property is omitted, AL applies `ToBeClassified` — a placeholder meaning "not yet reviewed", not a safe default. Leaving a field that actually holds PII (an email address, a customer name, an employee code) as `ToBeClassified`, or setting it to `SystemMetadata` ("no user or customer data") to silence the requirement, are both under-classifications and privacy bugs, even though the code still compiles.
+`DataClassification` tells the platform what kind of data a table field stores so that telemetry, GDPR data-subject requests, and the platform's audit surfaces can treat it correctly. A field can declare its own value or inherit the table-level value. When neither scope supplies a valid classification, the field remains `ToBeClassified` — a placeholder meaning "not yet reviewed", not a safe default. Leaving a field that actually holds PII (an email address, a customer name, an employee code) as `ToBeClassified`, or classifying it as `SystemMetadata` ("no user or customer data"), are both under-classifications and privacy bugs, even though the code still compiles.
 
 ## Best Practice
 
diff --git a/microsoft/knowledge/privacy/table-level-data-classification-cascades.good.al b/microsoft/knowledge/privacy/table-level-data-classification-cascades.good.al
index 80a4345..11cbbb6 100644
--- a/microsoft/knowledge/privacy/table-level-data-classification-cascades.good.al
+++ b/microsoft/knowledge/privacy/table-level-data-classification-cascades.good.al
@@ -1,10 +1,11 @@
 table 50202 "System Configuration Log"
 {
+    DataClassification = SystemMetadata;
+
     fields
     {
         field(1; "Entry No."; Integer)
         {
-            DataClassification = SystemMetadata;
         }
         field(2; "Changed By"; Code[50])
         {
@@ -14,6 +15,9 @@ table 50202 "System Configuration Log"
         {
             DataClassification = CustomerContent;
         }
+        field(4; "Changed At"; DateTime)
+        {
+        }
     }
 
     keys
diff --git a/microsoft/knowledge/privacy/table-level-data-classification-cascades.md b/microsoft/knowledge/privacy/table-level-data-classification-cascades.md
index cd31d07..55ac5d6 100644
--- a/microsoft/knowledge/privacy/table-level-data-classification-cascades.md
+++ b/microsoft/knowledge/privacy/table-level-data-classification-cascades.md
@@ -1,24 +1,24 @@
 ---
 bc-version: [all]
 domain: privacy
-keywords: [data-classification, table-level, normal-field, appsourcecop, as0016]
+keywords: [data-classification, table-level, field-inheritance, appsourcecop, as0016, false-positive]
 technologies: [al]
 countries: [w1]
 application-area: [all]
 ---
 
-# Set DataClassification on every Normal table field
+# Table-level DataClassification is inherited by fields
 
 ## Description
 
-AppSourceCop AS0016 requires every field whose `FieldClass` is `Normal` to declare `DataClassification` and use a value other than `ToBeClassified`. A table-level `DataClassification` property does not satisfy that field-level requirement. FlowFields and FlowFilters are handled separately by the platform and are covered by `flowfield-flowfilter-classification-systemmetadata.md`.
+A valid table-level `DataClassification` is the effective default for fields that do not declare their own value. A field-level value overrides that default only for the field on which it is set. AppSourceCop AS0016 accepts Normal fields that inherit a valid table classification; they do not remain `ToBeClassified`. FlowFields and FlowFilters are handled separately by the platform and are covered by `flowfield-flowfilter-classification-systemmetadata.md`.
 
 ## Best Practice
 
-Classify each Normal field according to the data it stores, even when every field in the table has the same classification. Repeat the property explicitly so AS0016 can verify every field.
+Use a table-level classification when it accurately describes the table's fields, and add a field-level classification only where a field stores a different kind of data. Do not flag a Normal field solely because it omits an explicit property when its table supplies a valid default; verify whether the inherited value matches the field's data instead.
 
 See sample: `table-level-data-classification-cascades.good.al`.
 
 ## Anti Pattern
 
-Relying on `DataClassification` at table scope and leaving Normal fields unclassified. The table property does not cascade in the way AS0016 requires, so the fields still fail AppSourceCop validation.
+Reporting every Normal field without an explicit `DataClassification` when the table already supplies a valid default, or requiring redundant field-level declarations that repeat the table value. A real issue exists when neither scope supplies a valid classification, or when a field's data requires an override of the inherited value.