The catalog

The catalog (menu Information and consent > Catalog) is the company's declaration of what it collects and the purposes it collects it for. The application calls each one a catalog item; this documentation also calls it a cell. The catalog 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.

#What an item declares

Beyond the category and the purpose, an item's form records:

• the basis for holding and use: consent, or a basis that does not require it (providing the requested service, a contract, a legal obligation, fraud prevention, professional contact information, and for a public body the bases specific to the Access Act). A basis other than consent requires a written justification. Only consent can be withdrawn by the person concerned themselves;
• the source of the information: from the person concerned, from third parties, or created or inferred by you;
• its sensitive nature, an automated decision or profiling, each with a bilingual text shown to the person;
• the categories of persons who have access to it within the organization;
• the retention rule that applies to it. The form does not open until a retention rule is in force: define your schedule first under Compliance > Retention;
• the products and services it belongs to, if you keep that register.

#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 request has been issued over a cell, its labels are locked against renaming. The logic is simple and protects the person concerned: if a cell a person has already received in a request could be renamed, their decision would suddenly point at something other than what they read. The lock prevents it. As long as no request covers the cell, the label stays editable. The link to your products and services stays editable even on a locked cell.

#Archiving, restoring, deleting

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. A cell nothing references yet (no document, no retention rule and no retention notice) can also be deleted; once it is referenced, only archiving remains possible.

#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 request has been issued over 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 bilingual text entered on the cell is frozen into each issued request and shown to the person beside the item it concerns.

#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.