Le sceau canonique

Raison d'etre

Le probleme a l'origine du sceau

Une responsable de la protection des renseignements personnels dit a un agent au telephone : allez-y pour le changement de traceurs. Deux semaines plus tard, le conteneur de balises est publie avec trois flux que le projet ne decrivait pas. Personne n'a menti. Le projet n'etait tout simplement lie a rien, alors « j'ai approuve ceci » est devenu un souvenir plutot qu'un fait.

Le sceau comble cet ecart. Il consigne ce qui a ete approuve dans une forme qu'un tiers peut reverifier des mois plus tard : le projet lu par la personne, les parametres executes par la machine et l'expiration qui eteint la permission. Les agents redigent; les humains signent. Le sceau rend la signature verifiable.

La specification

Sept blocs, dans cet ordre

Chaque sceau est un objet JSON forme d'exactement ces sept blocs, dans cet ordre. Un bloc manquant est une erreur, pas un raccourci : un verificateur ne peut pas controler ce qui n'y est pas.

1. stamp_metadata : l'enveloppe

schema_version vaut "0.1.0".stamp_id est un UUIDv7, de sorte que les sceaux se trient par date de creation sans faire confiance a l'horloge de quiconque. created_at_utc etexpires_at_utc sont des horodatages RFC 3339, et l'expiration est obligatoire. Une approbation sans expiration est une permission qui ne meurt jamais, et les approbations perimees ne doivent pas ressusciter.

2. action_declaration : ce qu'est l'action

consequential_action_row_id nomme l'une des douze actions lourdes de consequences, de CA-01 a CA-12, dans les termes memes de l'index. summary dit ce qui va se passer en une phrase. least_privilege_scope vautread, draft ou act : la plus petite permission dont la tache a besoin, jamais davantage.target_system_identifier nomme le systeme touche par un identifiant stable, jamais un secret d'acces ni un identifiant de point de terminaison. data_categories_touched enumere des categories, comme purchase_event ouemail_sha256, jamais des valeurs.

La regle sans exception : un sceau ne contient aucun renseignement personnel brut. Si un champ exigerait un nom, une adresse courriel ou un numero d'identification, il n'a pas sa place dans le sceau.

3. cited_authority : le droit qui encadrait le projet

corpus_version fige le corpus movahedi.ca contre lequel l'agent a redige, par exemple v2026.12.0.statute_citations enumere les dispositions, par exemple l'art. 8.1 de la Loi 25. enforcement_case_ids enumere les dossiers principaux, par exemple OPC-2023-001, l'affaire Home Depot de 2023 ou le CPVP a conclu que des donnees d'achat hors ligne parvenaient a Meta sans consentement adequat. La legislation en projet est etiquetee comme telle; cette spec ne presente jamais une disposition du projet de loi C-36 comme etant en vigueur.

4. execution_binding : les arguments exacts de la machine

execution_parameters contient les parametres que l'agent executera. Le sceau les canonise selon la RFC 8785, le schema de canonisation JSON (cles triees, aucun espace superflu, octets UTF-8), puis consigneexecution_payload_sha256, l'empreinte SHA-256 hexadecimale de ces octets. Tout elargissement des arguments apres l'approbation change l'empreinte. C'est le but recherche.

5. human_view_binding : la preuve que la personne a vu ce qui a tourne

human_draft_sha256 est le SHA-256 des octets UTF-8 du projet affiche que l'approbateur a reellement lu.bound_approval_digest_sha256 est la double liaison : le SHA-256 de la chainehuman_draft_sha256 + "|" + execution_payload_sha256 + "|" + expires_at_utc, barres verticales ASCII, sans espaces. Une seule empreinte lie le projet vu par la personne a la charge utile executee, jusqu'au moment ou la permission expire. Modifiez le projet apres la signature et l'empreinte casse. Echangez la charge utile apres la signature et l'empreinte casse. C'est le bloc qu'un verificateur controle en premier.

6. human_signoff : la parole de la personne

approver_role nomme le role, par exemple la personne responsable de la protection des renseignements personnels designee en vertu de l'art. 3.1 de la Loi 25. Des roles, pas des noms : un dossier d'approbation portable n'est pas l'endroit pour l'identite d'une personne. decision vaut approved,rejected ou modified.signed_at_utc est le moment RFC 3339 de la decision.attestation tient en une ou deux phrases, dans les propres mots de l'approbateur, disant ce qu'il croit avoir approuve. Une decision modified doit decrire la modification, sinon le sceau est invalide.

7. non_certification_disclaimer : le libelle immuable

Octet pour octet identique dans chaque sceau, dans chaque edition. Il figure ci-dessous exactement comme il doit figurer dans le JSON :

This stamp is an open evidence format for recording human approvals of agent actions. It is not legal advice, and it is not a movahedi.ca compliance certification.

Le libelle fait partie de la spec, pas de la decoration. On ne peut rien y ajouter, rien en retrancher. Et pour etre explicite sur ce que cette page ne dira jamais : aucun sceau n'est jamais decrit comme certifie, appuye ou approuve par movahedi.ca. Le sceau consigne des preuves. Il ne confere aucun statut.

Exemple concret

Un sceau fictif, de bout en bout

Café Lumen est un détaillant montréalais fictif. Son agent rédige un changement pour activer un flux d'evenements d'achat cote serveur, action lourde de consequences CA-05. La responsable lit le projet, approuve avec modification, et le sceau ci-dessous est ce qui est archive. Chaque valeur est inventee; les empreintes sont illustratives, non calculees.

{
  "stamp_metadata": {
    "schema_version": "0.1.0",
    "stamp_id": "0193a7c2-4b1e-7f9d-8c3a-2e5f6a7b8c9d",
    "created_at_utc": "2026-11-04T17:20:00Z",
    "expires_at_utc": "2027-02-02T17:20:00Z"
  },
  "action_declaration": {
    "consequential_action_row_id": "CA-05",
    "summary": "Activer un flux d'evenements d'achat cote serveur pour le detaillant fictif Café Lumen.",
    "least_privilege_scope": "draft",
    "target_system_identifier": "tag-manager:GTM-FAKE000",
    "data_categories_touched": ["purchase_event", "email_sha256"]
  },
  "cited_authority": {
    "corpus_version": "v2026.12.0",
    "statute_citations": ["Loi 25 art. 8.1"],
    "enforcement_case_ids": ["OPC-2023-001", "CAI-INTERFACES-TRUQUEES"]
  },
  "execution_binding": {
    "execution_parameters": {
      "container_id": "GTM-FAKE000",
      "feed": "evenements d'achat cote serveur",
      "destinations": ["entrepot analytique (premiere partie)"],
      "dry_run": true
    },
    "execution_payload_sha256": "fictional-digest-9f2c41aa07bd3e88c1d5f6a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5"
  },
  "human_view_binding": {
    "human_draft_sha256": "fictional-digest-1a2b3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f80",
    "bound_approval_digest_sha256": "fictional-digest-77aa88bb99cc00dd11ee22ff33445566778899aabbccddeeff00112233445566"
  },
  "human_signoff": {
    "approver_role": "responsable de la protection des renseignements personnels designe en vertu de l'art. 3.1 de la Loi 25",
    "decision": "modified",
    "signed_at_utc": "2026-11-04T17:35:00Z",
    "attestation": "Approuve avec le flux limite aux evenements d'achat pour 90 jours, puis nouvel examen. Aucune destination publicitaire sans nouveau sceau."
  },
  "non_certification_disclaimer": "This stamp is an open evidence format for recording human approvals of agent actions. It is not legal advice, and it is not a movahedi.ca compliance certification."
}

Lisez-le comme un verificateur. La portee estdraft, pas act : l'agent peut preparer le changement, mais un humain publie le conteneur. Les categories de donnees sont hachees ou de type evenementiel, jamais des valeurs brutes. L'autorite citee nomme la disposition et le dossier qui encadrent le projet. L'attestation porte la modification en mots simples : evenements d'achat seulement, 90 jours, puis nouvel examen, et aucune destination publicitaire sans nouveau sceau.

Verification

Comment verifier un sceau

1. Prenez execution_parameters, canonisez selon la RFC 8785, hachez en SHA-256. Comparez aexecution_payload_sha256.
2. Prenez les octets UTF-8 du projet lu par l'approbateur, hachez-les. Comparez a human_draft_sha256.
3. Recalculez l'empreinte liee a partir des deux empreintes et deexpires_at_utc. Comparez abound_approval_digest_sha256.
4. Verifiez que la decision est approved oumodified et que expires_at_utc est encore dans le futur.

Tout ecart, tout bloc manquant, tout sceau expire : rejet. Il n'y a pas de credit partiel dans une verification.

La reserve d'honnetete

Un sceau n'est honnete que dans la mesure du code qui le calcule. Si l'outil qui affiche le projet montre une chose a la personne et en hache une autre, le sceau ment magnifiquement. D'ou la regle : ne faites jamais confiance a des empreintes calculees par l'agent meme qui beneficie de l'approbation. L'outil de sceau les calcule localement, dans le navigateur de l'approbateur, sans que rien ne quitte la machine.

Versionnement

La v0.2 sera une nouvelle page, jamais une retouche

Les changements incompatibles seront publies comme spec v0.2 a une nouvelle adresse versionee. Cette page reste fige et verifiable pour toujours; les sceaux v0.1 n'auront jamais besoin d'etre reemis. Des precisions additives pourront y paraitre comme notes d'errata datees, marquees comme telles. Ce qui impose une v0.2 : un nouveau champ obligatoire, une formule d'empreinte modifiee ou une nouvelle valeur de decision.

Une question reste ouverte pour la v0.2 : une decisionmodified devrait-elle porter un diff lisible par machine du changement, ou l'attestation d'une ligne suffit-elle? L'attestation a gagne le debat pour la v0.1 par simplicite. Elle pourrait ne pas survivre au contact des vrais litiges.

Un sceau ne rend pas un agent digne de confiance. Il rend une approbation verifiable. Visez le second; le premier n'est pas a vendre.