Add retention policy knowledge to the privacy domain

[Jeremy Vyska (JeremyVyska)]

Business Central's retention policy feature had no coverage in BCQuality — the only mention anywhere in the corpus was a passing clause in the data-classification article. Extension-owned tables that accumulate rows (activity logs, integration logs, archives) routinely ship with no policy at all, and the two mistakes behind that are both LLM-invisible: registration that only runs in install code, and registration mistaken for a policy.

Two articles in microsoft/knowledge/privacy/, each with .good.al / .bad.al companions:

register-owned-log-tables-for-retention-policies.md — the engine only deletes from tables in the allowed-tables list, and an extension may register only tables it owns. Register from install and upgrade code, because install code does not run when an existing installation moves to a new version; guard with IsAllowedTable plus an upgrade tag; use MandatoryMinRetenDays where audit needs a floor, and locked filters via AddTableFilterToJsonArray. Anti-pattern: a hand-rolled DeleteAll against a hard-coded window, invisible to the Retention Policy Log and unadjustable by the administrator.

ship-a-default-retention-policy-setup.md — AddAllowedTable only makes a table selectable. Nothing is deleted until a Retention Policy Setup record exists, names a period, and is enabled, so ship one pre-created and disabled, gated by an upgrade tag — the shape codeunit 3907 "Retention Policy Installer" uses for Retention Policy Log Entry. Anti-pattern in both directions: registering and stopping, or inserting the setup enabled so the app deletes tenant data on a schedule nobody approved.

Platform claims are cited in ## References against the BC admin documentation and the Retention Policy module in microsoft/BCApps. Layer choice follows the current skills/write.md rule: privacy is owned by al-privacy-review, so its corpus lives in the Microsoft layer regardless of authorship.

Checks: validate_frontmatter.py reports 0 errors / 0 warnings; Test-ReviewFixtures.ps1 passes at 34 cases across 17 leaf domains (the convention-selected privacy fixture is unchanged).

Deliberately out of scope, noted for a later PR: Apply Retention Policy deletes at most 10,000 records per run shared across all policies, so a table gaining more than that per day never converges. That is a throughput concern and belongs in performance, not here.

🤖 Generated with Claude Code

https://claude.ai/code/session_011gvTjm746MtJEVWeRTbG46

[Jesper Schulz-Wedde (JesperSchulz)]

These are valuable additions: the distinction between allowed-table registration and an actual policy is important, the opt-in default is responsible, and the main platform claims align with the current retention-policy module. The repository validators and all PR checks pass.

I found three correctness/integration gaps that need addressing before these rules become authoritative agent guidance. Most importantly, the privacy review skill currently extracts no retention-policy signals and has no targeted cues for either rule. The new article keywords (retention-policy, AddAllowedTable, Retention Policy Setup, install/upgrade codeunits, log/archive tables) do not intersect its current token list, so a reviewer can miss both the absent registration and the “registered but no setup” anti-pattern. Please update al-privacy-review.md with relevance tokens and deterministic candidate-selection cues for both articles—for example, accumulating extension-owned log/archive tables or hand-rolled cleanup for the first, and AddAllowedTable without a corresponding setup for the second.

The inline findings cover refresh behavior, version scope, and the default-period implementation. With those corrections, the overall contribution should be in good shape.

[Jesper Schulz-Wedde (JesperSchulz)]

Retention policies and these System Application APIs were introduced with Business Central 2020 release wave 2 (v17), so [all] makes both articles applicable to versions where the objects do not exist. Please scope both articles to bc-version: [17..], consistent with how this corpus versions other platform features.

[Jesper Schulz-Wedde (JesperSchulz)]

Install and upgrade coverage is necessary, but not sufficient. The Retention Policies pages raise Reten. Pol. Allowed Tables.OnRefreshAllowedTables; current System Application, Base Application, Shopify, Email, and Performance Profiler installers all subscribe and re-run registration with a force path. This sample's upgrade-tag guard makes it exit after the first run, so it cannot participate in that refresh path. Please add the event subscriber and separate “refresh registration” from “one-time setup/tag” behavior, as the platform installers do.

[Jesper Schulz-Wedde (JesperSchulz)]

Please use the public Codeunit "Retention Policy Setup".FindOrCreateRetentionPeriod(...) helper here instead of reimplementing it. This implementation can fail if a Retention Period record already uses code SIX MONTHS for a different enum value: the filtered FindFirst finds nothing, then Insert collides on the existing code. The public helper is specifically intended to find or safely create the requested period and is what current Shopify, Performance Profiler, and Financial Report code uses.