The catalog

The catalog is the company's declaration of what it collects and the purposes it collects it for. It is a set of cells, each a (category, purpose) pair: a category of personal information (the what) crossed with a purpose (the why). Phone number x Billing is a distinct cell from Phone number x Marketing. Everything else rests on it: a consent document groups catalog cells, and a consent request targets catalog cells.

#The catalog is bilingual

Each cell carries a category and a purpose label in French, which are the primary columns. English is provided as optional sibling columns, category_en and purpose_en, shown to a person who is reviewing in English, with a fallback to French when a translation is missing. The cell's description is French-only; it is an internal note for the organization and is not shown as-is to the person concerned.

Bilingualism serves the clarity of the consent request.

#Normalized keys and deduplication

Alongside its display labels, each cell carries a normalized category key (category_key) and purpose key (purpose_key), derived from the French label. The key is the label trimmed, with internal whitespace collapsed, and lowercased. These keys do two things: they deduplicate the catalog (two cells cannot declare the same pair twice) and they are the stable hinge on which approval and verification index.

Because the key derives from the French, the join never re-keys: translating or tweaking the English label does not move the cell, and a consent granted under it stays attached to the same cell.

#Locking: a rename can never orphan a consent

As soon as a cell is referenced by a consent, it is locked against renaming. The logic is simple and protects the person concerned: if a cell under which an active consent exists could be renamed, that consent would suddenly point at something other than what the person accepted. The lock prevents it. As long as no consent attaches to it, the label stays editable.

#Archiving and restoring

A cell can be archived and then restored. Archiving is catalog hygiene: it removes a cell from active views without destroying it, for example when a purpose is no longer pursued.

#The cell detail page

Each cell has a detail page that gathers what depends on it:

• The consent documents that attach it: the versioned disclosures that group this cell among their items.
• Your own customers who accepted or declined it: the count is company-scoped, indexed on the organization's customer id. The page never shows a citizen's decentralized identifier; the company sees its customers, not the person's protocol identity.
• The lock state: the page shows whether the cell is locked because a consent references it.

#Automated decision (P-39.1 s. 12.1; A-2.1 s. 65.2)

A cell can be flagged as feeding a decision based exclusively on the automated processing of personal information. The Act requires informing the person concerned not later than at the time they are informed of the decision and, at their request, of the personal information used, the reasons and the principal factors and parameters that led to the decision, and of their right to have that information corrected; they must be given the opportunity to submit observations to a member of the personnel able to review the decision (P-39.1 s. 12.1; A-2.1 s. 65.2). The flag lets the organization know which cells feed such a decision; signalling it as early as the disclosure goes beyond what the Act requires. The flag on the cell is a governance signal; the text shown to the person lives in the consent document.

#Next

• Consent documents: how catalog cells are grouped into a disclosure (P-39.1 s. 8; A-2.1 s. 65).
• Consent requests: issuing an offer over catalog cells.
• Core concepts: the (category, purpose) grid and the normalized key, protocol-side.